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

render delegate: loading mtoa while render delegate active crashes maya #28

Open
pmolodo opened this issue Jan 9, 2019 · 1 comment
Assignees

Comments

@pmolodo
Copy link
Contributor

pmolodo commented Jan 9, 2019

Pretty much as the title says:

  • start maya, make sure mtoa is not loaded / not set to auto-load
  • start maya-to-hydra, set it as the viewport renderer, set it's renderer plugin to arnold
  • load mtoa
  • crash!
@sirpalee sirpalee self-assigned this Jan 15, 2019
@sirpalee
Copy link
Contributor

sirpalee commented Jan 16, 2019

This problem is not something we can quickly solve. It happens because Arnold still lacks full support of multiple universes. Every call has to take place between a pair of AiBegin and AiEnd calls, and plugins are limited to this scope as well. Meaning, the render delegate sets up the global playground for Arnold, loads the shaders, plugins etc. but later this is overtaken by MtoA, and MtoA closes this playground once it finished initialising the plugin.

While we can sort this specific issue by making sure MtoA is always loaded before Maya to Hydra, this approach is just a quick patch on one of many problems. Any subsequent renders for the hypershade, or renders in the viewport (or evaluating AiStandins!) will have the same effect. While we can push AD to tackle this problem in the future, it's not something we can expect in the near term.

I can see two options to handle this problem.
1, rendering in an external process. This approach will also solve the current LD_PRELOAD issues we see on Linux, but it adds complexity and a small overhead due to serialising/deserialising commands. Note, rendering happens in a separate process in Houdini to Arnold and Katana to Arnold, so the cost could be small enough not to notice. And my previous experience with rendering in an external process confirms that for most interactive events the overhead won't be excessive.
2, loading the Arnold library into a private namespace and using the functions from there. It won't solve our LD_PRELOAD issues, but has minimal overhead and doesn't require significant changes in the API. We have to provide an alternative implementation of the AtString class, that uses our functions to Hash strings but has the same memory layout as the original struct. One thing I'm unsure, how the side loading of libraries is possible on Windows. While I had prototypes confirming the viability of this approach, those were limited to Linux. (and potentially behaving similarly to OSX)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants