That would be easy for you to test out, so are you not usign the wip?
Thatâs a little surprising, I actually thought we were seeing slight improvements in speed for that model in wireframes and significant improvements with shaded/rendered display modes.
Your complex model that wouldnât load should load in the current WIP. There was a bug with file reading and blocks that was recently fixed.
I tested, I donât see a difference with my models. Only if I turn the isoparm density to something very high like 55, then I notice the lag. in V6 when wires are shown. Other than that, itâs not slower or faster, feels the same.
Are these models slow in V5?
With density 1 or 0 they are fast in both. With density 55 they are kind of slow in 5, slower in 6. Is there an FPS heads up settings/app I can use to see how slow?
Disclaimer: iâm on my desktop now, it has a Quadro FX 5800, a few years old but really powerful card. Nothing is really slow here.
Want me to try on my Surface 4?
I doubt thereâs much for you to test. The latest round of optimizations were all for shaded/rendered/ghosted type display. Somehow this thread got on to the topic of curve drawing which really hasnât changed much for quite a while.
That said, Iâm always interested in finding models that are slow and seeing if there are any things we can do to improve speed.
Thatâs part of the problem, itâs not only a âmodelâ but a drawing made of many objects.
On one project, I spend perhaps more than 5% of my effort hiding layers and things to keep rspeeds up so I can work.
I have over 8 hours into modifying a Honda-GX690 engine hull simple enough to use efficiently in as part of drawing. With the engine alone, I get perhaps 12-15 fps, 2xAA, shaded(colored-varient), no shadows, on a Quadro i7 laptop that gets a Holomark of 46464, which appears average.
I canât openly send you the model, but it is available from their distributors.
http://engines.honda.com/models/
Did you see the script that converts curves to meshes and joins them?
If it was possible to do something similar to blocks or inserted files then I would be really happy.
Even if quality and or tolerance was lower.
Or to flip the question, what is casing the slow draw speed? Are there anything that can be done that may cause sacrifices of some sort?
Sure. Rhino is a NURBS modeler. If I oversimplify quite a bit, OpenGL draws triangles and lines. OpenGL canât draw NURBS (very well). We convert smooth NURBS surfaces to polygon meshes, and smooth NURBS curves to polylines to send to OpenGL.
For surfaces and solids, we mesh once and save the mesh in the file. Steve and Jeffâs work has been to cache those meshes on the video card, so thereâs less geometry moving from RAM to the card. Thatâs the primary speed up youâre seeing today. Theyâve also done a lot of work rearranging our OpenGL code so that it can use more modern features and syntax, while also degrading gracefully on older cards. We are optimistic that by doing this weâll see not only performance improvements but also stability improvements over Rhino 5 (display instability is tied with install failures as our 1 tech support headache in Rhino 5).
For curves, surface edges, and isocurves, we create the polyline approximation for every frame draw. The polyline approximation is done to sub-pixel accuracy so that curves in Rhino always look âcorrectâ no matter how far you zoom in. This was really novel when we first did it, and it made Rhinoâs display look really nice without having to manually âregenerateâ the view, or without sending 1000-point polylines for each curve when zoomed out to the point that 4 points would do. The polyline approximation is computed on a single thread on the CPU - because this code was written years ago when there was only one or two threads at a time on a computer, and before OpenGL supported fancy shaders.
We know its possible to speed this up. Its possible to do some of that work on the GPU, use multiple threads on the CPU, and intelligently cache some of this information so that the computations happen less frequently. But all of those solutions are pretty substantial projects, and we probably wonât complete any of them before Rhino 6 ships.
But what actually makes it slower? Is it the rearranging (cleaning up) of the code?
Hi Brian,
Thanks as always for taking the time to compose this answer and explanation.
It makes sense and I see this is a matter of limited resources.
-Willem
I donât know. It may not even be possible for us to tell exactly what got a little slower. But we do know that a lot of time is spent cracking beziers into polylines.
Hard to say; in some cases the wire drawing is actually faster. Most cases the speed is about the same.
Wire drawing OpenGL code was rewritten to use OpenGL 3.0 shaders when drivers with that capability level are present (which is pretty common).
Iâll continue to work on fine tuning wire drawing, but we will most likely be within a few percent faster than V5 without a very large rewrite.
Would it be possible to have a setting to tune the polylines , much like rendermesh qualities currently can be set.
I see that in V5 while manipulating the view there is a course polyline that is refined in a static view.
It might be a can of worms, but being able to customise that âcoursenessâ would maybe help speeding up systems not up to par displaying the current model. Of course only if itâs fairly easy to implement for else it will take away resources for more sustainable solutions.
Probably caching the (course) polylines will help as well but I assume that has already been discussed and is either on a TODO list or dismissed for good reasons.
-Willem
I believe that happens in V6 as well. We do lots of degrading to make the frame rates faster when the view is rotating or panning. One frustration is that if you zoom with a mouse wheel, Rhino doesnât do the degrading because itâs difficult to tell if the current wheel movement is the last one (so therefore should draw high quality) or not (so draw quickly).
While TestMaxSpeed does a good job of showing you how quickly Rhino can do full frame draws, it doesnât do a very good job of showing Rhinoâs ability to keep the frame rate up when you rotate the view.
Youâre right that doing more degrading during view manipulation, and being able to do it during mouse wheel zooming, would help here, too.
I suppose we could add yet-another-setting to control polyline density. We could crack to 1/2 pixel by default, but if you were happy with 10-pixel accuracy we could spend less time. I doubt this would really help the masses, as theyâd have to find the setting and fiddle with it. Rhino is grown up enough now that I think the tiny geek-mode settings we add due to discussions on this forum mostly go unnoticed. But they sometimes take a lot of time to implement. Is it worth it for one- or two-hundred people that notice? Maybe. Iâd rather take a little longer and work on things that help everyone without ever having a setting.
3 Likes
Just a noob question. Is it possible to bring better anti aliasing than x8?
I presume this question comes from something not looking as smooth as you think it should in Rhino? Can you send an annotated screen shot describing what you wish looked better?
It might be that AA isnât the reason things look bad to you.
AA works similarly to what would happen if you rendered the frame bigger and then shrunk it in Photoshop. So for a 100 x 100 pixel viewport, 2x AA renders a 200 x 200 pixel image and then shrinks it. 8x renders a 800 x 800 pixel image. That much downsampling is probably enough.
It is nothing about being bad. It is a general question about contrast between no aa or x2 and x8. My question is: could it be even better?
I am very pleased with aa working in a perspective view but sometimes F,B,L,R views are missing the fine details.