Source Code Project Mantis - FSSCP
View Issue Details
0001583FSSCPgraphicspublic2008-01-20 03:502012-01-17 19:49
ReporterVA 
Assigned ToValathil 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
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 Fileszip TransFlagTestPack.zip (1,451,294) 2008-01-20 03:50
http://scp.indiegames.us/mantis/file_download.php?file_id=974&type=bug

Notes
(0009061)
taylor   
2008-03-29 20:00   
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   
2008-03-30 00:48   
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   
2008-03-30 01:42   
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   
2008-03-30 11:22   
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   
2008-03-30 15:22   
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   
2012-01-17 19:49   
With recent fixes to the render pipeline by Valathil, this bug has been splatted.

Issue History
2008-01-20 03:50VANew Issue
2008-01-20 03:50VAFile Added: TransFlagTestPack.zip
2008-03-29 20:00taylorNote Added: 0009061
2008-03-29 20:02taylorStatusnew => confirmed
2008-03-29 20:02taylorProjectionnone => redesign
2008-03-29 20:02taylorETAnone => > 1 month
2008-03-30 00:48VANote Added: 0009065
2008-03-30 01:42taylorNote Added: 0009066
2008-03-30 11:22VANote Added: 0009079
2008-03-30 15:22taylorNote Added: 0009081
2012-01-17 19:49The_ENote Added: 0013075
2012-01-17 19:49The_EStatusconfirmed => closed
2012-01-17 19:49The_EAssigned To => Valathil
2012-01-17 19:49The_EResolutionopen => fixed
2012-01-17 19:49The_EFixed in Version => 3.6.13