OpenGL in DisplayConduit

Forgot my question, I will have to use Unsafe code…


All is well! but I can not see anything … it’s because I have to define a correct glScissor.

Could you explain to me where is the origin of the OpenGL context. Do I have to trust the the Viewport, the RhinoView or the Window ?

I am trying to define a correct clip rectangle for glScissor, I guess I have to trust “C” (on the image), can you confirm that ?
(I’m still in the DrawOverlay function of a DisplayConduit)

thank you,

I used OpenTk thinking it would make things easier, but in fact, it’s more of a problem than anything else.
So, I write a file to directly import the functions of opengl32.dll in c#.

I asked myself another question, @stevebaer, in your file, What is the point of linking functions using wglGetProcAddress instead of using DllImport?

Thank you.

A yes we are saturday !!! :upside_down_face:

That’s just how OpenGL works on Windows. The newer GL functions need to be accessed from the driver using the wglGetProcAddress function as the functions may not actually exist depending on what version of OpenGL a driver supports. I also believe that you need to setup these functions one time while inside of a display conduit so you know GL is active (this may work outside of a conduit for your situation, I’m just not sure).

You should be able to just use a copy of that source file that I wrote for your own purposes.

Oh, you work on Saturdays! Thank you for your reply…
Yes, I am using your file and I need to add some functions.

Each RhinoView is a Window. GL coordinates are in relationship with the client coordinates for each Window. We just set glScissor to the size of the entire window in each frame; I doubt that is where the problem is coming from.

Thank you, it’s good to know.

Indeed, after several tests, it seems to me that the problem comes from OpenTk (Finally, my lack of knowledge with this framework)

I can not properly link the Rhino context to that of OpenTK. and being deprived of this library will not be worse.


Do you know which functions you need added? I can just add them to the GhGL project and you can use the updated source

Oh that’s nice.

glScissor  // more need I think
glViewport // maybe that either

and the constant that goes with …

Otherwise I do it and put the file on Github ? (I’m doing it right now)


in fact, apart from the constants, there is nothing

Are you doing this work? If you are, I would appreciate the additions to be added to GhGL through a pull request. Thanks

Yes, I do this. (You’ve helped me a lot already …)

1 Like


I revived this project !
I wonder why drawing calls with Display Pipeline (here DrawBox) seem to be done after my OpenGL calls.
In the code I call “Display Pipeline.DrawBox” before all my OpenGL methods (ghgl/OpenGL.cs at master · mcneel/ghgl · GitHub)
I’m plugged into DisplayPipeline.DrawOverlay.

OpnGL DisplayPipeline.BrawBow Order

Maybe I can understand for the gumball (but without considering that this drawing is a ui),
I might want to draw something on top of all the other drawings.

Is this the expected behavior?
How do I put my OpenGL code at the end of the pipeline?

@jeff, @nathanletwory maybe ?

Hard to say as we don’t know what you are actually doing.

Is the custom ImGui code in the same draw overlay phase as the call to drawbox? Have you made sure the drawbox is in that same phase definitely before ImGui code?

Hello @nathanletwory, thank you for your reply.

Yes and Yes.

Note that ImGui does not know OpenGL. the only goal of this library is to build arrays of vertices and uvs. after that I call the appropriate OpenGl functions to draw these imgui built arrays.

All functions are called in the DisplayPipeline.DrawOverlay event.
The DrawBox is called before the loop that draws the arrays built by imgui.

You’ll probably have to do something with depth info to make sure the ImGui geometry is on top of the drawbox call.

I don’t know the specfics here, so an actual OpenGL guru should answer this.

1 Like

This probably has to do with the order of draw overlay conduits. The conduit drawing the box is later in the conduit list than your conduit when being processed and since depth writing/testing is off during the draw overlay phase we see the effect of the box drawn on top.

I don’t have a good suggestion for a workaround at the moment.


After many tests, I found a solution.

When the DrawBox function is inside the DisplayPipeline.DrawForeground event, the box is drawn before my OpenGl code inside DisplayPipeline.DrawOverlay.

So I need 2 frames. a first to calculate the mouse position and store the bounding box to display and a second (forced by RhinoDoc.Views.Redraw) to draw the box (in DrawForeground) then the UI arrays (in DrawOverlay)

There is also probably (but not tested) the possibility of writing my own DrawBox OpenGl function…

Thank you for your answers.

1 Like