[Vasudan Admiral]

Umm, massive hack for just this particular case, but might you be able to make the glass polygons on the ring of that ship part of detail0, and then have all the opaque parts of the geometry (ring structure, window struts etc) as a rotating subobject? So the ring rotates but the glass stays in place?

You'd have to make sure the ring could not be destroyed mind you, or that would look really awkward.

As for the render sorting issue, it's even more complex than that! Assuming this is still the case in the engine, here's what can happen with transparency also, when the iceni is moved vertically from above to below the hatshepsut:






As you can see, the second pic is basically an optical illusion, only made possible by the FS2 rendering engine.
(I know it's done in Fred here, but it happens the same way in-game)

[FUBAR-BDHR]

The ring being detail0 hack has been though of but still has issues.  For one it doesn't work with inside and outside glass. So your hierarchy ends up like this:

Detail0 (outside glass)
->Inside glass
--->hull
----->rotation

Even with that there are parts that should be seen that aren't.  Also one day we will most likely need to blow out a section (it happens in the show) so yea the rotation really needs to be subsystems. 

[newman]

Even if we have to keep relying on sorting, making it so that transparency works even if transparent object isn't detail0 would be an improvement. Right now, it has to be detail0, and the way it should work to my understanding is, anything below it in hierarchy should be seen through it - which it isn't.
But ideally, we want to be able to have things like multiple domes with additive transparency when looking through all of them, meaning getting rid of depending on hierarchy in the pof.

[Nuke]

what if we take the main hull object, and replace all its textures with invisible, then to that model attach a copy as a submodel with textures intact. we would make this subsystem non-targetable, non-collidable and give it no hitpoints. you could also use the invisible model as a less complex collision mesh. now the transparency in those submodels are at the same level. if submodels are depth-sorted back to front, and transparent textures are at the bottom of the texture list. it should work. it would at least be worth a test. would be something like:

->hull (invisible textures with collide_invisible)
-->fakehull (textured, no_collide)
-->ring (transparent textures last)

[Angelus]

[daydream] if we only could manually set an override to render a subobject first on specific models only...[/daydream]

[Spicious]

Fiddling with submodel orderings won't help with the ring model. Looking through from the outside to the inside and back outside requires rendering the inside glass before the outside glass. But looking out from inside the ring into the ring elsewhere requires rendering the outside glass before the inside glass.

[Nuke]

a big transparent toroid has got to be one of the hardest things render correctly, especially when theres stuff in the middle of it. i have doubts that the idea expressed in my last post would work for that. but it might work for something like the agro ship.

[newman]

A bit of an update on this - I had an idea on how to make the botanical cruiser's multiple domes work, so I made a very quick pof to test it: we make the domes separate ships and dock them to the cruiser. Here's a test shot:



It actually works great. Which makes me wonder one thing - if it works well with separate ships, why can't it work on subsystems on a single one?

[Nuke]

because of the archaic way the engine sorts things?

[Spicious]

How thoroughly have you tested it?

[newman]

I just put a bunch of domes into fred, saved a mission, and ran it. Everything seemed fine. Guess I might try adding a few other ships and see if I can see them through all the domes (though if I see the domes through domes, which are other ships by themselves, I really should).

[Nuke]

if it turns out this works, maybe something along the lines of a $default cargo: tag is called for. it would have a child tags for +dockpoint: and +cargo: and any time that ship is created or placed in fred it would come with that cargo pre-installed. maybe also add a feature where the game treats it as a subsystem of the parent and puts local turrets and whatnot under the control of the parent ship. its not quite indended as a way to sneak around the transparency issues. but it would allow for stuff like modular turrets and other subsystems, also subsystems with transparency. of course the alternative is to support proper blending on subobjects.

[newman]

Sounds like a great idea to me. I can think of several instances where this would be extremely useful in Diaspora, pretty sure other projects would find plenty of uses for that too.

[swashmebuckle]

Yeah, that would be good for SWC on the freighters from the X-wing games that almost always are seen with their cargo containers.

[Topgun]

Why can't the engine render things in order of their z value?

[Iss Mneur]

Why can't the engine render things in order of their z value?

IIRC, that is the problem, the engine doesn't deal with z value.  It just enumerate the list of objects and renders anything that is "visible".

As for why multiple ships work. Because every ship is a different object, its rendering call gets a different position, thus the engine just pushed the problem to the graphics card.  Because the graphics card is told the object's position in space, the graphics card then uses it own z buffering and ordering (calculated based on the position of the object) to figure out the transparency.

[newman]

Don't suppose that info could be used to make it work on subsytems, then? Anyway, bottom line, it works.
I think Nuke's suggestion has a lot of merit. Hopefully one of the SCP wizards can make it happen..

[Sushi]

Why can't the engine render things in order of their z value?

IIRC, that is the problem, the engine doesn't deal with z value.  It just enumerate the list of objects and renders anything that is "visible".

As for why multiple ships work. Because every ship is a different object, its rendering call gets a different position, thus the engine just pushed the problem to the graphics card.  Because the graphics card is told the object's position in space, the graphics card then uses it own z buffering and ordering (calculated based on the position of the object) to figure out the transparency.

Sounds like it's probably possible to update the renderer so that this works for subobjects, then.

[Iss Mneur]

Sounds like it's probably possible to update the renderer so that this works for subobjects, then.

It probably is, but I don't know the details to be able to say definitively.  Nor could I say what the potential problems could be.

[DaBrain]

Well... I consider the cargo trick a hack or work-around.

It's neither a clean nor an efficient solution.


As long as it is the only solution, I won't discourage anybody from using it though.