Yes, Jorgen found that one first (see a couple posts up). https://mcneel.myjetbrains.com/youtrack/issue/RH-33220
I’ll get that fixed before next week’s WIP. It is not a GPU specific bug and will probably happen on all graphics cards.
There’s a lot more than just the use of VBOs that are built into this optimization. This just happened to be the name of the test command that I made when I started working on the optimization. Things have gotten well beyond just the use of VBOs (which we actually already did in V5 and in previous WIPs). The optimization has more to do with smarter management of VBOs and batch drawing them when possible.
Wireframe display is probably not going to see a big boost in performance. I’m seeing if there are little things here or there that we can to do improve wireframe performance, but I don’t see anything obvious at the moment that would make dramatic changes.
I did have one optimization in place in the past where we took the last frame and slapping it onto the current frame with a slight offset during panning. This made a huge difference in panning speed, but there were a lot of corner cases where things broke. I will look back into this optimization after I’ve finished the current shaded mesh optimization.
I have another one, if I make a SubD then it shades it ok, until I rotate the view, then the SubD becomes wireframe, until I click on the object or do something else. If I extract the rendermesh then that shows fine, but there are some edge errors, I have a naked edge color, and it shows both naked and joined edges at the same time.
Here are the different states:
Original mesh, SubD, Extracted Render mesh, exploded rendermesh:
Also note that the SubD “edge curves” are thinner than the rest, I don’t consider it a bug, I actually like it, maybe the meshes could benefit from that feature too. Unless it is something that slows the display down of course!
WOW! Just WOW!
I have made a test comparing the same, huge and complex model on my two machines.
NVIDIA GeForce GT 240M on RH WiP vs NVIDIA Quadro FX3700M on RH5.
Quadro is struggling while GeForce handles it easily. It used to be opposite.
The visual performance is so promising that it could be the only reason for me for switching to RH6.
Great work guys.
Correct, and they have already been fixed in the internal build. You guys will see this fix in next week’s WIP. For now the fix is to TestVboCache (enabled=false) when working with SubD objects.
I’ve been liking the thinner wires a bit more myself lately. On high DPI monitors (which I’m assuming is what you are using) we are scaling the thickness of wires up. It does look like we are slightly over doing the scaling though. I’ll tweak this for the next WIP.
Just tested some larger assemblies on WIP. Big improvement. I was already pretty happy with V5 but I’m a little blown away at how well the WIP handles them. Good job guys.
Here’s another one:
When I turn on controlpoints for a Nurbs Surface and manipulates it the render mesh isn’t updated in realtime like it does in V5.
It would be really nice if it would remesh in the background too, to refine the rendermesh while manipulating the nurbs surface. Not important, but it would be a nice feature.
And another:
Sometimes when I select something the parts of the display that is in shadow becomes the color of the viewport background. To illustrate it better it is here in orange:
@jeff I might need your help with this “becoming the viewport color” bug. I’m not sure what could be causing this. @Holo do you have a basic model that reproduces this?
@Holo As Steve suggested, a simple model will help immensely so that we’re not having to try to “model the problem”…
Also, something you (All of you) need to do when you come across a problem now is this:
Note the problem
Turn off the vbo caching via TestVBOCache command (disable it)
See if the problem still exists.
Report the situation
We still want to hear about the problem regardless of the results above…but this just helps us better understand whether or not this is a new problem introduced by the caching mechanism, or an already existing problem.
while attempting to create you some motivating screencaptures made with the new wip, i´ve run into an old bug which happens when capturing larger viewport resolutions using _-ViewCaptureToClipboard. If the _Scale option is used, the background (in below case it was a 2 color gradient) is repeated by the scale factor entered. I´ve tried to capture using _Scale=4 which caused below funky effect i could not withhold
btw. i really like the transparent shadow option for the groundplane without using a material. Thanks!
:
