Skip to main content

[JAVA3D-INTEREST] Transparency Sorting Problems

9 replies [Last post]
Anonymous

Hello all,

I have been banging my head over a transparency sorting problem for the last
few days and I can't come up with an answer. I have two spheres in my scene,
one enclosing the other. The sphere's are composed of many individual
Shape3D objects with individual geometry and some shared appearance
attributes (so they are not actually sphere geometries).

When the transparency attribute mode is set to NONE, things behave correctly
and the red shapes are inside the white shapes as it should be. When the
transparency mode is anything else (FASTEST or NICEST), red shapes begin to
show in front of the white shapes. Assuming this was a transparency sorting
problem, I enabled View.TRANSPARENCY_SORT_GEOMETRY. However this appears to
make things worse and not fix the problem.

I do not believe this is a z-buffer problem. When transparency mode is NONE,
everything behaves as it should. Also, my back/front clip ratio is only 2,
AND, the geometry always gets drawn in the wrong order as perfect quads, no
striping or flickering as you would expect with z-buffer precision problems.

I have attempted to replicate this in a simple test case but I have yet to
see the problem there. My geometry is such that the centroid of white
geometry should be always closer to the eye than the red geometry, so
sorting as Java3D defines it should work fine. Note that this is happen in
other places in my scene as well, but this is the easiest example.

Is there any strange combination of things that could prevent proper
transparency sorting even if it is requested in the view? I figured I would
ask here before I start compiling and debugging java3d-core myself (which I
really rather not spend time doing).

I have attached screen shots showing the different behaviors.

Thanks,
-mike

[no_trans_scene.png]
[with_trans_scene_geom_sorting.png]
[with_trans_scene_no_sorting.png]
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Kevin Rushforth

On Mon, 2004-07-19 at 04:48, Mike Pilone wrote:
> It is still unclear to me why transparency_sort_geometry would produce such
> strange results. Rendering from back to front should render the earth's
> surface, then the clouds, correct? Depth testing shouldn't come into play
> from my viewpoint. I'm still not convinced that this is a rendering
> artifact/oddity and not a bug in J3D.

Depth-sorted transparency using TRANSPARENCY_SORT_GEOMETRY is done based
on the bounds of the geometry as a whole, not on the individual
triangles (this is documented in the API description).

The current implementation, which is fast if not particularly accurate,
sorts the geometry objects based on the centroid of their bounds. Two
concentric spheres have the same centroid and, as such can't be sorted
accurately. A more accurate approach (but still not fool-proof) would be
to find the distance from the eye-point to the closest point on the
bounds of each geometry object and sort based on that.

The bottom line is that any bounds-based sorting is limited by how
tightly the bounds encloses the geometry. You can trade off speed for
accuracy by breaking up your geometry into smaller chunks, with the two
extremes being putting all geometry in one geometry array on the one end
versus putting each triangle in its own geometry array on the other end.

-- Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Mike Pilone

Ok,

>From the information you guys have provided I may have come up with an
explanation. I am rendering separate geometries for the earth and clouds,
they are not actually spheres or I would agree that things would be really
broken since the centroid of both of the spheres would be identical.

Each 'sphere' is composed of many smaller squares which are triangle fans.
What I am seeing is some of the squares flipping above or below other
squares as the viewer moves. The cloud layer is not co-planer with the earth
layer, so I don't believe an ordered group is required. There is a 10,000
unit separation in the layers.

I believe that what I am seeing may be a side effect of using the geometry
centroid for sorting. Depending on the angle to the eye, the distance to the
centroid can cause the earth layer to be closer to the eye than the cloud
layer. I think the solution would be what Kevin suggests, using a better
sorting metric such as closest point to the eye rather than centroid. For
now I guess I'll have to find a way around it.

Thanks for all the comments,
-mike

-----Original Message-----
From: Kevin Rushforth [mailto:Kevin.Rushforth@Sun.COM]
Sent: Monday, July 19, 2004 12:45 PM
To: interest@java3d.dev.java.net
Subject: RE: [JAVA3D-INTEREST] Transparency Sorting Problems

On Mon, 2004-07-19 at 04:48, Mike Pilone wrote:
> It is still unclear to me why transparency_sort_geometry would produce
such
> strange results. Rendering from back to front should render the earth's
> surface, then the clouds, correct? Depth testing shouldn't come into play
> from my viewpoint. I'm still not convinced that this is a rendering
> artifact/oddity and not a bug in J3D.

