Cycles plans for Blender 2.8x project #46258

New Issue

Thomas Dinges · 2015-09-25T01:24:46+02:00

Thomas Dinges commented

2015-09-25 01:24:46 +02:00

NOTE: For now this task is only meant for Cycles developers and module members!

Hi,
Now that 2.76 is out (at least the RC), it's time to think about the Blender 2.8x project and Cycles.
I see the 2.8x project as an opportunity to rethink some things and to work on bigger projects. Here some ideas that came into my mind.

(Bigger) projects

Continue work on the Kernel Split for both OpenCL and CUDA
Runtime compilation for CUDA kernels (feature based compilation as a first step, can happen before the kernel split as well)
OpenVDB integration
Rethink our bundled set of procedural textures, especially if we want to extend them in a meaningful way. (see e.g. D1463)

Deprecations

Remove Cache BVH feature (done)
Drop support for CUDA on 32bit platforms: I highly doubt that people, using a 32 bit OS are serious about GPU compute. And honestly, inline checks for e.g triangle_intersect_precalc() are a joke atm, Even with the kernel split, runtime compile on a 32bit OS with just 2GB of memory is highly questionable too. So I think 2.8x is a good opportunity to drop support here.

Looking forward to feedback here from you guys (@Sergey @brecht and others)

**NOTE: For now this task is only meant for Cycles developers and module members!** Hi, Now that 2.76 is out (at least the RC), it's time to think about the Blender 2.8x project and Cycles. I see the 2.8x project as an opportunity to rethink some things and to work on bigger projects. Here some ideas that came into my mind. **(Bigger) projects** - Continue work on the Kernel Split for both OpenCL and CUDA - Runtime compilation for CUDA kernels (feature based compilation as a first step, can happen before the kernel split as well) - OpenVDB integration - Rethink our bundled set of procedural textures, especially if we want to extend them in a meaningful way. (see e.g. [D1463](https://archive.blender.org/developer/D1463)) **Deprecations** - Remove Cache BVH feature (**done**) - Drop support for CUDA on 32bit platforms: I highly doubt that people, using a 32 bit OS are serious about GPU compute. And honestly, inline checks for e.g triangle_intersect_precalc() are a joke atm, Even with the kernel split, runtime compile on a 32bit OS with just 2GB of memory is highly questionable too. So I think 2.8x is a good opportunity to drop support here. Looking forward to feedback here from you guys (@Sergey @brecht and others)

Thomas Dinges commented

2015-09-25 01:24:46 +02:00

Changed status to: 'Open'

Thomas Dinges commented

2015-09-25 01:24:46 +02:00

Added subscribers: @ThomasDinges, @Sergey, @brecht

Aaron Carlisle commented

2015-09-25 01:39:12 +02:00

Added subscriber: @Blendify

Brecht Van Lommel commented

2015-09-25 04:02:06 +02:00

It all sounds good to me.

Personally I think implementing something like the Disney principled BSDF is important. As I understand it this shader was used for everything in Big Hero 6 (except for hair and volumes), and it doesn't have that many parameters, so that seems quite powerful and simple for users.

I would also enable multiple importance sampling by default for lights, volumes and world. Probably filter glossy as well.

For the GPU it would be nice to let a single GPU render multiple tiles at once, to get rid of the tile size problem. For the CPU multiple cores could also cooperate on the same tile too.

Basically I think being simple to use is one of Cycles' strengths, and it would great to make it even simpler. But it's entirely up to you guys to decide what to work on of course.

It all sounds good to me. Personally I think implementing something like the Disney principled BSDF is important. As I understand it this shader was used for everything in Big Hero 6 (except for hair and volumes), and it doesn't have that many parameters, so that seems quite powerful and simple for users. I would also enable multiple importance sampling by default for lights, volumes and world. Probably filter glossy as well. For the GPU it would be nice to let a single GPU render multiple tiles at once, to get rid of the tile size problem. For the CPU multiple cores could also cooperate on the same tile too. Basically I think being simple to use is one of Cycles' strengths, and it would great to make it even simpler. But it's entirely up to you guys to decide what to work on of course.

Joshua Lotfi commented

2015-09-25 04:53:46 +02:00

Added subscriber: @jml

Carlo Andreacchio commented

