Problem with displaying the line segments

Test scene consists of 2 cubes: one inside another.
Each cube is displayed with 6 rectangular boundary faces and 12 edges.

Scene 1:
Green external cube, blue internal cube, white edges, white background.
Scene is displayed correctly.

Scene 2:
Transparent green external cube (alpha=128), transparent blue internal cube (alpha=128), white edges, white background.
Bug: all edges are not displayed.

Scene 3:
Transparent green external cube (alpha=128), transparent blue internal cube (alpha=128), white edges, black background.
Bug: some edges are displayed irregularly with changing the brightness.


See BasicBox.java attached below.

Note 1:
Test platform is Windows-8, 64 bit, java-8u112, java3d-1.6.0-final, jogl-2.3.2.

Note 2:
On previous configuration with java3d-1.5.2 all scenes are displayed correctly in all cases:
frame of edges is displayed with clear white lines both for external and (in transparent case) internal objects.

Hi

Please fill a bug report. You'll have to provide a SSCCE: http://sscce.org

Yeah as gouessej said, we'll need to see the code that produces this if possible. Please get a minimal test case together, it doesn't look like more than a couple of pages of ode and post it here, then we can have a play and give you some ideas, or accurately capture the issue.

Thanks.

Here is minimal example reproducing the problem.
BasicBox.java

world,
Excellent example, thanks for that.

I've got it going and I see exactly the output you've shown.

In testing this I've put it into the 1.7.0 version (which uses shaders) and I get one of 2 outputs depending on the render pass that the lines are rendered in.
Either in the non transparent pass:

Or the transparent pass:


Just before I go on with testing I wanted to make sure your expected output was in the transparent path, as you have set the lines to be anti aliased.

Can you please confirm, and also tell me if these images match the 1.5.2 output you were getting?

Note the above images don't have lighting calcs in the shaders I've attached.

Thanks,
Phil.

world,
I'm pretty sure this is related to the OpenGL fixed function pipeline issue of having no transparent triangle sorting strategy, whereas DirectX does. Though I'm not sure if you are using the DirectX dll behind java 1.5.2 because I couldn't find a release with it in it.

Anyway I can get the expected rendering simply by commenting out the line

lineAttr.setLineAntialiasingEnable(true);

Because anti-aliasing forces lines to be in the transparent pass, and therefore they don't write to the depth buffer and hence get mixed with other transparent renders. Note that the centroids of all your shapes are the same so geometry sorting won't help here.

If you want to keep them nicely anti-aliased (and who wouldn't) then you need to reorganize your scene graph using an OrderGroup to make the lines render after the boxes in the transparent pass

So I added a new member

private SimpleUniverse universe;
private BranchGroup root;
private TransformGroup trans;
private OrderedGroup og = new OrderedGroup();

added it to the trans group

trans = new TransformGroup();
trans.setCapability(TransformGroup.ALLOW_TRANSFORM_WRITE);
trans.setCapability(TransformGroup.ALLOW_TRANSFORM_READ);
trans.addChild(og);
root.addChild(trans);

and put the line box into it, instead of trans

trans.addChild(new Box(w, w, w, app));
//trans.addChild(lineShape(w, lineColor));
og.addChild(lineShape(w, lineColor));

You may already know this but this two items are also a good idea.

view.setTransparencySortingPolicy(View.TRANSPARENCY_SORT_GEOMETRY);

System.setProperty("sun.awt.noerasebackground", "true");

Please have a go and tell us if it helps,
Phil.

Hi

At first, the native renderer based on Direct3D contained tons of unfixed bugs, I removed it from Java3D 1.6.0 several years ago, we won't revert this change. You can look at other solutions in other similar scenegraph APIs and engines and then port one of them somehow to Java3D >= 1.6.0.

Do you mean Lenovo? It's possible to emulate OpenGL / OpenGL-ES through Direct3D with Angle or to use OpenGL ES software rendering with SwiftShader but an hardware upgrade would be easier and I don't think that investigating on supporting extremely badly maintained drivers is the way to go. Some Lenovo laptops emulate some colors in their palettes, you'll face some other troubles if you persist :s We will never support OpenGL 1.0, it's simply impossible as Java3D is a retained mode scenegraph API from its very beginning. I assume that you're aware of the few choices in scenegraph APIs still supporting OpenGL >= 1.3 whereas numerous ones require OpenGL 2.1.

Excellent job Phil, thank you for your patience and your devotion :)

Thank you for your large investigation.
My expected graphics on previous java3d-1.5.2 looks as on your first row of images (called "non transparent pass"),
where the lines are entirely white and sharp and all internal lines are visible (on the 2nd and 3rd images).

First my new information.

2. Good news - is that if in original BasicBox.java the only one line is changed to:

trans = new TransformGroup(initialLocation());

Then the lines are correctly displayed on all 3 images. It is almost OK, with only one small disadvantage:
On the 2nd and 3rd images line color changes from 'white' to 'blue' when the line visually intersects internal cube.

Modified source for this case:
BasicBox2.java

3. Bad news - is that if the angles of initial transform are changed, than in most cases lines are disappeared again.
For example it is enough to change Z-rotation angle from PI/6 to PI/4.
Modified source for this case:
BasicBox3.java

