Some news and questions though: If i set my device to use Tahiti chip, i can start rendering and it completes the shader creation and finally starts to render . But It renders only slightly faster than using cpu and still 7 of 8 cpu cores are used. The speed is very slow compared to using cycles in blender, approx. 5%, so i´m not shure if this is working as expected yet. I´ve set my device using RhinoCycles_SelectDevice. Anything i can try to get this faster ?
btw. does rhino cycles create temporary ocl files and do you clean them up ? I´m asking since i´ve recently found a lot of them in my temp folders.
Looking at this demo I was wondering if this idea would be a cheap way to improve the experience:
Instead of building the image starting with black and adding illumination information as it’s computed, what if the engine would record the average pixel color of the image (updated each time an higher number of cycles is reached) and using this value as the "background"
This would diminish the flashing effect we see each time the view is updated and it would seem to be smoother.
If it’s not possible to get that average value fast enough, maybe try with a median grey instead of black?
I haven’t focused much on the OpenCL performance the past weeks. It may very well be that I have to ensure the correct settigs ate given to Cycles - for now no instructions to get it faster. Hopefully when I get to it
RhinoCycles creates in %APPDATA%/mcneel/rhinoceros/6.0/rhinocycles/datat/cache a set of .clbin files. These are the compiles kernel files. New ones will be created when the kernel headers change - that generally doesn’t happen very often.
The background color depends entirely on the environment configuration in the render settings. In this demo the skylight is configured with a hdr that has relatively large black areas. If I had it set to use the same texture as the background, in this demo the gradient, initial pixels would be much more grayish.
This progressive refine is already much smoother than the non-progressive refining method used earlier, where there was an even more distinct flash.
I am not sure if your method would be easy to implement. Right now I’m concentrating on integrating Cycles’ existing feature set, before thinking about completely new features
Can I ask a naive question here? Is Cycles a McNeel render engine or a third party engine that is being ported to Rhino by McNeel, a la Brazil, or some other scenario? I have noticed that there is a Cycles for Blender out there, seems unlikely that they aren’t connected.
Cycles is the Blender Cycles render engine. My job is to integrate it into Rhino as tightly as possible.
To save a few clicks: I have been a very active Blender developer. For a long time I was responsible for the official Blender builds for Windows. I have typed code for Blender since 2003, I mentored for the Google Summer of Code program, I worked with the real-time collaboration integration of Verse into Blender, worked on the foundations of Blender UI as it currently stands, helped organize a few blender conferences, and many other things. You may know me better as jesterKing in the Blender community.
Integrating (porting) Blender Cycles into Rhino is a very cool project. Both the Rhino and Blender dev and user communities are very similar, so I feel home in both