HL2 Map Design Question: Brush or Mesh?

    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

    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.

    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.

    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

    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.

    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

    well there is kind of something similar. There is an entity you can use to convert regular props to physics props, but as far as I know there is no was to turn it back into a static prop.

    Quote from DD

    I agree but that's beside my point. In the end you insulted BSP, so I insulted Unreal.

    Huh? Because I mearly stated an accurate prediction about the future of predominately BSP/brush based game design, you thought I was trying to slam HL or Quake? I never even mentioned one or the other, or even thought about Unreal for that matter. O_o

    Quote from DD

    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.

    Unreal culls on the node level based on how the level designer has zoned the map. Zoning is a method Unreal uses to make sure entire rooms/areas are culled at a time. The only disadvantage Unreal has compared to Quake or HL, is that it's BSP cuts can be a little messier, but it really doesn't matter seeing as how all you're going to do with it is make the basic shell of a room and then populate it with meshes. You don't have to worry about perfect BSP polys with Unreal like you do in Quake or HL. As long as you don't have any HOM's and don't try to create spheres with it, you good to go.

    If you want to see it in action, load up UT2004/03 and any indoor map and open the console and type "rmode 1" for wireframe view, then type "show staticmeshes" to turn them off, then move around and watch how the nodes cull. :wink:

    If you ever do a .t3d export of an Unreal map and open it up in notepad, you'll see that there is no BSP tree in that file, even though the brush dimensions and locations are there. Then, when you import that .t3d file into an empty workspace in UnrealEd, your brushes show up in wireframe view mode but not in 3D mode. You don't see that BSP tree because it doesn't get exported with all the rest of the map data because you'll have to do a fresh compile after you import anyway.

    Quote from DD

    Not many people know the theory behind BSP and it doesn't make you any less talented or more.

    I understand the theory. :!:

    On another topic, nice info Zaphod. Gee, look at all those meshes. :wink:

    Surely you can make the clientside physics objects similar on all machines, even if there's randomisation to the fall, all you need to do it make sure all clients have the same seed. It's never going to be perfect unless it sends some information over but... meh. There's not really a lot of place for clientside ones as players like shitting about with scenery anyway, I was playing Doom yesturday and thought it was great punting cans down the hallway with my fists of fury, if I just looked like I was punching air that'd be totally crappy!

    Oh, and even id, master of the BSP, define their own visportals now.

    I'm guessing you define visportals in Source as well.

    When the dev-tools were left in the CS:Source beta, you could use different commands to show things that can help during development of maps. One of these were to show portals, which looked like they were placed by the mapper (in doors and such)

    Ofcourse, I could be completely wrong and stupid.

    I think for terrain it depends on the scale. You can deform flat plains to make terrain or you can make make a mesh of more notable bits of terrain. You can do it either way. Clearly I don't know which way is *best*, but I've seen people do both. Doing it with deformation is alot more accessible to the average mapper though as it doesn't require modeling the terrain.

    -Dranore

    No, Hl2 uses exactly the same process as hl1 and quake 1 did for vis. The only difference is that you can create entities called area portals which you can turn on and off and fade in and out to manually close off portals. For instance you can have a door block vis when it is closed by putting an area portal inside of it that is linked to open and close with the door, or have a window that only opens up to viz when you get close enough for the portal inside of it to fade out.

    Terrain, or displacement meshes start out life as a normal brush. Once you select one or more faces of the brush you can turn it into a displacement mesh, choosing from a number of preset resolutions. You put a bunch terrain pieces together, with the edges of them them lining up perfectly, and then you can "sew" them together, and use a tool to lower/raise smooth/add noise. Terrain is pretty cheap, probably just a little more expensive than world geometry. It still however adds to your wpoly count, and adheres to the same rules regarding performance.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login