Depth-sorted transparency using TRANSPARENCY_SORT_GEOMETRY is done based
on the bounds of the geometry as a whole, not on the individual
triangles (this is documented in the API description).

The current implementation, which is fast if not particularly accurate,
sorts the geometry objects based on the centroid of their bounds. Two
concentric spheres have the same centroid and, as such can't be sorted
accurately. A more accurate approach (but still not fool-proof) would be
to find the distance from the eye-point to the closest point on the
bounds of each geometry object and sort based on that.

The bottom line is that any bounds-based sorting is limited by how
tightly the bounds encloses the geometry. You can trade off speed for
accuracy by breaking up your geometry into smaller chunks, with the two
extremes being putting all geometry in one geometry array on the one end
versus putting each triangle in its own geometry array on the other end.

-- Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Florin Herinean

Please remember that there is no "real" transparency in realtime graphics.
Only blending. Thus transparency is simulated by combining the pixels to be
drawn with the already drawn pixels on the canvas. This leads to interesting
paradoxes, you can search the web for that.

However, java3d assumes that you'll set the transparency attributes only for
transparent objects, not to opaque ones as seems to be in your scene !!! For
transparent objects that does not overlap, the order of drawing is
meaningless, so *BY DEFAULT* Z-Buffer is disabled by java3d when drawing
transparent shapes.

You can use RenderingAttributes.setDepthBufferWriteEnable to control whether
that specific shape participate to z-buffer, or you can set it globaly in
View.setDepthBufferFreezeTransparent

However, please note that enabling z-buffer for transparent objects, makes
the rendering to be order dependent. Objects that are behind transparent
ones will not be drawn at all if by chance the transparent ones were drawn
first (are culled by the z-buffer).

My recomandation is to enable both z-buffering for transparent shapes and
sort by geometry and make sure that you don't have overlapping shapes
z-wise.

Cheers,

Florin

-----Ursprungliche Nachricht-----
Von: Mike Pilone [mailto:mpilone@botch.com]
Gesendet: Freitag, 16. Juli 2004 14:05
An: interest@java3d.dev.java.net
Betreff: [JAVA3D-INTEREST] Transparency Sorting Problems

Hello all,

I have been banging my head over a transparency sorting problem for the last
few days and I can't come up with an answer. I have two spheres in my scene,
one enclosing the other. The sphere's are composed of many individual
Shape3D objects with individual geometry and some shared appearance
attributes (so they are not actually sphere geometries).

When the transparency attribute mode is set to NONE, things behave correctly
and the red shapes are inside the white shapes as it should be. When the
transparency mode is anything else (FASTEST or NICEST), red shapes begin to
show in front of the white shapes. Assuming this was a transparency sorting
problem, I enabled View.TRANSPARENCY_SORT_GEOMETRY. However this appears to
make things worse and not fix the problem.

I do not believe this is a z-buffer problem. When transparency mode is NONE,
everything behaves as it should. Also, my back/front clip ratio is only 2,
AND, the geometry always gets drawn in the wrong order as perfect quads, no
striping or flickering as you would expect with z-buffer precision problems.

I have attempted to replicate this in a simple test case but I have yet to
see the problem there. My geometry is such that the centroid of white
geometry should be always closer to the eye than the red geometry, so
sorting as Java3D defines it should work fine. Note that this is happen in
other places in my scene as well, but this is the easiest example.

Is there any strange combination of things that could prevent proper
transparency sorting even if it is requested in the view? I figured I would
ask here before I start compiling and debugging java3d-core myself (which I
really rather not spend time doing).

I have attached screen shots showing the different behaviors.

Thanks,
-mike

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Mike Pilone

Florin,

Thanks for the great information, although I am still not getting the
results I expect. I believe I might not understand something completely.

I set the view to not freeze the z-buffer:
view.setDepthBufferFreezeTransparent(false);

and I set depth buffer writing on for all of my shapes (although this is the
default for rendering attributes, so I don't believe it should change
anything):
renderAttribs.setDepthBufferWriteEnable(true);

I also enabled transparency sorting:
view.setTransparencySortingPolicy(View.TRANSPARENCY_SORT_GEOMETRY);

So, from my understanding of Java3D, all opaque objects should be drawn,
then transparent objects sorted based on distance from the eye, then drawn
from back to front.

In my scene (see the attached screenshot), the earth (the inner geometry) is
getting randomly blocked out by the clouds (the outer geometry). All of the
visible geometry has a transparency attributes set, however the transparency
attribs value is 0 and the cloud transparency is coming from the texture:
textureAttribs.setTextureMode(TextureAttributes.COMBINE);
textureAttribs.setCombineRgbMode(TextureAttributes.COMBINE_REPLACE);
textureAttribs.setCombineAlphaMode(TextureAttributes.COMBINE_MODULATE);

So, based on the java3d rendering sequence as I know it, the earth (inner
geometry) should be rendered first, followed by the clouds (outer geometry),
which should properly apply the alpha value to the earth pixels already
drawn. I don't understand the result I am getting and why it is random and
not predictable. The changes to the depth buffer appear to solve the problem
of the earth rendering above the clouds, but now it renders randomly below.

Anymore thoughts or links to information would be greatly appreciated.

Thanks,
-mike

-----Original Message-----
From: Florin Herinean [mailto:fherinean@carnot.ag]
Sent: Friday, July 16, 2004 8:29 AM
To: interest@java3d.dev.java.net
Subject: AW: [JAVA3D-INTEREST] Transparency Sorting Problems

Please remember that there is no "real" transparency in realtime graphics.
Only blending. Thus transparency is simulated by combining the pixels to be
drawn with the already drawn pixels on the canvas. This leads to interesting
paradoxes, you can search the web for that.

However, java3d assumes that you'll set the transparency attributes only for
transparent objects, not to opaque ones as seems to be in your scene !!! For
transparent objects that does not overlap, the order of drawing is
meaningless, so *BY DEFAULT* Z-Buffer is disabled by java3d when drawing
transparent shapes.

You can use RenderingAttributes.setDepthBufferWriteEnable to control whether
that specific shape participate to z-buffer, or you can set it globaly in
View.setDepthBufferFreezeTransparent

However, please note that enabling z-buffer for transparent objects, makes
the rendering to be order dependent. Objects that are behind transparent
ones will not be drawn at all if by chance the transparent ones were drawn
first (are culled by the z-buffer).

My recomandation is to enable both z-buffering for transparent shapes and
sort by geometry and make sure that you don't have overlapping shapes
z-wise.

Cheers,

Florin

-----Ursprungliche Nachricht-----
Von: Mike Pilone [mailto:mpilone@botch.com]
Gesendet: Freitag, 16. Juli 2004 14:05
An: interest@java3d.dev.java.net
Betreff: [JAVA3D-INTEREST] Transparency Sorting Problems

Hello all,

I have been banging my head over a transparency sorting problem for the last
few days and I can't come up with an answer. I have two spheres in my scene,
one enclosing the other. The sphere's are composed of many individual
Shape3D objects with individual geometry and some shared appearance
attributes (so they are not actually sphere geometries).

When the transparency attribute mode is set to NONE, things behave correctly
and the red shapes are inside the white shapes as it should be. When the
transparency mode is anything else (FASTEST or NICEST), red shapes begin to
show in front of the white shapes. Assuming this was a transparency sorting
problem, I enabled View.TRANSPARENCY_SORT_GEOMETRY. However this appears to
make things worse and not fix the problem.

I do not believe this is a z-buffer problem. When transparency mode is NONE,
everything behaves as it should. Also, my back/front clip ratio is only 2,
AND, the geometry always gets drawn in the wrong order as perfect quads, no
striping or flickering as you would expect with z-buffer precision problems.

I have attempted to replicate this in a simple test case but I have yet to
see the problem there. My geometry is such that the centroid of white
geometry should be always closer to the eye than the red geometry, so
sorting as Java3D defines it should work fine. Note that this is happen in
other places in my scene as well, but this is the easiest example.

Is there any strange combination of things that could prevent proper
transparency sorting even if it is requested in the view? I figured I would
ask here before I start compiling and debugging java3d-core myself (which I
really rather not spend time doing).

I have attached screen shots showing the different behaviors.

Thanks,
-mike

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

[trans_attribs_z_buf_write.png]
---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Florin Herinean