Continue experiments and apply suggested changes.

4. Comment antialiazing settings in BasicBox2.java

//lineAttr.setLineAntialiasingEnable(true);

Images look like in your second row. Here we can note the following:
1. Lines of internal cube have green color. It seems, it is more correct (then white), because we look at them through the transparent green surface.
2. Not all of lines are displayed on the 2nd image. It can be interpreted as bug, because the surfaces are transparent, and they are displayed on the 3rd picture.

Modified source for this case:
BasicBox4.java

5. Next modification - is addition of shapes to OrderedGroup instead of TransformGroup:

group = new OrderedGroup();
trans.addChild(group);
root.addChild(trans);
//trans.addChild(new Box(w, w, w, app));
//trans.addChild(lineShape(w, lineColor));
group.addChild(new Box(w, w, w, app));
group.addChild(lineShape(w, lineColor));

The result is the following: the internal box is not displayed in the 2nd and 3rd cases:

Modified source for this case:
BasicBox5.java

6. Changing the order of shapes addition to OrderedGroup:

group.addChild(lineShape(w, lineColor));
group.addChild(new Box(w, w, w, app));

The result is different, but also incorrect:

Modified source for this case:
BasicBox6.java

7. Addition of lines:

System.setProperty("sun.awt.noerasebackground", "true");
view.setTransparencySortingPolicy(View.TRANSPARENCY_SORT_GEOMETRY);

doesn't change the result (both with use of OrderedGroup or without it).

world,
Thanks for this further testing, I don't get the any difference when setting and altering the initialRotation, I suspect it's because of the distance sorting issue I mentioned, where all cubes have the same center so they get rendered in an arbitrary order, and your system choose two different orders but mine doesn't.

In your ordered group example you've done what I did when I first tried it, which is to put all four of the objects into the ordered group, you'll notice I put only the lines in the ordered pass, to force them to run before the boxes. Putting the boxes all into ordered groups actually causes some boxes and lines to be not rendered at all, which I don't understand yet, and which I need to read more about the exact order of operations. Possibly the ordered pass forces depth writing for some reason.

Can you try it once more with anti-aliasing left on and

trans.addChild(new Box(w, w, w, app));
//trans.addChild(lineShape(w, lineColor));
og.addChild(lineShape(w, lineColor));

Another interesting point to note is that in a opaque line drawing situation there is a mechanism to stop these sorts of problems

PolygonAttributes polyAttr = new PolygonAttributes()
polyAttr.setCullFace(PolygonAttributes.CULL_NONE);
polyAttr.setPolygonOffset(0.2f);
polyAttr.setPolygonOffsetFactor(0.2f);
app.setPolygonAttributes(polyAttr);

This pulls the poly forward towards the screen and means it succeed at depth tests and gets nicely drawn over any other opaque poly that has the same depth.

Unfortunately in the transparent pass our lines are testing depth but not writing it so other transparent objects also draw, meaning the offset calls don't help.

You can do the same thing with some complex stencil buffer settings, but that's probably overkill




As you mentioned the white background shows through on the second frame and causes transparent colors to match up, it's easier to see the effects with a red background and a black background, otherwise you're eyes play tricks on you regarding what's drawn and what's not.

Thanks,
Phil.

5.1 I have already checked different variants of Box and lineShape addition.
For example this one:

trans.addChild(new Box(w, w, w, app));
//trans.addChild(lineShape(w, lineColor));
//group.addChild(new Box(w, w, w, app));
group.addChild(lineShape(w, lineColor));

gives the same set of pictures as BasicBox4.java (see above) both with enabled and disabled antialiasing.

8. Adding the following code:

polyAttr.setPolygonOffset(0.2f);
polyAttr.setPolygonOffsetFactor(0.2f);

Doesn't change result in all cases.
Checked 4 combinations: with/without OrderedGroup, enabled/disabled antialiasing.

I suppose the 'system' (low-level library) knows nothing about cube's center.
Explanation: what if we have non-convex or non-simplyconnected objects?
Such objects can have complex intersections an even self-intersections.
So, the only way for the 'system' to display correctly everything - is:
1) Consider the whole set of all elementary elements (segments, triangles),
2) Find intersections of all pairs of elements,
3) Split elements with intersection lines or points (if have) and construct new list, that have no intersections,
4) Order new list in Z-direction, where Z-axis - is normal to the screen expressed in virtual coordinates,
5) Draw new ordered list.
Then invisible parts will be automatically removed from the target projection of 3D scene on the screen.
Transparent elements will be also displayed correctly, because we take into account both background color
and color of elements that have been already drawn at this place.

---

To decide which way of displaying is correct, to avoid subjective judgments,
we can imagine the corresponding physical construction:
two cubes made of green and blue transparent glass, one inside another;
each cube has thin white (non-transparent) tubes along the edges.

What we can see then? The answer: white frame will be visible in any case with some features:
1) segments of lines visible through the green surface will be green,
2) segments of lines visible through the green and blue surfaces will be of some dark color.

Conclusion:
1) Non of considered variants gives expected picture,
Most close to correct - BasicBox2.java (see above) and BasicBox4.java (see above),
2) Even good pictures are unstable, depends on initial scene location.