UT2k3 Limits and optimising.

[RevBillyG]

Well, I'm happily editing away and throwing all sorts of meshes and BSP into maps annd generally enjoying the engine. However, seeing that my pc isn't exactly a typical system, it's hard to say how well a map will run across a whole range of cpu/gfx setups.

I remember that in UT the general standard was to keep the polycount below 250 in CTF and below 90 in DM (although as time went on and PCs got faster, the counts were raised).

What sorts of limits am I looking for in UT2k3? I know about stat game, rmode etc but I'm not sure exactly how to use that information to help optimize a level.

Any tips?

 

[]yS[concrete]

yea once i get the game i can test it out on my craptastic machine

if itll run well on this you should be fine

 

[TheSpoonDog]

Beta test

 

[Birelli]

Because of the large differences between BSP/Static Meshes, it's kind of hard to tell. From my experience I wouldn't go over 4,000 mesh triangles being rendered at once, as that is the threshhold at which it starts to become unplayable for me, and I've got almost literally the min system specs for UT2003 (750mhz PIII and GeF2). With BSP though I'm not sure what the relationship is between BSP polys and mesh triangles in terms of playability.

 

[Wormbo]

From what I heard, the BSP polycount shouldn't be much higher than in UT because BSP needs a lot of time to render.
When using static meshes the ideal polycount depends on how often you reuse a static mesh. Multiple copies of the same mesh produce a better framerate than a lot of different static meshes with aproximately the same polycount.
The Unreal Wiki and the BUF Mapping forum should provide you with more information.

 

[Mychaeel]

From what I heard, the BSP polycount shouldn't be much higher than in UT because BSP needs a lot of time to render.

That's only partly true because BSP geometry in UT2003 has one distinct property less than it had in Unreal Tournament: It's not involved in occlusion calculations anymore (except for zoning, but that's an entirely different matter), so that saves quite a bit of performance when dealing with BSP.

However, BSP polygons still need to be sent to the video card one by one every frame the same way they used to in older engine versions (unlike static meshes that are cached in video memory), so while you'll likely be able to use more BSP geometry on the screen at any time, you don't gain as much as by using static meshes.

Also keep in mind that all BSP polygons facing you in your field of view in the visible zone(s) are drawn in UT2003 (due to the missing BSP occlusion), so the advantage of being able to draw more BSP polygons per frame is somewhat relativized by the fact that more of them are drawn than those you can actually see.

 

[Mulch_D]

Well I can also help test on a low standard machine, you know my e-mail.

 

[Trueblood]

Why not have alook at ready made levels Original and Custom? find afew bigish maps on a site... the people that "test" it on the sites will tell you of how much its laggs, compare to your system. Then use the UEd to see what the creator used and how much 'polycount' was used.
Probaby not explained very well but, i not long got out of bed!