search

mitsuba-renderer / mitsuba2

Mitsuba 2: A Retargetable Forward and Inverse Renderer
Other
2.04k stars 267 forks source link

vertex_positions_buf - render_torch (access violation reading location 0x0000003455D60000) #305

Open garrido-pablo opened 3 years ago

garrido-pablo commented 3 years ago

Please add one of the following label to your issue's title, and delete this section:

Summary

"Access violation reading location" when running render_torch() and passing vertex_positions_buf as **kargs. Program crashes when function Mesh::recompute_bbox() is called from Mesh::parameters_changed(). Specifically, vertex_position(0) is not valid when trying to expand the bounding box.

System configuration

Description

Access violation reading location 0x0000003455D60000. The error only happens when calling render_torch() with vertex_positions_buf in the scene parameters list and when including torch parameters as **kwargs.

Steps to reproduce

  1. Keep vertex_positions_buf in the parameters list, e.g. scene_params.keep(['PLYMesh.vertex_positions_buf'])
  2. Get torch params from scene_params, e.g., torch_params = scene_params.torch()
  3. Call render_torch() with parameters generated above: rendering = render_torch(scene, params=scene_params, unbiased=True, spp=4, **torch_params)

Run differentiable_geometry_test_pytorch.py script in minimal_example.zip (see attachment) to reproduce bug.

Please note that the bug only happened when vertex_positions_buf is updated in render_torch(). This creates an access violation (possibly vertex_positions_buf has a wrong direction or null pointer). The callstack can be seen in AccessViolation.PNG The problem appears when the bounding box is expanded in function Mesh::recompute_bounding_box(), which is called from Mesh::parameters_changed().

Note that the script runs smoothly if line 34 is commented out and line 33 is uncommented. In this case, vertex_positions_buf is not part of the parameter list. This means that the reference to vertex_positions_buf might not be properly updated.

minimal_differentiable_geometry_example.zip

Speierers commented 3 years ago

Hi @garrido-pablo ,

Could this be related: #276 ?

garrido-pablo commented 3 years ago

Hi @Speierers. Thanks for answering back. I'll take a closer look at the issue based on that post. It seems quite related.

It's interesting that the problem only happens when updating vertex_positions_buf - updating vertex_normals_buf and vertex_texcoords_buf won't cause any crash. Is there any reason for this?

garrido-pablo commented 3 years ago

Adding m_vertex_positions_buf.managed() in Mesh::parameters_changed() fixed the issue. I noticed, however, that gradients of vertex positions are not backpropgated.

Speierers commented 3 years ago

I noticed, however, that gradients of vertex positions are not backpropgated.

Could you give us a little more information maybe?

garrido-pablo commented 3 years ago

I fixed the issue temporarily by doing a few modifications in function render_torch() (see autodiff.py file attached):

  1. Ad-hoc variable assignment for geometry-related parameters with key 'vertex_*': params[k][:] = type(params[k])(v)
  2. Set parameters with key 'vertex_*' as dirty and call params.update() before calling the first 'render()' function
  3. Repeat first two steps described in 2. before calling second 'render()' function

I'd appreciated it if you could tell if my fix makes sense or if it's the right thing to do. I tested the changes mentioned above and seemed to work just fine.

autodiff.zip