Significant transparency difference on different GPU's

[K24A3]

I'm using low transparency on my three multilayered skyboxes (3DS files not the jPCT skybox) and have found that there is a huge difference on two different GPU's, namely the Tegra2 and PowerVR (Omap 4430).

To equalize the transparency on both devices, I need to set the transparency much higher on the PowerVR.

Using Transparency of 4 looks vibrant on the Tegra2, but almost black on the PowerVR.
Using Transparency of 16 looks great on the PowerVR but too bright and very washed out on the Tegra2.

Setting the transparency to Additive doesn't resolve the problem.
I tried setting the transparency of the layers incrementally (for example 2, then 4, then 8 ) but that doesn't help.

I'm assuming it's a design trait of the GPU's in question, so the solution would be to detect the GPU and set the transparency accordingly or let the user modify the values manually.

Is this a generally known issue? Does jPCT calculate transparency based on OpenGL flags? Or am I missing something?

(OpenGL ES 1.1, jPCT 1.24)

[EgonOlsen]

No, jPCT just sets the requested value via OpenGL. What the GPU do what that value is up to them. It could also be related to the used color depth...maybe that's different!?
Anyway, i can't anything about it....i think. To be 100% sure, some screen shots would help.

[K24A3]

This is interesting, I took screenshots on both devices and they look almost identical in the images. So it must be a result of the manufactures screen calibration or something. I'll add an option to let the user change it manually.

Thanks.

(Edit: Color depth is 32bit on both devices)

[K24A3]

I've ran into a strange transparency glitch that I can't figure out.

I have a transparent skybox/sphere using additive transparency, with normal transparent 3D objects inside.
Intermittently the brightness of the objects change drastically. For 20 seconds they look normal, then suddenly drop in brightness for no apparent reason as if a light went out.

I have disabled all lights except for ambient but it still happens.
If I make the skybox solid (no transparency) the problem goes away.
If I make the objects solid the problem goes away.

So I'm thinking it's a transparency calculation problem in either OpenGL or jPCT since it's happening on two totally different GPU's.

Have you seen this kind of behavior before?
I'm currently putting together a test app to send to you.

[EgonOlsen]

Have you seen this kind of behavior before?
I'm currently putting together a test app to send to you.

Yes, i've seem something like this lately, but in the desktop version. I'm not sure right now, if this was something to fix in jPCT-AE as well and if it was, if i actually did it. I'll wait for your test case and check it out...

[K24A3]

I'm having a bit of difficulty replicating it in the test app but I'll send it through when ready.

It seems to only affect 3DS files, not primitives. I have around 64 simple planes (in my project) and 128 cubes (in the test app) which are not affected at all.
So perhaps it's a culling issue with file-based objects (just a guess).

[EgonOlsen]

Or maybe some sorting issue? Do you have a screen shot?

[K24A3]

It's quite intermittent so it's difficult to get a good screenshot. I'll get onto it tomorrow since it's getting late here.

It seems to only affect objects that are in a brightly textured part of the sky-sphere, affecting massive 3D objects in the distance spanning ~1000 units (the object is one piece but only the polygons in the bright texture space are affected). It's also affecting very small nearby objects. Transparency multiplication error perhaps..

Edit.. I'll have to double check but I believe the massive object is well within the sky-sphere so I don't think it's a clipping issue. Clipping is set to world.setClippingPlanes(-1, 18000);

[K24A3]

I managed to replicate the problem very well in the test app and have sent you the project files.

As the camera moves around, you'll notice that the small star-like shapes change in transparency, usually when the objects are close to the camera. The different camera angles also seems to affect it.

The large textured "road" also changes transparency if very close but you'll need to turn off the automatic camera translation and use the accelerometer to move the cam around.

The yellow cones which are part of the shapes disappear at certain angles but I think that is a different issue related to Z-buffering.

Note that in my other app the transparency glitch affects polygons in the distance so I don't think it's necessarily a problem with objects close to the camera.

As mentioned before, if you turn off the transparency of either the shapes or the sky-sphere, the problem goes away.


...attached an image showing the problem. On the right side, the top shape is a deep red, the bottom shape is the expected transparency.

[attachment deleted by admin]

[EgonOlsen]

As i already guessed, it's a sorting issue. I was somehow thinking that you were using the build-in SkyBox-class, which is why i got a little confused (because that one shouldn't suffer from this problem). The problem is, that transparent objects has to be drawn in proper order. To determine this order, they are sorted based on their center in camera space. For the skybox, this can't give you proper sorting in all cases, because it spans the whole scene. There are three possible solutions to this:

• do skydome1.setSortOffset(100000); right after creating the object
• render the skydome/box in another instance of World. That's what the SkyBox-class does, but it's more code to do this.
• don't use transparency on the skybox if possible...why are you doing this anyway? It eats up your fillrate...should there be objects behind the skybox? In that case, you might have to fiddle around with the sort offsets some more.

[K24A3]

Ok I see how it works now, setSortOffset has resolved the problem in the test app, I'll try it in my other app later today.

I need it to be transparent for the effect I need, and I realize the performance impact. The performance is borderline acceptable on the Tegra2, but has virtually no impact on the Omap. But in saying that, the Tegra2 was never good at 32bit framebuffers anyway since the core is optimized for 16bit dithered color if I recall correctly.

Appreciate the help, thanks.

[K24A3]

It's all good in the other app as well.

I got a few more FPS by making the furthest skydome's opaque, which obviously made that dome much brighter. Using negative values in setAdditionalColor() doesn't make it darker but that's fine I'll just adjust the ambient lighting or darken the texture itself.