Cycles and display pipelines

@andy, @jeff, @nathanletwory

I chatted with Andy earlier today in regards to problems that he and Nathan were having to get Cycles to execute inside of a standard Rhino viewport. Their difficulty was stemming from the fact that they were attempting to create a CRhinoDisplayPipeline_OGL subclass and overriding some of the functions in order to inject their own code in appropriate locations. This difficulty is getting multiplied by the fact that they are attempting to do this in C# and are dealing with the MFC CRuntimeClass class which really doesn’t work to well on Mac (at least in our current Mac code.)

After thinking about this for a while, we already have a mechanism for injecting code in the pipeline and changing how it works… CRhinoDisplayConduit

I propose that we add what you guys find to be necessary to the display conduit class, be it new notifications like PREDRAWMIDDLEGROUND and PREDRAWFRAMEBUFFER or new virtual functions that can be called at the appropriate times inside of the pipeline. This will improve the conduit support for everyone and we can dogfood the specific functionality you need while we work out the details.

Any opinions?

I guess I’d like to hear more about what it is they’re trying to change, when and why… But sure, if the conduit can be augmented to accommodate their needs, then why not…

I have absolutely no business butting in here, but it sure sounds like a natural to me! Does it also provide the opportunity to do some important, (relatively) time consuming things in optimized native code and save some time otherwise crossing the managed/unmanaged border?

All of our core OpenGL display code is written in optimized C++. Conduits as they currently exist already do what you are asking about. If you are in a conduit and get notified that some very ‘heavy’ object is going to be drawn, you can always do something like tell the display pipeline to draw a box and don’t draw the heavy object. In this cases there is very little .NET code involved and possible a whole lot of C++ code running inside of the display pipeline’s DrawBox function.

If you take a look at the RhRDK_RDP_DisplayPipeline.h file you’ll get a glimpse of what they are trying to do. I also added a reminder to chat with you about this during our next skype meeting.

I assume this means that the conduit will have to determine whether it is running inside a display mode that is set up as a Cycles display mode. At the moment, that’s not easy. There’s no way to add custom attributes.

Presumably that means that the conduit will have to do a check at the start of every single ExecConduit call to determine the pipeline type. Is this something that makes sense?

  • Andy

I have to admit that I find the current overridable pipeline concept pretty elegant, even if it could be more flexible and more consistently implemented (at the moment, printing, view-capture and display all go through totally different pathways).

The conduit idea seems like more of a hack to me. Conduits are for minor modifications to an existing view - pipelines are for wholesale replacement of the functionality.

or… a display mode could be registered with a specific conduit. This would be relatively simple and would make the conduit not have to check against a pipeline type in it’s function calls.

I could interpret this as; “Steve please don’t invent anything new and just help us get pipeline subclassing to work”. I’m not offended; I would just like to know if that is your opinion so I don’t keep going down this path. I’ve already solved the issue you guys are running into with CRuntimeClass in .NET when I added support for user data; so I know I can make this work if it is really the path we want to go down.

I just don’t like the fact that we have two different ways to drive how pipelines work; subclassed pipelines and conduits. You can basically achieve the same result with both systems which can lead to confusion from the perspective of the SDK. Kind of like have two different material classes :smirk:

Nope - don’t interpret it as anything except me typing without thinking.

As I was driving home, I was thinking that your argument is stronger than mine. You’re right - there should be one way to customize the pipeline. However -and it will be up to you to pick your battles - the SDK at the moment allows us to do it only one way, and I want Cycles viewport integration done very soon. I don’t intend to wait for this new design, but I will happily change the Cycles design when you’re ready.

Of course, once Cycles is working, we can use it as a case study to ensure that your design actually works.

As for two materials classes…surely you mean at least 4…more likely more.

ON_Material
CRhinoMaterial
CDisplayAttributeMaterial
CRhRdkMaterial

  • CRhRdkBasicMaterial, CRhRdkPictureMaterial, CRhRdkMetalMaterial, CRhRdkGlassMaterial, CRhRdkPlasticMaterial, CRhRdkPaintMaterial…etc etc.

Everything I write can be interpreted that way :smile:

Andy, I would not pay any attention to that last comment, it really sounds like Steve wrote it without thinking.

-Pascal

Continuing on the dev meeting of last night, my understanding is that whatever I am currently working on I do as part of RhinoCommon where it makes sense (wrapping C# class), and for as long as is needed to get the official way properly done for rendered viewport usage. Am I correct, @andy?

/Nathan

I will discuss this with Steve tomorrow evening - then we’ll know what to do. In the meantime, as long as you don’t actually commit anything, we’re golden.

  • Andy