Page MenuHome

ray offsetting giving precission problems / render artifacts / cracks on far away geometry
Confirmed, NormalPublicTO DO


System Information
windows 8.1.1 x64, geforce 660

Blender Version
Broken: tested 2.65 till 2.73 #bbf09d9
Worked: !

Short description of error
strange cracks appear on model in cycles render, if i reset rotation most of them disappears, if i reset position all then disappears.

Exact steps for others to reproduce the error
-after opening shift-z to render and you'll see these cracks:

-reset rotation -> some disappears

-reset position -> all disappears

i have checked the mesh no overlapping !

Related Objects

Event Timeline

Yousef Harfoush (bat3a) raised the priority of this task from to 90.
Yousef Harfoush (bat3a) updated the task description. (Show Details)
Yousef Harfoush (bat3a) edited a custom field.
Yousef Harfoush (bat3a) updated the task description. (Show Details)

Think you are hitting a float precision limit here, your model is rather small and quite far away from origin. Yet, I would not expect that kind of issue to happen so soon (not even three orders of magnitude between size and offset)…

Sergey, this one is for you too I guess?

Bastien Montagne (mont29) lowered the priority of this task from 90 to Normal.Feb 28 2015, 2:40 PM

the model is ~0.4 cubed, which is normal for a character, also this sample is taken from a big environment, in which the character should be in place to act.

any progress or a work around? my chars. already been animated and i still can't render them, thank you.
and sorry to annoy.

@Yousef Harfoush (bat3a), it's not strictly speaking easy to solve issue, seems machine arithmetic backfires here.

The possible workaround is to scale the scene up.

The possible workaround is to scale the scene up.

i didn't understand, you mean the scaling assets! which i tried but couldn't because they are already animated.

i also understand it may need time to resolve, thanks for your time.

The problem isnt exactly the object scale, Its the size of the object combine with it being nearly 160 units away from the scene center.

160 isn't really all that big though. (typically these issues happen at around ~5000+).

@Campbell Barton (campbellbarton), it's not that huge numbers to make single precision floats to become an issue imo. But i still didn't nail the root of the issue down and it'll take some time still i'm afraid.

bat3a: in the following diagram we can see that the contrast between the scene size and the facial detail is quite large. The spread between them is approaching 6 decimal places.

It seems like the subtle shadows and AO being rendered on the face are breaking down because of this. It looks like the position info for subtle AO and shadow calculations are being rounded off.

There is a oddity of human perception that makes it very difficult for us to tell the difference between our own movement vs the movement of our surroundings. Relativity something or other.

It's only the feeling of acceleration that gives it away for us. If we feel ourselves moving then we know that we are moving, however, our eyes alone cannot really see the difference.

You can take advantage of this effect by keeping the camera close the origin then moving and rotating the entire scene using the reverse movement of what you would do for the camera.

When viewing from the camera's point of view at, it appears as if it's the camera that is moving through the scene when in fact the camera is completely stationary and it's really the entire set which is moving around.

Here's an example, that show's how to use the idea of relative movement to keep everything viewable near the origin so these problems do not show up.

A tool similar to 'Lock Camera to View', but which moves the entire scene while leaving the Camera at the grid origin(0.0), with 0.0 rotation and a scale of 1.0. should allow for the illusion that the camera is moving through the scene when really the camera is at it's default transform for the entire animation. Otherwise, moving and rotating the set can be a bit unruly without a tool like this.

  • By not transforming the Projection Matrix, errors towards the edges of scenes of never close enough to be visible. Far away objects move towards the camera instead of the Projection moving towards them.
  • Some types of shader math can fall apart when the Projection Matrix is moved or rotated. Parallax/Relief type math is very difficult to work with when the projection is altered.

That problem also clears up when the camera remains stationary.

I moved the model more than 1000 units away from the origin to exaggerate the errors and there seems to be a pattern sort of visible here.

The errors appear to show up mostly in crevices where the normals are perpendicular to the y-axis...?

Rotate the model and now the errors rotate to different positions along the surface. weird.

@marc dion (marcclintdion): even if the scale is big, it is very expected, the character head in the sample is ~0.4 unit which is near human, also the environment scale is almost real, so this should not happen at the very least.

also the problem is that i already animated the chars.,i use a simple workflow -my team is very small actually 2- it's just single file that contains everything, so the full environment with various scenes are game like, if i needed a shot i move the chars. to the scene place, so taking the chars to origin is very hard if not impossible.

Some pattern is showing here. The model is about -2500 units along the y-axis in order to make the error more easily visualized.

These 6 images are all orthographic view renders, each one faces a different direction. (+/- x, +/- y, +/- z), only the x and z axis renders are showing errors with the model at this position.

  • when viewing Parallel to the y-axis in both directions, the artifacts are not present, but this only happens when the model is close to the y-axis grid line.

Moving the model straight down the x-axis now makes the x-axis orthographic renders error-free. This same thing for z as well.

Developer information:
The issue is actually coming from the way how ray bounce is happening: it is using ray_offset() in order to avoid self-intersection. This function will push ray along the face normal by a small value. This small value is different for different axis and actually depends on magnitude of the original coordinate. In this case ray is getting pushed a bit more along Y axis than along X and Z axis. This makes ray to be moved into the surface itself, causing light artifacts.

I'm not really sure how to solve this with current approach to ray bounce, but the idea i was testing is to avoid having ray_offset() all together and perform "near clip" check in triangle intersection code. Here's a really quick patch which demonstrates the idea:

. It is only done for triangles, motion triangles and hair would give artifacts with it.

This approach could make it simplier to deal with T43865, increasing ray_tnear for a huge values of det would avoid false-positive intersections.

I tried 'tnear.patch' and it generates a pattern on the model surface that sort of looks like some kind of paper bump texture(the pattern is nice :). The model also becomes very dark when moved far away from the scene origin and away from the axis lines. It looks as if there is a point point nearby and with no scene AO.

(forgot to press 'Submit' for this a couple days ago for the rest of this:)

Did a bit more trouble-shooting:

The next image shows renders where both the view and model are at (-10,000) along the y-axis. Instead of rotating the view around the model, the model was duplicated for all 6 views and each instance of the model was rotated in model space.
There is only one small area and only one of the render where any errors can be seen even though the model is very far from the origin.

The next image shows what happens when the View is rotated, and with the models rotation remaining stationary. The artifacts are now unmistakably present.

The following image shows the head models and camera which are all moved (10000) units along all three axis. These renders are all aligned the various axis for both positive and negative directions.
It's now difficult to see any discernible pattern with respect to which axis the errors are showing up on. The errors are no longer concentrated along a plane which is perpendicular to the view, instead, they are now scattered about the surface of the model and visible from every viewing direction. Aligning the view to an axis can no longer hide the problem.

The patch i've attached only to show an idea, i didn't mention it fixes anything. It still needs quite some work to be done.

Might I suggest you try a different idea: Lock down the Projection Matrix and then move its transforms to the next matrix down the chain using the reverse values for each component of position and rotation to give the illusion that the camera is moving.

I'm fairly confident this problem goes away if you do this.

Moving to a TODO since it's known floating point issue which existed in all releases.

@Sergey Sharybin (sergey): do i need to redo my animation now! or is there a work around that can overcome this till it is fixed, frankly a TODO task means years+ of waiting, thank you.

it is not a trivial issue to fix in a general case without causing render slowdown. TODO does not mean years+ of waiting, there's WIP patch which you can potentially use already.

Non-code workaround for you would be to parent your scene to an empty and move it closer to the scene origin.

ok i tried the batch you've made, it works! i didn't try it before because of the artifacts that @marc dion (marcclintdion) mentioned, which i didn't find any of it ! but maybe it would exist in some extreme situation.

one thing arises is that the viewport is darker than the final render (or it turns smoothing off), here is a test:

also i didn't notice a slowdown in my case, notice the render time for viewport and render.

thank you.

@Yousef Harfoush (bat3a), the issue mentioned by @marc dion (marcclintdion) are happening with really insane coordinates, which are totally stressing single precision floating point arithmetic. Those cases are quite tricky to solve in general case and requires some black magic (which would still fail in certain circumstances btw).

The viewport issues are rather interesting, i'll have a look into them ASAP.

I finally remembered the keywords to find this document.

Creating Vast Game Worlds
Experiences from Avalanche Studios.


They go into some detail on some of the problems they encountered with large worlds and some of the ways they dealt with this in code.

this patch is not applicable to latest git, i would appreciate if someone updates it cause the problem still exist.

thank you.

anyone could update this thank you.

the problem still occurs in latest build 9b29233

If behind the scenes, Blender were to move the entire scene using the inverse of the camera transform instead of moving the camera itself, then visible close-up models would never be far from the origin. Now round-off/precision errors would likely be mostly eliminated.
It's a huge job that would take an expert in the field (not me of course! :) It would have to appear to the end-user that nothing has changed so far as UI and navigation are concerned.

There is D6250 which addresses this issue.

If behind the scenes, Blender were to move the entire scene using the inverse of the camera transform instead of moving the camera itself, then visible close-up models would never be far from the origin. Now round-off/precision errors would likely be mostly eliminated.

In other words, why is Cycles performing any calculations in world space? Wouldn't camera space be a more appropriate space for these operations? Perhaps offset by some fraction of far clip?

So looks like we have to live with that.

By the way, I got around my problem on hand by having the cyclist cycle in place and moving the landscape. This is the equivalent to (marcclintdion) 's proposal.

Don't know if this is the same issue, but I am having a similar problem, a large scale scene with a character far away from world origin

This eyebrow's material has a Alpha value of 0, so it should have been completely transparent. It works fine at the world's origin, but does not work at all at where the character should be. This is a serious issue, hope it gets fixed soon.