V6 Goal: Display Performance

Yes, Jorgen found that one first (see a couple posts up).
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.

1 Like

I just committed a fix for the AA bug so this should just work in the next WIP. Thanks guys for reporting

1 Like

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:

And same view if I do a small manipulation:

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!

And here in rendered:

and after viewport manipulation:

Problems with Sub-D’s were on Steve’s list :wink: :

1 Like

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.

1 Like

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.

1 Like

Sounds great, the monitor I use is a 27" 2560x1440, I tried a 4K monitor but the software I used didn’ support it well enough, so I downgraded :wink:

What “Text Scale” are you running Windows at? This is what Windows uses to report DPI settings

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.

I’m running it at 100%

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:

Turning off VBO eliminates this.

Thanks, I can repeat this and will try to get it fixed right away

@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:

  1. Note the problem
  2. Turn off the vbo caching via TestVBOCache command (disable it)
  3. See if the problem still exists.
  4. 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.


@jeff and @stevebaer,

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 :wink:

btw. i really like the transparent shadow option for the groundplane without using a material. Thanks!



Ok thanks @clement, we’ll check it out. Pretty sure this used to work in the new engine, so something worked its way into (or out of) the code.


I’ve almost got this fixed Jeff. We never properly supported gradient backgrounds through tiles.

Ya, I guess not… I was just thinking of tiled rendering in general…gradient seems to have slipped through the cracks.

The gradient background tiling bug will be fixed in the next WIP.