Possible bug in render depsgraph for object_instances #60771

New Issue

Jonathan Dent · 2019-01-22T22:05:27+01:00

Jonathan Dent commented

2019-01-22 22:05:27 +01:00

Hi again.
Encountering some odd behavior and I'm not sure if it's a bug or not.

I'm pulling the matrix_world variable of all instances in the depsgraph 'object_instances' that are true instances, generated by either a particle system or a dupli object. Both have motion between frames (so all the instances are moving):

for inst in self.bl_depsgraph.object_instances:
    if inst.is_instance and inst.instance_object.type == 'MESH':
        print(inst.matrix_world)

for reference self.bl_depsgraph is the render depsgraph.

I'm doing this at two frame locations, frame 8 and frame 8.5. I am advancing the frame using the Scene.frame_set(frame, subframe) method.

For one instance_object, here's what I get:

8.0
<Matrix 4x4 ( 0.1362, -0.0526, -0.2029, -1.5307)
            ( 0.0573, -0.2234,  0.0964,  0.0914)
            (-0.2017, -0.0990, -0.1097, -0.7790)
            ( 0.0000,  0.0000,  0.0000,  1.0000)>
8.5
<Matrix 4x4 ( 0.1362, -0.0526, -0.2029, -1.5307)
            ( 0.0573, -0.2234,  0.0964,  0.0914)
            (-0.2017, -0.0990, -0.1097, -0.7790)
            ( 0.0000,  0.0000,  0.0000,  1.0000)>

As you can see the matrix is identical at both frame positions despite the instance)object in question having movement.

If, however, I manually advance the frame number in the 3D view and then manually print out the matrix for the same instance using the Python console (and context.depsgraph), I get this:

8.0
<Matrix 4x4 ( 0.1362, -0.0526, -0.2029, -1.5307)
            ( 0.0573, -0.2234,  0.0964,  0.0914)
            (-0.2017, -0.0990, -0.1097, -0.7790)
            ( 0.0000,  0.0000,  0.0000,  1.0000)>
8.5
<Matrix 4x4 ( 0.1362, -0.0526, -0.2029, -1.5691)
            ( 0.0573, -0.2234,  0.0964,  0.1100)
            (-0.2017, -0.0990, -0.1097, -0.8373)
            ( 0.0000,  0.0000,  0.0000,  1.0000)>

Here there is a difference, as expected.

I'm not sure if this is a bug or if I'm not calling something correctly. During rendering does the depsgraph update automatically on a frame shift or do I need to trigger it manually?

Here's the full code block. All_times is a list of all the subframes that need to be called, in this case [0.0, 0.5]

for time in all_times:
    new_frame = current_frame + time
    int_frame = math.floor(new_frame)
    subframe = new_frame - int_frame

    self.bl_scene.frame_set(int_frame, subframe=subframe)

    print(self.bl_scene.frame_float)

    if time in xform_times:
        for inst in self.bl_depsgraph.object_instances:
            if inst.is_instance and inst.instance_object.type == 'MESH':
                inst_key = f"{inst.instance_object.name_full}|{inst.persistent_id[0]}"
                if inst.persistent_id[0] == 1:
                    print(inst.matrix_world)

Hi again. Encountering some odd behavior and I'm not sure if it's a bug or not. I'm pulling the matrix_world variable of all instances in the depsgraph 'object_instances' that are true instances, generated by either a particle system or a dupli object. Both have motion between frames (so all the instances are moving): ``` for inst in self.bl_depsgraph.object_instances: if inst.is_instance and inst.instance_object.type == 'MESH': print(inst.matrix_world) ``` for reference self.bl_depsgraph is the render depsgraph. I'm doing this at two frame locations, frame 8 and frame 8.5. I am advancing the frame using the Scene.frame_set(frame, subframe) method. For one instance_object, here's what I get: ``` 8.0 <Matrix 4x4 ( 0.1362, -0.0526, -0.2029, -1.5307) ( 0.0573, -0.2234, 0.0964, 0.0914) (-0.2017, -0.0990, -0.1097, -0.7790) ( 0.0000, 0.0000, 0.0000, 1.0000)> 8.5 <Matrix 4x4 ( 0.1362, -0.0526, -0.2029, -1.5307) ( 0.0573, -0.2234, 0.0964, 0.0914) (-0.2017, -0.0990, -0.1097, -0.7790) ( 0.0000, 0.0000, 0.0000, 1.0000)> ``` As you can see the matrix is identical at both frame positions despite the instance)object in question having movement. If, however, I manually advance the frame number in the 3D view and then manually print out the matrix for the same instance using the Python console (and context.depsgraph), I get this: ``` 8.0 <Matrix 4x4 ( 0.1362, -0.0526, -0.2029, -1.5307) ( 0.0573, -0.2234, 0.0964, 0.0914) (-0.2017, -0.0990, -0.1097, -0.7790) ( 0.0000, 0.0000, 0.0000, 1.0000)> 8.5 <Matrix 4x4 ( 0.1362, -0.0526, -0.2029, -1.5691) ( 0.0573, -0.2234, 0.0964, 0.1100) (-0.2017, -0.0990, -0.1097, -0.8373) ( 0.0000, 0.0000, 0.0000, 1.0000)> ``` Here there is a difference, as expected. I'm not sure if this is a bug or if I'm not calling something correctly. During rendering does the depsgraph update automatically on a frame shift or do I need to trigger it manually? Here's the full code block. All_times is a list of all the subframes that need to be called, in this case [0.0, 0.5] ``` for time in all_times: new_frame = current_frame + time int_frame = math.floor(new_frame) subframe = new_frame - int_frame self.bl_scene.frame_set(int_frame, subframe=subframe) print(self.bl_scene.frame_float) if time in xform_times: for inst in self.bl_depsgraph.object_instances: if inst.is_instance and inst.instance_object.type == 'MESH': inst_key = f"{inst.instance_object.name_full}|{inst.persistent_id[0]}" if inst.persistent_id[0] == 1: print(inst.matrix_world) ```

