I agree that we don’t need yet another TEST model. What does help the discussion is seeing how YOUR typical realistic model with YOUR typical display mode behaves in the WIP. What numbers are you getting and what would make you happy?
Ha, turnaround is fair play😄 Just giving you guys a hard time. I know you guys don’t mean ill will and I’ve got a pretty thick skin. No worries
Shaded polysurface display (which is also shaded meshes under the hood) has long been a major complaint by users. There are many threads on this forum in the past complaining about shaded polysurface performance compared to simple shaded meshes.
I do plan on improving curve display performance; it is more of when it will be done. In general, we don’t like to promise on things in the future until we can get around to implementing it. Part of that whole ‘delivering beyond expectations’ thing😄 If I can keep your expectations low, then I can probably deliver beyond them.
Here’s what I don’t understand:
I just made a nurbs model of a sub-d bike I made and the result is 9800 nurbs surfaces.
(workflow not important, but just so you know where the surfaces came from)
If I in rendered mode has edges and curves turned off and run testmaxspeed it takes 14 seconds.
And then I extract the rendermeshes of all surfaces and hides the nurbs and run testmaxspeed it takes 3 seconds…
So why is Rhino calculating all the nurbs data that is not seen? It just doesn’t make sense to me. All it does is moving the camera, and showing the rendermesh, so to me this should be just as fast as the extracted rendermesh.
None the less, I wish we could have a mode that just shows the rendermesh when manipulating the view, and then calculate the nurbs data when the camera is still. It would be a good hybrid mode for most of my needs for a fast display mode.
This sounds like a bug. The speeds should be very similar. I’ll have to try and reproduce this.
A similar test in shaded mode:
Nurbs with isocurves turned off and edges visible takes 4.06 seconds.
edges extracted as curves, render meshes extracted and nurbs hidden (similar look) takes 4.03 so that is exactly the same.
Here is the mesh of the bike you can use to convert to subd-> nurbs.
subd mesh bike raw.3dm (196.5 KB)
I can totally understand this. I think I made my point here and it was heard, so I will be patient and hope that R6 or maybe even a WIP will address this issues.
I am just doing some test on a few of my models by using testmaxspeed and a few are indeed fasterin shaded mode. However I also had a few “microfreezes” where the display is doing nothing for a few seconds (it feels like it has to reload something…), I will try to isolate the problem further.
another small thing I stumbled upon while testing:
when using shaded mode -lightning scheme -lightning method : default lighting changing the Ambient color does not seem to work, my geometry stays pretty dark despite my attempt to bright them up by using a lighter grey shade (see picture…)
As far as I remember @Micha did exactly the same thing a long time ago (even with a bike …!)
I cannot find the exact tread though…
Yeah, I know, it was me who started that testing and provided him with the bike
nah, he took it to new heights and deserves the credit
Right, the original model was from Holo from somewhere of the internet.I deleted the bad surfaces only, because in the old discussion the argument was, the bad objects cause the slow down.
I afraid I was more a pain in the neck with the bike model posts, so people think it’s my bike.
Steve, great, I hope you find the reason for the speed difference between NURBS and mesh only display mode.
Here is the old link:
New V6 Display Faster: GPU Tessellation
It seems V6 is limiting it’s max redraw to the monitor fps setting, is that right?
In V5 I can get 1063 fps on a simple object test in wireframe, while in V6 I can only get 61 fps. But I also get 61 fps if I make 400 copies of that simple object.
Seems like a smart move if that’s the case.
Just a quick question I added here, but since I noticed this post about the display, it could be better to ask here:
- In V5 with a CustomMeshObject/CustomBrepObject the OnDraw inherited method wasn’t called on Rendered mode if the object wasn’t selected. This seems to be fixed in V6 but I noticed if you remove the call to base.OnDraw, the Render Mesh is still drawing on the viewport. I attached a project in the url above with an example project.
Just dropping a quick note to say that the new viewport feels like butter. Very nice- going to try to load heavy files to see if there is a difference between 5 and 6.
A little good news and big bad news.
Better, but not really good - v6 shows my complex NURBS models a little bit faster than at v5 (approx. 20% faster).
Bad news - extracted the render mesh and hide the NURBS (bike model test) - at v5 it needs 5s for testmaxspeed and at v6 12s. Since my complex models are quite slow (around 1fps) I try to use mesh versions of the objects at the scene (for rendering) often. V6 shouldn’t be slower than v5 in this case too. I hope the old mesh speed or better will come back.
Are you sure WIP is using the nVidia card and not the built in Intel card?
You can force what card to use in the Quadro drivers.
Here are my scores on my workstation with a Geforce 1070, both with 100 and 1000 speres:
V5, 100 spheres: 2.88 sec
V6, 100 spheres: 1.98 sec
V5, 1000 spheres: 27.33 sec
V6, 1000 spheres: 21.88 sec
I thought I am sure, when I saw my nVidia card as the main hardware for OpenGL in “Video Hardware and Driver Information”.
I also have set Nvidia as default graphic procesor for Rhino 6 WIP. So…I don’t know if its correct to force it via Quadro drivers…?