Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing material rebuilds the shapes in Solaris #474

Closed
sirpalee opened this issue Jul 17, 2020 · 5 comments
Closed

Changing material rebuilds the shapes in Solaris #474

sirpalee opened this issue Jul 17, 2020 · 5 comments
Assignees
Labels
blocked Development blocked due to external issues bug Something isn't working houdini Related to Houdini integration render delegate Related to the Arnold Render Delegate

Comments

@sirpalee
Copy link
Contributor

Describe the bug
When changing material properties in Solaris, the shapes are synced again with all their parameters dirtied.

To Reproduce
Steps to reproduce the behavior:

  1. Create a heavy geometry in Solaris (or a simple geometry with heavy subdivision)
  2. Assign a material to it
  3. Change any of the material parameters
  4. Observe the delay as the render delegate rebuilds the mesh

Expected behavior
Material changes should restart the render almost instantly.

Used Software Versions

  • Arnold: 6.0.3.1
  • USD: 19.11
  • Compiler: GCC 6.3.1
  • OS: CentOS 7 and Windows 10
  • Any 3rd-party app: Hoduini-18.0.499

Additional context
After the initial investigation, it looks like the shapes are receiving all dirty sync and the render delegate is doing what it's instructed to do.

@sirpalee sirpalee added bug Something isn't working houdini Related to Houdini integration render delegate Related to the Arnold Render Delegate labels Jul 17, 2020
@sirpalee sirpalee self-assigned this Jul 17, 2020
@sirpalee sirpalee added this to To do in Sprint 28-29 via automation Jul 17, 2020
@sirpalee sirpalee added the blocked Development blocked due to external issues label Jul 30, 2020
@sirpalee sirpalee removed this from To do in Sprint 28-29 Jul 30, 2020
@sirpalee sirpalee added this to Needs triage in Ticket Triage via automation Jul 30, 2020
@sirpalee sirpalee moved this from Needs triage to High priority in Ticket Triage Jul 30, 2020
@sirpalee
Copy link
Contributor Author

This was reported to SideFX and we are still waiting for a reply. Marking the ticket as blocked and removing it from the sprint.

@sirpalee sirpalee moved this from High priority to Low priority in Ticket Triage Aug 10, 2020
@sirpalee
Copy link
Contributor Author

We got confirmation that fixes for [https://github.com/PixarAnimationStudios/OpenUSD/issues/1250](USD 1250) solves the issue. I'm going to move the ticket to low priority because there isn't much we could reasonably due.

@autodesk-oss-arnold-bot
Copy link

Issue synced internally to ARNOLD-13251

@BigRoy
Copy link
Contributor

BigRoy commented Jan 12, 2024

I assume this issue was solved by the fix for USD 1250 being implemented? Or is that there still something present currently in Arnold-USD for which we should keep this open to track certain optimization possibilities?


With Houdini 20.0.547 and Htoa 6.2.5.0 I'm mostly noticing if I go to another frame it restarts the progressive quickly (in scene only geometry changes in position) that the initial sampling is very slow. Then if I move the viewport camera around a bit it remains just as slow and the progression in the progresive rendering is much slower. But then if I 'wait' for a bit as the progression has come along nicely then if I move the camera round suddenly the progression for the new camera position is very rapid. Any idea why it might be slow initially on a new frame?

@cpichard
Copy link
Collaborator

Hi @BigRoy , I have double checked that when we changed the materials parameter the shapes are not synced again, so all good for this very issue. However, as you mentioned in your last comment and in the forum, I found a bug where the camera node was recreated when there was a change of camera parameter, which in turn forced the resync of the scene which could be very slow on big scene. This was the main cause of the slowdown. There is a PR ready to be merged and land in the next versions of arnold-usd #1855.
Thanks for the investigation, that was really useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Development blocked due to external issues bug Something isn't working houdini Related to Houdini integration render delegate Related to the Arnold Render Delegate
Projects
Status: Done
Ticket Triage
  
Low priority
Development

No branches or pull requests

3 participants