Hi,
Consider this: smooth colour, a quad, defined
anticlockwise, red and green on opposing diagonals.
On, SGI O2 - I get the green channel as the main render colour, and at maximum intensity on the green-green diagonal.
On an HP sv6 console device OR via eXceed3D
it’s the same for the same code.
However, over the network sv6 ->> O2, the same code produces the red channel as the main colour, with the maximum intensity on
the red-red diagonal.
Clearly, this problem leads to all kinds of rendering errors in complex scenes.
Anyone any ideas where I look for a clues!
If I simply move the first vertex/colour
data to the end of the quad definition, then the O2 will give the same result at the first sv6->O2 code.
So, to me it would seem the hardware is drawing the 2 triangles for the quad in a different order when the data comes over the net!
The same problem happens with a basic triangle too!
Anyone any experience here please?
Regards,
Rob.
Originally posted by Rob Fletcher:
<…>
So, to me it would seem the hardware is drawing the 2 triangles for the quad in a different order when the data comes over the net!
Yup.
That’s because your quad is non-planar (in color space, but that doesn’t matter). As you see this leads to all sorts of ‘undefined’ behaviour. Explicitly split your quads and it’ll work consistently across platforms.
Which leads us to …
The same problem happens with a basic triangle too!
How did you manage to do that?
First shot I’d say that’s impossible (as long as you don’t run out of numerical precision).
Hmmm …
Hi Z,
Just retested the triangle case … nope I was wrong. They are OK!
I got a reply from an HP BB, and they point out that the decomp process is implementation “dependent”, and therefore you can get undefined and different results on different hardware! Ok Fine, and yes, I would therefore need to do the decomp myself in order to be sure.
I suspect the problem is that the GLX stream I am getting over the net has been subjected to the decomp process on the HP before being sent to me, and this has then been rendered incorrectly (well, differently) by my SGI.
In the end this was my curiosity wanting to know why and how this could happen.
Basically, I can write code on my SGI, and render on the SGI, and the same code will port and render the SAME on the sv6.
I am wanting to investigate/benchmark the sv6 solution and see what OpenGL constructs perform well on the sv6 and which don’t.
Display lists are the key, but I am curious to know if the box splits up e.g. a large single display list across the multiple processing nodes, or if it is more efficient to create a lot of smaller lists and pass those over.
The box has modified X and OGL libs, and it may be that it is processing the raw GLX stream!
Interesting box … check it out.
Anyone out there using one???
Thanks,
Rob.