Did cycles killed Luxrender ?

Now tht we have cycles totally integrated and interactive we should we use lux ?

luxrender still has some things that Cycles cant do right now, like Bloom, vignette, glare, C. Aberration etc…

or if Cycles can do them i dont know how…

It most certainly did not. In fact, the work on Cycles is going to improve blender’s render API so that external engines like Lux can integrate better.

here is one thing “vignetting” that can be done in Cycles doing it this way…

Well, it is quite hard to say how much was the development influenced by integration of Cycles into Blender. This question goes probably on the developers of Luxrender. The frozen development can be seen also at the Yafaray - a similar situation. It’s primarily related to the low number of developers. Does it make sense to their development? From my point of view, yes. Cycles isn’t in current stadium very suitable e.g. for interior renders, there is still a lot of staff that should be done (not sure, there is only Path tracing support? - at least Bidirectional would be nice) and I am also not sure if Cycles is aimed at this area of rendering. So I will be more then happy to see the continuation of Lux / Yafa(mainly) development.

i do believe you can do bloom and vignetting in the compositor.

you probably can…(i just dont know how… :evilgrin:

that compositor thing still seems foreign even after using for awhile…

it would be nice to just have proper nodes to do what you want(vignette node, bloom node, glare node ,etc)

you could probably make your own vignette, bloom and glare group node setups in less than half a days work and than from there own you just append them to a file when you need them its not that hard.

for me Cycles has kind killed both of those two renders just because of its node based shaders. I hope there is not too much of a focus on integrators and more on things like passes, dof, motion blur, hair.

Cycles with node materials and passes will move it far ahead of Lux and Yafaray.

Luxrender however does seem like it can make limited use of the Node UI.

It has a mix material, a mix texture, a multi-mix texture, various fresnal textures and others that use geometry information. Theoretically, some of those could be presented as node types instead and still send information that the Luxrender core can understand.

I would still that while Cycles is the engine I prefer now, Luxrender may still be useful for those who want to get a level of photorealism that matches that of photography down to the physical attributes of the materials, I am personally watching to see where their SPPM implementation ends up because it seems to address one of the key issues that keep people from using Lux, which is speed.

Meanwhile I would still probably use Cycles as my main renderer, one of the main reasons being the idea that it can strike a good balance between realism and flexibility.

I think there’s plenty of room for both & then some.

I sure hope they all keep innovating. I think Lux has SSS and volume? Need that.

I have kind of found SPPM to be slow in both Yafaray and Lux, slower than the other integrators. Both Yafaray and Lux materials seemed to be more geared towards material layering. Cycles has an edge as its materials are node based and built around OSL that lightpath node is a magic box of neat tricks.

With Mango on the horizon passes and motion blur will probably come in months. In four or five months it will likely have a huge lead over both engines.

Personal I am focusing on one engine as I would rather master one engine than be merely ok in several. I tried doing that in the past but I think its kind of a flawed way to go about things for someone who is a hobbyist and has limited time to pour into multiple hobbies.

LuxRender’s material system is actually node based. However due to Blender limitations it was impossible to expose this in Blender’s node system, leading to the current situation of layered materials and textures. It seems that finally there’s some progress on this in Blender, thanks to Cycles. Hopefully we can soon do what we’ve wanted to do for a long time.

Disclaimer: I’m a LuxRender developer

The difference between LuxRender and Cycles is much greater than that. The biggest one is that LuxRender is and will be physically based, while Cycles is not and from what I’ve read won’t be.

This divide is most obvious when making materials. For example you shouldn’t use a specular reflection component higher than 0.25 in LuxRender because it’s not physical. Doing so can lead to weird looking objects and lots of noise. On the flip side, if you use realistic values you get something which looks natural without much tweaking.

Yes, LuxRender currently supports homogeneous volumes, which can be used for anything from fog and god rays to SSS. It also has limited support for non-homogeneous volumes (for smoke).

Luxrender at least supports AMD/ATI. Opencl will get implemented in Cycles, but it’s taking it’s time.

What a joker this holyenigma guy. Those are simple postprocessing effects.

Call me when Cycles got bidirectional pathtracing with mlt for those difficult internal scenes, is a full spectral renderer or has more physical-based materials, including with SSS.

It’s an edge for artists, who love to tweak until the very last brush stroke. It’s not an edge for archviz professionals who just want materials to be as close to the real thing as possible. So, yes, there’re obviously very distinct audiences for Cycles and Luxrender.

Does Cycles have a 3DS Max exporter? I think not…

Will these changes allow us to use nodes in a similar way as cycles. would they be able to increase the speed and efficiency and will you be able to use multiple gpu’s.