[Nuke]

i think the submodels get rendered on a different pass than the hull model. so it does all the rendering for the subsystems in who knows what order, then it does the hull (or maybe the hull comes first). what it should do is sort all the submodels in reverse z order, rendering the hull at its place in line and not after (or before) the submodels. at least thats how i understand the problem.

[Galemp]

Trick, hack, or workaround, it's still a brilliant solution and an excellent use of lateral thinking. Great job!

[ION3]

In this example the Drawing order would prapably be: Dome 3 -> Ship -> Dome 2 -> Dome 1   (assuming it's based on the distance of the object centers to the observer) (actually more likely to be based on the distance to an imaginary plane through the observer,  at an angle of 90 degrees to the direction the player is faced) (could also be based on bounding spheres?)

That means that the ship won't get drawn through dome 3, so the ship itself has to be split up into multiple sections aswell. So that the center of the ship section below dome three is further away than the center of dome three.

[Nuke]

i think what needs to be done is while building the list of polygons to throw at gl. the lists for all the submodels are generated first and sent through, then the list of the polies in the hull model are sent. what i think needs to be done is the polygon list must be created for each, then the lists must be merged into a single list, and possibly z-sorted by polygon center (this may or may not be necessary), before being sent to the video card for rendering. z-sorting sorting submodels may work in some situations and would be faster, but there would be situations where it would not render correctly (for example situations where you have a trasparent subobject near the center of the ship, and parts of the hull exist both in front of and behind it with reguards to a specific view origin). mind you my understanding of opengl is very basic, and about all i know how to do is render a bunch of polies in wireframe.

[Pottuvoi]

Sadly this is also something every developer has to endure as current GPUs still cannot automagically render transparencies correctly. (there were some GPUs during old days that did this just fine...)
DX11 or Shader Model 5 finally brought some nice features which make per-pixel sorting of transparent samples/surfaces feasible, but I doubt that freespace will have proper support for a while.

[newman]

Well, using domes as separate ships that are docked to the cruiser's hull is a workaround, but it does open other cans of worms. It would be best if it would function as subsystems, which it currently doesn't.

[Tomo]

It sounds like the ship drawing order is backwards at the moment - drawing subobjects first, then finally detail0.

If instead it drew Detail0 first, then the subobjects from furthest to closest (sorted by origin), that should work.

The limitation of this scheme is that Detail0 cannot contain any transparent geometry, but any and all subobjects can.
- Basically, you can always see the detail0, except where obscured by a subobject.

In ION3's drawing, this would mean SHIP > Dome 3 > Dome 2 > Dome 1

Thinking about it further, this would also require all glass to be double-sided as otherwise you'd lose the back of each dome.

(Edit)
... aaand I just realised why it's the way around it is.
Subobjects first means that you never have to check whether a subobject should be visible, as the 'turret' behind the ship gets obscured when the ship is drawn.

So to do this we'd need one heck of a lot more checking of the Z.

Likely a more fruitful effort would be working out how to pass the entire geometry to the GPU in one go, rather than several passes, so the GPU can do the z-sort.

[Nuke]

z sorting sob-objects wouldn't cut it. you would need to create a polygon list for the whole model, not just individual submodels as its done now. then you would need to z-sort the list by polygon origin.