2015-09-25 05:34:41 +02:00

Added subscriber: @candreacchio

Arzhan Singh commented

2015-09-25 06:47:03 +02:00

Added subscriber: @groundjet

Arzhan Singh commented

2015-09-25 06:47:18 +02:00

Removed subscriber: @groundjet

Arzhan Singh commented

2015-09-25 06:50:07 +02:00

Added subscriber: @groundjet

Ivan commented

2015-09-25 08:04:56 +02:00

Added subscriber: @1vanK

Ivan commented

2015-09-25 08:04:56 +02:00

This comment was removed by @1vanK

*This comment was removed by @1vanK*

Sergey Sharybin commented

2015-09-25 08:55:15 +02:00

Wouldn't really call it "Cycles for Blender 2.8x", more like "Cycles roadmap" or so.

There's numerous of patches which are to be finished here and which could be applied for whatever our next release will be:

New features:

Self-shadowing option
Shadow catcher
Denoising (combined with variance estimation which should be also aligned with adaptive sampling). This also actually touches render pipeline and compositing, but some extra info is to be provided by Cycles.
Motion blur center (basically, which frame corresponds to fully opened shutter), D1380
Sample offset option for the renderfarms

Optimization:

Merge remaining optimizations from the Gooseberry branch
Theraded object export, D618
Fallback to simplier area light samling for small area lights being far away from the shading point
Low light threshold, D832

Experiments:

Camera lens nodes
Use new Perlin noise

But this is surely only stuff i've been working on, bigger plan will include work like:

Finishing work with OpenVDB and Alembic (main problem currently is the pipeline)
Switching to texture definition objects (or whatever their official name is) to overcome texture limit for CUDA cards with compute capability 3.5 and above.
Switching to non-packed image textures for OpenCL (will mean OpenCL 2.x bump)
Improvements in subdivision surfaces, real bump mapping

And surely feedback from @brecht is also good here.. So the list could actually become much-much longer.

I'm not sure opening a design task is the best way to communicate this. We've got handful developers in the area, we can just agree on the roadmap and do a code.blender.org post. Otherwise i'm afraid this task will get flooded with feature requests, requests to change priorities and so on.

