supercube animation

supercube animation

Description

cube of cubes of cubes of cubes
Cube of cubes of cubes of cubes flythrough. Uses radiosity and raytracing. Uses nodes.

Message boards : Comments and discussion : 710

Author Message
Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4467
Credit: 2,094,806
RAC: 0
Message 7203 - Posted: 25 Dec 2007, 15:00:40 UTC

Interesting cube you got there. Are the surfaces that flicker multilayered or single-layered - looks like some kind of z-buffer issue?

Profile batan
Send message
Joined: 29 Aug 07
Posts: 69
Credit: 39,901
RAC: 0
Message 7378 - Posted: 8 Jan 2008, 10:00:29 UTC - in response to Message 7203.

Interesting cube you got there. Are the surfaces that flicker multilayered or single-layered - looks like some kind of z-buffer issue?


I have had this problem repeatedly and I don\'t know exactly what causes it. It seems to me that the problem mostly appears with right-angled or parallel surfaces, even when no reflectivity is used. I think maybe it has something to do with ray samples and light incidence at certain angles, switching back and forth. Actually I think it\'s a Blender bug, because I didn\'t have any similar problem before with other software.
The bad thing about it is that you usually don\'t detect it with single-frame test renders.

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4467
Credit: 2,094,806
RAC: 0
Message 7382 - Posted: 8 Jan 2008, 10:47:02 UTC
Last modified: 8 Jan 2008, 10:55:48 UTC

It\'s not a bug but rather a consequence of the way any 3D renderer works - it happens even in OpenGL implementations and commercial rendering applications.

Basically any renderer (at least those that use the basic rendering ideas which have been in widespread use for quite a while now) uses some kind of buffer to determine what faces are in front of what other faces in each point in the image - in other words, they have to represent whatever structure \"will be present under that pixel\" so that they can render the correct colour and lighting for that pixel. This is mildly simplified - you can read more about it on the net here (z-fighting) and here (z-buffering).

The problem is when more than one structure/face in the scene is a potential hit. How can this happen?, you ask. Well, if more than one face is close enough to each other they will (depending on the distance to the camera) fall bellow the resolution of the zbuffer - in laymans terms the zbuffer can no longer distinguish which face is in front of the other.

Example (working as intended):
Face A is located 10 meters away from the camera and facing the camera, face B is also facing the camera but is 11 meters away.
The zbuffer in this example has a resolution of 1 meter and hence will always be able to distinguish these two structures.

Example 2 (still working):
Now we move face A 0.4 meter further away from the camera so that A is at 10.4m and B is at 11m. Zbuffer res is still 1m.
Now what does the zbuffer do when it finds something that it cannot represent? Round it:
A: 10.4m rounded is 10m
B: 11m rounded is 11m
Nice, still working A is in front of B.

Example 3 (working sometimes - what you see in this session)
Let\'s move the camera back by 0.2m now. This puts A at a distance of 10.6m and B at 11.2m.
Rounding:
A: 10.6m rounded is 11m
B: 11.2m rounded is also 11m
Oops! What happens now is pseudorandom and depends on a lot of weird stuff that I\'m not going to go into, but basicly the renderer goes \"Erhm...? Whatever.\" and just picks one of the faces - which will sometimes result in B and sometimes in A.
Since A was originally in front of B it may have received more light in the lighting calculations and B may be entirely overshadowed by A. This causes the flickering that you see in this session when the renderer switches between A and B for different frames.

Ok, but the faces in this session aren\'t close to each other and the zbuffer in Blender has a very nice resolution, what goes wrong?
Looking at your scene an interesting thing shows up: Each vertex is presented numerous times! This may be an effect of whatever exporter/importer you have used. Effectively this puts a lot of faces very close (in fact infinitely close) to each other and is bound to result in a lot of trouble.

Have a look here:


There\'s a tool in Blender that allows you to \"Remove duplicates\" when selecting the entire set of vertices in edit mode. This should give you a perfect looking mesh and permanently remove any zbuffering issues in the scene. Also it is likely to speed up the preview and rendering of the scene a lot.

Profile batan
Send message
Joined: 29 Aug 07
Posts: 69
Credit: 39,901
RAC: 0
Message 7511 - Posted: 18 Jan 2008, 12:59:45 UTC

I just saw your message, Janus, about reasons for flicker in a scene. Thanks a lot for explaining that, it is really useful and of course I like to understand things. About the multiple vertices on top of each other - yes, that seems plausible. I will keep that in mind and check for duplicates in the future.
However I must say that I have never had this problem with 3D Studio, even with duplicate mesh present. But working with Blender is much faster and easier.

Is there any way to influence / set the z-buffer resolution?
Nevermind, I\'ve just read in the Wikipedia article that the z-buffer resolution is dynamically assigned according to the distance of the objects against the camera (because far objects don\'t need to be so exactly represented as close ones). As far as I remember, the scenes where I had flickering were large scenes, with objects very close and others at great distance from the camera - so that might have been a factor.
So, again, thanks -- I\'ll work on this.


Post to thread

Message boards : Comments and discussion : 710