When it comes to render a large dataset OpenGL display list are generally used to speed up render since geometry and texture data is loaded into the graphic card memory and at each refresh there is no need to pass geometry to the graphic pipeline. Is there any plan to add support for custom display lists on the drawing conduit ? Or its already available but i missed it ?
gd
We don’t use OpenGL display lists; those are part of the legacy OpenGL api and are deprecated in the modern version that we use.
If you are using RhinoCommon, there are built in display caches on geometry that are used and only rebuilt when you change the geometry. If you are using the C++ SDK, there is a CRhinoCacheHandle class that you should pass to the pipeline draw functions. You need to maintain a one to one association with a CRhinoCacheHandle and geometry.
Fine so I could make a DLL in c++ to generate geometry caches. The reason is that actually I get really slow frame rate with the continuos drawing of the conduits. Actually making a c# plugin but I can plan to split and add a c++ DLL.
Gd
If you’re using .NET the caching is already done for you. We would need some more details on what your conduit is doing to help figure out performance issues
Maybe I am using the conduit in a incorrect way
If I have let’s say a large amount of mesh objects to display, I just call the drawmesh from the conduit display routine, what else can be done to cache this data ?
Maybe a small example.could be enough to understand
My display conduit is quite large , it connects to our FEA application trough a COM interface
caches all data and results then displays them into rhino.
to make a test I can provide everything included Rhino plugin c# code
A few questions:
Well all of those
I have both vertex mesh and color meshes
I need to modify a mesh and copy it
And yes with text frame rate gets really bad
If I can understand better the conduit I could overcome most of these, but what is not clear to me is that the conduit draw is called at each rhino viewport refresh, so how does the cache work ?
I am used to c++ where we make opengl cache buffers and update them when required
Gd
The conduit functions are called every frame for every viewport.
When one display pipeline functions are called within your conduit, the display code needs to generate vertex and index buffers that are stored on the GPU and used by shaders to display the geometry. These buffers are stored on the geometry and reused in later frames. Any time the geometry is altered, the cache on that geometry is deleted so a new one will be built on the next draw call. If you are modifying these meshes every frame, then caching will have no effect on improving performance.
Here’s a break down on the operations in a display pipeline. Hope this helps
https://developer.rhino3d.com/api/RhinoCommon/html/T_Rhino_Display_DisplayPipeline.htm
Ok
So basically I am doing wrong.
This has to be the workflow
Hd
Draw the objects in any order you want and whenever you want. The key part is to not make changes until the user requires a different plot. We can probably further optimize your conduit, but this is a good place to start.
To be more clear I can have a bunch of objects and make changes only to those that require update.
Gd
Steve
Sorry but I am unable to understand how all this works.
I need to understand whats going on in the background of the display pipeline
to avoid breaking the rules.
Many objects I draw are created on the fly while drawing so clearly the cache needs a refresh, what is not clear if its a single cache or I can have multiple objects
I am really confused on how to make a optimized pipeline , I have far too many items to draw
I can send you in private the file so You can give a look and judge the best thing to do
The problem is that I have a lot of objects , meshes,polylines,lines,text with attributes that get modified like visibility,color,geometry,text
gerry
Sure, you can send me code in private.
Just my 2c on a future option for more involved operations if possible :
DisplayCache dc = new DisplayCache();
dc.Open();
dc.DrawPoly()
dc.DrawMesh();
…
…
dc.Close();
pipeline.Display( dc );
Basically give the user the opportunity to keep the cache
and update it manually without automatic processing, I understand the easy api but when it comes to pipeline optimization better to give a few options, nobody knows better than who is writing the code
how to optimize display.
gerry
Hi Steve
Any info on this ?
I Must underline that our intended plan is to use Rhino as the main app host and
detach our UI but clearly we must be sure its feasible.
gd
There are two possible solutions that jump out at me that you can try.
Single false color mesh
For the above image, the absolute fastest way to draw all of the colored quads representing forces is as a single false colored mesh. I can’t tell from looking at your code if this is a possibility or not.
Minimize material changes
If the above is not possible, then this trick may help. Display materials have a lot of information in them and can be quite heavy to set up. Keep a dictionary of materials based on color in memory instead of newing one up for every mesh on every call. Then sort your meshes to draw based on color before drawing them to minimize material changes. If the exact same material is used from one DrawShadedMesh call to the next, this will allow for the material to be reused instead of a new one being set up from scratch.
I couldn’t tell from looking at the code if new meshes are created every time the conduit is called. If this is happening, then that is also a massive hit on performance and should be avoided
Hi Steve
Well the model in the above image a very small one compared to real world examples.
The display pipeline is already very complex (and still not all elements have been ported),
so I think that without a kind of API tool to manage Opengl buffers its unfeasible.
Do we have a more grainy API in C++ for Ogl display-vertex buffers ?
gd
Not really. Do you have an SDK example that has support for lists that you are asking for? I want to make sure my assumptions about what you are requesting are correct.
Do you expect your meshes and materials to change on every single frame in Rhino?
I can write something up, but it’s hard to make decisions on what is important based solely on looking at a single source file so I’ll need guidance.
Hi Steve
No I don’t have a C++ example since we are using a third party tool to manage OpenGl display tree
actually.
No we are not going to change display data at each frame, basically we
Draw item data (Mesh, polylines,text)
So we have a tree of geometry_items with color, geometry, visibility flags
if one item in the tree has the visibility flag off all sub items are skipped
each item data would need a display cache object
So the steps would be :
– Pre-Display (or Build Display )
Draw into one or more cache object’s (Meshes,lines text) , this is done only when we need to update the display, one cache item for each geometry_item in the tree
– Display step loop ( frame display )
Display cache object’s ( no actual drawing occurs, only cache buffer’s are displayed )
–Clean up
Destroy cache buffer objects
This is what we do with Opengl display buffers and I am sure somewhere behind the
actual pipeline these objects are available, but this is up to you if feasible
Whats not clear actually is the separation between the display build step
and the display itself, considering that only one cache cannot satisfy optimization
since a hole rebuild is needed when maybe we just need to change a text
cheers
Gerry
.
