Cycles: wrong 3D world positions for objects with shared mesh #54786

New Issue

sasha · 2018-04-24T09:46:51+02:00

sasha commented

2018-04-24 09:46:51 +02:00

I have one issue when rendering 3D world positions with blender. It is not working for objects, which share same mesh.

On the scheme below, you can see how scene is made.

Be careful: I did mistake when drawing coordinates near quads. I wrote them accidently not as (x,y,z), but as (y,x,z).

Test scene consists of 4 objects, which share one mesh. We know exact positions of the quads in world coordinate system. We should observe those positions when rendering current positions.
Rendered images have (r,g,b,a) channels filled with (x,y,z,id) values.
(x,y,z) is world position of the point on the surface. Id is an id of the object.

There are 2 frames, in second frame last object moves by one to the right. SVM machine is used, but for OSL results are the same.

Rendered values from .exr files:
Object 1: (from scheme above left upper corner should be around position (0,1,0), read section “be careful” )
Frame: pixel_x pixel_y x y z id
1: 200 40 0.011460 0.769714 0.000000 1
2: 200 40 0.011460 0.769714 0.000000 1

Conclusion:
Frame: pixel_x pixel_y x y z id
1: 200 40 0.011460 0.769714 0.000000 1 -> hit region inside quad, lets assume that is correct, because it is quit near to a position (0,1,0)
2: 200 40 0.011460 0.769714 0.000000 1 -> since quad is not moving in frame 2, it should have same position as in frame 1, which is true.
We do assumption that for object 1 everything is correct!

Object 2: (left upper corner should be around position (2,1,0) )
Frame: pixel_x pixel_y x y z id
1: 200 120 1.558336 0.761882 0.000000 2
2: 200 120 1.558336 0.761882 0.000000 2

Conclusion:
Object 2: (left upper corner should be around position (2,1,0) )
Frame: pixel_x pixel_y x y z id
1: 200 120 1.558336 0.761882 0.000000 2 -> blender rendered this position for the object 2, which is wrong cause this position points to the area between quads, there is no quad at this position, which means blender has bug.
2: 200 120 1.558336 0.761882 0.000000 2 -> since quad isnot moving position should be the same as in frame 1, which is true, but position in frame 1 is wrong by itself due to internal blender bug

Object 3: (left upper corner should be around position (4,1,0) )
Frame: pixel_x pixel_y x y z id
1: 200 200 3.073426 0.754163 0.000000 3
2: 200 200 3.073426 0.754163 0.000000 3

Conclusion: the same effect as for object 2 is observed here.

Object 4: (left upper corner should be around position (6,1,0) and in the next frame should be around (7,1,0), since quad moved to the right by one )
Frame: pixel_x pixel_y x y z id
1: 200 280 4.746234 0.777621 0.000000 4
2: 200 320 5.425383 0.762278 0.000000 4

Conclusion: similar effect as for object 2 is observed here.

Here is test file:
SharedMesh_blender.blend

Question: how to avoid this problem?

