For LuxCore API to work in LuxBlend, it has to find pyluxcore.pyd and all needed dlls (lux.dll, OpenImageIO.dll, python34.dll I think).
You can achieve this by either copying those files into the addon folder “luxrender” or by setting the path to the files in the user preferences in Blender.
I will definitely try to simplify the installation process before the final release of 1.5, things like this should not happen.
It would also be cool if we could install addon and its presets at once.
Impressive list of updates, though that’s why Lux doesn’t get a good chunk of stable users and you neither see works done with it in galleries around…IMHO…Pretty powerful engine, really weak user experience. You need to be quite involved in their forums and know a good amount of stuff even to get it running, so i guess people just prefer to fire up Cycles and gets similar (i don’t mean big Lux) engine capabilities without any efforts.
At the moment, we have a large chunk of stable users but they are from DAZ/Poser, not from Blender. We had a large chunk of Blender users before the release of Cycles but the situation has changed.
P.S. no flame intended, I’m just saying that 99% of Blender users will use the render engine shipped with Blender, there is very little room for anything else (and yes, I don’t consider Blender Internal, in my opinion it is not playing in the same league of Cycles, Lux, Yafaray, etc.).
Not sure, if a renderer is simple to use, it will be used, look a keyshot/Corona for exemple, very simple to use, so it’s used.
Cycles is not as simple as somebody can say.
Right now, I cannot use luxrender on GPU, So I don’t have to much time to figure how to use it and if the manip that JoseConseco said dosn’t work, I will not use it.
Hi Dade, I wanted to take the chance to congratulate you on luxrender. I’m Senior CG Lead/Lighter and been wanting to try lux in production for a long time… I feel Luxcore is just getting there. It would be beautiful to have a more flexible option than cycles in terms of lighting algorithms for production, that work on the same shader workflow and can adapt to many lighting situations. The quality bar is getting higher and higher and luxcore seems such a powerful tool to add that extra touch to renders, since it is now flexible (biased and unbiased), gpu accelerated, and has all that chunk of algorithms to play with. Now with all the beautiful render passes you added it gets closer and closer… (If only there was a gpu accelerated way of getting the beautiful caustics of bidir!).
Thanks for your hard work!! I’m sure that if lux keeps going like this it will be adapted to many workflows… flexibility, speed and quality is key. Quality is already there, flexibility and speed is getting better and better!! (in fact, with metropolis, opencl pathtracer is faster than cycles in many many scenarios, not to mention cleaner in hotspots/caustics/indirect and able to solve more situations).
Congratulations and thank you!
keep up the good work!!
Uh, that’s way too complicated. I’ll just wait for RC2 in that case.
No flame intended here too, absolutely. I just have the feeling Lux is a sort of supercar, without the steering wheel, at the moment. It’s not about engine shipped with the software, if an engine DOES HAVE great advantages over another (integrators, speed, usability, material system, flexibility, whatever…) and accessing to it would be just:
@-IP- some comparisons would be really really great to see.
If someone is interested in comparison of Lux/Cycles/Mitsuba you could visit my site : https://bartoszstyperek.wordpress.com/2015/02/14/luxcore-vs-mitsuba-vs-cycles-round-3/
Lux made huge progress in speed, but somehow on my PC it lags a bit behind Cycles. However I think, LuxCore on OpenCL + AMD Gpu, can be faster than Cycles, but I do not have AMD GPU, so I only tested Nvidia card. And on Nvidia’s cards Cudas are faster than OpenCl, so it is no suprize that Cycles was faster.
SOME COMPARISONS.
about the comparisons above, Sobol sampler is clearly not Lux renders strongest. Metropolis shines most.
Edit: Path OPEN CL with metropolis in Lux seem to capture caustics and solve them well, but clamped.
Forgot to add also that it is interesting how hotspots (small sunlight size) is another problem in cycles, besides caustics. Picture resolution doesn’t help, but there were lots of fireflies in the glasses hotspot.
I wonder… did anyone noticed Matte material is far slower to use than Glossy? Is it normal?
Moved to Lux forum >>> http://www.luxrender.net/forum/viewtopic.php?f=36&t=12233&p=114664#p114664
Hi Dade,
Your renderer is really amazing. Have AMD hardware here and it’s lightning fast. However, DAZ/Poser user have a really easy to use plugin with reality. On Blender, you must install Lux1.5, then the addon from the Luxrender folder, then manually copy the presets, then set the path to Luxrender. I would make a new start for 1.5 here when the installer doesn’t require any other step than activating the addon.
Amazing also how fast your kernel compile and how memory efficient it is compared to cycles!
A good installer, a good bugfixing period, some nice renderings and it will be used for sure!
I think too, what might be working against Lux is that the render settings can resemble an airline cockpit compared to the handful of intuitive and straightforward options for Cycles.
Last I used Lux (before Cycles), there were dozens upon dozens of integrator and sampling combinations you can do. The panels could be whittled down to only expose the absolute best options for the majority of scenes (and integrator options being additive so as to say, you also want to make the sampler bidirectional and then make it use the metropolis algorithm).
Lux for a long time was more in line with old-school renderers like Mental Ray which gives you tons of options to help find that optimum for your scene, but at the cost of a heavy amount of experimentation. I think overall what really helped Lux until a few years ago was that it was literally the only actively developed open source engine that made use of physically-based shading (as Yafaray and BI was pretty heavy into legacy methods and Mitsuba didn’t exist yet).
I personally view luxrender as an engine which primary concern hasn’t been production (the one that works in the market, with deadlines and all that), but as a constant, passionate study of light and the way it can be rendered, and a constant exploration of algorithms and new ways to render reality. In my opinion, with luxcore, luxrender has finally come to a point in which all this study and exploration is coming to maturity, and I feel the engine is gearing towards a powerful production renderer, but as a consequence of all the above. Is all this that gives me so much faith in the future of it, in nature, everything complex matures slowly (like us), and luxrender is no exception. Mark my words, Luxcore will be the most powerful opensource renderer eventually, and all the usability quirks people are complaining about will be slowly ironed out, since the core will be finally mature.
Very nicely said -IP-, I totally agree.
About the complicated user interface, that was one of the reasons I wanted to contribute to LuxBlend, to improve the situation there.
Here’s a comparison of the old settings (with classic API selected) on the right and the settings in LuxCore API mode on the left:
I’m trying to center the UI on the user again, not on the available settings. Everything an artist does not need for most renders is hidden behind the “advanced settings” checkbox, only useful settings are shown.
This optimization process is of course not finished and can still be improved a lot (also in many other places). User feedback is very welcome.
Wow, that´s a huge improvement, usability wise.
LuxCore does have one major feature that is missing from Cycles: volume priority. I had a chance to finally play with it, and it is a very cool feature that makes it almost effortless to mix items with different volume properties together (like an air bubble in the middle of a glass bulb). Bidir can’t be beat for difficult interior lighting (something Cycles will always struggle with since it is only a unidirectional path tracer) and caustic effects.
As far as having to do some reading on Lux’s settings, I’d say that Cycles is not immune to this by a long shot. I remember a lot of people having real issues with the node system and relearning how to create materials. With any rendering engine there is no ‘one size fits all’ solution so understanding how it works (even on a superficial level) and what the settings do is essential to getting a good result in a reasonable time.
Lux is great, few years ago it was my favourite renderer, then cycles pop up with nodes deeply integrated but it’s not Lux. Do you have any roadmap. I’m waiting for two things in new Lux 1.Particles with objects (group) as hair. 2. Network render. 3. But not essential multi UV support.
Regards Martin
I think LuxCore does have volume priority now: http://www.luxrender.net/wiki/New_in_1-5#Volume_Priority
I guess LuxCore does have volume priority now: http://www.luxrender.net/wiki/New_in_1-5#Volume_Priority