Ok, now I understand what you want. For your case you don't need to sort by
geometry. You need only to enable z-buffer *and* use an OrderedGroup, so
that the clouds will always be rendered after the earth.

Good luck,

Florin

-----Ursprungliche Nachricht-----
Von: Mike Pilone [mailto:mpilone@botch.com]
Gesendet: Freitag, 16. Juli 2004 16:44
An: interest@java3d.dev.java.net
Betreff: RE: [JAVA3D-INTEREST] Transparency Sorting Problems

Florin,

Thanks for the great information, although I am still not getting the
results I expect. I believe I might not understand something completely.

I set the view to not freeze the z-buffer:
view.setDepthBufferFreezeTransparent(false);

and I set depth buffer writing on for all of my shapes (although this is the
default for rendering attributes, so I don't believe it should change
anything):
renderAttribs.setDepthBufferWriteEnable(true);

I also enabled transparency sorting:
view.setTransparencySortingPolicy(View.TRANSPARENCY_SORT_GEOMETRY);

So, from my understanding of Java3D, all opaque objects should be drawn,
then transparent objects sorted based on distance from the eye, then drawn
from back to front.

In my scene (see the attached screenshot), the earth (the inner geometry) is
getting randomly blocked out by the clouds (the outer geometry). All of the
visible geometry has a transparency attributes set, however the transparency
attribs value is 0 and the cloud transparency is coming from the texture:
textureAttribs.setTextureMode(TextureAttributes.COMBINE);
textureAttribs.setCombineRgbMode(TextureAttributes.COMBINE_REPLACE);
textureAttribs.setCombineAlphaMode(TextureAttributes.COMBINE_MODULATE);

So, based on the java3d rendering sequence as I know it, the earth (inner
geometry) should be rendered first, followed by the clouds (outer geometry),
which should properly apply the alpha value to the earth pixels already
drawn. I don't understand the result I am getting and why it is random and
not predictable. The changes to the depth buffer appear to solve the problem
of the earth rendering above the clouds, but now it renders randomly below.

Anymore thoughts or links to information would be greatly appreciated.

Thanks,
-mike

-----Original Message-----
From: Florin Herinean [mailto:fherinean@carnot.ag]
Sent: Friday, July 16, 2004 8:29 AM
To: interest@java3d.dev.java.net
Subject: AW: [JAVA3D-INTEREST] Transparency Sorting Problems

Please remember that there is no "real" transparency in realtime graphics.
Only blending. Thus transparency is simulated by combining the pixels to be
drawn with the already drawn pixels on the canvas. This leads to interesting
paradoxes, you can search the web for that.

However, java3d assumes that you'll set the transparency attributes only for
transparent objects, not to opaque ones as seems to be in your scene !!! For
transparent objects that does not overlap, the order of drawing is
meaningless, so *BY DEFAULT* Z-Buffer is disabled by java3d when drawing
transparent shapes.

You can use RenderingAttributes.setDepthBufferWriteEnable to control whether
that specific shape participate to z-buffer, or you can set it globaly in
View.setDepthBufferFreezeTransparent

However, please note that enabling z-buffer for transparent objects, makes
the rendering to be order dependent. Objects that are behind transparent
ones will not be drawn at all if by chance the transparent ones were drawn
first (are culled by the z-buffer).

My recomandation is to enable both z-buffering for transparent shapes and
sort by geometry and make sure that you don't have overlapping shapes
z-wise.

Cheers,

Florin

-----Ursprungliche Nachricht-----
Von: Mike Pilone [mailto:mpilone@botch.com]
Gesendet: Freitag, 16. Juli 2004 14:05
An: interest@java3d.dev.java.net
Betreff: [JAVA3D-INTEREST] Transparency Sorting Problems

Hello all,

I have been banging my head over a transparency sorting problem for the last
few days and I can't come up with an answer. I have two spheres in my scene,
one enclosing the other. The sphere's are composed of many individual
Shape3D objects with individual geometry and some shared appearance
attributes (so they are not actually sphere geometries).

When the transparency attribute mode is set to NONE, things behave correctly
and the red shapes are inside the white shapes as it should be. When the
transparency mode is anything else (FASTEST or NICEST), red shapes begin to
show in front of the white shapes. Assuming this was a transparency sorting
problem, I enabled View.TRANSPARENCY_SORT_GEOMETRY. However this appears to
make things worse and not fix the problem.

