HL2 Map Design Question: Brush or Mesh?

[Dranore]

Izuno, thanks for the pertinent reply. Much appreciated.

I imagine you could do an entire map in static meshes with matched collision. Is it a good idea? Well if HL2 does in fact load all meshes to the video card for processing and storage, then it seems not... depending on your video card I guess. If you're loading an entire map into the card, obviously not all at once... but at least everything you see, that's probably not how HL2 is optimized to run... and could end up slowing everything down... from this discussion it strikes me that anything other than simple box geometry makes a good canidate for meshes and should probably be used as such.

I'm probably the most n00b person in this discussion though... so I could quite easily be wrong. hehe...

-Dranore

[DD]

I'm not saying BSP will disappear completely. I'm just saying that meshes will become much more predominate in maps than BSP.

Me too.

Lol. I'm assuming you're trying to slam Unreal, which is real BSP. It's culling methods and CSG are just a little different than your beloved Halflife. What is the correct culling method? Just because it's done differently doesn't mean it's done wrong. When you're creating an engine you implement the best culling methods for that type of engine. Just because it's not what your used to doesn't make it wrong.

Yes I'm slaming unreal for calling BSP when it is not a Binary Space Tree. It's not what half-life defined, it's not what quake defined, it's a programming theory used with other methods to help cull out what is and what isn't in view.

A fair balance of the two, weighted towards mesh of course, allows for massive indoor areas with tons of detail that artist in max couldn't do even near as fast.

Eh? I think somehow you just contradicted yourself in the same sentence. Nearly as fast as what? A highly detailed indoor area that is mostly mesh would require an artist. O_o

Let me be more specific, or let me word it better. Obviously the artist can create tons of smaller objects, but when it comes to create the simple halls, rooms, the SHELL, it simply takes longer and the cost is little, mostly less in indoor areas.

Believing one or the other is a wrong approach entirely. You do what's best for the game. You pick the best tech for the situations.

I agree but that's beside my point. In the end you insulted BSP, so I insulted Unreal. I believe as consoles become more and more like PC's, as they are, we'll see more and more engines using BSP or form of, not heavily, but still used and NOT going exstinct.

[DD]

http://www.cs.buffalo.edu/~whitley/research/graphics/bsp/tutorial.html

This was the first, or second result on google. Unreal doesn't not have partions or generate partions to decide what to cull automatically. You have to manually zone everything which usually results in different partitions. All partitions are equal in a BSPT.

[zaphod]

to take a break from the e-penis tech knowledge battle and answer the original question specifically about the source level creation process:

things that need to block vis, and very simple primitive shapes = brush

anything else = model

basically, your scene is going to be made up of 4 elements:

standard world geometry: this is the stuff that calculates visibility and chops shit up accordingly, like you are used to in hl1. This is what you build the basics of your map with, so that the BSP engine can do it's work. It is very cheap to render world polies, though they get more and more expensive as the number of world polies climbs to around 4k. A level with 2k world polies could run twice as fast as a level with 4k world polies. This number is still very important for performance issues. And having as few world polies as possible is still something you have to consider when optimizing your map.

func_detail: func_details are world geometry that you figure is not neccesary to the vis process. for example, a crate sitting on the floor made out of world geometry will chop up the floor accordingly, and since you probably don't need the engine to be calculating whats visible from each side of the tiny crate, you would make it into a func_detail. A func detail is the exact same as regular world geometry, except for the fact it gets taken out of the map when the map gets cut up for vis purposes. Once in the final bsp, it is just as cheap as regular world geometry only it does not cut up any surround faces.

brush based entities: things like doors and such, these aren't particularly expensive unless you put lots and lots of them in your level

models: model polies are cheap cheap cheap. Where a general limit for world polies can be 4k, you can have as many as 75k model polies in a scene before you start noticing a substantial slowdown. This number is kind of a double edged sword however. While rendering model polies is cheap, calculating things for the actual model entity gets more and more expensive the more seperate instances you have in view at once. For example, having 4 vases sitting on a shelf would be 4 times as expensive as having one model of 4 vases sitting on a shelf. The engine have to calculate colission and such for every seperate model entity ever frame, so grouping models where possible has been essential to optimize performance on levels with lots of seperate model entities. This of course is a tradeoff against your memory expense, where you might only have to load one model that you use multiple times in your level, versus having multiple grouped versions of the singular model.

