I have grabbed the code from https://github.com/mcneel/RhinoCycles, but it appears incomplete. Is it possible to get the missing bits, or is that private? I was hoping to use it as a guideline for how to develop our renderer plugin, but there is too much missing.
Hi @CarstenW,
You’ll need also the CCSycles submodule: https://github.com/mcneel/CCSycles
I can type up some text to guide you through the source code of RhinoCycles, but it’ll take some time. I’ll try to have something in this thread later tonight though.
/Nathan, your friendly RhinoCycles developer.
1 Like
The CCSycles code doesn’t seem to fit into the same place as the RhinoCycles code. The RhinoCycles solution looks one level up for a directory which is one level deep in the CCSycles code. How am I meant to integrate these together so that one solution finds both?
Oddly, CSycles seems to be a standard plugin, not a RenderPlugin? I was looking for example code for how to support the production renderer as called from the menu or the _Render command, but I do not find it. It looks like in the RenderPlugin::Render() call we need to pop open the window by ourselves? Any hints for how to get this working are welcome. I can start a new thread if you prefer.
Ah, right.
I have been working with the plug-in project being part of a larger Rhino source-code solution. The structure for this to compile better is:
$DEVROOT\RhinoCycles
$DEVROOT\cycles (which is the CCSycles repository as submodule).
So you should clone the CCSycles repository as cycles in $DEVROOT, next to the RhinoCycles clone. The CCSycles project is a wrapper project around the Cycles render engine. It does not have any dependencies on Rhino code, and does not implement any plug-ins.
I have been a bit lazy in keeping the public repositories properly up-to-date with my changes, they may be a bit out of sync. I have added this on my todo list to handle this week.
RhinoCycles currently has three different ‘render engine’ implementations, which you can find in
The modal render engine is called from a separate plug-in CyclesForRhino: https://github.com/mcneel/RhinoCycles/tree/master/CyclesForRhino
The Render command calls
https://github.com/mcneel/RhinoCycles/blob/master/CyclesForRhino/Plugin.cs#L66
and then there is a preview rendering mechanism that calls into
https://github.com/mcneel/RhinoCycles/blob/master/CyclesForRhino/Plugin.cs#L120
I hope this gives you the information you were looking for.
/Nathan
I am back on this now.
It is a bit hard for me to follow the code with so few comments. Is Rhino.Render.RenderPipeline the class I need to inherit from to get the Production Render window to open?
I am writing a short series on render engine integration. For this series I am working on a sample plugin called MockingBird. The first part is already published, the second part is close to being finished. The second part talks about RenderPipeline and AsyncRenderContext - both are needed to get a modal render window open. I should have the second part done tomorrow.
First part:
The third part will talk about the ChangeQueue, and on towards interactive viewport rendering. I hope to get the articles and sample code for it done during this week. I’ll make amendments and improvements as necessary.
/Nathan
That sounds great, I will look at that now.
I have read the first part, and we had these items in place already. I did make the change about only setting the Instance when not set, although I am not clear on when that would make a difference.
In the (unlikely) case that the plug-in constructor gets called multiple times. It shouldn’t, but better safe than sorry.
I have pushed the first bits of the MockingBird sample project to GitHub here: GitHub - jesterKing/MockingBird: A plug-in writting using Literate Programming to show how to integrate a render engine into Rhino 3D using RhinoCommon.
In the coming days the remaining bits and pieces will be written and added.
/Nathan
I have read part 2 now and have the production rendering window open. I just need to hook up our renderer, and then this task is done for now. I look forward to parts 3-5 in any case 
Nathan, I am finding that compared to what I have already used for the viewports, I am having some difficulty reusing our rendering component at the C# level. How are the AsyncRenderContext and RenderPipeline meant to interact with the viewport system?
It looks like if I rewrite some of my RenderControl class (instantiated in the DisplayMode class) and inherit from AsyncRenderContext, then I could possible share the code that way, is this correct? I still have to re-find my RealtimeDisplayMode class for SignalRedraw…?
For RealtimeDisplayMode you shouldnt need an AsyncRenderContext. Still typing on the article that touches on this subject.
/Nathan
I have coded up something for now, to make progress, but I found that I had to code a very similar rendering thread with small changes, which is what I was hoping to avoid. It isn’t so much code in this case, but in general, I try to avoid duplicate/very similar code, for maintenance reasons. I will read installment 4 when it comes.
Fourth chapter is mostly done, I just got sidetracked with some emergency crash fixes, and the the birth of my third child last Saturday. I’ll have the article done and published next week.
/Nathan
6 Likes
Congratulations! !
Now try and get some sleep anyway! 
Congratulations!
I hope the little one and mother are doing well!
Wish you and your family all the best.
-Willem
1 Like
Wow, congratulations, I didn’t know you had side-projects on the go! 
Take your time, I look forward to it, but there is no pressure at the moment.
Thanks