Totally confusin transparency behavior

#1 Anyone? Bueller?

Is there anyone who works on TSE who could talk about this? Is this a known issue? Would it be helpful if I posted the actual .max and .png files for download?

#2 Well first i assume that it's a DTS shape. If it's DTS i suggest creating an inner cube which faces inwards and an outer cube which faces outwards. You need to define the order specificly in 3dsmax so that the inner cube is rendered first... then the outer cube. I don't think you can get the effect your looking for with the culling or two sided flags alone.

#3 I don't think double sided faces work in TSE, I'll have to check on that. I think that's what your main problem is here.

#4 @Tom: yes, it's just a standard .dts of a nice boring cube. :-) What you're suggesting seems like a bit of extra work that wasn't needed under TGE but in any case our actual models are not just cubes and have complicated transparencies where I don't think that approach would work. I'm also a little reluctant to change the models if this is something that's just broken at the moment in TSE and will eventually get fixed. But thank you for the idea anyway.

@Brian: if you could look into this that would be great. We have a number of models that were fine in TGE but simply don't render properly (or at all) in TSE. I went ahead and put the .max/.dts/.png files for the cube test up on the website in case it helps. "14.dts" is the latest test file (the one that I used to generate the screenshots above). The first four texture are used on the four sides of the cube and are all SuperPNG generated. The last texture ("test_texture.png") was used for the top and was generated with the normal .png plugin in Photoshop but we're not concerned about that one.

www.tolchin.net/gg/pngTEST01.max
www.tolchin.net/gg/14.dts
www.tolchin.net/gg/test_texture-super.png
www.tolchin.net/gg/test_texture-super2.png
www.tolchin.net/gg/test_texture-superback.png
www.tolchin.net/gg/test_texture-superfront.png
www.tolchin.net/gg/test_texture.png

Thanks!

#5 Hi,

did someone find a proper fix for this?

I ran into the exact same problems with our trees (the leafes dont render at all)
and need to fix it by weekend.

So i guess i need to remove SORT:: from the DTS files so that i can see them again?

#6 I haven't gone back to trying out the "test cube" that I posted above, but we still have many weird transparency issues. Ben Garney posted a fix to ShapeBase.cpp a few weeks back that resolved some of our transparency issues, so if you're having trouble with a ShapeBase-derived object and you haven't picked up the latest code in a while you should definitely do that. There is more info on that in this thread:

www.garagegames.com/mg/forums/result.thread.php?qt=30974

One of things we discovered is that *sometimes* you can fix certain transparency issues by doing some non-intuitive things. For example, in TGE you could get .dts object transparency by simply checking the "Opacity" checkbox for the object's texture in 3D Studio Max. But in TSE, sometimes you *must* uncheck this box or the object won't draw at all. Other times, you have to have it checked or it won't draw. It seems to depend on whether you're drawing a semi-transparent .dts on top of another semi-transparent .dts or not. We have to play around with the settings (the "Opacity" checkbox in Max and the Material datablock translucency flag in script) and see which combinations work, but like I said sometimes we still can't get the transparency to work properly. I'm hoping that as TSE matures a bit some of these issues will get resolved. :-/ Good luck!

#7 I instructed our Modeller to send a dts file without "Opacity" checked and it still doesnt render at all.

He sent a Obj file with which i can test around a little.


I think that TSE should ignore all DTS saved properties regarding opacity and sorting and using a Material datablock for it instead.

i'll look into the code to see if that is a possibility.

#8 Okay i tried without Opacity and without SORT and now it renders.

but with a few glitches:

www.rebtiel.net/seelentanz/Baum02.png

The Leafes dont render against the Waterblock and they dont Render against other DTS.

The Trunk and the Ork Model shine thru the leafes.

its not visible on this Picture but it renders good against interiors

#9 We took the SORT tag out of our .dts models too because it seems to prevent the object from rendering.

We also have the same problem with our tree: the trunk shows in front of the leaves regardless of the angle you view the tree at. We're making an RTS game, so it's more important how the objects look from above (and the objects are fairly small anyway), but I'd still like to get these issues resolved.

We don't have a waterblock in our scene (yet) so I didn't know it wouldn't render against that. TSE seems to have LOTS of problems with transparency. :-(

#10 I just found out why it doesnt render water and the trunk and the model behind the tree texture...

the Scene Graph actually renders DTS files and the Water AFTER the transparent textures are written. Since transparencies dont write to the Z-Buffer the depth at these specific Pixels is the one of the Terrain in the Background (in my example). If after the Tree has been Rendered the Water gets rendered it performs a depth test and cant "see" that the Tree is in the Foreground and just overpaints the Tree with the Water. Same happens with DTS files.


try adding the following to your material definition:

translucentZWrite = true;

this produces new odd results (the water wouldnt render behind the tree) but it proofes my theory.

One possible solution for this is my suggestion stated here

www.garagegames.com/mg/forums/result.thread.php?qt=31632

and another way is to rethink the way the Scene Graph sorts stuff and change it accordingly.

I'll have a dive into Code tommorow

#11 That's interesting because I'm sure I was told that the "translucentZWrite" flag only affected interiors, and not .dts objects. So I took that flag out of all my material datablocks. :-/