I do not believe this is a z-buffer problem. When transparency mode is NONE,
everything behaves as it should. Also, my back/front clip ratio is only 2,
AND, the geometry always gets drawn in the wrong order as perfect quads, no
striping or flickering as you would expect with z-buffer precision problems.

I have attempted to replicate this in a simple test case but I have yet to
see the problem there. My geometry is such that the centroid of white
geometry should be always closer to the eye than the red geometry, so
sorting as Java3D defines it should work fine. Note that this is happen in
other places in my scene as well, but this is the easiest example.

Is there any strange combination of things that could prevent proper
transparency sorting even if it is requested in the view? I figured I would
ask here before I start compiling and debugging java3d-core myself (which I
really rather not spend time doing).

I have attached screen shots showing the different behaviors.

Thanks,
-mike

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Mike Pilone

Unfortunately I don't believe an ordered group will work too well for me. My
application supports terrain visualization when close to the earth and off
axis. Without proper geometry sorting mountains in the distance appear in
front of the nearer features. I believe it would be too much overhead to try
and sort my geometry myself using an ordered group and it would be much more
efficient to do it in the renderer after a majority has been view frustum
culled.

It is still unclear to me why transparency_sort_geometry would produce such
strange results. Rendering from back to front should render the earth's
surface, then the clouds, correct? Depth testing shouldn't come into play
from my viewpoint. I'm still not convinced that this is a rendering
artifact/oddity and not a bug in J3D.

Anyone have a comment?

-mike

-----Original Message-----
From: Florin Herinean [mailto:fherinean@carnot.ag]
Sent: Friday, July 16, 2004 10:09 AM
To: interest@java3d.dev.java.net
Subject: AW: [JAVA3D-INTEREST] Transparency Sorting Problems

Ok, now I understand what you want. For your case you don't need to sort by
geometry. You need only to enable z-buffer *and* use an OrderedGroup, so
that the clouds will always be rendered after the earth.

Good luck,

Florin

-----Ursprungliche Nachricht-----
Von: Mike Pilone [mailto:mpilone@botch.com]
Gesendet: Freitag, 16. Juli 2004 16:44
An: interest@java3d.dev.java.net
Betreff: RE: [JAVA3D-INTEREST] Transparency Sorting Problems

Florin,

Thanks for the great information, although I am still not getting the
results I expect. I believe I might not understand something completely.

I set the view to not freeze the z-buffer:
view.setDepthBufferFreezeTransparent(false);

and I set depth buffer writing on for all of my shapes (although this is the
default for rendering attributes, so I don't believe it should change
anything):
renderAttribs.setDepthBufferWriteEnable(true);

I also enabled transparency sorting:
view.setTransparencySortingPolicy(View.TRANSPARENCY_SORT_GEOMETRY);

So, from my understanding of Java3D, all opaque objects should be drawn,
then transparent objects sorted based on distance from the eye, then drawn
from back to front.

In my scene (see the attached screenshot), the earth (the inner geometry) is
getting randomly blocked out by the clouds (the outer geometry). All of the
visible geometry has a transparency attributes set, however the transparency
attribs value is 0 and the cloud transparency is coming from the texture:
textureAttribs.setTextureMode(TextureAttributes.COMBINE);
textureAttribs.setCombineRgbMode(TextureAttributes.COMBINE_REPLACE);
textureAttribs.setCombineAlphaMode(TextureAttributes.COMBINE_MODULATE);

So, based on the java3d rendering sequence as I know it, the earth (inner
geometry) should be rendered first, followed by the clouds (outer geometry),
which should properly apply the alpha value to the earth pixels already
drawn. I don't understand the result I am getting and why it is random and
not predictable. The changes to the depth buffer appear to solve the problem
of the earth rendering above the clouds, but now it renders randomly below.

Anymore thoughts or links to information would be greatly appreciated.

Thanks,
-mike

-----Original Message-----
From: Florin Herinean [mailto:fherinean@carnot.ag]
Sent: Friday, July 16, 2004 8:29 AM
To: interest@java3d.dev.java.net
Subject: AW: [JAVA3D-INTEREST] Transparency Sorting Problems