I have one issue when rendering 3D world positions with blender. It is not working for objects, which share same mesh. On the scheme below, you can see how scene is made. ![scheme.jpg](https://archive.blender.org/developer/F2971183/scheme.jpg) ``` ``` Be careful: I did mistake when drawing coordinates near quads. I wrote them accidently not as (x,y,z), but as (y,x,z). Test scene consists of 4 objects, which share one mesh. We know exact positions of the quads in world coordinate system. We should observe those positions when rendering current positions. Rendered images have (r,g,b,a) channels filled with (x,y,z,id) values. (x,y,z) is world position of the point on the surface. Id is an id of the object. There are 2 frames, in second frame last object moves by one to the right. SVM machine is used, but for OSL results are the same. Rendered values from .exr files: Object 1: (from scheme above left upper corner should be around position (0,1,0), read section “be careful” ) Frame: pixel_x pixel_y x y z id 1: 200 40 0.011460 0.769714 0.000000 1 2: 200 40 0.011460 0.769714 0.000000 1 Conclusion: Frame: pixel_x pixel_y x y z id 1: 200 40 0.011460 0.769714 0.000000 1 -> hit region inside quad, lets assume that is correct, because it is quit near to a position (0,1,0) 2: 200 40 0.011460 0.769714 0.000000 1 -> since quad is not moving in frame 2, it should have same position as in frame 1, which is true. We do assumption that for object 1 everything is correct! ------ Object 2: (left upper corner should be around position (2,1,0) ) Frame: pixel_x pixel_y x y z id 1: 200 120 1.558336 0.761882 0.000000 2 2: 200 120 1.558336 0.761882 0.000000 2 Conclusion: Object 2: (left upper corner should be around position (2,1,0) ) Frame: pixel_x pixel_y x y z id 1: 200 120 1.558336 0.761882 0.000000 2 -> blender rendered this position for the object 2, which is wrong cause this position points to the area between quads, there is no quad at this position, which means blender has bug. 2: 200 120 1.558336 0.761882 0.000000 2 -> since quad isnot moving position should be the same as in frame 1, which is true, but position in frame 1 is wrong by itself due to internal blender bug ---- Object 3: (left upper corner should be around position (4,1,0) ) Frame: pixel_x pixel_y x y z id 1: 200 200 3.073426 0.754163 0.000000 3 2: 200 200 3.073426 0.754163 0.000000 3 Conclusion: the same effect as for object 2 is observed here. Object 4: (left upper corner should be around position (6,1,0) and in the next frame should be around (7,1,0), since quad moved to the right by one ) Frame: pixel_x pixel_y x y z id 1: 200 280 4.746234 0.777621 0.000000 4 2: 200 320 5.425383 0.762278 0.000000 4 Conclusion: similar effect as for object 2 is observed here. Here is test file: [SharedMesh_blender.blend](https://archive.blender.org/developer/F2971568/SharedMesh_blender.blend) Question: how to avoid this problem?

sasha commented

2018-04-24 09:46:51 +02:00

Added subscriber: @shurup4ik

Brecht Van Lommel commented

2018-04-24 10:13:16 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2018-04-24 10:13:16 +02:00

I don't think shared meshes have anything to do with this, the output looks identical to me if I make each object use its own mesh.

I didn't look at the numbers in detail, but I'm guessing you are looking at the edges of the quads, where antialiasing happens? Since you're writing this into the Combined pass it will blend the position with the black from the background. Rendering with 1 sample so there is no AA (possibly at e.g. 4x resolution for better results in compositing) could help.

I don't think shared meshes have anything to do with this, the output looks identical to me if I make each object use its own mesh. I didn't look at the numbers in detail, but I'm guessing you are looking at the edges of the quads, where antialiasing happens? Since you're writing this into the Combined pass it will blend the position with the black from the background. Rendering with 1 sample so there is no AA (possibly at e.g. 4x resolution for better results in compositing) could help.

sasha commented

2018-04-30 14:22:18 +02:00

Dear @brecht , thanks for your advice. Yes, you are right I had anti-aliasing issue. After choosing following settings to switch off AA, positions at the edges were correct.

Important steps to switch off AA in cycles in case somebody will need it:

Choose "Branched Pass Tracing"
Set AA samples to 1

In #54786#496600, @brecht wrote:
I don't think shared meshes have anything to do with this, the output looks identical to me if I make each object use its own mesh.

I didn't look at the numbers in detail, but I'm guessing you are looking at the edges of the quads, where antialiasing happens? Since you're writing this into the Combined pass it will blend the position with the black from the background. Rendering with 1 sample so there is no AA (possibly at e.g. 4x resolution for better results in compositing) could help.

Dear @brecht , thanks for your advice. Yes, you are right I had anti-aliasing issue. After choosing following settings to switch off AA, positions at the edges were correct. ![cap.PNG](https://archive.blender.org/developer/F3147404/cap.PNG) Important steps to switch off AA in cycles in case somebody will need it: 1) Choose "Branched Pass Tracing" 2) Set AA samples to 1 > In #54786#496600, @brecht wrote: > I don't think shared meshes have anything to do with this, the output looks identical to me if I make each object use its own mesh. > > I didn't look at the numbers in detail, but I'm guessing you are looking at the edges of the quads, where antialiasing happens? Since you're writing this into the Combined pass it will blend the position with the black from the background. Rendering with 1 sample so there is no AA (possibly at e.g. 4x resolution for better results in compositing) could help.

Brecht Van Lommel commented

2018-04-30 14:24:18 +02:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2018-04-30 14:24:18 +02:00

Brecht Van Lommel self-assigned this 2018-04-30 14:24:18 +02:00

Brecht Van Lommel commented

2018-04-30 14:24:18 +02:00

Thanks for testing, closing report then.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles: wrong 3D world positions for objects with shared mesh #54786