Your thoughts about Static Mesh/BSP balance?

[Stefander]

I've been part of the Unreal community for quite some time now, and I've finally decided to get into mapping with Unreal Tournament 3 when it ships for expanding my Game Design portfolio. When I downloaded the Unreal 3 beta demo yesterday, I saw a lot of things that made me start to think about what to leave BSP and what to use as a static mesh, as there's a lot of complicated geometry and UVing involved (and ofcourse the seams). While I've done a decent lot of UT2004 mapping and consider myself to be an advanced level artist and 3D modeler, I still can't seem to find the right balance for using static meshes in a level, I tend to make everything in an external package and then import it into UnrealEd (I'm still way too used to the Halo CE and Halo Vista content importing pipeline where all the geometry is basically one big static mesh when compared to the Unreal engine).

Anyone wanting to share their thoughts and help me out a bit with the thought process for seperating the BSP and static meshes? Would really appreciate it, maybe it'll help some other people out in the process as well :D

- Stefan Wijnker

[Caravaggio]

At this point i think it's safe just to map large flat floor and walls with bsp. If you got a hold of roboblitz and opened a map with the editor it came with, you could see that in some places there wasn't much there, even fairly simply looking walls were a SM placed over and over again.

[Dangerdog]

Should help a little with UT3 as the bsp is now additive or subtractive, the static meshes are much more important to detailing but as you can see from the demo they now play a greater part in actual gameplay too.

[porcup!ne]

im by no means a mapping expert, but i've got a few under my belt in utk4. i believe that in ut3, you want to use bsp as sparingly as possible.
the engine is optimized to render static mesh. GPUs render static mesh much faster that BSP. Also, repeating the same static mesh throughout a map cuts down on rendering workload.
bsp(binary space partition) has always been additive or subtractive. it's binary, meaning one of 2 possibilities. on or off if you will. the player moves in subtracted space, and is blocked by added space.

[cydonian]

Interesting. I had no idea UT3 favors static mesh over BSP. Is this documented somewhere?

[Sharpfish]

bsp(binary space partition) has always been additive or subtractive. it's binary, meaning one of 2 possibilities. on or off if you will. the player moves in subtracted space, and is blocked by added space.

He meant the starting space. It was previously always subtractive to start and you'd carve it out and add brushes in that carved out space. Now you have the option to start with a full block and carve out (as before) or an empty space and add in (each is more useful for it's own reason, outdoors / indoors etc).

In 2k3/2k4 I used BSP *ONLY* for hard geometry, floors/walls/ceilings - the 'shell' of the level, then detailing and some hard geo was static meshes I'd make outside of UED. With the new engine there will be more of that 'outside of UED' going on but as I hear most stuff is now self occluding (per poly or per mesh I don't yet know) meshes are going to be more heavily used for 'basics'. I don't know how much BSP is optimised for in the new engine but I thought they said it would be less than optimal so use it only where needed (shell work/floorplan or even just as one space with your meshes in).

When i've had the ed for a week i'll know more of course, the Roboblitz editor was fun to dabble with but I couldn't take it seriously - too many bugs and I was too busy anyway so I never found out too much.

[Caravaggio]

Interesting. I had no idea UT3 favors static mesh over BSP. Is this documented somewhere?
Kind of. If you look at the green wireframe shot on the tech page I'm fairly sure everything there except for the floor is a SM. And probably that too since there's only one color of wire there...
http://www.unrealtechnology.com/html/technology/ue30.shtml

[CrysAk]

i've been using Unreal for 9 yrs now, and alot of it comes down to common sense (after you know the propeties of meshs/BSP)

main rule..

large flat surfaces/subtractive spaces - BSP (BSP also culls)
detail/complicated rounder objects/smooth - mesh

try to keep BSP as *CLEAN* as possible (snap to grid, very little/no overlap, esp at strange angles, and you'l be fine
Lighting is alot easier on BSP also, esp if your new to the engine

in short .
BSP should be the main structure/skelleton of the level, with meshs decorating it

at least thats what i have always gone off and has always worked well, dont take this as gospel though, theres exceptions for everything ^^

hope that helps a little


[edit]

also, if you dont know already, BSP is an invaluable tool when it comes to greyboxing (your first attemp at the level in the editor) to playtest and improve before decorating and making look pretty ^^

[DGUnreal]

The proper answer is "it depends".

Don't even bother attempting to relate UE3 to UE2.5 (UT2004), pretty much the entire occlusion and rendering system is different.

Whether you use CSG (technically correct) versus StaticMeshes depends on a large number of things.
StaticMeshes are normally more flexible, CSG is usually quicker to prototype.
You are best off waiting until UDN3 goes public and then read up on how mapping in UE3 works. And if you think knowing UT2004 mapping means that you will be able to map in UT3 easily, it doesn't. The differences in the engine are significant.

UE3 has been designed so that StaticMeshes render faster and lightmap better than CSG. Certain CSG designs also have shadowmap issues.

For outdoor maps such as you usually find in WAR, CSG may not be used much, except for block-building areas if relevant, and areas where it can be applied as a large occluder surface.
For indoor maps, it will be used more often, for creating the basic room-corridor layout, and it may even be completely covered over by smeshes as it will still be used as a main occluder surface.

[CrysAk]

if you think knowing UT2004 mapping means that you will be able to map in UT3 easily, it doesn't. The differences in the engine are significant.


dont scare them off lol

its not that differnt, just more features.. .. alot.. more features actualy now i think about it

but the fundementals are the same, any proficeent 2k4 designer wont find it to be an issue, some things as you mentioned just work a little different/better now

im sure there will be an extremely helpfull UDN section when its release (im guessing... ...)

[DGUnreal]

dont scare them off lol


UDN3 does have a lot of information.

However, many areas such as the Materials, Terrain, Lighting settings, and Occlusion are going to be difficult for most community mappers.

A large percentage of UT2004 community mappers have difficulties with something simple like StaticMesh Type 1 collision and the UseSimple*Collision properties... well UT3 adds a lot of more complex stuff than that.

I'm not stating that working with CSG or placing StaticMeshes in UnrealEd is going to be more difficult necessarily, just that UT2004 was considerably more forgiving for map assets that were configured incorrectly. With UE3 you must get things correct or you are going to have map problems.

[Oblivionbringa]

I prefer doing my maps 100% out of static meshes, and I blockout maps with static meshes. Epic however does use csg in their maps, as you will see in the GOW and ut3 maps, I would say they use it quite a lot.

Basically the only thing I see csg being good for is blocking out maps, it doesnt really have any advantages over static meshes ( as long as you have 3ds max, or maya ). Also ue3's occlusion system is a fully automatic per pixel solution. So anything can act as an occluder, meaning you dont need to setup csg just for the purpose of occlusion.

However for those of you who want to use csg regardless ( or have no choice ), the good news is that the bsp editing tools have been vastly improved, so creating csg is alot easier now.

[Oblivionbringa]

I agree with DGUnreal, except for the bit about occlusion. Occlusion in ue3 is very easy compared to previous unreal engines. However everything else he mentioned, especially the lighting system is all very complicated and will take a long while to learn. In fact the lighting system is the most difficult of them all, oh and dont even get me started on the nightmare that is cascade. ;)

[-=¤willhaven¤=-]

Quick answer: use both but don't use too much of either one. ;)

[Stefander]

Quick answer: use both but don't use too much of either one. ;)

Good enough ;) But as Oblivionbringa said, there's also no problem with using everything as a static mesh in U3 anymore, which is great to hear for people like me who aren't used to it being any other way ;)

[KewlAzMe]

I'm no mapper but lately I've been told that people can make large chunks for maps in 3dsmax or maya in 1/10 of the time it took them to map in UED with bsp. So depending on your fluency in modeling programs you might want to try that. BSP i think is being phased out from main architecture, using it only for volumes and zoning and quick/lastminute/touchups

[DGUnreal]

I have used ue3 professionally for over a year and a half now, and we dont use csg at all.

Also ue3's occlusion system is a fully automatic per pixel solution. So anything can act as an occluder, meaning you dont need to setup csg just for the purpose of occlusion.


I have been using UE3 for almost two years myself. :p
I'm sure Phil beats us both out on that one though. ;)

Like yourself I also prefer using SMeshes, often for prototyping a level as well. A few primitive SMesh shapes are quick to duplicate and scale and move around, no builds required.

