I would like know if it’s possible to use a vertex buffer in DisplayPipeline.DrawOverlay ?
I would like use ImGui for build a ui in a display viewport, ImGui not dépend to a graphic or UI library, it only builds a structure of vertices.
My problem is that after ImGui built this structure, I need to rebuild it with Rhino objects to draw them in a window. but it is slow.
An alternative solution is to use a mesh of rhinoceros, but here too it is not very useful,
The overall ImGui process is to build a vertex structure, then define a VBO and call glDrawElements for each element.
is it possible to manipulate opengl to draw an overlay on a viewport ?
I’m confused. Why not use one of the standard .NET UI tools, such as WinForms or WPF? If you want cross-platform compatibility, use Eto, which is built into Rhino?
This is not for cross-platform. My reason is to have a simple way to build a dynamic user interface.
I have some functions or classes where I can use a reflection in CSharp to generate the user interface.
it’s very similar to the fast editing of properties in Blender.
Currently, I use either Eto or directly GDI+, a bit like Grasshopper.
But the code comes very hard with a lot of functions and a lot of UI changes that depend on the context.
the first menu is with GDI, the second with Eto.
I looked in rhino-developer-samples but I did not find how.
In addition, I admit that I am not very strong with c++ (I think it’s not possible in C# ?), do you have a sample to guide me?
You shouldn’t need to get the OpenGL context in a conduit to work with OpenGL; it is already set up. The way to get the context is through wglGetCurrentContext()
this could be easily called through a pInvoke in C#
Does this toolkit require that you know how to use OpenGL?
If you’re executing inside a conduit, then it means you’re already “inside the pipeline”… which means the current context has already been setup and activated and there’s nothing you really need to do… So unless you’re planning on writing some kind of caching or association mechanism using some kind of tuple which includes the context, you really shouldn’t need to be concerned with contexts, or platform dependent issues.
We could better answer your questions and concerns if we knew more about what you’re doing and/or planning to do with OpenGL specific things.
Right, once you are working directly with OpenGL then you don’t need much from Rhino’s display functions. For head’s up display, you probably just need the viewport size information from RhinoCommon so you can use it in OpenGL.
D’accord, merci !
yes being already in the pipeline seems easier all of a sudden.
which means that direct calls to glBindFramebuffer or glDrawElements work inside ?
No, I do not need that (that’s where ImGui is useful)
Makes me a little nervous to read that… Mainly because Rhino makes extensive use of FBOs, so it’s extremely important that if you plan on using them, that you first query the GL system for what the current FBO is, save it, set your FBO, do your stuff, but then make sure to reset the current FBO back to the one you saved… otherwise, you can really mess up the display and viewports because the frame buffers are now incorrect or out-of-sync.
basically this:
GLint crntFBO;
::glGetIntegerv(GL_FRAMEBUFFER_BINDING, &crntFBO); // save the current FBO that is bound...
::glBindFramebuffer(GL_FRAMEBUFFER, YOUR_FBO);
// do your stuff...
...
...
::glBindFramebuffer(GL_FRAMEBUFFER, crntFBO); // put the saved FBO back.
Please be conscious of any other kind of “buffer state” that you might be changing… if you do not save and restore them when using them, then you can really mess things up. Which means, you cannot just set them in one part of your plugin, and then assume they’re always set… you will need to always set them and restore them at the point you plan on using them…if that makes sense.
If you use the OGL implementation I think you don’t have to worry about OpenGL yourself at all. You’d use the ImGui_ImplOpenGL3_RenderDrawData() function directly. It does everything for you:
This is the example I use as a guide (and I’m wrong, this code does not use FBO)
So far, I did not really know where and how to insert it into “Rhino’s pipeline”.
I will try tomorrow but I think I should have all the information thanks to you all …
I’m slowly building the user interface. right now, I’m asking myself a few questions, essentially with “what is enabled or set in the DrawOverlay of a DisplayConduit ?”
more exactly, should I define my own projection matrix ? Or inside the DrawOverlay function, the matrix is correct with orthographic projection ? (I guess so)
Also, are there Shaders enabled in the DrawOverlay function ?
I know the best thing to do is to save the state and then restore it, as Jeff told me.
But I write some of the code in CSharp and set the projection and the shaders (only to display the glyphs of the fonts) obliges me to place the code “unsafe”
I would like as much as possible to avoid the unsafe code…