I was wrong about one thing: the trunk is no longer showing up in front of the leaves (even without that flag set). I wonder if that was fixed by the changes Ben made to ShapeBase.cpp. Anyway, turning on the translucentZWrite flag definitely helps with some other issues, so I will add that back in again. It does make the edges of the textures render a bit strangely, but it definitely helps prevent other objects drawing in front of the tree when they're really behind it. Thanks for the tip!

#12 So, is this a bug or am I doing something wrong with my material?

I have a translucent cube that I'm rendering. With translucentZWrite=false, you can't see the cube when the water is behind it, mutch like the image Florian posted. When I set it to true, you can't see the water through the cube, but instead see the terrain behind it. Also, some objects (all maybe? I only have one) don't show up behind the cube, but interiors do. The tri's in the cube are also two sided and with transluscentZWrite=true, you can't see the inside until you actually move the camera inside of the cube.

Kinda a neat effect and if it's something I'm doing wrong then I'm going to at least keep the settings and possibly use it as a special effect later, but for now I'd like to figure out what I'm doing wrong so I can get the expected behavior.

Thoughts?

#13 Hi,

I think that it is a bug. The Scenegraph draws the Water in a later pass than the transparent objects. Since transparent objects dont have any depth-value the Water render pass treats the transparent objects as if they werent there and simply draws over it.
If you set "translucentZWrite=true" you actually have a depth-value there but the depth-value is extended along the whole triangle and not only the visible part of your texture (e.g. Leaf in a leaf-texture)

AFAIK there are 2 solutions to that:

1. Draw transparent objects after drawing the water: this could lead to one problem tho: depending on water implementation it can be that it wont render reflection of the transparent objects on SM 2.0 cards.

2. Completely removing depth-values for invisible parts of the leaf texture by using the HLSL texkill command. This has an issue too: it doesnt work with semi transparent surfaces.

I think this should be the right way to do it:

1. Render Atlas Terrain, then Interiors, then Shapes (not the transparency ones)

2. Render the Reflection of the Water to a Texture (Atlas -> Interiors -> Shapes -> Transparent Shapes)

3. Render the whole waterblock

4. Render all Transparent Faces

I cant really check onto that right now because i wait for my new GPU to arrive (Finally getting rid of my GF3)

#14 Yes, transparency is messed up ;) It's on the list for fixing in MS3. It's mostly water that's a problem right now, but there are also issues with transparency flags exported from MAX colliding with translucent Materials.

#15 Hi @ all

I think i may have found a possible solution to this:

i see two cases of transparencies (i'll discuss later why i made a distinction here)

1. Masked: where a pixel is either fully visible or fully invisible (Could be color-keyed actually)

2. Blended: where alpha can be any range from 0 to 255

The problem is that blended materials are normally rendered without z-buffer from back to front. No z-buffer means no depth information and this will lead to a totally confusing rendering behavior.

So my idea is:

If you render transparencies to a new surface (texture) with z-buffer you can later copy it into the picture.
But then you still have the depth value of the first transparent object. what about the others?

you need to do a few additional renderpasses. each time culling away all depthvalues that are smaller than the depth value of the last pass. with each pass you will get deeper inside the world while maintaining depth values for all objects you render. Then later you can just copy these layers from back to front into the rendered view (with its terrain, interiors, and shapes (water could be treated as an additional layer))

but if you have a large amount of trees that will all have transparencies on you would need a lot of these passes to get any good results ... performance would be horrible.

Thats why i made a difference between masked and blended transparencies ... you can ignore all those masked transparencies if you render them all into one layer using TEXKILL. TEXKILL prevents the GPU from drawing a fragment alltogether ... it wont write any color values, depth values and stencil values. So you can still maintain an accurate depth buffer by using those. TEXKILL is not the fastest thing on earth but i think its a very powefull tool

To be able to run entirely on the GPU it needs Flow Controls (if then else) ... AFAIK this is only true for 2.x and 3.0 models (according to MSDN)

1.1 - 2.0 would most likely need to read back data to system memory to archieve the same effect

EDIT: I forgot to add a few things

if you render all masked items in one pass you will get away with maybe 2-4 passes for the blended items. its very unlikely that you will have more than 4 glasslike materials in a row.

if you hook this technique into shadow mapping you could simulate light casting thru a churchwindow projecting the window-colors onto the floor. You would need to render a normal depth buffer + the same layers you render for blended materials. (those layers still need color and alpha information so you wont get away with just rendering the depth buffer)

Cheers,

Florian

#16 Where's the resource for this? The church thing sounds neat.

kidding! :P

Nice ideas... too bad I'm not there yet.

#17 This is a little overkill. I think all that needs to happen is:

Draw the water.

Draw translucent objects (sorted).

The reason this wasn't done originally is because of the refraction of the water, which relies on warping what is already in the frame buffer. If the translucent objects are drawn after the water, they will not be refracted. This could be solved by rendering them both before and after the water, but in most cases that's more than what is necessary.

A lot of the tree rendering problems can be solved by simply switching on alpha testing so that the opaque parts of the texture write to the zbuffer, and the clear parts do not.

I'll be adding an alpha test flag to Materials soon so this can happen.

#18 I'm having a lot of problems with transp in TGEA... and cannot found nothing usefull to solve them... Anyone have some suggestions?

If you someone wanna take a look...

www.garagegames.com/mg/forums/result.thread.php?qt=62847


Tnx,
JoZ