Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: current
    • Fix Version/s: not determined
    • Component/s: j3d-core
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      580

      Description

      We are running into a problem with putting objects with transparencies inside a
      sphere with a transparency.

      The idea was to be able to look around while inside a sphere with a background
      texture with transparency, and have another sphere beyond the first with auto
      rotation to simulate clouds drifting in the background of the scene. What we
      found were objects rendered inside the beyond the origin will show the
      transparent sphere object texture in front of objects closer to the camera.

      There is an example here:

      http://diytest.diyonline.com/bug3d/index.jnlp

      which has the java source code included in the jar.

      The inner sphere, with the alpha component, is at radius 29, Color(255,0,0,127),
      the outer sphere is at 30 and white (no alpha), and the 2 transparent windows
      are at -.4 and .4 on the Z axis. I also added a ground texture to show that
      images without an alpha component between the window and the spheres turn off
      the odd rendering.

      If you pull the windows closer to you, than origin, the problem vanishes, if you
      push them beyond origin, it reappears.

      Turning off View.setTransparencySortingPolicy(View.TRANSPARENCY_SORT_GEOMETRY)
      causes the front window to never show the bug, and the rear window to always
      show the bug without regard to location.

        Activity

        Hide
        jcoy added a comment -

        Created an attachment (id=354)
        Source code for transparency sort bug

        Show
        jcoy added a comment - Created an attachment (id=354) Source code for transparency sort bug
        Hide
        aces added a comment -

        Using javax.media.j3d.Background node could avoid this problem, but it only
        accepts Shape3D, texture 2D and plain colour as child node.

        This issue happens because transparency object sorting uses node bounding centre
        to sort. As the spheres objects used as background has bounding center matching
        scene center, there is a "fight" when sorting transparency.

        As workaround, I suggest to move background away from scene center, just a
        little bit.

        public void addBackground(BranchGroup bg)

        { // a TG to move background center away from scene center TransformGroup tgTranslate = new TransformGroup(); // set background a bit back, up and to right side Vector3f translation = new Vector3f(3.0f,3.0f,3.0f); // transform Transform3D t3d = new Transform3D(); t3d.setTranslation(translation); tgTranslate.setTransform(t3d); // BG to hold on background nodes BranchGroup bgBackGround = new BranchGroup(); // build BG nodes buildSimpleSphere(bgBackGround, 29f, new Color(255, 0, 0, 127), true); // far away, red, 50% alpha buildSimpleSphere(bgBackGround, 30f, new Color(255, 255, 255, 0), false); // a bit further, white, no alpha // add background nodes to scene tgTranslate.addChild(bgBackGround); bg.addChild(tgTranslate); }

        Show
        aces added a comment - Using javax.media.j3d.Background node could avoid this problem, but it only accepts Shape3D, texture 2D and plain colour as child node. This issue happens because transparency object sorting uses node bounding centre to sort. As the spheres objects used as background has bounding center matching scene center, there is a "fight" when sorting transparency. As workaround, I suggest to move background away from scene center, just a little bit. public void addBackground(BranchGroup bg) { // a TG to move background center away from scene center TransformGroup tgTranslate = new TransformGroup(); // set background a bit back, up and to right side Vector3f translation = new Vector3f(3.0f,3.0f,3.0f); // transform Transform3D t3d = new Transform3D(); t3d.setTranslation(translation); tgTranslate.setTransform(t3d); // BG to hold on background nodes BranchGroup bgBackGround = new BranchGroup(); // build BG nodes buildSimpleSphere(bgBackGround, 29f, new Color(255, 0, 0, 127), true); // far away, red, 50% alpha buildSimpleSphere(bgBackGround, 30f, new Color(255, 255, 255, 0), false); // a bit further, white, no alpha // add background nodes to scene tgTranslate.addChild(bgBackGround); bg.addChild(tgTranslate); }
        Hide
        jcoy added a comment -

        Thanks for the feedback.

        While that causes the initial rendering to appear correct, it doesn't really
        solve the problem; it only masks the obviousness of it. The demo was designed
        to make the problem obvious and clear. With those changes in place, all I have
        to do is move the mouse wheel forward and the problem represents itself.

        I could just as easily place the planes forward of origin, but since the goal is
        an interactive environment where the perspective can be adjusted, the issue remains.

        Show
        jcoy added a comment - Thanks for the feedback. While that causes the initial rendering to appear correct, it doesn't really solve the problem; it only masks the obviousness of it. The demo was designed to make the problem obvious and clear. With those changes in place, all I have to do is move the mouse wheel forward and the problem represents itself. I could just as easily place the planes forward of origin, but since the goal is an interactive environment where the perspective can be adjusted, the issue remains.
        Hide
        aces added a comment -

        > Thanks for the feedback.

        You are welcome.

        > it doesn't really solve the problem; it only masks the obviousness of it.

        My intention was to help, not to mask anything.

        IMHO, this is not a Java3D bug.
        Things like this should be discussed in forum, where users could share their
        solution for complex background, like yours.

        Good Luck.

        Show
        aces added a comment - > Thanks for the feedback. You are welcome. > it doesn't really solve the problem; it only masks the obviousness of it. My intention was to help, not to mask anything. IMHO, this is not a Java3D bug. Things like this should be discussed in forum, where users could share their solution for complex background, like yours. Good Luck.
        Hide
        jcoy added a comment -

        Well, I might be inclined to believe this wasn't a bug if textures using an
        alpha component didn't follow completely different rules than normal textures.

        If I do the same thing without an alpha component, things closer to the
        viewpoint get drawn in front of things behind it.

        With an alpha component, the expectation is to first flip a switch to say "yes,
        please put them in order", and you still get very odd rendering behaviors.

        It's not that I need help finding a workaround, it's that I thought you were
        trying to make a product that was, you know, good.

        Show
        jcoy added a comment - Well, I might be inclined to believe this wasn't a bug if textures using an alpha component didn't follow completely different rules than normal textures. If I do the same thing without an alpha component, things closer to the viewpoint get drawn in front of things behind it. With an alpha component, the expectation is to first flip a switch to say "yes, please put them in order", and you still get very odd rendering behaviors. It's not that I need help finding a workaround, it's that I thought you were trying to make a product that was, you know, good.
        Hide
        jcoy added a comment -

        That may have been a bit over the top. My apologies. It was a at least a day
        locating and retrofitting the bug back to a clear, concise program after
        implementing a workaround.

        I'm not on a duck hunt here, I'm trying to present a problem as I see it, so
        that it can be addressed.

        It is irrelevant to me if this is set for milestone 20.x.x or even beyond, but
        it is a bug that alpha transparencies render differently than non-alpha
        transparency objects. In that example, I can certainly create the window pane
        without glass; I can generate the alpha background as a plane or maybe a half
        sphere, I can do a variety of things AFTER the fact to mask the problem, but the
        underlying issue is textures render differently when an alpha transparency is
        present even where the texture defines itself as non-transparent. This is
        unexpected behavior.

        In any real work environment, additional requirements get added on. When far
        into a project the client says "Everything looks good, but those houses looks
        totally fake with those (non-)windows", correcting it shouldn't mean having to
        re-design the scenegraph to implement a void to add a transparent section. The
        house shouldn't be rebuilt from sticks to skip the transparent portions any more
        than it should be a problem observing outside a swimming pool when underwater.
        Granted, masking the problem is often a viable option, but it is still simply
        masking the problem.

        Even if it is expensive or the algorithm is ugly, the option to order
        transparencies the same as as other objects should (minimally) be available.
        The demo was created explicitly to make the problem immediately obvious so as to
        allow programmers to quickly recognize the issue and hopefully perceive the
        implications of this bug.

        As I said, when it gets fixed is irrelevant at this point, but it is a bug, and
        should be so noted.

        Show
        jcoy added a comment - That may have been a bit over the top. My apologies. It was a at least a day locating and retrofitting the bug back to a clear, concise program after implementing a workaround. I'm not on a duck hunt here, I'm trying to present a problem as I see it, so that it can be addressed. It is irrelevant to me if this is set for milestone 20.x.x or even beyond, but it is a bug that alpha transparencies render differently than non-alpha transparency objects. In that example, I can certainly create the window pane without glass; I can generate the alpha background as a plane or maybe a half sphere, I can do a variety of things AFTER the fact to mask the problem, but the underlying issue is textures render differently when an alpha transparency is present even where the texture defines itself as non-transparent. This is unexpected behavior. In any real work environment, additional requirements get added on. When far into a project the client says "Everything looks good, but those houses looks totally fake with those (non-)windows", correcting it shouldn't mean having to re-design the scenegraph to implement a void to add a transparent section. The house shouldn't be rebuilt from sticks to skip the transparent portions any more than it should be a problem observing outside a swimming pool when underwater. Granted, masking the problem is often a viable option, but it is still simply masking the problem. Even if it is expensive or the algorithm is ugly, the option to order transparencies the same as as other objects should (minimally) be available. The demo was created explicitly to make the problem immediately obvious so as to allow programmers to quickly recognize the issue and hopefully perceive the implications of this bug. As I said, when it gets fixed is irrelevant at this point, but it is a bug, and should be so noted.
        Hide
        kcr added a comment -

        As has been explained, this is not a Java 3D bug. There are two issues here.

        First, sorting is done on a per-geometry basis using the centroid of the bounds
        of the object. More sophisticated sorting algorithms are possible by using the
        TransparencySortController utility class. This gives applications control on
        doing the sorting.

        Second, as to the question of why the rendering changes when transparency is
        enabled, see View.setDepthBufferFreezeTransparent, which might explain some of
        this difference.

        Show
        kcr added a comment - As has been explained, this is not a Java 3D bug. There are two issues here. First, sorting is done on a per-geometry basis using the centroid of the bounds of the object. More sophisticated sorting algorithms are possible by using the TransparencySortController utility class. This gives applications control on doing the sorting. Second, as to the question of why the rendering changes when transparency is enabled, see View.setDepthBufferFreezeTransparent, which might explain some of this difference.
        Hide
        jcoy added a comment -

        So it is not a bug that sort order for the textures without transparencies in
        the example I posted is window, window, background, but with transparencies it
        becomes window, background, window. Perfect.

        Additional testing has shown the sort order with transparencies is based on the
        location of the object rather than the objects area (which is not true without
        transparencies), and since a sphere's location is at the center, that pretty
        much explains the problem. We have seen the same issue with other Shape3Ds and
        the sort order with planes is a real problem when triangles start disappearing
        because you have a horizontal plane intersecting a vertical one in a scene.

        Show
        jcoy added a comment - So it is not a bug that sort order for the textures without transparencies in the example I posted is window, window, background, but with transparencies it becomes window, background, window. Perfect. Additional testing has shown the sort order with transparencies is based on the location of the object rather than the objects area (which is not true without transparencies), and since a sphere's location is at the center, that pretty much explains the problem. We have seen the same issue with other Shape3Ds and the sort order with planes is a real problem when triangles start disappearing because you have a horizontal plane intersecting a vertical one in a scene.

          People

          • Assignee:
            java3d-issues
            Reporter:
            jcoy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: