Doubtful, unfortunately. The main issue is fast transfer of the render results back to Blender. We need to do some low-level work for that to happen. It’s definitely something we’d love to do though.
Hi Lord
I there any plan or roadmap to be able to do that low-level work ?
ty
I’ve already spent some time investigating what needs to be done, and I think I have a good overview. However some parts involve low-level CPython coding, which I’ve never done before.
It’s been near the top on my personal road map for a while, however I’m currently pretty busy so not a whole lot of time for LuxRender in general. But yeah, hopefully it won’t take ages.
Do you think it would be possible that the Cycles progressive render viewport is made available to external engines? I find it a very interesting feature. It makes a lot of sense for Luxrender and Yafaray could use it as well in pure adaptative sampling mode.
+1! +1! +1! +1! +1!
You mean render-to-viewport (ie “Rendered” viewport shading)? If so, this has been possible for some time, using view_draw, at least that’s my understanding. I haven’t actually tried it yet though.
A couple of shots of the LuxBlend node editor in action:
Properties panel is now mostly in order. Hierarchy chart, previews, etc:
Volumetric glass with spectral absorption:
Dirty-metal Suzanne using vertex-color dirt:
The plan currently is to get this merged into mainline LuxBlend and start passing it out with the LuxRender weekly test builds in time for 2.67rc1. Later this week, I’m planning to make a short preview/tutorial on the new node editor. Where everything is, how to switch it on, etc. I’ll probably also cover a few of the other new toys in Lux 1.3, since there are quite a few (in no particular order):
-Vertex colors
-Pure-GPU rendering (for AMD too!)
-Hair support (also works on GPU)
-A new QMC sampler (based on Cycles’ sampler, iirc, but with noise-aware sampling added on)
-Double-sided materials (can attach separate shaders on front and back face)
-Instances can emit light (bioluminescent trees, anyone?)
-New fresnel textures, false-color image out (for luminosity measurement) and more!
this looks great… can’t wait to try it out… )
Great news, can you elaborate about this QMC sampler or provide some link? Thanks
Nice thanks! Looking forward to give a deep try to Lux once nodes work ok
Managed almost completely lock down Win7 (screen went black for a while, didn’t respond to anything) with three simple steps:
-moved main light (sun) to empty layer (the scene has also another light, area type)
-added point light
-changed rendering from bidirectional to direct lighting
Can you consistently do this? Are you using hybrid or slg?
That would in deed be a great option
progressive rendering and scene pre setup in Cycles
finale rendering in Yafray
just the shaders etc have to be the same and thats where I see the problem!
No, the scene setup for yafaray would happen in yafaray. Probably one of their progressive rendering modes - pathtracing or bidirectional. These are nowhere near as fast as Cycles though, at least in terms of getting a good preview fast, so really it wouldn’t necessarily make a whole lot of sense for yafaray.
For luxrender though, it might, especially in the SLG modes.
Tried it twice, so yes. I don’t know what “hybrid” or “slg” are, I’m an artist. I have OpenCL version with default settings.
Also noticed that when I load that scene the cpu usage for Blender goes up to 60-70%. I think it can have something to do with material preview which is black (doesn’t render). If I load another scene, change to Luxrender and try to look at the material preview cpu usage shoots up. Maybe it jams the rendering process?
I have a laptop for rendering only and it has non-OpenCL version of Lux. In it the cpu usage is “only” 30-40% and I can see the material preview. But when I repeat those steps same thing happens. What I now noticed is that memory usage goes to 99% and looks like Windows starts to use swapping to hard disk.
However I think the cpu usage bug is unrelated to Luxrender. It’s a bug in Blender and it’s easy to reproduce: change rendering engine (tried both Lux and Yafaray) while the material preview is on and cpu usage goes up and stays there, even you change back to Cycles or BI.
Thats my point if you could set up the scene with materials with Cycle nodes and pass that to Yafaray to render into a file it would be beneficial. Otherwise not really
Except external engines would have to adopt a shader system closely mimicking the one in Cycles. Which isn’t necessarily in the engine’s best interest otherwise.
If it’s possible at all!
Is that 60-70% cpu usage bug a known one? It kind of sucks.