Jonathan Dent commented

2019-01-22 22:05:27 +01:00

Added subscriber: @jdent02

Jonathan Dent commented

2019-01-22 23:33:24 +01:00

Additionally, this same thing happens if I iterate through depsgraph.objects. Based on the docs I was under the impression that these were references to objects residing in bpy.data.objects but in reality they appear to be a completely independent data blocks that also do not update their transforms when the frame is changed during rendering.

Transforms do export properly with objects that are retrieved through old fashioned bpy.data.objects or depsgraph.scene.objects.

Additionally, this same thing happens if I iterate through depsgraph.objects. Based on the docs I was under the impression that these were references to objects residing in bpy.data.objects but in reality they appear to be a completely independent data blocks that also do not update their transforms when the frame is changed during rendering. Transforms do export properly with objects that are retrieved through old fashioned bpy.data.objects or depsgraph.scene.objects.

Philipp Oeser commented

2019-01-23 11:37:05 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-01-23 11:37:05 +01:00

Just to make this a little simpler for everyone looking at this:

Could you just share a simple .blend file that has the animation, working script that show how you get your scene, depsgraph, etc?
(this is just to make sure we a re all on the same page...)

Will mark this as incomplete until we have that...

Just to make this a little simpler for everyone looking at this: Could you just share a simple .blend file that has the animation, working script that show how you get your scene, depsgraph, etc? (this is just to make sure we a re all on the same page...) Will mark this as incomplete until we have that...

Jonathan Dent commented

2019-01-23 13:30:17 +01:00

Thanks Philipp. I’ll get a scene and mock-up to you later today

Jonathan Dent commented

2019-01-24 04:03:32 +01:00

test_render.zip

Here's a stripped down version of the render plugin. Instead of exporting items it just prints matrix_world

For the scene the cube is a 'real' object and the Suzanne's are duplis. When you run the render you'll see the cube shows different matrices for the two motion steps while the duplis all show the same for both steps.

[test_render.zip](https://archive.blender.org/developer/F6385109/test_render.zip) Here's a stripped down version of the render plugin. Instead of exporting items it just prints matrix_world For the scene the cube is a 'real' object and the Suzanne's are duplis. When you run the render you'll see the cube shows different matrices for the two motion steps while the duplis all show the same for both steps.

Brecht Van Lommel commented

2019-01-24 04:09:09 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-01-24 04:09:09 +01:00

For rendering, use engine.frame_set() instead of scene.frame_set() to change the frame.

In 2.8 the renderer gets a dependency graph and copy of the scene data that is independent of the editable / viewport data.

For rendering, use `engine.frame_set()` instead of `scene.frame_set()` to change the frame. In 2.8 the renderer gets a dependency graph and copy of the scene data that is independent of the editable / viewport data.

Jonathan Dent commented

2019-01-24 05:00:25 +01:00

Well that's good that it's not a bug. This should be mentioned in the Python API section of the release notes. For addon devs like me there is no mention that you need to use the engine to set the frame now instead of the scene. Then I waste you guys' time posting reports on bugs that aren't bugs.

Jonathan Dent commented

2019-01-24 14:08:26 +01:00

Changed status from 'Open' to: 'Archived'

Jonathan Dent closed this issue

2019-01-24 14:08:26 +01:00

Jonathan Dent self-assigned this 2019-01-24 14:08:26 +01:00

Jonathan Dent commented

2019-01-24 14:08:26 +01:00

Brecht, your suggestion works. Thanks for the input!

I don't mean to sound like a broken record but I would strongly suggest this be mentioned in the release notes. I'm sure the Lux and Radeon guys are probably smart enough to figure it out, but more hobby/average devs like me really rely on those release notes to know what has changed.

Thanks.

Brecht, your suggestion works. Thanks for the input! I don't mean to sound like a broken record but I would strongly suggest this be mentioned in the release notes. I'm sure the Lux and Radeon guys are probably smart enough to figure it out, but more hobby/average devs like me really rely on those release notes to know what has changed. Thanks.

Brecht Van Lommel commented

2019-01-24 14:21:25 +01:00

I agree, we need better docs for this.

Note that even in 2.7 this function needed to handle some specific cases, but now in 2.8 things break entirely if you don't use it.

I agree, we need better docs for this. Note that even in 2.7 this function needed to handle some specific cases, but now in 2.8 things break entirely if you don't use it.

Sign in to join this conversation.