Wouldn't really call it "Cycles for Blender 2.8x", more like "Cycles roadmap" or so. There's numerous of patches which are to be finished here and which could be applied for whatever our next release will be: New features: - Self-shadowing option - Shadow catcher - Denoising (combined with variance estimation which should be also aligned with adaptive sampling). This also actually touches render pipeline and compositing, but some extra info is to be provided by Cycles. - Motion blur center (basically, which frame corresponds to fully opened shutter), [D1380](https://archive.blender.org/developer/D1380) - Sample offset option for the renderfarms Optimization: - Merge remaining optimizations from the Gooseberry branch - Theraded object export, [D618](https://archive.blender.org/developer/D618) - Fallback to simplier area light samling for small area lights being far away from the shading point - Low light threshold, [D832](https://archive.blender.org/developer/D832) Experiments: - Camera lens nodes - Use new Perlin noise But this is surely only stuff i've been working on, bigger plan will include work like: - Finishing work with OpenVDB and Alembic (main problem currently is the pipeline) - Switching to texture definition objects (or whatever their official name is) to overcome texture limit for CUDA cards with compute capability 3.5 and above. - Switching to non-packed image textures for OpenCL (will mean OpenCL 2.x bump) - Improvements in subdivision surfaces, real bump mapping And surely feedback from @brecht is also good here.. So the list could actually become much-much longer. ---- I'm not sure opening a design task is the best way to communicate this. We've got handful developers in the area, we can just agree on the roadmap and do a code.blender.org post. Otherwise i'm afraid this task will get flooded with feature requests, requests to change priorities and so on.

Thomas Dinges commented

2015-09-25 13:14:27 +02:00

Hi,
I mainly opened this to collect some feedback from Cycles developers, which can be used as a basis for further discussion at e.g. the Blender conference in Amsterdam.

@brecht: Nice ideas. I agree that we should rethink some defaults in Cycles and as you said, enable MIS for example.

@Sergey: Good list! Just one question, I thought OpenCL 1.2 is required for the non-packed image textures, sure it's 2.0? We sure want to jump to OpenCL 2.0 at some point, but I am afraid it will take some time before all vendors support that.

One other thing that I would like to tackle are the various "todo" comments in the code. We have 202 "todo" comments in the cycles code base, maybe it wouldn't be a bad thing to spend a few days on these, and try to solve some of them or make sure they are still valid.

Hi, I mainly opened this to collect some feedback from Cycles developers, which can be used as a basis for further discussion at e.g. the Blender conference in Amsterdam. @brecht: Nice ideas. I agree that we should rethink some defaults in Cycles and as you said, enable MIS for example. @Sergey: Good list! Just one question, I thought OpenCL 1.2 is required for the non-packed image textures, sure it's 2.0? We sure want to jump to OpenCL 2.0 at some point, but I am afraid it will take some time before all vendors support that. One other thing that I would like to tackle are the various "todo" comments in the code. We have 202 "todo" comments in the cycles code base, maybe it wouldn't be a bad thing to spend a few days on these, and try to solve some of them or make sure they are still valid.

Heverton Franciel da Silva commented

2015-09-25 13:59:45 +02:00

Added subscriber: @HevertonSilva

Leroy commented

2015-09-25 14:00:03 +02:00

Added subscriber: @Leroy-Xie

Leroy commented

2015-09-25 14:00:03 +02:00

This comment was removed by @Leroy-Xie

*This comment was removed by @Leroy-Xie*

Heverton Franciel da Silva commented

2015-09-25 14:03:49 +02:00

Removed subscriber: @HevertonSilva

Thomas Dinges commented

2015-09-25 14:07:48 +02:00

Please read the original message here which says "NOTE: For now this task is only meant for Cycles developers and module members!" Thanks.

Please read the original message here which says "**NOTE: For now this task is only meant for Cycles developers and module members!**" Thanks.

Heverton Franciel da Silva commented

2015-09-25 14:09:40 +02:00

Added subscriber: @HevertonSilva

Sergey Sharybin commented

2015-09-25 15:04:15 +02:00

@ThomasDinges, well ok, two things got mixed here. For packed textures 1.2 is indeed the bare minimum. With 2.0 we can get rid of CPU roundtrip for the split kernel. But either my brain mixing some stuff in now (crunchtime with thesis eeh) but it could also be some neato stuff for textures support arrived in 2.0.

One more thing which will be handy in 2.0: workaround we did for global/private address space function arguments. In new OpenCL it's possible to skip doing manual tricks and benefit from some sort of c++-ish polymorphism.

And i agree that re-evaluating TODOs in the code is a good thing. Maybe even mention all relevant ones in the Cycles TODO Wiki page.

P.S. One more major thing (not directly Cycles-related) -- node/shaders graphs presets! This issue appears every so often now, really need to be addressed. But that's more of a Blender side work (which might be not so sexy-looking).

@ThomasDinges, well ok, two things got mixed here. For packed textures 1.2 is indeed the bare minimum. With 2.0 we can get rid of CPU roundtrip for the split kernel. But either my brain mixing some stuff in now (crunchtime with thesis eeh) but it could also be some neato stuff for textures support arrived in 2.0. One more thing which will be handy in 2.0: workaround we did for global/private address space function arguments. In new OpenCL it's possible to skip doing manual tricks and benefit from some sort of c++-ish polymorphism. And i agree that re-evaluating TODOs in the code is a good thing. Maybe even mention all relevant ones in the Cycles TODO Wiki page. P.S. One more major thing (not directly Cycles-related) -- node/shaders graphs presets! This issue appears every so often now, really need to be addressed. But that's more of a Blender side work (which might be not so sexy-looking).

Lukas Stockner commented

2015-09-25 15:38:58 +02:00

Added subscriber: @LukasStockner

Lukas Stockner commented

2015-09-25 15:38:58 +02:00

Some stuff from my current list is:

Compressed encoding (LogLuv 32bit) for float textures to reduce memory usage of huge HDRs
Grouping smaller textures into bigger ones to allow more textures on GPU (that might be obsolete with Sergey's post above)
Cubemap output for the panorama camera
Trying out the "Weighted Path Tracing idea" mentioned on BA: It's a mix of Pathtracing and Branched PT, where the user sets a number of secondary rays per sample and weights for the individual closure types

Regarding filtering, I'm currently working on a test implementation of Locally Weighted Regression filtering. LWR also has an extension for flicker-free animation filtering and adaptive sample distribution, so I think it would be a great approach for Cycles. However, the adaptive stuff means that it must be done directly in Cycles, not in the Compositor. Also, the current way in which Blender renders animations doesn't really allow for cross-frame filtering...

But IMHO the most important area is the handling of render passes, both in the Render API and in Cycles. A flexible system would allow many new features such as true AOVs (adding separate output nodes in the shader tree, maybe with Light Path Expressions to specify where they will be evaluated), "Light groups" (in the Luxrender sense, images passes that only contain the contribution of certain lights), many more Debug passes and Pass support for external renderers without having to modifying Blender...

Some stuff from my current list is: - Compressed encoding (LogLuv 32bit) for float textures to reduce memory usage of huge HDRs - Grouping smaller textures into bigger ones to allow more textures on GPU (that might be obsolete with Sergey's post above) - Cubemap output for the panorama camera - Trying out the "Weighted Path Tracing idea" mentioned on BA: It's a mix of Pathtracing and Branched PT, where the user sets a number of secondary rays per sample and weights for the individual closure types Regarding filtering, I'm currently working on a test implementation of Locally Weighted Regression filtering. LWR also has an extension for flicker-free animation filtering and adaptive sample distribution, so I think it would be a great approach for Cycles. However, the adaptive stuff means that it must be done directly in Cycles, not in the Compositor. Also, the current way in which Blender renders animations doesn't really allow for cross-frame filtering... But IMHO the most important area is the handling of render passes, both in the Render API and in Cycles. A flexible system would allow many new features such as true AOVs (adding separate output nodes in the shader tree, maybe with Light Path Expressions to specify where they will be evaluated), "Light groups" (in the Luxrender sense, images passes that only contain the contribution of certain lights), many more Debug passes and Pass support for external renderers without having to modifying Blender...

Ivan commented

2015-09-25 15:45:45 +02:00

Removed subscriber: @1vanK

Matt Heimlich commented

2015-09-25 16:27:47 +02:00

Added subscriber: @MatthewHeimlich

Matt Heimlich commented

2015-09-25 16:27:47 +02:00

Adding to the TODO tackling, I think time should be spent finishing some of the more half-baked features present before jumping into new things. Hair, hair shaders, volumes, and deformation blur still add much more to render time than should be acceptable, and proper displacements+autobump are a big part of a production pipeline that have been sitting on the table for years. Support for industry standards like UDIM and Ptex should also be high priority, even if Blender itself can't properly create them yet, especially considering that Cycles is now stretching its legs in other 3d packages. UDIM especially would likely take almost no time to implement, as everything we would need is already in the code.

I've played with the LWR patch. It is indeed very impressive. While not 100% accurate, I think it's a fantastic goal for Cycles considering the target audience and their likely limited access to render horsepower.

Adding to the TODO tackling, I think time should be spent finishing some of the more half-baked features present before jumping into new things. Hair, hair shaders, volumes, and deformation blur still add much more to render time than should be acceptable, and proper displacements+autobump are a big part of a production pipeline that have been sitting on the table for years. Support for industry standards like UDIM and Ptex should also be high priority, even if Blender itself can't properly create them yet, especially considering that Cycles is now stretching its legs in other 3d packages. UDIM especially would likely take almost no time to implement, as everything we would need is already in the code. I've played with the LWR patch. It is indeed very impressive. While not 100% accurate, I think it's a fantastic goal for Cycles considering the target audience and their likely limited access to render horsepower.

Dalai Felinto commented

2015-09-25 17:05:48 +02:00

Added subscriber: @dfelinto

Dalai Felinto commented

2015-09-25 17:05:48 +02:00

@LukasStockner:

Cubemap output for the panorama camera

I mentioned to @Sergey my interest in implement this, but he said he would prefer to have this supported via camera nodes instead.

@LukasStockner: > Cubemap output for the panorama camera I mentioned to @Sergey my interest in implement this, but he said he would prefer to have this supported via `camera nodes` instead.

Brecht Van Lommel commented

2015-09-25 17:12:43 +02:00

In #46258#337677, @MatthewHeimlich wrote:
Support for industry standards like UDIM and Ptex should also be high priority, even if Blender itself can't properly create them yet, especially considering that Cycles is now stretching its legs in other 3d packages. UDIM especially would likely take almost no time to implement, as everything we would need is already in the code.

For UDIM you really need to use something like the OIIO texture cache to avoid running out of memory, which is not easy to add to SVM. For OSL it's simple but in that case you can already write a simple OSL shader for UDIM. Even if you keep all textures in memory it's still a bunch of work to implement.

In my opinion UDIM is also a pretty terrible solution to the problem, but unfortunately seems to have become a standard so it may be unavoidable at some point. There's a bunch of undefined things regarding how to handle missing tiles, how to do wrap modes for texture filtering, how to filter across tiles, which tile to read metadata from, etc, and the large amount of image files is not very user friendly to work with.

> In #46258#337677, @MatthewHeimlich wrote: > Support for industry standards like UDIM and Ptex should also be high priority, even if Blender itself can't properly create them yet, especially considering that Cycles is now stretching its legs in other 3d packages. UDIM especially would likely take almost no time to implement, as everything we would need is already in the code. For UDIM you really need to use something like the OIIO texture cache to avoid running out of memory, which is not easy to add to SVM. For OSL it's simple but in that case you can already write a simple OSL shader for UDIM. Even if you keep all textures in memory it's still a bunch of work to implement. In my opinion UDIM is also a pretty terrible solution to the problem, but unfortunately seems to have become a standard so it may be unavoidable at some point. There's a bunch of undefined things regarding how to handle missing tiles, how to do wrap modes for texture filtering, how to filter across tiles, which tile to read metadata from, etc, and the large amount of image files is not very user friendly to work with.

Matt Heimlich commented

2015-09-25 17:23:12 +02:00

I'd be curious to hear your thoughts on .tx support as well, Brecht (and Thomas and Sergey). The render time savings in Arnold and Renderman are pretty enormous in my own tests.

Interesting notes on the UDIM front. I've done some manual setups using the mapping node with decent results and figured that a basic implementation wouldn't take anything more than a couple of functions to parse the file name and automatically adjust the mapping accordingly.

I'd be curious to hear your thoughts on .tx support as well, Brecht (and Thomas and Sergey). The render time savings in Arnold and Renderman are pretty enormous in my own tests. Interesting notes on the UDIM front. I've done some manual setups using the mapping node with decent results and figured that a basic implementation wouldn't take anything more than a couple of functions to parse the file name and automatically adjust the mapping accordingly.

Brecht Van Lommel commented

2015-09-25 17:32:33 +02:00

.tx files currently should give good memory savings (and faster startup time) when using OSL, since that uses the OIIO texture cache to load just the necessary tiles and resolutions. For longer renders there won't be significant render time savings, unless you run out of memory.

For SVM it's more difficult because we'd need to add support for ray differentials for all nodes that manipulate texture coordinates, which OSL handles automatically. For CPU rendering that would be good that add. GPU support for a texture cache would be great but it's very challenging to implement.

.tx files currently should give good memory savings (and faster startup time) when using OSL, since that uses the OIIO texture cache to load just the necessary tiles and resolutions. For longer renders there won't be significant render time savings, unless you run out of memory. For SVM it's more difficult because we'd need to add support for ray differentials for all nodes that manipulate texture coordinates, which OSL handles automatically. For CPU rendering that would be good that add. GPU support for a texture cache would be great but it's very challenging to implement.

Jason Clarke commented

2015-09-26 17:49:37 +02:00

Added subscriber: @JasonClarke

Sergey Sharybin commented

2015-09-27 11:30:41 +02:00

Speaking of ray differencials.. We need to support mipmaps for SVM. It's quite straightforward to do on CPU, on GPU where we're limited in memory and can't really do on-demand scaling it's a bit tricky.

The idea i had in mind here is to exploit CPU roundtrip which currently happens in split kernel. Roughly speaking, kernel might detect missing data which then lead to CPU roundtrip and missing data will be uploaded to the GPU. A bit tricky to implement in a proper way so performance is not killed by the constant data transfer happening..

Speaking of ray differencials.. We need to support mipmaps for SVM. It's quite straightforward to do on CPU, on GPU where we're limited in memory and can't really do on-demand scaling it's a bit tricky. The idea i had in mind here is to exploit CPU roundtrip which currently happens in split kernel. Roughly speaking, kernel might detect missing data which then lead to CPU roundtrip and missing data will be uploaded to the GPU. A bit tricky to implement in a proper way so performance is not killed by the constant data transfer happening..

Bartosz Moniewski commented

2015-09-28 11:11:29 +02:00

Added subscriber: @BartekMoniewski

Kévin Dietrich commented

2015-09-28 12:23:11 +02:00

Added subscriber: @kevindietrich

Kévin Dietrich commented

2015-09-28 12:23:11 +02:00

Hi gang, I have been a little silent lately.

For OpenVDB, currently it is using a node to get the volume from a file. This feels about right for just sampling the grid as a texture, but when it comes to ray intersection (accelerated ray marching/empty space skipping) it feels a bit hackish to me. Also I haven't really spent time to figure out which grid in a file to use for ray marching, or how to let the user choose it. Currently it is using the first grid with "density" in its name (case insensitive) or the first scalar grid otherwise. Then I'm not sure how to extend it to have, maybe, motion blur going on (how to choose the velocity grid if one or more are present, etc...).

I would rather see (make) a better integration where volumes are dealt with like objects, with some attributes to get what the user wants. The attributes don't really need to be passed through the attribute node, they could also be hidden in a convenient volume node or else. For that, I would also like to see some sort of volume primitive in Blender, which is then passed to Cycles. At first this will only be for gas simulations (maybe liquids too). This would also make it easier to deal with external VDB files as they don't have the same scale and orientation than Blender's (so first import in Blender, set proper scaling..., then pass to Cycles), and it will also make it easier to support level sets (or distance fields) rendering in Cycles.

Anyway, I haven't put much thoughts into this, and it deals with workflow/pipeline a lot, so this is open for discussion.

P.S. : there is also compilation with OSL/LLVM that needs to sorted. Initially DreamWorks had accepted my quick patch to replace the built-in C++ typeid system with boost's typeid system (easier and less painful than creating a home brew system for it's usage in OpenVDB), so it can be turned off, but then they reverted the change because... it's using boost and they want to get rid of it and switch to C++11 (good and bad news right there ;). Anyhow, I think it should be doable with my current implementation to isolate the OpenVDB code so there are no collisions with OSL during compilation. I'll check on that shortly.

Hi gang, I have been a little silent lately. For OpenVDB, currently it is using a node to get the volume from a file. This feels about right for just sampling the grid as a texture, but when it comes to ray intersection (accelerated ray marching/empty space skipping) it feels a bit hackish to me. Also I haven't really spent time to figure out which grid in a file to use for ray marching, or how to let the user choose it. Currently it is using the first grid with "density" in its name (case insensitive) or the first scalar grid otherwise. Then I'm not sure how to extend it to have, maybe, motion blur going on (how to choose the velocity grid if one or more are present, etc...). I would rather see (make) a better integration where volumes are dealt with like objects, with some attributes to get what the user wants. The attributes don't really need to be passed through the attribute node, they could also be hidden in a convenient volume node or else. For that, I would also like to see some sort of volume primitive in Blender, which is then passed to Cycles. At first this will only be for gas simulations (maybe liquids too). This would also make it easier to deal with external VDB files as they don't have the same scale and orientation than Blender's (so first import in Blender, set proper scaling..., then pass to Cycles), and it will also make it easier to support level sets (or distance fields) rendering in Cycles. Anyway, I haven't put much thoughts into this, and it deals with workflow/pipeline a lot, so this is open for discussion. P.S. : there is also compilation with OSL/LLVM that needs to sorted. Initially DreamWorks had accepted my quick patch to replace the built-in C++ typeid system with boost's typeid system (easier and less painful than creating a home brew system for it's usage in OpenVDB), so it can be turned off, but then they reverted the change because... it's using boost and they want to get rid of it and switch to C++11 (good and bad news right there ;). Anyhow, I think it should be doable with my current implementation to isolate the OpenVDB code so there are no collisions with OSL during compilation. I'll check on that shortly.

Brecht Van Lommel commented

2015-09-28 13:20:56 +02:00

@kevindietrich, I think it would indeed be best to have a built-in volume object in Blender, there's lots of awesome possibilities with the OpenVDB library.

If you want an intermediate solution for Cycles though I think it would be fine to have a mesh property that has an OpenVDB filepath. Then you don't need to add a new node and all attribute lookups can simply use that file. For ray intersection I would automatically use all attributes requested by the shader network. So that means you might intersect multiple grids and then merge the intersections (or you could try to merge the grids though that's trickier if they have different transforms).

