Cycles Hydra Render Delegate #96731
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
24 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#96731
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Status
There is experimental support for building Cycles as a Hydra render delegate. This enables Cycles to be used as a renderer in applications with Hydra support, for example Usdview, Omniverse and Houdini.
No official support is provided at this point due to the experimental state.
Features
.. list to be completed ...
Bugs
Building
https://wiki.blender.org/wiki/Building_Blender/CyclesHydra
Changed status from 'Needs Triage' to: 'Confirmed'
Added subscribers: @brecht, @pmoursnv
Added subscriber: @SteffenD
Added subscriber: @Alaska
Added subscriber: @sherholz
Added subscriber: @RicoF
Thanks for the great work on this.
Are there any details, which build configurations have been tested?
I'm getting some build errors on windows vs2019 when Python is enabled, so I had to disable it in the USD (21.08) and the hdCycles builds.
Also the OpenVDB versions are causing some problems. The USD default is v6.1 and the Cycles defaulft is 8.0.1 and changing any of them to match them is generating new errors.
Added subscriber: @Stefan_Werner
I am havening similar issues when trying to build it under Linux.
One of the main problems seems to be that the build prefers using the
USD, Boost, and Python versions of the Blender dependencies and not the ones used to build the external USD.
Is there any reason why hdCycles uses its own FindUSD.cmake to set up the USD dependencies instead of the cmake config which is automatically build
by USD?
Added subscriber: @LazyDodo
Try setting the CMAKE_FIND_PACKAGE_PREFER_CONFIG option to sidestep that behavior.
It's probably not possible to use Blender's precompiled libraries at all, unless you build USD against Blender's precompiled libraries. So right now, it may be easiest to build without a precompiled library directory present, and setting
TBB_ROOT_DIR
,OPENVDB_ROOT_DIR
,PYTHON_ROOT_DIR
, etc. manually if needed.We should be able to make this process smoother though, or at least document it.
Right, the build process could use some improvement. Setting
USD_ROOT
,TBB_ROOT(_DIR)
,OPENVDB_ROOT(_DIR)
etc. works for the moment though (most importantlyUSD_ROOT
andOPENVDB_ROOT
, the others are used in mostly ABI compatible ways, so doesn't matter as much if linking against the different version in the precompiled libraries). Can also just disable OpenVDB support to not worry about it at all withWITH_OPENVDB=0
. To get a USD build working that was built with Python, currently have to set aUSD_PYTHON_LIBRARIES
CMake variable with the additional libs to link (e.g.USD_PYTHON_LIBRARIES=boost_python37-vc141-mt-x64-1_68;python37
on Windows for Python 3.7).Relying on
find_package(pxr)
andpxrConfig.cmake
could be an option to solve this, just need to find a way to integrate this into the Blender build system without disrupting it when not building the Hydra render delegate.This issue was referenced by
f60cffad38
Added subscriber: @zNight
This issue was referenced by
0de0950ad5
Added subscriber: @EstebanCovo
I committed various fixes for Linux, and updated the standalone repository to include the Hydra render delegate. Hopefully I didn't break Windows in the process.
I did some work towards getting this building against Houdini in D14594: Cycles Hydra: support for building against Houdini.
It's not actually working yet, any help debugging this is welcome.
Awesome! There is a bit more necessary to get it running with Houdini on Windows it seems. I posted some suggestions to D14594 that made it work for me.
This issue was referenced by
9b92ce9dc0
I added support for rendering USD files from the Cycles standalone executable in blender/cycles@1a5f493 and blender/cycles@5d03a41.
This also includes changes to make the Hydra render delegate build using the upcoming 3.2 precompiled libraries update. The resulting plugin will not be particularly useful as Blender can't load it, but being able to build the standalone executable without any additional libraries is nice.
Still rough around the edges in many ways, here's a render with a USD file exported from Blender:
I also made some changes to Houdini building to fix issues with packages in blender/cycles@949e461.
Topic for feedback created here:
https://devtalk.blender.org/t/cycles-hydra-render-delegate-and-usd-feedback/24075
Added subscriber: @Funnybob
Added subscriber: @p2or
Added subscriber: @semimetallic
Added subscriber: @ahmed.hindy96
Added subscriber: @platerytter
any updates for Solaris integration and feature parity?
There doesnt seem to be any updates since last April
No updates yet, it's actually been a while, I guess the team has been super busy, It was picking up steam for a while but it went silent pretty quickly, we have been impleenting a Hybrid pipeline at the studio for a while now and having a Hydra delegate of cycles would be huge for us, since the majority of our artists prefer blender for asset development and most feel more comftrable with cycles than Redshift.
We are still super excited to see Cycles rendering properly in Solaris, I hope the dev team has some time later this year, we can't wait to try it out!!
This is currently up to community to pick up, I personally don't have much time to invest in this in the near future. There was some interest from Intel to improve the implementation but nothing concrete so far.
That's a shame, now that there seems to be interest in developing Hydra viewport support natively having a cycles delegate seems like a logical step.
Added subscriber: @ao.cmi
Added subscriber: @tlinde
Hey there,
thx to all contributors for the work on the hydra delegate. It all sounds very promising and it will enable lots of projects, increasing the usage of cycles.
I am trying to compile cycles standalone together with USD on Linux. Sadly, I get a segmentation fault as soon as I try to "usdview" a simple scene (tried several scenes) with hdCycles. I started a GDB session and this is where it segfaults:
dstPtr=0x0,
looks like the issue? Is it due to OpenGL interop not fully implemented on Linux?Tried USD Version: 22.03 and 21.11
cycles: tag v3.3.0, master
OS: Ubuntu 20.04
GPU NVIDIA RTX 3060 Ti (driver 515.65.01)
USD compile command (conda env):
I also built the hdCycles with the USD library included in the cycles SVN. If i tr to run this with my usdview I get this error:
What USD version are you using in the SVN?
Any ideas what the problem is in both cases? I could contribute here if that would be desired, would need some pointers though.
Thx in advance
The USD version can be found in the headers, it's 22.03 for Blender currently.
OpenGL interop is not implemented on Linux, but it should be falling back to slower pixel copying without interop, which I think is where the crash is happening for you.
The code seems to expect that first
HdCyclesRenderBuffer::Allocate
gets called specify the size in_dataSize
, and thenHdCyclesRenderBuffer::Map
gets called to allocate that in_data
, after which there should be a non-null buffer to write to inHdCyclesRenderBuffer::WritePixels
. You could investigate why that's not happening as expected.Thank you for the suggestion. I'll investigate as soon as I have as bit more time again to look into that.
I had some time to look into the problem now:
HdCyclesRenderBuffer::Allocate
defines the size of the memory to allocate, but an actual allocation ofHdCyclesRenderBuffer::_data
happens only inHdCyclesRenderBuffer::Map
.There are two options:
_data.resize(_dataSize);
orHdCyclesRenderBuffer::Map
directly inHdCyclesRenderBuffer::Allocate
HdCyclesRenderBuffer::Map
inHdCyclesRenderBuffer::WritePixels
if not already mapped. AHdCyclesRenderBuffer::unmap
at the end of the scope of ``HdCyclesRenderBuffer::WritePixels` would make sense?Both options work and the example scenes are rendered in
usdview
, but the question is which option is the correct one. IMHO option 1 would be the sound choice, but i don't know the hydra details about whenHdRenderBuffer::Map
is being called.I'd go with option 2, calling Map/Unmap inside
WritePixels
. We don't need to check if already mapped, I don't think that's possible.In
HdCyclesOutputDriver::update_render_tile
there are two cases, and in one we are already using Map/Unmap, and the other isWritePixels
where we could do the same.Thx @brecht for your comments and pointers in the right direction. I've tested your suggestion to go with option 2 and I've just submitted a patch (https://developer.blender.org/D16272). Let me know if something is missing and if more information is needed.
Added subscriber: @txrxfx
Added subscriber: @AlvaroCastaneda
Added subscriber: @scopelma
Added subscriber: @AlexeyAdamitsky
Added subscriber: @rrrus
Added subscriber: @Cjhosken