models or csg?

[Mad Danny]

I have a castle with lots of nice curvy arches and stuff and the poly count is creeping up rather higher than I'd like.. now for the sake of optimisation I might do the 'models with invisible csg collision' method but I was wondering, what sort of performance difference would you get between 1. making the higher poly items models and using invisible csg for collision and 2. using passable csg (ie. non-colliding) and an invisible lower-poly version for collision - basically the difference between a model and a non-collision csg.

in case anyone was wondering the specific case involves several turrets with spiral staircases and rows of arches along the walls - kinda painful in a large outdoors environment..

[toastar]

1) no shadows (can be remedied), but it can handle about 10 times the triangles
2) a light performance increase in third person

both wont recieve simple model shadows

[child]

Well, I would go for making the higher poly items models and using invisible csg for collision.
Models look a lot better and if you bake the shadows into the textures you get really good results. Additionally brushes/csg dont support smoothshading, models can have both smooth and flatshading.

Also, models are rendered a lot faster than csg, so you would save some needed ressources in order to keep your map playable.

[Mad Danny]

models it is then.. although texturing'll be a pain since it's a rather large turret :s
but I can use my cheap trick of mapping every step to one little piece of texture :p

what exactly do you mean by 'texture baking' - I think I know the idea but not sure specifically

and is there any practical way to get shadows displaying on an invisible surface by any chance?

[--Fragman--]

Nah, dont htink that's possible...however texture baking is rendering shadows on the texture in your modelling prog, using similar lighting settings.

[Mad Danny]

Nah, dont htink that's possible...however texture baking is rendering shadows on the texture in your modelling prog, using similar lighting settings.

that's what I thought.. hmm.. does SS project shadows on walls or just on the floor? the polygon shadows are single-surface aren't they?

'cause I could always try getting away with just making some of the main floors csg for player shadows and baking for the walls with lights on them

[Dead Eye]

models are highly over-rated. you should only use them as recommended... as Croteam does in their maps... for objects that don't need per-poly collision detection, things that are relatively high poly and repetative in the game like torches and statues and stuff. the speed increase from models comes from not needing to do collision detection on all polys, so using models and then invisible polys for collision really doesn't save you anything. in fact i think it's a waste because it takes twice as much memory needing two polys for everything. if you need more complicated primitives than SEd has to offer, consider importing geometry from say lightwave or maya and then hit the + key to add it to the current layer. works like a charm. for turrets with spiral staircases and rows of arches that's what mip-brushing is for.

[toastar]

models are highly over-rated. you should only use them as recommended... as Croteam does in their maps... for objects that don't need per-poly collision detection, things that are relatively high poly and repetative in the game like torches and statues and stuff. the speed increase from models comes from not needing to do collision detection on all polys, so using models and then invisible polys for collision really doesn't save you anything. in fact i think it's a waste because it takes twice as much memory needing two polys for everything. if you need more complicated primitives than SEd has to offer, consider importing geometry from say lightwave or maya and then hit the + key to add it to the current layer. works like a charm.

even so, performance goes up by an incredible amount and different effects. uv map styles, different shaders, and animations can be acheieved. use models? why not?

[Dead Eye]

yeah toastar, as demonstrated from your levels, models make great eye candy :P. but for danny's case is it really needed for staircases and arches? these are relatively plain things that don't need all those fancy SKA effects.

[toastar]

depends how many there are...
labyrinth could have converted to models and been incredible AND playable

its also a finalization thing. if you get bad performance you can always switch to models (which allows for more things to add as well)

ps
thanks for the compliment :)

[Mad Danny]

I was considering working with mip brushes now that I recently learned how to do them properly (I think)

there's a couple of other things I was wondering about.. what exactly is sectoring or zoning for or is it only for determining atmosphere/water/gravity zones etc.? does it have any relation to visibilty or such?

I'm also currently reading up on setting detail/occluding polygons which should help a bit - am I right in assuming I just switch all really small polys to 'detail' and all really big ones to 'occluder' or thereabouts?

And one thing I'd been wondering about brush mipping.. since it's actual geometry how does it handle collisions? I mean if you have a platform with a monster standing on it and the visible mip brush doesn't have the platform does it mess with collisions or are collisions done invisibly based on the original architecture?

If there's no collision bugs then I can just slope the stairs when further away than a few metres and remove them completely if you're outdoors!

One last thing.. how do mip brushes take shadows? - does each mip have it's own shadowmap or what?

P.S. do 'shoot through' polys allow projectiles through or just the bullet object (or is this more a 'coding' question? since as far as I've seen only the non-projectile bullets pass through which will mess things up for the mod I'm working on where my friend is making the bullets into projectiles for bullet-time

P.P.S. I know that it's recommended to use a binary grid rather than decadic but what about for geometry created in something like 3DS, which uses a decadic grid? does it mean I won't be able to line stuff up so precisely or such with the binary grid? and if all geometry is made in such an external program what graphic glitches would likely occur using a decadic rather than binary grid?

[--Fragman--]

Well, it depends on how small your architecture is...importing everything shouldn't give you a problem at all, but if you want to mess with it in SEd you shouldn't use smaller distances then 0.25 or so, maybe 0.125, dunno...
Shoot through blocks bullets, not projectiles, might be changeable in code, dunno.
Check the help file and www.seriousengine.com for explanations on zoning/sectoring, mip brushes, detail and occluder flags etc...

[child]

@ Dead Eye : You shouldn't use skamodels coz of the fancyness factor, you should use them to save ressources in the first place. They save ressources, thats a fact.
Also models dont need multipass rendering cycles to look good like most csg polys with multiple filled texture-layers.
Did I already cover smoothshading ? oh I already did ;)

@ Mad Danny : Sectors are essential ! the S-engine is a portal engine, this means if you have a map with several sectors the engine makes sure it will only render sectors which are visible to you. A lot of sectors will give you better fps-results. Anyway, to see what stuff gets rendered even though you can't see it, just playtest in the editor with Viewmode 8(press 8 on the numblock) and you see the wireframe of the polys that get rendered. Note that sectors wont get rendered once you can't see into them.

[Mad Danny]

Sectors are essential ! the S-engine is a portal engine, this means if you have a map with several sectors the engine makes sure it will only render sectors which are visible to you. A lot of sectors will give you better fps-results. Anyway, to see what stuff gets rendered even though you can't see it, just playtest in the editor with Viewmode 8(press 8 on the numblock) and you see the wireframe of the polys that get rendered. Note that sectors wont get rendered once you can't see into them.

so I should make things like my main corridors and turret interiors sectors? how would I do this using 3DS imports? - would I just like make a plane that blocks doorways or something? or do I make my rooms sealed with invisible polys? how do I manually define all the sectors when everything is imported?

Shoot through blocks bullets, not projectiles, might be changeable in code, dunno.

nup - blocks projectiles - bullets are invisible line collision items - all shots with models though (ie. projectiles) treat it as a colliding surface