Please remember that there is no "real" transparency in realtime graphics.
Only blending. Thus transparency is simulated by combining the pixels to be
drawn with the already drawn pixels on the canvas. This leads to interesting
paradoxes, you can search the web for that.

However, java3d assumes that you'll set the transparency attributes only for
transparent objects, not to opaque ones as seems to be in your scene !!! For
transparent objects that does not overlap, the order of drawing is
meaningless, so *BY DEFAULT* Z-Buffer is disabled by java3d when drawing
transparent shapes.

You can use RenderingAttributes.setDepthBufferWriteEnable to control whether
that specific shape participate to z-buffer, or you can set it globaly in
View.setDepthBufferFreezeTransparent

However, please note that enabling z-buffer for transparent objects, makes
the rendering to be order dependent. Objects that are behind transparent
ones will not be drawn at all if by chance the transparent ones were drawn
first (are culled by the z-buffer).

My recomandation is to enable both z-buffering for transparent shapes and
sort by geometry and make sure that you don't have overlapping shapes
z-wise.

Cheers,

Florin

-----Ursprungliche Nachricht-----
Von: Mike Pilone [mailto:mpilone@botch.com]
Gesendet: Freitag, 16. Juli 2004 14:05
An: interest@java3d.dev.java.net
Betreff: [JAVA3D-INTEREST] Transparency Sorting Problems

Hello all,

I have been banging my head over a transparency sorting problem for the last
few days and I can't come up with an answer. I have two spheres in my scene,
one enclosing the other. The sphere's are composed of many individual
Shape3D objects with individual geometry and some shared appearance
attributes (so they are not actually sphere geometries).

When the transparency attribute mode is set to NONE, things behave correctly
and the red shapes are inside the white shapes as it should be. When the
transparency mode is anything else (FASTEST or NICEST), red shapes begin to
show in front of the white shapes. Assuming this was a transparency sorting
problem, I enabled View.TRANSPARENCY_SORT_GEOMETRY. However this appears to
make things worse and not fix the problem.

I do not believe this is a z-buffer problem. When transparency mode is NONE,
everything behaves as it should. Also, my back/front clip ratio is only 2,
AND, the geometry always gets drawn in the wrong order as perfect quads, no
striping or flickering as you would expect with z-buffer precision problems.

I have attempted to replicate this in a simple test case but I have yet to
see the problem there. My geometry is such that the centroid of white
geometry should be always closer to the eye than the red geometry, so
sorting as Java3D defines it should work fine. Note that this is happen in
other places in my scene as well, but this is the easiest example.

Is there any strange combination of things that could prevent proper
transparency sorting even if it is requested in the view? I figured I would
ask here before I start compiling and debugging java3d-core myself (which I
really rather not spend time doing).

I have attached screen shots showing the different behaviors.

Thanks,
-mike

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Florin Herinean

Hi Mike

Your problem is very well known in the computer graphics. It's not specific
to java3d, you'll see it in any graphic language (opengl, directx) or 3d
application. You can solve it only in 2 ways:

1. make use of the OrderedGroups to ensure that the transparent things are
drawn in the correct order,

2. tear down your geometry in many small *individual* quads or triangles.

Now let me explain again *your* problem:

a) from the engine point of view, it seems that both the earth and the
clouds are transparent, i.e. they have a TransparencyAttribute set, so the
"draw opaque first, then transparent" won't work.

b) the earth and the clouds are both approx. concentric spheres. The
transparency sort will not work, since the *shapes* (and not the individual
triangles composing the shapes) are located at the same "z". So the engine
may decide to draw sometimes first the clouds, sometimes the earth,
depending on the rounding errors.

Solution 2 will give you good *geometric* results, but the performance will
be completely compromised if you'll need to have one shape for every
triangle or quad.

So, in my opinion, you have to use OrderedGroups. Incidentaly, OrderedGroups
are also a solution for using multiple transparent layers !

You may combine geometry sorting with ordered groups.

I'm seing the ordered group as containing 2 branch groups: one with all the
earth / terrain visualisation stuff, and the second containing clouds and
atmospheric effects.

I don't see why the terrain visualization makes difficult the use of
OrderedGroups at the very top level.

Cheers,

Florin

-----Ursprungliche Nachricht-----
Von: Mike Pilone [mailto:mpilone@botch.com]
Gesendet: Montag, 19. Juli 2004 13:49
An: interest@java3d.dev.java.net
Betreff: RE: [JAVA3D-INTEREST] Transparency Sorting Problems

