Surfaces mix in 16 bit

Troubleshooting graphics
1

Greetings everyone,



I have a problem where two parallell surfaces facing the cam “mix” beyond a certain distance from the cam like this:

This only occurs when my screens color quality is set to 16 bit. (not the one in jme properties dialog)



640×502




I have tried to search the forum for this thinking it’s a common problem but with no luck, perhaps because I don’t know what to call it. Does this problem have a name?



Grateful for any help

2

What you have there is 2 object that have the exact same distance from the camera right? That's a common problem with 3D graphics in general and some videocards, but it has nothing to do with jME specific.



What you should do is make sure one object is just a little closer to the camera than the other.

3

Where'd you get those keyboard key images?  Those are nice. :slight_smile:



darkfrog

4

Accually one of the surfaces is a little closer to the camera. I don't have a problem when in 32 bit (screen color, not jme properties) and when standing a bit closer to the surfaces this doesn't occur.



I didn't have this problem before I converted to quake3loader. Then all was dynamic light,



now the static geometry (like the wall the picture is hanging on) is multitextured with lightmaps (i think) and has no dynamic light



and the picture that is hangin on the wall is all dynamic lights.



Could it have something to do with the fact that they have different renderstates?


Where'd you get those keyboard key images? Those are nice.


Thanks, I photographed my laptops keyboard and edited them in Photoshop.
5

I don't suppose you'd be willing to release that work to the public?  They really look very nice.



darkfrog

6

Maybe they need to be even more apart in 16 bit , because perhaps the depth precision is less too. With some video card driver software you can force full precision in all modes too.

7

Oops I just realized something

Could it have something to do with the fact that they have different renderstates?

the problem occurs with two lightmap surfaces too, so its not that.

I don't suppose you'd be willing to release that work to the public?
8

No you can't do that in code, as it's driver/videocard specific. Just make sure the difference in distance is bigger, or reduce the drawing distance of your camera, or give up on 16 bit mode. (who uses that these days really?)

9

I like youre keyboard keys, are they quads rendered in ortho ??

10

To kidneybean: Thanks, Yes they are.

11

Hurray, I think I found the problem!



The lightmap trimeshes was set like this:


triMesh.setRenderQueueMode(Renderer.QUEUE_OPAQUE);



I simply removed that line and the "surface mixing" (anyone got a name for that phenomena) was completely gone no matter how far away the camera is!

I'm trying to understand this. Was the problem the fact that surface nr1 was put in opaque bucket but not surface nr2?
If so should I instead put both surfaces in the opaque bucket?
12

It changes the order of rendering… maybe they flipped position and it works better.



But if you're going to work with transparant objects, you should put all (non transparant) objects in the OPAQUE queue. In the queue the closest object should be rendered first, so let's hope it'll work that way.

13

actually, it is rendered by states now, not distance.  The pictures look a bit like z fighting to me btw.

14

I'd have to agree with Renanse. It looks to be z-fighting, the difference between the near and far plane play a pivotal role in the accuracy of depth calculations for objects further from the camera. What are you setting the near/far planes to? As a test I'd try setting it to something like (1, 500). Try to keep these values as close together as you can get away with, it is very tempting to make them huge.

15
renanse said:

actually, it is rendered by states now, not distance.


Oh yeah. Duh.
16
the difference between the near and far plane


I'm not sure I understand what you mean. Do you mean the distance between the two surfaces that are mixing?

I couldn't make that huge because that would result in misplacement of that plane. The picture that is "hanging" on the wall needs to be rather close to the wall or it will look funny. But thats not what you are talking about right?

As I posted before the problem vanished when I removed the wall trimeshes from the opaque bucket. I later tested putting all non transparent and non ortho stuff in the opaque bucket and that works too.
17

No, the near/far plane of the Camera. This defines how many bits are needed to accurately calculate the depth buffer.



Here's a better explanation:



http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html

18

Thanks, that was a good link. :slight_smile: