SetUseDrawOpenG - bug?

Rhino Developer
1

Hello,

Not sure what this function should do exactly, but this looks like a bug in RealtimeDisplayMode

function
public virtual void SetUseDrawOpenGl(bool use);

We can override, but can not change the value of use (not a reference)

Márton

2

If you override SetUseDrawOpenGl you are supposed to always call the base class method.

You’d generally override this only if you need to keep track of calls to this function yourself, the actual magic that happens is as per documentation:

During run-time change whether to use OpenGL drawing of results or not. For instance offline rendering (viewcapture* with different resolution than viewport) could use RenderWindow instead of direct OpenGL drawing.

If you pass true to the base implementation the RDK realtime integration mechanism expects you to use OpenGL to do the drawing into the framebuffer. If you pass in false you’ll be using the instance of a RenderWindow in the StartRenderer to use for collection your render result in. This instance will be used to draw the results to the viewport for you.

For Raytraced we use the RenderWindow method when 1) we’re doing an offline/modal render (i.e. ViewCaptureToFile with different settings than viewport) 2) the graphics driver doesn’t support at least OpenGL 4.1 or 3) Rhino is run through RDP

In all other cases (that are pretty much the default) we use OpenGL to do the drawing of the Cycles results into the Raytraced viewport.

For Raytraced I am not overriding the SetUseDrawOpenGl(bool) function, as I don’t need to keep track. But I do use it to switch between the OpenGL and non-OpenGL (RenderWindow) drawing mechanisms of the underlying realtime display integration mechanism of the RDK.

You can find three uses of the function in https://github.com/mcneel/RhinoCycles/blob/rhino-6.x/Viewport/RenderedViewport.cs

The very low-level OpenGL drawing I do inside the Cycles engine like so: https://github.com/mcneel/cycles/commit/3043b8c5ebcebb361c7d288481ba6e1cf17c0b84#diff-25d902c24283ab8cfbac54dfa101ad31

3

Thanks for the explanation.

Drawing with OpenGL could be a good way to go…
But what I don’t understand from your examples. How to connect to the opengl context? Can I get it from Rhino?

Márton

4

When you get the chance to draw your results into the framebuffer Rhino has already prepared OpenGL for you to draw in.

The process for a realtime display integration goes something like this:

  • with a nice model the user switches to your display mode implementation
  • your RealtimeDisplayMode implementation will be instantiated, Raytraced initializes the Cycles engine here also, if needed
  • as part of the setup process PostConstruct() on your implementation is called if you have an override for it. In Raytraced that is used for figuring out OpenGL supported level
  • The rendering process gets started with a call to your implementation of StartRenderer
  • Whenever your engine has results ready you signal the display pipeline of Rhino by calling SignalRedraw().
  • Whenever the pipeline gets to it a call to DrawOpenGl() is made at which point you can use OpenGL to draw your results to the framebuffer, Raytraced implementation looks like this. You see it calls into a function on my actual engine, and through several function indirections (because wrappers) you’ll find that the result is just really being drawn as a texture on a quad over here.

In short: you don’t need to get a context, Rhino already has set it up for you. If you investigate the actual framebuffer drawing code in Cycles as used in Rhino you’ll find that there is no context fetching/switching/setup done anywhere. Drawing just happens.

5

Yes it seems it is working:) without manual opengl context handling. Nice! Thank you.

Márton

6

Good to hear :slight_smile:

Do ask when you have more issues to solve!