Unfortunately I don't believe an ordered group will work too well for me. My
application supports terrain visualization when close to the earth and off
axis. Without proper geometry sorting mountains in the distance appear in
front of the nearer features. I believe it would be too much overhead to try
and sort my geometry myself using an ordered group and it would be much more
efficient to do it in the renderer after a majority has been view frustum
culled.

It is still unclear to me why transparency_sort_geometry would produce such
strange results. Rendering from back to front should render the earth's
surface, then the clouds, correct? Depth testing shouldn't come into play
from my viewpoint. I'm still not convinced that this is a rendering
artifact/oddity and not a bug in J3D.

Anyone have a comment?

-mike

-----Original Message-----
From: Florin Herinean [mailto:fherinean@carnot.ag]
Sent: Friday, July 16, 2004 10:09 AM
To: interest@java3d.dev.java.net
Subject: AW: [JAVA3D-INTEREST] Transparency Sorting Problems

Ok, now I understand what you want. For your case you don't need to sort by
geometry. You need only to enable z-buffer *and* use an OrderedGroup, so
that the clouds will always be rendered after the earth.

Good luck,

Florin

-----Ursprungliche Nachricht-----
Von: Mike Pilone [mailto:mpilone@botch.com]
Gesendet: Freitag, 16. Juli 2004 16:44
An: interest@java3d.dev.java.net
Betreff: RE: [JAVA3D-INTEREST] Transparency Sorting Problems

Florin,

Thanks for the great information, although I am still not getting the
results I expect. I believe I might not understand something completely.

I set the view to not freeze the z-buffer:
view.setDepthBufferFreezeTransparent(false);

and I set depth buffer writing on for all of my shapes (although this is the
default for rendering attributes, so I don't believe it should change
anything):
renderAttribs.setDepthBufferWriteEnable(true);

I also enabled transparency sorting:
view.setTransparencySortingPolicy(View.TRANSPARENCY_SORT_GEOMETRY);

So, from my understanding of Java3D, all opaque objects should be drawn,
then transparent objects sorted based on distance from the eye, then drawn
from back to front.

In my scene (see the attached screenshot), the earth (the inner geometry) is
getting randomly blocked out by the clouds (the outer geometry). All of the
visible geometry has a transparency attributes set, however the transparency
attribs value is 0 and the cloud transparency is coming from the texture:
textureAttribs.setTextureMode(TextureAttributes.COMBINE);
textureAttribs.setCombineRgbMode(TextureAttributes.COMBINE_REPLACE);
textureAttribs.setCombineAlphaMode(TextureAttributes.COMBINE_MODULATE);

So, based on the java3d rendering sequence as I know it, the earth (inner
geometry) should be rendered first, followed by the clouds (outer geometry),
which should properly apply the alpha value to the earth pixels already
drawn. I don't understand the result I am getting and why it is random and
not predictable. The changes to the depth buffer appear to solve the problem
of the earth rendering above the clouds, but now it renders randomly below.

Anymore thoughts or links to information would be greatly appreciated.

Thanks,
-mike

-----Original Message-----
From: Florin Herinean [mailto:fherinean@carnot.ag]
Sent: Friday, July 16, 2004 8:29 AM
To: interest@java3d.dev.java.net
Subject: AW: [JAVA3D-INTEREST] Transparency Sorting Problems

Please remember that there is no "real" transparency in realtime graphics.
Only blending. Thus transparency is simulated by combining the pixels to be
drawn with the already drawn pixels on the canvas. This leads to interesting
paradoxes, you can search the web for that.

However, java3d assumes that you'll set the transparency attributes only for
transparent objects, not to opaque ones as seems to be in your scene !!! For
transparent objects that does not overlap, the order of drawing is
meaningless, so *BY DEFAULT* Z-Buffer is disabled by java3d when drawing
transparent shapes.

You can use RenderingAttributes.setDepthBufferWriteEnable to control whether
that specific shape participate to z-buffer, or you can set it globaly in
View.setDepthBufferFreezeTransparent

However, please note that enabling z-buffer for transparent objects, makes
the rendering to be order dependent. Objects that are behind transparent
ones will not be drawn at all if by chance the transparent ones were drawn
first (are culled by the z-buffer).

