2022-3-29 Blender Rendering Meeting

Some steps towards getting this building for Houdini here, but it’s not actually working yet.


I 100% agree. I have never understand why the world is not a light object (or at least why there isn’t a dome type of light object anymore), because in production (we work with maya at the studio) we always rely on different dome lights with tweaked visibilities/intensities combined with light linking…e.g., we use more than one dome, one is only for speculars, one for hair, etc…so we can have a lot of control over certain aspects of the rendering output without having to separate those in different layers/scenes

1 Like

Never used Maya, and actually world as a scene property has grown on me as a second nature. But once I started messing with unreal, the concept of world=lamp opened my eyes

1 Like

Does the Intel OneAPI use Open CL and if yes could it be used to support AMD GPUs in blender.

There are several things here:

1.- Light Linking: not there yet

2.- Light Path: you can already use light path and have different environment for every light path

3.- Multiple worlds illuminating: that’s what Lukas has in his list, multiple worlds as light groups

Si the thing of it being an object or not is totally secondary, the important thing here is to have several environments available in different ways but no need for it to be an object :slight_smile:

I remember correctly vega’s hip has been submitted

AMD only supports the newer cards right now and some cards on Linux. Considering Apple added RX 580 support and Metal outperforms HIP !!?? Intel’s OneAPI support would be a god send for older AMD GPU users.

OneAPI will not work for AMD GPUs, and we’re not using OpenCL.


Thanks. I probably misunderstood what I read on the Intel site. That’s sad news for older AMD GPU users though.

I agree that world HDRi as “lights” is way better. And it also makes more sense since you can easily rotate a “World Light / 360 Light”

OneAPI can talk to Intel GPUs through Level Zero or OpenCL. I don’t know if AMD hardware is also working with that OpenCL backend or not, and unfortunately I don’t have the hardware to try. There is also a HIP backend for oneAPI DPC++, but I suspect that’s not what you’re asking for.

If someone with development experience and an AMD GPU wants to try, I’ll be happy to assist. I’m curious myself to see if it works.


That’s super interesting. Since the older devices are Opencl compatible I guess someone who has knowledge and experience with the OpenCl code could get the 99% of AMD GPUs that are currently unsupported by blender up and running ( probably slower but better than nothing ).
The HIP backend is kindda useless for older devices because they are unsupported by HIP anyway.

Thank you! ACES may not be perfect (as many are eager to point out) but having options is better than not. I appreciate the openness to implementing tools that simplify my pipeline.


With your very latest changes I can now successfully build under Linux and run Cycles as a Hydra delegate in Houdini:


This is so awesome! First thing I noticed is that the package JSON isn’t working. I have to declare PXR_PLUGINPATH_NAME in the command line while starting Houdini.

P.S.: Is there a separate thread for the Cycles Hydra delegate here in these forums already?


With that I totally agree, some times we may need to work with ACES, not because we want to or not, but because the client uses it, so the ACES usage is out of question in those situations :slight_smile:


Another quick update: With Brecht’s latest changes the package JSON workflow is now working out of the box. :slight_smile:
P.S.: Still no dedicated Cycles Hydra thread? It would well deserve it.

I remember vega’s hip resubmitted

1 Like

I’ve created a topic here now:


When will the eevee test branch be available?

1 Like

The latest status update was provided here:

There are no concrete dates announced at this point, it’s under active development.