For the best performance you do want to keep all scene objects to only those that you need and not insert unnecessary objects to render, so you wouldn't add CSG if it wasn't required in your design.
However, my comment on occlusion was not meant to be taken as "you must use CSG for occlusion", since either CSG or SMeshes can act as occluders.
UE3's occlusion does use a convex test based on the bounding box of each object. CSG will occlude per surface.
So in the case of a design of an indoor room-corridor map where each of the walls were constructed of fifty small SMesh objects, a performance gain should always be realized by having CSG "subwall" behind the actual wall SMeshes and setting the SMeshes to bUseAsOccluder=False.
In the engine, the previous frame's occlusion results are used to determine which primitives to use as occluders for the current frame. If the single CSG surface that is used as the current occluder remains as the occluder and the smaller SMesh wall pieces are never used/tested for occlusion (due to bUseAsOccluder=False), a performance increase should always be realized.
FYI: I have profiled this on builds up to QA_Sept for both scene frustum SMesh tri counts and for framerate and it does work.

From Andrew (Epic I assume): "Disabling it [bUseAsOccluder] for primitives which aren't important occluders may be performance win."

Normally bUseAsOccluder is used to prevent occlusion popping and fast moving objects from being tested.

I don't mean this as a negative connotation, I noticed that your post count is 4 at this time. If you search back through the Epic and BeyondUnreal forums you should find that I am a profiling test dweeb with the Unreal Engine... ;)
So if you want something tested to see how it works, or if it works, or if it is broken, or if it can be broken, send it to me. :D

[Sharpfish]

To the origingal poster - play the UT3 demo (Shangri la is a good detailed example) and bring up the console and type 'show bsp' and 'show staticmeshes' to toggle either on and off, then you can see first hand how Epic balanced it (don't worry, collision is still there so you don't fall through the floor) from what I can see Shangri LA is mostly Static meshes + terrain with some underlying BSP as expected (the bare shell of the level). In fact it's a very similar ratio to UT2k4 maps on first inspection!

Also depending on what kind of map you are going for you are generally going to use a mix like ShangriLa *OR* rely more heavily purely on statics (level designed mostly in Max or whatever), even some 2k3 custom maps were large static meshes when the map was trying to be 'artistic' or 'unique' and very little BSP. Personally I will be doing as much as possible in a 3D editor because it's just a lot quicker when working on unique/detailed stuff and allows your imagination to flow more/quicker. I will use BSP sparingly but again it depends on the type of maps you are making.

as for performance > you have to get your hands dirty and get hands on experience (regardless of editor or engine version), I used to spend hours optimising my maps (moreso the latter ones) and in general they ran well according to feedback, there was a lot of stuff to consider (zones, antiportals, mesh placement, overdraw) and now, from what DGUnreal is saying it seems a lot simpler (how it should have worked previously; but we had a 'hacky' system instead that was transitonary towards static meshes being used properly - same goes for 'hacky' lighting) but thought should still be used and the testing still applies!

[chiefwhosm]

type 'show bsp' and 'show staticmeshes' to toggle either on and off
Having just used that in Suspense I have to admit I was quite surprised at where the bsp was used. Especially the roads of the bridge itself, I suspected those to be static meshes rather than bsp because of the way ragdolls can fall through the road to the water beneath.
Pity you get all the HOM effects with static meshes disabled, guess that's the new additive mapping with the sky being a static mesh causing that.

[DGUnreal]

as for performance > you have to get your hands dirty and get hands on experience (regardless of editor or engine version), I used to spend hours optimising my maps (moreso the latter ones) and in general they ran well according to feedback, there was a lot of stuff to consider (zones, antiportals, mesh placement, overdraw) and now, from what DGUnreal is saying it seems a lot simpler (how it should have worked previously; but we had a 'hacky' system instead that was transitonary towards static meshes being used properly - same goes for 'hacky' lighting) but thought should still be used and the testing still applies!


Yeah, no more AntiPortals, ZonePortals, etc., so less work in that area of mapping. CSG and StaticMeshes both cull automatically (for the most part). There is still optimizations required though, and too many properties IMHO :p.
I also find the editor noticeably slower to work in, regarding productivity.

[Sharpfish]

Pity you get all the HOM effects with static meshes disabled, guess that's the new additive mapping with the sky being a static mesh causing that.

That's the backbuffer (same in 2k4) not being cleared. They don't clear it as its quicker to not do it needlessly, and normally in any map you would have something blocking the 'view' of the backbuffer (previously skyboxes), so when you turn something off that was the furthest 'z point' away and nothing else is in front you get whatever moves across it left drawn (not cleared). The same happens in older UT games too if there is nothing there, turn BSP off in a typical older map to remove skybox and see it.