Vulkan is the next step. I assume, with it others (ie. CUDA/Optix tools) will have easier way to be able to use Radeon HW and CPUs along.
1 Like
Duh, You clearly dont have a clue about any of this. Search Radeon rays, tut tut tut.
Someone have already started working on it, in some capacity. Alex Fuller, a Sr. Lighting TD at ILM.
And don’t worry much, Blender always care for most of its user-base and doesn’t give sheer importance to only one or few particular hardware vendors.
2 Likes
So, AMD cards will be able to use OptiX?
For a rookie could you explain how this works?
Optix will be integrated in Cycles or a separated engine ?
Unfortunately, OptiX ray-tracing engine (which is created by the engineers of NVIDIA corporation) can only be used with NVIDIA cards. It’s common corporate business strategy and planning (just like Embree works only with Intel CPUs). These high-end computer hardware companies also make some of the cutting-edge complementary software, so that it eventually helps in increase their sale of the main product they are manufacturing.
Basically, OptiX as a ray-tracer can be built on top of most physically-based ray-tracing rendering engines. If you scroll above few posts above, I posted a link where a demo from Pixar, how they have build it on top of Katana (a product of Foundry; which is a LookDev and lighting solutions tool for feature length and VFX studios).
So, in Cycles you can envision an option/preset to switch back and forth between its default ray-tracing algorithm and that of OptiX, whichever an user can find some advantage and can leverage out of their NVIDIA GPUs.
Embree works just as well with AMD CPUs.
4 Likes
Oh, I didn’t know that. Perhaps their main competitor is NVIDIA now.
Maybe i`m wrong, but i was under the impression that the main thing that gave RedShift its speed was the GPU Biased aspect of it, processing Irradiance Point Cloud and Irradiance Cache in th GPU…,??.. or not?
2 Likes
It’s still a lot faster than Cycles (or anything else really) even when you don’t use those options. Honestly, for a lot of outdoor scenes the extra time needed to build the cache is slower than just using brute force pathtracing.
Interesting, faster even without using IPC and IC.
I don`t use RedShift because my video card does not supported, (is way to old). But i tried in the beta days, only with interiors, and was already very fast rendering with a combination of BruteForce and one of the Irradiance options.
Will be great to see what performance boost Cycles will have with Optix, although i may need to buy a new video card to check that out.
What is the difference between RedShift/Octane/Cycles ?
they all are raytracers but with diffrent flavour
Cycles - straight unidirectional path tracer - most simple to setup but noisy in indoors
Octane - kinda the same as cycles but with bidirectional option which could be useful in some situaions
Redshift is diffrent - it like goold ol’ Vray with all it’s fast unbiased point cloud methods to bake/calculate of GI which made vrau so popular back in the days. RedShift tries to do the same but on GPU so in some cases it could be much faster then others
Point Cloud methods usually introduce bias.
yes, biased of course
It’s just a typo
thanks for pointing out
Main point is that you could use combination of raytrace with Irradiance cache/photon map and there are many cases where results will be visually realistic enough but 10 times faster than brute force
1 Like
a little bit of bias for a massive speedup sounds like a good deal.
1 Like
That is why Cycles includes biased methods like ray marching, sample clamping or filter glossy.
This is true they speed up render times but often also they introduce artist overhead of having to manage cache sizes and think about point clouds or manually edit sample clamping values etc. And especially for animation renders to avoid popping of GI or shadows. Which leads to artists having to “think” or spend more time for a faster render. Also in a world of 32 core processors becoming more common, point clouds become less multithreading-friendly.
Point is, there’s very few free lunches out there. Just saying “hey faster render, let’s go back to point clouds and light probes” or whatever method is a bit simplistic view of things.
3 Likes
I don’t know why you talk about “going back” to some light probes for gi in offline renderer.
I think it is safe to say, vray and Corona have good gi caching methods, with good defaults so no artist overhead and the boost is something that you will not be able to complete with anytime soon.
I’m sorry but the argument that we now have 32 core processors so we don’t need it is… Wrong.
Reminds me of the time cuda was beginning to be a big deal for rendering and everybody thought now we don’t need caching. Even today same priced cpu will beat gpu if the lighting is complex and there is a ton of interaction between complex materials if you have caching. Existing tricks in cycles are Nice, but they surely introduce a lot of bias and they do need some extra work and testing from artist. Gi caching with good defaults could easily replace All the ao and simplify ao tricks, it would be more accurate, faster to setup and give more boost. Now if there is no one to do it, or it’s too difficult or something like that, then ok, I get it. But All the arguments against it I read here are like from 2004.
1 Like
That may have been true 10 years ago, but it is no longer true now.
Most of the modern production renderers, such as Corona and V-Ray have indirect lighting caches defaulting to high quality and stable solution. To make it stable in animation, in Corona it’s a matter of switching one radio button switch from still image to animation, and in V-Ray, it’s a matter of doubling one value from 1000 to 2000, that’s it.
The unbiased renderer myth has been debunked several times over past few years. There are some brute force path tracers out there, such as Arnold, that don’t cache, but they are still not unbiased. Also, despite not using any cache, Arnold is these days harder/longer to set up than Corona or V-Ray, because it still requires you to micromanage individual sampling and ray branching.
There’s currently not a single successful production renderer on the market that’s unbiased. There are a few unsuccessful ones, and even their claims of being completely bias-free don’t take much time to debunk.
The only way someone could interpret biased renderers as slower to setup is if the person had bad experience with let’s say Mental Ray and Redshift. Especially Redshift has completely failed in terms of usability, still requiring users to set up many sampling values which relate to each other in often counter intuitive ways. Redshift is definitely not an example of what a modern renderer looks like.
1 Like
Sorry you’re right in that I used the term “unbiased” a bit fast a loose with regards to the renderers out there. Mostly I was referring to pathtracers such as arnold and renderman and cycles for the colloquial use of the term “unbiased” (complete marketing from arnold). I would agree with you though that it’s hard to get caching right/easy both from a UI and developer standpoint, which is kinda my point. I’d rather cycles developers didn’t waste their energy on that as it’s not a given that adding something like that would make it easier.
More interesting IMO is using the pathtracer with different lighting algorithms (bidirectional/unidirectional/SPPM etc) and intelligently switching between them. Sort of like what Pixar is currently doing with the PxrUnified integrator in RenderMan 22. As a renderer developer this seems like a more forward thinking way to approach things.
@lacilaci86 I think you misread my statement about multithreading. GI caches inherently don’t scale well to large thread counts because of IO locks in any implementation I’ve seen. I didn’t say that because of multicore processors we don’t need it.
1 Like