collada texture transparency bug

Create issue
Issue #404 open
Thomas Koletschka created an issue

When adding a collada file with transparent textures I have to view the object in transparent mode first in order to make it load (more or less) correctly. Before setting the model to transparent the textures are rendered incorrectly and transparency is ignored. After setting the model to transparent and back loading additional instances of the object show up correctly (when loading multiple instances and viewing one transparent it also makes the other one transparent however, this is probably related to #259).

The model shows up as expected/desired transparency wise when viewing it in transparent mode (just the ordering of transparent parts is incorrect sometimes), but after disabling transparency mode it does not render the transparent parts of the texture correct anymore. My example object is a tree with different layers for leaves and the transparent parts of those layers often render all the way through to the floor or trunk ignoring other transparent parts behind them.

See this video for a better understanding (tree1 was exported using sketchup6 and tree2 using sketchup8): http://youtu.be/01VJa_z7SIY The model is available here: http://sketchup.google.com/3dwarehouse/details?mid=772012e0183084608da3b5c4427262d1&prevstart=0

Comments (22)

  1. Thomas Koletschka reporter

    When setting scene blend to alpha blend and disabling depth write through a material script [1] the texture's transparency gets visualized correctly and solid objects behind transparent parts of the model show up correctly (see http://i.imgur.com/M8zP9yj.png). The only problem that persists is incorrect ordering of transparent parts within a model (multiple models with transparent parts occlude each other correctly, but transparent parts within the same model don't get ordered correctly and distant transparent parts are often rendered in front of closer parts, see above image). When rendering with depth write on (instead of off) faces with transparent textures are rendered in the correct order but the transparent parts of their texture ignores other transparent objects behind it and it also seems to ignore textured models (see http://i.imgur.com/vM7Iln0.png ... the textured polaris gets incorrectly occluded while the non-textured polaris shows up correctly). And last but not least the tree with alpha blending disabled (which is the way the model is loaded without explicitly specifying it through a materials script): http://i.imgur.com/x9BmRqE.png

    So there seems to be two problems:

    • For models with transparent textures alpha blending needs to be turned on and depth write needs to be turned off.

    • There doesn't seem to be an easy fix for the sorting problem as Ogre apparently only sorts by entities (models) and not by faces which causes transparent faces within a model and intersecting models with transparent faces to be rendered in random (? or at least incorrect) order.

    [1] http://www.ogre3d.org/tikiwiki/tiki-index.php?page=-material#Transparency

  2. Thomas Koletschka reporter

    Ha, found a fix:

    alpha_rejection greater 128
    depth_write on
    

    makes it render correctly :) (see http://i.imgur.com/DT6hT86.jpg) .... alpha_rejection greater 128 causes texture with alpha channel greater than 128 to be ignored, so it's not the same as actual alpha blending and semi-transparent textures wouldn't work but semi-transparent objects are far far far less common than objects with "binary" alpha channels (just opaque and fully transparent parts) so I think this would be a satisfactory solution for the default behaviour. If someone wants to use a semi-transparent object they could still do so by forcing the behaviour via material script.

  3. Thomas Koletschka reporter

    Nope. 498 fixes transparency specified via sdf, this ticket is about transparency specified via transparent textures on collada models (i.e. textures with alpha channel).

  4. Louise Poubel

    Transparency coming from PNG textures used by collada meshes still doesn't work out of the box. On the other hand, they work just fine for OBJ files.

    For now, one solution for DAEs is to use an Ogre material as suggested above by @thomasko . I made a pull request adding an example to gazebo_models.

    Using an Ogre material comes with its own issues and extra effort, so I think ideally we need to properly support the PNG transparency. I'm reopening this issue.

  5. Stefan Kohlbrecher

    Transparency coming from PNG textures used by collada meshes still doesn't work out of the box. On the other hand, they work just fine for OBJ files.

    I'm not so sure about that :)

    Bumping into this issue right now. I have and obj file using .png textures with alpha for transparency. In default mode, gazebo does not render those transparent, making a mess of the model. As in the OP, when switching mode to "transparent" things look how they should (apart from everything being transparent :) ). See attached two screenshots.

    I'm on 16.04/Kinetic/Gazebo9 installed from .debs.

    default view: default_render.jpg

    transparent view: transparent_render.jpg

  6. Stefan Kohlbrecher

    On a related note, turning off backface culling for this kind of model would be necessary. Asked about this on Gazebo Answers as this might be possible somehow and not warrant a issue here.

  7. Nate Koenig

    Would it be possible to get access to the assets that you are using, or a simple example that we can use to reproduce the problem?

  8. Stefan Kohlbrecher

    Can't share that particular asset, but found out a few things in the meantime. I switched to importing the obj into Blender and exporting COLLADA from there.

    Blender exports materials with partly transparent textures like this per default:

           <transparent opaque="A_ONE">
                  <texture texture="CLGGTM11_png-sampler"/>
           </transparent>        
    

    After looking at the ColladaLoader.cc code I noticed that apparently, not only the transparent tag is required, but also the transparency tag should be there. After a bit of playing around, replacing the above entry with this ended up working for me:

                <transparent opaque="A_ONE">
                  <color>1.0 1.0 1.0 0.99</color>
                  <texture texture="CLGGTM11_png-sampler"/>
                </transparent>
                <transparency>
                  <float sid="transparency">1</float>
                </transparency>
    

    A few notes about that:

    • It seems like it would be better to not initialize material transparency in ColladaLoader with 0 when a transparent tag is set, instead setting it to 1, as the intent most likely is to have transparency, if a transparent tag is set. This at least is the way Blender exports things.

    • For some weird reason, setting the alpha in the color tag to 1.0 makes the railing solid, but setting it to 0.99 makes transparency work correctly (apart from the railing being very slightly translucent). That behavior looks like a bug to me.

  9. Stefan Kohlbrecher

    LGTM, won't have time to compile Gazebo and test this week, however. This fixes the first issue, but not the weird change between correct rendering with 0.99 alpha vs wrong with 1.0 alpha, correct?

  10. Roselle Carmen

    I opened an issue similar to this one.

    There were a lot of hard coding and hacking to get the asset textures to work.

    I’m not sure if I would be able to replicate success again without Ian’s help. Would like this to be looked into for future assets.

  11. Log in to comment