It actually turns out not to be a whole lot of work to support different versions once the architecture is in place.
OpenGL 1.2 is the Microsoft software mode OpenGL (non-hardware accelerated). We’ve already written support for that years ago and it doesn’t make sense to drop this since it is very helpful when diagnosing misbehaved drivers.
OpenGL 2.1 is the driver level that VMWare operates at and which many users run (even though we don’t recommend it).
We aren’t sure what the top level OpenGL level we’ll need in V6, but we will need to support at least OpenGL 3.0 since that is when frame buffer objects became part of the core. We are pretty much targeting OpenGL 4.5 since that is the most recent version, but it is hard to say if we will need any specific features of 4.5.
I’m hoping this architecture will make it relatively easy to drop in support for a new version of OpenGL when we find a need for it without too much code rewrite. So far, things look good.
The main reason I asked is because I was imagining Rhino using some really powerful new OGL 4.5 features, and you folks having to write lots of work-around code for earlier OGL versions.
Of course I suppose you could just use some boilerplate code that puts up a message box that says something like “Nyah, Nyah you can’t use this feature because you’re too cheap to get a computer that supports OGL 4.5. HaHaHaHa!”
There will definitely be things that just don’t work when running on lower version number drivers. This already happens on Rhino where you get antialiasing through multisampling when the driver supports is. Other features like shadows drop out when running on non-hardware accelerated OpenGL.
Not sure if this is the right place to put my post but…
Have noticed two small issues in the latest WIP (it can be that it has been touched before)
Seems that points (exc. when drawing a curve) are not displayed correctly ->rectangle is not present around the point. When zooming in/out - works as normal. See enclosed.
Height of the help textbox (whatever is the right name) is higher than needed -> mouse can be seen twice. Also enclosed.
Thanks for letting me know. We just made a pretty large architectural change to our OpenGL code. Now we need to figure out what is going wrong and fix issues like this.
Thanks for your answer.
I got a moment of doubt when I switched to a maximized view : things began to be fluid again, but a few seconds later, the stuttering came back.
I have noticed that in the latest WIP edge thickness is not stored.
It can be changed via Rhino Options -> View - > Edge Thickness(pixels) but after a while (first redraw) value comes back.
Can you check it please?
Updated: actually same behavior can be noticed for all settings - size of the control point and etc.
How about meshing, could objects to be meshed as a result of an operation be put in list for muti-threading?
(I was trying to watch Rhino for things that affect the apparent speed.)
[ I heard it in good word that ID family games often had inline assembly in the C rendering code : )
They would even send out polygons to be filled grouped by their texture, but I should think that that would largely help when there are more textures(materials) involved than we see in CAD. ]
Objects only need to be meshed once and that meshing does occur on a separate thread so you can cancel the operation. This does not affect display performance.
The latest WIP (March 1, 2016) contains optimizations for shaded object display.
Shaded and rendered display modes can see significant speed improvements. Improvements will vary based on the model that you are using, but some users should see dramatically improved performance.
The optimizations are turned on by default, but you can test timing differences for now by turning the feature off through the use of the “TestVboCache” test command. Running this command and changing the option of Caching to Disabled will set the display pipeline to run in a manner as it was running in previous WIPs. This command should eventually go away, but I’m using it for now to find any place where I may have broken the display and things don’t “look” correct.
Currently there are cases where this optimization is not enabled. Blocks, transparent/ghosted objects, objects with per-face materials, and custom render meshes like curve piping are cases that I know the optimization has not been applied to yet. I am working on handling these cases over the next few weeks and will let people know when they have been implemented.
Give it a ‘spin’ Hopefully you’ll see a marked improvement in performance. If you see any bugs or slower display than in the past, please let me know so I can get these fixed as soon as possible.
Was hoping you would pick up on this comment It all depends on the model of course (and now your graphics card more than even), but I’ve seen speed improvements any where from a few percent better up to 500%
Hopefully you’ll see a marked improvement in performance. If you see any bugs or slower display than in the past, please let me know so I can get these fixed as soon as possible.