Cycles Requests

When you say “graphics cards we support” you must mean Nvidia and AMD. But why don’t you just add support for Intel iGPUs, at-least the ones that support newer OpenCL? I’m hoping that Intel iGPU’s would make hybrid rendering faster, especially with shared virtual memory.
If Blender starts to support OpenCL 2.1, then we can use it on Intel in the meantime, but then we’ll have progress by the time AMD supports it.
I’m not a programmer, so tell me if I’m wrong. But isn’t OpenCL 2.0+ more portable across hardware than 1.2, especially with SPIR-V?

I’d love this as well! Deep compositing solves so much!

It’s more of a general rendering request, since Eevee would also benefit from this.

OpenCL C++ and shared virtual memory are mostly convenience features that make code simpler to write, not to make it run faster. SPIR-V is mostly useful for people writing compilers.

If we have to maintain double code, any convenience is lost. None of these new features solve the reason why we don’t support Intel GPU’s currently, which is that it’s a lot of work for us to support another platform which will only give minor speedups over CPU rendering.

2 Likes

when can we expect Intel Open Image Denoicer for cycles :heart_eyes:

2 Likes

One thing that every denoiser is prone to do is slaughter the subtleties of reflections with varying roughness and color. I’d personally love for a roughness pass, and denoiser algorithms that take that roughness pass into account

A post was split to a new topic: Procedural Cycles nodes summer of code

I woudl like to request a render-time Boolean shader much like the VRay Clipper as demonstrated here: https://www.youtube.com/watch?v=DLRzW6ixopI

This can also be animated for cross-cut reveals that can cap geometry and shade the caps in the object material / texture.

7 Likes

Progressive rendering with F12 is really slow compared to bucket.
But it would be nice to see the whole rendering shortly after pressing F12.

I’m not sure, but maybe it’s not easy to fix at all.
Implementing cycles viewport IPR into F12 is probably not easy because of denoising.

In this case, one could render the image with maybe 32 samples and then rerender it again and again to merge the samples from the buckets until a certain amount of loops/passes is rendered.
For example: 32(Samples) x 16(passes) = 512 samples in total

Arnold render and Renderman do it like that i think.

1 Like

I posted a proposal some times ago on rightclickselect asking exactly for this! (If I find it I’ll link it here)

1 Like

It isn’t “yet” being worked on? Could it be considered before 2020?

I posted this in this GSoC Project - but as Brecht pointed out, it’s way too much work for that - maybe at some point it can be picked up, so I just copy-paste it here:

The ability to create your own expressions
This could be a Node that allows text input and the creation of your own in- and outputs. You could then input for example:
outputA = inputA * pow(inputB, 2) + 1
This would of course be restricted to the existing Math operations. This way instead of creating huge networks of Math Nodes, a single Node with an expression would be enough.

Adding in and Outputs could work like it currently works with NodeGroups - in the Sidebar (with your additional functionality to controll the type).

An Example would be Rendermans PxrSeExpr

6 Likes

as mentioned previously, you can already do this with OSL, and if you stick to basic equations oslpy will even make them run on the gpu.

Sure, you can do everything with OSL. But this would be more handy and accessible. I’m not proposing to make this Node compile complex OSL - just basic expressions.

I have an update for oslpy that’ll make it work with eeve/2.8 just need to find some time to finish it.

4 Likes

But the “bad” part of OSL is that, at least in the past, it made Cycles slower and it was only supported under CPU, no GPU support, for OSL to be really widely used and available I think GPU support has to be implemented, and render times with OSL need to be optimized, just my 2 cents :slight_smile:

OSLPY makes it run on the cpu and gpu without having to have the osl checkbox checked, there’s no slowdowns.

1 Like

Oh! What? awesome!

And is that already implemented in master?

I mean… can we use OSL with GPU already by default?

Then, the OSL checkbox… shouldn’t be removed?

1 Like

it’s an addon, doesn’t ship with stock blender. more info here

no 2.8 compatible version?

And it seems it’s yours! :slight_smile: , you don’t want it to be included in Blender? (as an included addon I mean)

Cheers!

I have a 2.80 version that’ll work with both eeve and cycles, just need to find some time/motivation to finish up tying up some loose ends

1 Like