Is there a possibility to make an integrator like the biased redshift GPU algo in cycles ?
Redshift is insanely fast. Nearly realtime but sadly only on Windows and then only on Maya/Max.
Or would it be more wise to wait for a bigger/faster MC optimisation (noisefree/speed)?
And if so, are there any plans ?
Update: what about a photon mapping/cache+MC (Vray style) uses but on GPU+CPU.
The whole Inside/Outside light transport in vray is amazing.
I also see 2 directions here:
Extend the actual PT to the realism of a maxwell/octane/MLT for stills and extremely highend shots.
Use either a huge optimisation, and/or a new biased MC integrator for animatons.
Cycles could have more options for rendering with more realistic lighting. Then we wouldn’t need external renderers like Luxrender. But why make things too easy.
Before asking questions like this, do more research on the difference between a production path tracer and something like RedShift. Cycles already has plenty of “bias” options (clamping, filter glossy, path lengths, etc.), but “bias” isn’t just some knob you turn up in the code. Could these things be added to Cycles? Sure. It’s code. You could add a calculator and a chess game to play during rendering to Cycles if you really wanted to. But it clearly goes against the design principles, just as adding in a biased, non PT-based integrator would be. Anyone could add these to Cycles’ core code, but there’s still a lot of work to be done on the initial goals of the engine before it’s time to start tossing in the kitchen sink.
In fact current Cycles is the most physically correct renderer in the industry if talking about rough reflective surfaces. All other renderers, including Luxrender, are playing catch up to it currently.
Most of the other renderers already have the GGX model, it’s just a matter of implementing the extension to it that is described in the paper.
It won’t be that hard for them to catch up if they make it a priority (and last I’ve seen, Lux is currently in the back of the pack in terms of glossy materials since they don’t have GGX yet).
From what I understand, they are looking at splitting up the kernel into smaller modules… Which will mean dropping in a new integrator ‘should’ be easier then what it currently takes to implement a new integrator.
It doesn’t matter what it is all called unless it is the only shader in you material… as soon as you mix two shader with the layer weight or Fresnel node then it’s not really physically correct.
Not that is a major problem because I don’t think physical correctness is the main aim of Cycles.
I don’t even know how to answer to this. I’m just amazed now that I don’t have to use Luxrender to get great caustics and all that, because Cycles is clearly more physically correct and better than anything else.
c’mon! again that sentence is all about the GGX multiscatter which Cycles afaik was the first to implement. Every other software have (had?) buggy glossy roughness calculation, aka energy loss at high roughness values
Cycles shaders are just component to build more complex shaders that eventually act as physically correct. In fact, at the beginning they were called closures, probably a name that didn’t induce into thinking they were full shaders as the name shader does
Right, diffraction is out of reach because of the non-spectral nature of cycles, but you can simulated it quite well unless you’re pursueing scientific diffraction correctness.
All that said, it’s true that glass shader being there is to be considered as an exception
How do you define “physically correct”? Even when Cycles BSDFs don’t model every phenomenon that exists when light interacts with surfaces, that doesn’t make it physically incorrect. They’re idealized surface models. Physics is full of idealizations and approximations where factors are simply ignored for practicial purposes. What would make it incorrect would be something like violation of the conservation of energy law (which afair does happen with the Add Shader).
What you are doing in any physically-based renderer is simulating an approximation of the real world, using the laws of physics. Even if your approximation of the real world doesn’t model the full visible (or invisible!) spectrum of light, for example, it can still correctly apply those laws.
It also has nothing to do with the fact that effects like caustics are inefficient to the point that you may not be able to use them in practice.
They are BSDFs which can be combined to form other BSDFs. The term ‘closure’ stems from OSL and is a programming language term. A single BSDF can be a perfectly fine approximation of a real-world surface (i.e. a “shader”). In fact, mixing them makes for a much more questionable approximation of real-world surfaces. It would be better if there were dedicated BSDFs aimed at approximating things like coated plastics - then you could locally deal with the fresnel effects, for instance.
Nothing in the machine is physically correct except parts and the electrons itself
Everything is simulated without perfect accuracy possible (limits of known math, theories, understanding, tech, single precision…).
If it looks real or even better
I would prefer physically correct to be considered as the artists skill, an expertize that understands and is proven to be on pair with realism even if only using crayons.
After all, realism is boring and needs styling to achieve true artistic value. Look up what ancient Greeks did & how long it lasted.
Wishing for Blender to evolve, it would be amazing if simulating light (Cycles) and the viewport (OGL) could mix in realtime.
I think that is where the problems start. If physically correctness is what people want then I think the better approach would be to go for uber shaders. But I don’t think physical correctness is the aim of Cycles.
