Oi oi oi, Can this Please not become just another rendering Engine war zone. That is in now way what the thread was started for. Cycles Great, Lux Render (realtime Opencl very nice for AMD users to test quick light setups),BI Internal yep not cutting edge but still useful. Many many different software’s that all have their place. The test’s ive been doing with AMD card based Lux render mode has been with Bi directional VCM (works great even on old kit like my AMD HD 5850). The thread was started about how one idea can benefit another, how one idea mixed with another can spawn new idea’s. I’ve done a few tests with LUX over the last day that ill have to post, But have to say even in Complex shading scene’s with my naff graphics card in getting near noise free images after 600-2000 samples (2-6 Mins).
Couple tests already posted just to show how far Lux GPU has moved on, Second one has realtime Auto focus DOF, Vignet,Bloom etc)
Please people play nice and don’t try to make this into a competition between very talented devs from different groups.
Lux is difficult, because for start it has many different rendering methods with rather cryptic settings. You need to know that stuff pretty well to produce good results. Lux’s realistic way to handle light is problematic in many scenes (resulting to fireflies and noise) but it means you get realistic looking scenes without tricks. Even if you just use plain color material in Lux it looks realistic. Cycles relies more on setting up convincing materials and textures.
They are different type of renderers like mentioned before. Until of course if Cycles gets more realistic rendering options (which I’m hoping it will). The good thing in Cycles is that it’s fast and easy to use (you don’t need a physics degree to use it like with Lux). I didn’t like Cycles at first, but I’m starting to like it.
You can easily see the difference the filters have here, and that would lead to the large fireflies as well
The last render is where LuxRender 2.0 is heading, which appears to basically be a rewrite of LuxRender with what has been learnt with previous Lux versions, and SLG/LuxRays.
Dade from LuxRender has already written a basic demo of how a ‘inside Blender’ version of LuxCore (2.0 base) can be written using the python[?] API for LuxCore.
Do you notice anything ? Yes, it supports view port real-time update like Cycles, I move the cube around and the upper left view port is updated in real-time
"
These 2 links here contain info on whats going on with the new Lux development:
The Suzanne scene above (fully exterior, opaque materials) is a good example of when it is completely counterproductive to use a bidirectional integrator.
I wonder what people that ask for caustics are rendering all day, according to the Arnold dev practically none of their customers ever asks for them.
I also don’t understand how people can find Luxrender harder to use when it comes with perfectly fine material presets, whereas Cycles doesn’t even come with a coated glossy default material. The default render preset may not be the fastest, but it always converges to a decent result. I’ve always considered Luxrender to be a great “fire and forget” solution.
As for the fireflies, you should render at a higher resolution and let some filter that is designed for the task take care of it it (e.g. hot pixel removal for photography). Also, just don’t render things that are stupidly hard for any of the algorithms, until the silver bullet has been invented for you.
For a good (and fairly general) overview of the relevant algorithms and BSDFs, I recommend to consult the excellent Mitsuba Manual.
Indeed, when comparing rendering engines, it is extremely hard to not end with an holy war. I want to clarify a couple of points so please keep in mind there is no flame intended:
LuxRender project interest in GPU rendering started well before Blender Project interest and we proposed a collaboration in the past. It was kindly rejected, no problem but just to say that we have already done an offer and it wasn’t accepted. Now it seems something very hard to set up with a large amount of code already written in both projects.
the argument that Cycles works on NVIDIA OpenCL so it is an AMD compiler fault if it doesn’t work, is very weak. I have read on this forum that Cycles is 7 times slower than SLG when rendering about the same scene (i.e. the classic BMW benchmark) with NVIDIA OpenCL on NVIDIA GPUs. If it is true, the only logical conclusion is that, from a practical point of view, Cycles doesn’t work with OpenCL at all. Is there anyone using Cycles OpenCL version on any platform ?
LuxRender GPU code uses many tricks to be able to work with OpenCL from AMD, NVIDIA, Intel, Apple, etc. The tricks have been developed over many years of work, fighting with vendor bugged drivers. The obvious question is if the same tricks can be applied to Cycles too.
In my opinion, the answer is yes and no. Some can be applied, some would require such huge rework of Cycles code to not be practical for Blender Foundation. So it is likely to not be a working OpenCL Cycles version for a foreseeable future.
Mmmm, I’m afraid that touching such sensitive arguments (for people ego) without starting a flame war is impossible
As you said, it is hard to compare renderers, so I wouldn’t draw conclusions from what someone claimed on these forums. Cycles runs at about 75% the performance of CUDA in OpenCL on NVIDIA, which is also reasonable because the CUDA compilation takes longer and CUDA is closer to NVIDIA hardware. Since the CUDA version is faster and has been tested thorougly, of course everyone is using that.
I don’t think it’s a weak argument to point to 15GB of ram usage and a 30 minute compile process that often ends up failing as AMDs fault (after all, they admitted to it and we are seeing improvements). On the other hand, if it compiles and ends up running slowly, that could be due to architectural differences. SLG runs much slower on NVIDIA, more so than most any other OpenCL benchmark. I’d speculate the BVH code and the simple shader model gives GCNs raw power a significant edge here.
The above is so full of wrong I just have to correct it:
Internally LuxRender has always been node based. We could not expose this fact directly in Blender because Blender did not support custom nodes until very recently. Cycles got node support earlier because Blender was internally modified to support Cycles nodes explicitly.
LuxRender was by no means the first consumer pathtracing engine released, not even close. The most famous one might be POV-Ray, which started it’s life back in the mid-1980’s…
Dade estoy totalmente de acuerdo, tienes idea cuando sale lux 2.0. Ademas lux no solo tendria que andar mejor en blender si no tambien la integracion de interface con el mismo. Una cosa que podria solucionar que luxrender reduzca la cantidad de ruido es el algorismo de Disney pero no se sabe si sera libre el algorismo. 3dLuver puedes subir el archivo de video de youtube para probarlo con mi Asus 7870. Lo otro seria poder tratar de comparir Vram y con ram mediante el chip onboard de video porque no entiendo porque no se puede usar el onboard de la placa madre. Asi poder usar la onboard para la representacion del video escritorio tipo windows ect y dejar la gpu placa liberada totalmente.
Dade totally agree, you have no idea when 2.0 goes lux. Lux also not only would have to walk better in blender if not also the integration of the same interface. One thing that could solve LuxRender reduce the amount of noise is the algorism of Disney but it is unknown if it will be available on algorism. 3dLuver can upload the youtube video to prove it with my Asus 7870. The other would be to treat of sharing Vram and ram using onboard video chip because I do not understand because you can not use the onboard motherboard. So to use the onboard video for the representation of the type desktop windows ect and leave the gpu plate fully released.
PBRT and the Physically Based Rendering book was written by Matt Pharr and Greg Humphreys, LuxRender started out with some other codebase but quickly the entire codebase was replaced by a fork of PBRT. That’s so long ago LuxRender effectively has always been a fork of PBRT.
Name any forum where both artists and technicians hang out, and I promise that you will very-regularly encounter “arguments” that sound like “flame wars.” But, have no fear. If people weren’t very emotionally-vested in what they were doing, they couldn’t be doing this sort of thing at all, and the rest of us wouldn’t have what we have. :yes:
