[chief1983]

So, been hearing some differing opinions and was wondering if someone could shed some definitive light on this, in terms of the FSO engine currently.  Basically we've been leaving parts of our models unsealed, so they clip internally but you never see this on the outside.  It makes unwrapping easier, cuts down poly count, etc.  But, I've heard from a couple sources that once in game these models may perform worse than models that were intersected and sealed, or somesuch.  I've also heard that possible future engine enhancements will require that models are sealed meshes but I can't recall what enhancements those might be.  Anyone else care to weigh in on this?

[Black Wolf]

If SCP did that it'd break so many mods as to be utterly ridiculous. Never happen.

[Vasudan Admiral]

To my knowledge, the main risk with internally clipping models is if shadows come back into play, though how much of a problem it would be there I don't know. It seemed to work fine with the HTL fenris with Bobs old test builds, and that has a lot of open geometry - but the problems may not have been visible for whatever reason. Also keep in mind that as far as the engine is concerned each smooth group is an unsealed mesh.

I would say use intersecting geometry, BUT if you no-collide inside the model, you should be seeing very few if any internal polygons. Ie, the intersecting parts should all just be surface greebles. If you are making your model out of a jumble of huge intersecting parts then you're just asking for all kinds of horrible problems with rendering and collision detection.

So: Sealed mesh for the main hull object(s), unsealed meshes for the surface greebles and other small, easy to separate parts.

[chief1983]

Sorry Black Wolf, I should probably clarify that taking advantage of those particular features would require models to be done a certain way, it wouldn't break any existing models.

[Nuke]

i had started doing unsealed meshes when i realized how much it could cut down on polycounts, of course this was under the assumprion that the polygons themselves arent really used for collision detection, only in collision tree generation (and moi/mass computation) at model convert. then again i may be completely wrong.

[Scooby_Doo]

i had started doing unsealed meshes when i realized how much it could cut down on polycounts, of course this was under the assumprion that the polygons themselves arent really used for collision detection, only in collision tree generation (and moi/mass computation) at model convert. then again i may be completely wrong.

This is what I do... makes modelling and uvmapping a heck of a lot easier to do and saves a ton on polycount.

The only things I can see problems are shadow (which we don't have) and shinemaps (some common sense should prevent this).

[Bobboau]

sealed meshes are preferred for a few reasons, any sort of spatial analysis (like MoI calculations) rely on an assumption of sealed geometry, BSP calculation might get compromised, future endeavours like shadows, decals, geomod, etc would become complicated or impossible with unsealed meshes.  however in spite of all these things I'd say if you aren't worried about what might happen to your models in the future, knock yourself out.

[Scooby_Doo]

It would help if it was possible to do bsp cutting automatically via an app.... sorta like building Quake 1 worlds.

[Nuke]

quake levels are done by brush modeling, it assumes 2 things, there are no leaks (inside and outside must be isolated), and all objects are convex. not quite compatible with space ships (at least cool looking ones).

[Scooby_Doo]

Leaks were allowed in the bsp.exe, However vis testing didn't allow them though (always hated this part, took forever)

[Wanderer]

Also it would be very nice if modelers would use single submodel to represent the main hull of the ship. Certain things in the code (namely modeloctant stuff) assume that primary 'root' submodel is the main hull and some fragment of the main hull. This will lead to 'interesting' effects when ai tries to find target spots on the hull against which to attack.

[Scooby_Doo]

You mean have everything that isn't a dedicated subsystem attached to the root lod?  Unfortunately pcs2 seems to have a limit on the number of triangles per subsystem/lod.  It stalls out while trying to save them.  Only way I've found around it is to have a basic root lod and one or more non-tabled subsystems for the detail work.

[Wanderer]

I guess it would be 'good enough' the primary root lod would atleast resemble the actual ship in both size and shape

[chief1983]

Scooby, that sounds like detail boxes.

[Scooby_Doo]

Somewhat.... although they're not real subsystems. They lack all subsystem info (including tables and pof entries), except their name.  They're also not included in bounding boxes either, although collision detection is there.

I guess "anonymous subsystems" kinda work for a description.

[Zacam]

Not that I've posted a single model, and not that I've successfully managed anything since the old Lightwave 4 days, but in general reading, I'm not a big fan of non-closed models.

Just because it's going faster in the engine doesn't mean it's working better. Just because it's easier, doesn't make it better. At at some point, it'll bite you in the ass.

Sooner or later, the day comes when you can't hide from the things that you've done anymore.

[Vasudan Admiral]

And on that day, you'll just reconvert with a few holes plugged if you built it the way I'm talking about.
However that would be completely irrelevant if FS/PCS2 handles smoothgroups by splitting the mesh into polygon islands along the seams anyway.

Bobboau, would you be able to tell us how smoothgroups work for PCS2?

Really though there are much worse geometric boogiemen than unsealed meshes.

[Nuke]

Leaks were allowed in the bsp.exe, However vis testing didn't allow them though (always hated this part, took forever)

i musta been thinking about quake2. quake1 map compilation was less strict. you could compile lighting before compiling vis in quake 1, and if you were using one of the more modernized quake engines, like darkplaces for example, you could get by without the viz and would allow for some transparency to be implemented. q2 maps on the otherhand required a vis before you could even think about lighting. with a huge folder full of unfinished quake 1 and 2 maps, many of which just wouldnt compile, im pretty sure that freespace would just break if we tried to implement that kind of geometry abstraction system.

Also it would be very nice if modelers would use single submodel to represent the main hull of the ship. Certain things in the code (namely modeloctant stuff) assume that primary 'root' submodel is the main hull and some fragment of the main hull. This will lead to 'interesting' effects when ai tries to find target spots on the hull against which to attack.

i sometimes did this in truespace. my original version of the chaos for example, was modeled and uv mapped in ts3.2 and was made up of primitives (go figure i was using techniques i learned in quake mapping). converting the model was a nightmare, considering the tools we had back then really sucked. my solution to this problem was to pirate aquire ts 4, which had per-face uv mapping. it was hard to make work but it allowed many solid mesh models to be created (these are the classic models, many of which have since been htled). this is why my early models were very stable (also since i didnt export to other proggies for uv editing). now that i use max, i really like the attach feature. even if you dont seal stuff, you can use this to make a bunch of object one object.

Really though there are much worse geometric boogiemen than unsealed meshes.

like micropolies, bad normals, no normals, duplicate polygons and so on.

[Thaeris]

I'm actually glad to know there's a good reason to advocate the usage of sealed meshes, as most of the models I've been working on are all sealed. Of course, that means the poly count will be a bit higher, but there you go... 

[Vasudan Admiral]

If it's needlessly higher then again I'd say no just make the main hull sealed, and make as many greebles into 'floating' unsealed greebles as possible. Whether they are in the main hull object or are in a separate detail-box subobject it doesn't matter, but just making everything fully sealed for no reason might not be the best approach.