Talk:Prop Types Overview

Both Prop_Physics and Prop_Dynamic say BOTH "Optimal from a visibility standpoint, it uses the convex hull of the object. " and "From a visibility standpoint, they are assumed to be boxes." Which is it, a convex hull or box? --Kateye 20:03, 7 Oct 2006 (PDT)

Automatically emitting prop_details on a material

I have taken the liberty of moving the whole "Automatically emitting prop_details on a material" section to it's own page detailtype. I hope the reasons are fairly self evident and this won't upset anyone. It is quite a large section, containing valuable information, on quite a specific subject concerning a neat trick with prop_detail and VMT files. IMO it was too detailed to belong in "Prop Types Overview", which is already large enough. By giving it its own page, it is also easier to reference it from other articles. I'll put a link in the See Also section. I hope that's OK. --Beeswax 19:50, 3 Apr 2008 (PDT)

Well as it turned out someone had done this before, and added quite a bit to the material that used to live here. So see Detail Props now! --Beeswax 20:17, 3 Apr 2008 (PDT)

Prop Physics Question

SDK is still uploading on my computer, (Yes, still have Dial up, unlike you ;)) so, just wondering, can you use brushes as a prop physic, or do you need a prop physic override? --JeffMOD 14:24, 4 Apr 2008 (PDT)

I think you want a func_physbox. (Mind you, with a name like that who wouldn't want one ;-) --Beeswax 15:33, 4 Apr 2008 (PDT)

Thanks, Beeswax. --JeffMOD 13:55, 9 Apr 2008 (PDT)

Also, Is complexity measured in polygons of the model? 'Cause, I have an idea for a multiplayer MOD, but the apartement complex would have 150 prop physics if they were all spawned. :) And that's just for the 30 players the server would hold at max!

LOL that sounds like it would be worth a try! The short answer from me is "I don't know". AFAIK there are so many different factors that add to CPU and GPU load, it's difficult to say "keep models to x polygons". To help you with the trial-and-error approach, there's showbudget. If I were you, I would begin with func_physboxes which are quicker and easier to edit than models, although they are less efficient in game. If you can get that working well, use it as a benchmark and start replacing the brush entities with models. I don't know how much extra optimisation you would get from converting all your func_physboxes to prop_physics - but it would certainly be a lot of work to go to waste! Remember that if you like your 'mock-up' map, you'll want to add lots of lovely (expensive) textures and lighting, etc which will push up the CPU/GPU load again. So if you can't get the basic, simple textures, simple lighting etc to play smoothly with func_physboxes I would go back to the drawing board at that point. Also bear in mind that each Player in a multiplayer game uses a lot of resources. Aiming at 30 might be a little ambitious and quite difficult to playtest! Other readers might have different opinions/suggestions? --Beeswax 17:17, 9 Apr 2008 (PDT)