That it’s using 60-70% CPU for material previews is expected, it’s programmed to use one thread less than the number of available cores. So if you have a dual-core with hyperthreading (say an i3) then you have four “virtual” cores and the material preview will use 3/4 of them, ie 75% (at full tilt).
Why the material preview is black I do not know, and I can’t reproduce the other error you had (Windows going black, graphics driver crashed I presume).
It could be our code for halting the preview-in-progress isn’t optimal and gets stuck if you switch rendering engines while it’s churning, I’ll look into that. In the meantime you could you check out the console to see if there are any messages there? Window -> Toggle System Console in Blender’s main menu.
No it’s not. With Cycles or BI there is no such thing happening. When you switch to Yafaray or Lux it goes up and it’s constant cpu usage, not temporary. Console messages shows that Lux is trying to render the material preview (constanly in couple of seconds interval), but then it says: Preview aborted, Render interrupted. When I switch to Yafaray there is one line: INFO: YafaRay (None).
It looks like the preview is trying to render, but is going incredibly slowly. May I ask what CPU you have? That speed it shows in the video (~30ks/s) is about 1/30th the speed it goes on my machine. (i7 930).
Ah, ok, that’s what I was afraid of. What’s going wrong is your system is just taking ages to come up with anything for the preview. It’s already a slow CPU, and since it only has two cores the “run preview on all threads but 1” thing Luxblend does is dropping half your CPU power on top of that.
Thinking about this, I realized it would be really simple to add an overall time limit to how long the preview will render for. Currently it’s in an adaptive sampling mode (noise-aware metropolis + haltthreshold) and has no other stop condition defined. Meaning Lux will keep spinning on it until it sees a reasonably noise-free image. On my dev machine this takes about 7-10 seconds for most materials. On a machine like yours with 1 thread instead of 7, obviously that’s going to be a lot longer. We could just define the halttime property as well so the render cuts off after a fixed amount of time (say, 30 seconds?) no matter what. I’m pretty sure it will always send back some sort of image after this (whatever it has, although that might look like an impressionist painting sometimes…)
It goes to 70% right when you switch to Luxrender, even without showing any preview of materials. It must be something else. Also with Yafaray it seems to be 40% all the time, so both of them are doing something. What is also strange that if you switch back to Cycles it wont fix it.
Even if you don’t have the properties editor open anywhere? In the video you posted the CPU use definitely seems to be coming from the mat preview. I think it is starting over when you switch windows to and from Blender.
I get that error message too, but it’s not harmful. I haven’t looked at it, but in those cases I like to stick a try / except statement into the script just to keep the error from cluttering up the console.
I followed the instructions on wiki’s “installing development builds” and I think it went as planned, but still it goes up to 70% cpu, which I believe is a bug (now reported in bug tracker) in Blender or hardware/drivers. However now the material preview is working.
What is the timetable for making hybrid path and bidirectional stable? I’m actually using Luxrender more with DAZ Studio (via Luxus) than Blender, but anyway… I love the speed I get with CPU+GPU (i7 + GT630M), but Luxrender doesn’t run for very long before Windows 8 informs me that the program has stopped working. Of course, CPU only works just fine…
Do you have a simple scene which reproduces this? If so, please file a bug report here and attach a zip with the scene files (ie lxs etc): http://www.luxrender.net/mantis/