There are also different flavors of entities you can use to put models in the game that have varying levels of expense: here they are listed from cheapest to most expensive

prop_detail: this is the cheapest way to put a model in the game, becuase it calculates one lighting value at compile time and cannot change. This is also usually coupled with the model fading in and out of view depending on distance This is used for things like dynamically spwaning grass and debris on terrain, or trash on the ground that fades in and out of view.

prop_static: this is what you will use for most structural models, it's the cheapest entitiy to use next to prop_details. A static prop can take dynamic lighting, but thats about it. You put it in your scene and it's going to stay there, you cannot turn it off or on or effect it through scripting in any way.

prop_dynamic: a prop dynamic is like a prop static only that it can be effected through scripting and other player interactions. You can swap out the texture on it via scripting, hide it, unhide it, break it, parent it, etc.

prop_physics: this is probably the most expensive entity you can put in your level. Depending on what else is rendering in your scene physics objects can cause a big hit if you put a lot of them in your scene.

[DD]

BTW Tom is a very talented level designer, he is able to create mood which I have extreme trouble to achieve. Half his unreal work is unreleased but I've seen it and it looks great, if only he would release it. Not many people know the theory behind BSP and it doesn't make you any less talented or more. It doesn't mean you do not have a strong understanding of the technical side of level design either, I think you do.

[st0lve]

Interessting.

[Fullauto]

Useful stuff there Zaphod.

[rockdude86]

thank you zaphod your post made me understand how i can get my map working properly you should send the post to the valve erc collective i believe you would make a lot people happy with it. this is faremost the most usefull thing i have ever read on a forum! once again thank you i will admire you forever

[FrieChamp]

Thanks a lot for the detailed explanation Zaphod.

I was about to ask what experiences you have with prop_physics in muliplayer maps till I realized that Bloodlines doesn't have multiplayer...or does it? Something like coop?

Because when you activate physics for objects in FarCry multiplayer maps, your performance will go doooooown...but that is mostly caused due to the massive amount of data which needs to be sent, so I was wondering if HL2 got some kick-ass netcode to handle that.

[Pericolos0]

cs:source has a lot of stuff like barrels etc with physics.

Don't know if they cause lag tho but i havnt heard much ppl complain

[zaphod]

there are two types of physics props for multiplayer, one that is client side, and one that is server side. The client side one only simulates physics on on your personal machine, so people will be wondering what the hell you are doing when you are shooting a soda can or whatever becuase they will still see it sitting in it's original position. The server side ones are feed to everyone else on the server so it is always in the same position for everybody, these can cause a bit of lag which you might have noticed in cs:source. I don't really know the specifics of how many or what not you can get away with, macman would be better able to answer that.

[Dranore]

Thanks for the relies. I appreciate the detailed response Zaphod. I have another question for you all. Is it possible to enable and disable physics simulations on the fly when the player interacts with it? It seems to me that would be the best way to deal with it... that way any object that was capable of being effected by physics could exist in a scene in quantity without crunching up CPU and bandwidth. If not by default would it be feasible/possible to impliment that sort of function? Perhaps that's beyound the scope of what you mappers know about. I figured I'd ask anyways.

BTW, you have prop_dynamic twice, once before and after prop_physics... was that a mistake?

I'm leading a mod as well as mapping so this information is extremely useful... we've been hypothesizing some things and it's really guessing as there isn't much official info out there. :\ Thanks again for the info and time.

-Dranore

[zaphod]

oops, fixed that mistake in my previous post. There is no way to "turn off" physics simulations while they are at rest, otherwise they would never be awake to take the first impact that starts a new physics simulation. Physics props are constantly alive and able to be interacted with.

[Izuno]

Like I said, I defer to Zaphod as a good source on Source.

....pun intended.

gg Zaph!

[Dranore]

That makes sense to a certain degree, but in the same reguard they could be "asleep" as it were, and as soon as the player triggers an interaction with it, bring it to life? I dunno again... this kinda getting OT... but it seems logical to me... I guess it depends on how the enging monitors the entities... whether ist's constantly checking any phys_entities that are loaded for changes or whether it's just waiting for a condition to trigger it's physics reaction.

-Dranore