My recomandation is to enable both z-buffering for transparent shapes and
sort by geometry and make sure that you don't have overlapping shapes
z-wise.

Cheers,

Florin

-----Ursprungliche Nachricht-----
Von: Mike Pilone [mailto:mpilone@botch.com]
Gesendet: Freitag, 16. Juli 2004 14:05
An: interest@java3d.dev.java.net
Betreff: [JAVA3D-INTEREST] Transparency Sorting Problems

Hello all,

I have been banging my head over a transparency sorting problem for the last
few days and I can't come up with an answer. I have two spheres in my scene,
one enclosing the other. The sphere's are composed of many individual
Shape3D objects with individual geometry and some shared appearance
attributes (so they are not actually sphere geometries).

When the transparency attribute mode is set to NONE, things behave correctly
and the red shapes are inside the white shapes as it should be. When the
transparency mode is anything else (FASTEST or NICEST), red shapes begin to
show in front of the white shapes. Assuming this was a transparency sorting
problem, I enabled View.TRANSPARENCY_SORT_GEOMETRY. However this appears to
make things worse and not fix the problem.

I do not believe this is a z-buffer problem. When transparency mode is NONE,
everything behaves as it should. Also, my back/front clip ratio is only 2,
AND, the geometry always gets drawn in the wrong order as perfect quads, no
striping or flickering as you would expect with z-buffer precision problems.

I have attempted to replicate this in a simple test case but I have yet to
see the problem there. My geometry is such that the centroid of white
geometry should be always closer to the eye than the red geometry, so
sorting as Java3D defines it should work fine. Note that this is happen in
other places in my scene as well, but this is the easiest example.

Is there any strange combination of things that could prevent proper
transparency sorting even if it is requested in the view? I figured I would
ask here before I start compiling and debugging java3d-core myself (which I
really rather not spend time doing).

I have attached screen shots showing the different behaviors.

Thanks,
-mike

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

Matthew Hilliard

Hi Mike.

My own encounters with this problem revolves around the way the depth is
calculated for transparency and blending in j3d.
From my own personal experience, it is the weakest feature of the API.

The first problem you may encounter here is that multiple faces for a
single geometry may be drawn in the incorrect order--this is less of a
problem for single sided, convex shapes, but given a million artists at a
million typewriters, you'll find very little geometry in the real world
that doesn't experience this.
There is an obvious work around here which is to break down a geometry into
a single geometry for every face. Not a pretty solution, but it does the job.

The next problem you'll encounter (that also seems to be the one you're
describing) is the sorting mechanism in J3D doesn't sort the geometries for
its blending pass very well. While 3D engines such as those put out by
Epic and id use BSPs to not only effectively place faces in the correct
rendering order, but also split them in the event of a depth overlap--J3D
seems to base the order on the *AVERAGE* depth of the geometry in
question--my best educated guess (someone correct me please) is it uses the
depth of a bounding box or similar mechanism which only works most of the
time, to sort back to front.
This is a fair solution, as it is lightweight, very fast, and lends itself
very well to the existing J3D scenegraph.
Where it breaks down very quickly is the blending of very large geometries
such as clouds, skylines and walls, which are mostly behind another blended
object, yet appear in front, because some portion of the large object
stretches its bounding box in front of the other. The trick here seems to
be break down large objects into severely smaller ones. Remember this
problem will still occur with large faces, so you'll have to tessellate
large faces and split those into separate geometries as well as well
(pre-calcualte this if you can, its a nightmare at runtime). Even this
isn't perfect, since there is still room for polys with large differences
between their near and far distances to overlap incorrectly and
occasionally "pop" in and out of sight--but it does minimize the visual
headache, and gives you a place to start.

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

cs
Offline
Joined: 2005-03-24

hello everybody,

i think i'm experiencing the same problem. my 3d world contains some objects within a huge sphere, with both objects and sphere having TransparencyAttributes set. in some positions of my ViewPlatform, the sphere is rendered in front of the objects. i can confirm that this depends on whether the sphere's center or the object's boundingsphere center is closer to the view platform.

my question.. is there presently any work done regarding a better sorting policy? or any fix? i don't want to use some OrderedGroup, as my scene graph is kind of generic.

thanks,
cs
--