The RTTI issue is annoying yes. It should indeed be possible to isolate either the OSL or OpenVDB code to use different RTTI flags, I think we were doing that for OSL at some point.

@kevindietrich, I think it would indeed be best to have a built-in volume object in Blender, there's lots of awesome possibilities with the OpenVDB library. If you want an intermediate solution for Cycles though I think it would be fine to have a mesh property that has an OpenVDB filepath. Then you don't need to add a new node and all attribute lookups can simply use that file. For ray intersection I would automatically use all attributes requested by the shader network. So that means you might intersect multiple grids and then merge the intersections (or you could try to merge the grids though that's trickier if they have different transforms). The RTTI issue is annoying yes. It should indeed be possible to isolate either the OSL or OpenVDB code to use different RTTI flags, I think we were doing that for OSL at some point.

Lsscpp commented

2015-09-28 14:59:33 +02:00

Added subscriber: @lsscpp

Germano Cavalcante commented

2015-09-28 16:09:13 +02:00

Added subscriber: @mano-wii

Will Olis commented

2015-09-28 18:26:55 +02:00

Added subscriber: @WillOlis-1

Will Olis commented

2015-09-28 18:30:10 +02:00

Removed subscriber: @WillOlis-1

Ronny G commented

2015-09-28 22:26:30 +02:00

Added subscriber: @nudelZ

Anderson Omori commented

2015-09-29 03:56:20 +02:00

Added subscriber: @AndersonOmori

Anderson Omori commented

2015-09-29 04:10:34 +02:00

Removed subscriber: @AndersonOmori

kb commented

2015-09-29 12:07:13 +02:00

Added subscriber: @gregsaw

David Fenner commented

2015-10-13 19:17:42 +02:00

Added subscriber: @DavidFenner

David Fenner commented

2015-10-13 19:17:53 +02:00

Removed subscriber: @DavidFenner

Joshua Lotfi commented

2015-10-14 03:52:15 +02:00

Removed subscriber: @jml

carlos commented

2015-10-15 02:40:52 +02:00

Added subscriber: @carlossifuentes

carlos commented

2015-10-15 02:40:52 +02:00

This comment was removed by @carlossifuentes

*This comment was removed by @carlossifuentes*

Bartosz Moniewski commented

2016-01-25 19:13:15 +01:00

Added subscriber: @LukasTonne

Bartosz Moniewski commented

2016-01-25 19:13:15 +01:00

This comment was removed by @BartekMoniewski

*This comment was removed by @BartekMoniewski*

Brecht Van Lommel commented

2016-01-25 19:23:46 +01:00

Please, this is not the place for feature requests, if you have ideas mail bf-cycles, post proposals on forums, on the wiki, etc.

JT Nelson commented

2017-03-23 05:33:40 +01:00

Added subscriber: @jta

Diego Gangl commented

2017-06-12 01:54:36 +02:00

Added subscriber: @Januz

Stefan Werner commented

2017-07-21 16:07:17 +02:00

Added subscriber: @Stefan_Werner

Brecht Van Lommel commented

2018-01-24 03:21:59 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2018-01-24 03:21:59 +01:00

Brecht Van Lommel self-assigned this 2018-01-24 03:21:59 +01:00

Brecht Van Lommel commented

2018-01-24 03:21:59 +01:00

Archiving this task, it was useful to get everyone's opinion but no point keeping it open now. We maintain a roadmap here:
https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/Roadmap

Archiving this task, it was useful to get everyone's opinion but no point keeping it open now. We maintain a roadmap here: https://wiki.blender.org/index.php/Dev:Source/Render/Cycles/Roadmap

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles plans for Blender 2.8x project #46258