z-ordering issues with brain regions

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Load latest build version of WBC (0.7.0.6)
2.Open up brain regions hierarchy in the data type tab
3.Check the "brain stem" box

What is the expected output? What do you see instead?
When all the brain regions are loaded, and you rotate the brain, different 
regions pop in front of others unexpectedly.  It appears that the z-ordering 
is not being consistantly computed.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by stephen....@gmail.com on 4 Jan 2010 at 10:17

[GoogleCodeExporter]

Initially brain regions to appear inside other brain regions, but slight 
rotations 
cause them to appear like they are visible through the enclosing region.

Original comment by stephen....@gmail.com on 4 Jan 2010 at 10:18

[GoogleCodeExporter]

How can I reproduce this with consistency?

Original comment by caprea on 6 Jan 2010 at 7:27

[GoogleCodeExporter]

This may be a place where the OctTreeMesh is useful again.  More on this in the 
old 
issue 220

Original comment by stephen....@gmail.com on 6 Jan 2010 at 11:07

[GoogleCodeExporter]

I've tried every trick I know and even laid a trail of my empirical findings in
r1656
Determined that this bug could not be fixed in a reasonable amount of time, it 
is an
underlying problem with JME. It is possible, but means changes to JME source and
being really efficient and clever in designing our own spatial sort method.

JME uses the center of the bounding box to sort, the solution would do some more
complex geometry calculations to determine the spatial sort.

From the forums;
basixs: the z-buffer is just a 0-1 dataset, there is nothing that ties it to an
object...
you could implement your own ordering system, I think you would basically need 
to
find the farthest point on an object in respect to the camera.  but this would 
still
have issues when there are 'overlapping' objects, also I think it could be 
quite a
performance drain (depending on the number and complexity of the models)...

Momoko_Fan: Check this page for info: http://www.opengl.org/wiki/Alpha_Blending
jME sorts transparent objects back-to-front, so that correct transparency is
achieved. Unfortunately, under certain circumstances, this sorting can cause 
what
you're describing. When two transparent objects are close to one another, and 
you
move the camera to the side, the distance from one object will become closer to 
the
camera and it will be drawn first, thus changing how the scene looks like.

See these threads:
http://jmonkeyengine.com/forum/index.php?topic=7182.0
http://www.jmonkeyengine.com/forum/index.php?topic=11661.0

Looking for acknowledgement or advise before I file this under "WillNotFix"

Original comment by caprea on 7 Jan 2010 at 10:05

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Oops, that previous comment should be referencing r1655

Original comment by caprea on 7 Jan 2010 at 10:08

[GoogleCodeExporter]

From Steve Lamont:

It's not really a problem in jME, _per se_.  It's more because of the
architecture of OpenGL.  The Z buffer is a pretty dumb device and it
depends upon fragments (and thus polygons) being presented in the
proper order to it.  The larger the objects, the more likely that some
polygons will be presented to the renderer in the wrong order.

I have the same problems in Unys and Jinx and have mostly decided to
live with it.

About the only way you can do it is to create a "polygon soup", that
it, a database of individual polygons, and perform a z-sort on each of
the polygons (or, actually, just the transparent ones), then render
back to front.

OctTree is a sort of halfway measure to make the problem a bit more
tractable.

You can reduce the maximum number of polygons in each tree node to
make the problem less apparent but this creates huge numbers of
objects and kills performance.

I don't know how jME does its z-sort.

                                                       spl

Original comment by stephen....@gmail.com on 9 Jan 2010 at 1:56

[GoogleCodeExporter]

Original comment by stephen....@gmail.com on 9 Jan 2010 at 1:57

[GoogleCodeExporter]

Moving back to 0.8 to accommodate other priorities we need to address earlier

Original comment by stephen....@gmail.com on 13 Jan 2010 at 9:34

• Added labels: Milestone-Release0.8
• Removed labels: Milestone-Release0.7.5

[GoogleCodeExporter]

This link may help to address this:

http://jmonkeyengine.org/groups/general-2/forum/topic/weird-transparency-behavio
r/#post-85601

Original comment by stephen....@gmail.com on 13 Sep 2010 at 3:35

[GoogleCodeExporter]

I've tried all of the TestFunction() tricks mentioned in this thread, and left 
comments in the code in the place where I made the changes and how it worked 
out. I'll have to point out that this thread is mostly about the blackness of 
the net being solved, the ordering of the transparency is still an unsolved 
issue for him mentioned in the last reply.

Original comment by caprea on 13 Sep 2010 at 5:48

[GoogleCodeExporter]

I see.  OK, thanks. 

Original comment by stephen....@gmail.com on 13 Sep 2010 at 6:52

[GoogleCodeExporter]

Closing a whole raft of issues because they are not relevant to the web version 
any more

Original comment by stephen....@gmail.com on 7 Mar 2011 at 10:31

• Changed state: WontFix