2019-12-07 11:57 EST


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001583FSSCPgraphicspublic2012-01-17 19:49
ReporterVA 
Assigned ToValathil 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
Product Version3.6.9 
Target VersionFixed in Version3.6.13 
Summary0001583: Glitch in transparency render order for ship textures
DescriptionThis is a bit of a weird one. If you have a ship that uses a transparent texture of any kind (ie, can be set transparent by the alpha map or the '-trans' flag), there is a display error that only causes ships _smaller_ than the one with the transparency to be rendered on top of it when they should be behind. Since it's best described with a picture:

http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/TransRenderOrderBug.jpg

The pic is a bit dark, but you can sort of see how the iceni in the middle, which is still below the hatshepsut is being rendered as though it were in front of the transparent texture.

There's a little series of pics here displaying the same thing but with a bit more brightness since it uses FRED:

Correct:
http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/CloudProblem1.jpg

Incorrect:
http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/CloudProblem2.jpg

Correct:
http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/CloudProblem3.jpg

Also, for comparison, if you make the smaller and non transparent ship into something that is bigger than the transparent one, then it will all render correctly at all times:
http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/CloudProblem4.jpg

I've attached a test pack that was used to make the first screenshot - has the trans texture version of the hatshepsut, the trans texture and the mission file.
Additional InformationIf anyone is wondering what on earth this has to do with anything, it was found during testing of Twisted Infinities atmospheric mission where we have the cloud pof using transparent textures:

http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/screen0378.jpg

As you can see, the ocean - a HUGE pof, is rendering correctly relative to the clouds, while the island and fenris are rendering over it.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0009061

taylor (administrator)

I managed to track down the cause for this a while ago, but I have yet to figure out what the hell the do about it. You can actually get it to render correctly depending on your position and view angle. The reason is how it sorts order based on z, since it easily changes and doesn't really represent the true order of the objects in the view.

I have thought about several possible fixes for this, but they are all pretty messy, so I'm not really prepared to mess with it just yet. If I get a brainstorm, of just have enough time on my hands, I'll try and get this fixed in the existing code. Otherwise this is likely to way for 3.7+ to be fixed.

~0009065

VA (reporter)

Yeah - I can sometimes get it to snap the render order into the correct positions when the small object is near the edge of the large transparent one.

I do have a question though - if the z order is originiating from the camera, how can things get out of order in this way, and how does it only affect transparent objects rather than everything?

Thanks for this BTW. It's much appreciated. :)

~0009066

taylor (administrator)

It takes the object position and then adds the object radius to it, and uses that to z-sort with. The problem is that a small but closer object can be obstructed by a larger but slightly further away object. Even if you took the radius out of the equation you would have the same problem, since a closer/smaller object could be obstructed by a larger/further object depending on how it was positioned, but the small object would show up anyway. It's kind of a mess really. I'm thinking that we need some sort of quick occlusion test there based on the bounding box, but my previous attempts at doing that haven't yielded very good results.

And the reason this only affects transparent objects is actually quite simple: the video card fixes it for us otherwise. Render order in the game is determined by the object position, but the video card is looking at each vertex for the order. For transparent objects to work properly they have to be rendered in the correct order, but it's still wrong for opaque objects as well. It's just that the video card is covering our backs and dealing with the opaque objects itself, which is something that it can't do with transparent objects since proper blending is dependent on the order.

~0009079

VA (reporter)

Wow, sounds like a relic of software rendering to me. I bet it was also responsible for the retail bug that would render small turret subobjects over the top of the hull of ships when viewing from certain positions.

This was before the HTL engine was implemented, so I guess the 'fix' for the bug was getting the graphics card to hide the bug. :\

~0009081

taylor (administrator)

Yeah, I think that there was more code in place to address it on the software side, but that has since been removed since it gets done in hardware with D3D and OGL. On a per-model level this same basic thing is responsible for a series of lighting bugs as well. This is something that really needed to be addressed with the original HTL conversion, but it wasn't and now it's a bigger problem that it used to be considering all of the new content that's available.

I know that this will be fixed with the material system, since that will be a major upgrade that requires all of this code be rewritten, but getting it fixed before then without a rewrite is a little more complicated than I originally thought. The material code will add a scene manager, which will do a z-pass for all opaque objects to set the proper depth order for the video card and then those objects will be rendered front-to-back, then transparent objects will be rendered back-to-front afterwords so that all transparent objects will blend properly. That's the proper way to fix all of this anyway, but it's a rather large amount of work to get it to the point where that's possible.

I'm still going to try and figure out a good way to temporarily "fix" the existing code in the meantime though. It isn't going to be perfect by any means, but it should be a lot better than it is now.

~0013075

The_E (administrator)

With recent fixes to the render pipeline by Valathil, this bug has been splatted.
+Notes

-Issue History
Date Modified Username Field Change
2008-01-20 03:50 VA New Issue
2008-01-20 03:50 VA File Added: TransFlagTestPack.zip
2008-03-29 20:00 taylor Note Added: 0009061
2008-03-29 20:02 taylor Status new => confirmed
2008-03-29 20:02 taylor Projection none => redesign
2008-03-29 20:02 taylor ETA none => > 1 month
2008-03-30 00:48 VA Note Added: 0009065
2008-03-30 01:42 taylor Note Added: 0009066
2008-03-30 11:22 VA Note Added: 0009079
2008-03-30 15:22 taylor Note Added: 0009081
2012-01-17 19:49 The_E Note Added: 0013075
2012-01-17 19:49 The_E Status confirmed => closed
2012-01-17 19:49 The_E Assigned To => Valathil
2012-01-17 19:49 The_E Resolution open => fixed
2012-01-17 19:49 The_E Fixed in Version => 3.6.13
+Issue History