V6 Display Performance: Block Improvements

unhandled
wip-6-win-splash

(Steve Baer) #1

The latest Rhino WIP (May 16, 2017) contains a large rewrite of the block display code. You should see performance improvements in models that use many blocks (including nested blocks.)

This was a large rewrite so I won’t be surprised if there is a bug or two that still need to be squished. Please let me know if you have models that are not showing any performance improvements or don’t appear to be displaying blocks correctly.

There is one outstanding bug that I already know about where blocks are not properly displaying transparent (ghosted) surfaces. https://mcneel.myjetbrains.com/youtrack/issue/RH-39146

Thanks,
-Steve


#2

just installed the new wip and opened a file with over 60 blocks which i was working with the last week. i really feel a huge improvement.
last week i was totally feed up with working on that file, display performance was just terribly lagging.
of course my “feeling” is not an accurate comparison - but i’m pretty happy this happened.


#3

Installed and tested - :grin: - that’s great, my complex models based on a lot of blocks are fast running now. Also I see the switching to wireframe mode very seldom anymore. That’s fantastic!!!

In a next step the display quality could be improved. Intersecting edges are not so nice shown like in the past.
Example: splite a surface and asign different colors.

Also there seems to be a bug. I did the quick split test in my complex train file. In top view the splitted surface is shown random moved.

If I select the splitted surface than the top view shows the right placement.


#4

Steve,

I had high hopes when I saw the title of the update, since we model large models exclusively made with blocks.
In opaque shades modes, the result is indeed amazing, but as soon as I use a shading mode with transparency, it’s back to snail-speed.
Even worse, it completely screws up the benefits of the previous update : the framerate is down to sub-V5 levels, and the switching between shaded and wireframe is stuttering.

I never use opaque shaded modes ; I find that a slight transparency helps a lot.

Cheers,


#5

Hi @stevebaer

I have tested few of the current files I am currently working on in WIP.
Enclosed is the export of one block which was visible in the pre-last WIP but not visible in the latest WIP.
Actually, it becomes visible only when you select it -> please, pick in the middle of the rectangle area.

The file is enclosed.

Bug_Block.3dm (68.7 KB)

Thanks,
Dmitriy


#6

Hi again,

Similar behavior but maybe a bit different:
Blocks are present in the file - I can see this in Block preview and can count them in the Block Manager.
But when I try to select those - it says no objects to be selected.
See screenshots enclosed.
In the previous WIP it was ok.

N.B: I have not tested new WIP on the too deeply nested blocks but I can notice a performance improvement.

Thanks,
Dmitriy


#7

I tested what Osuire said and I can confirm that as soon as I switch to ‘ghosted’ mode the viewport becomes extremely sluggish. I tried activating the new OpenGL tesselation feature, but also no improvement there, so I guess that there might be some bug still hidden somewhere.
Other than that I find the renderspeed of the viewport greatly improved when using blocks.

I noticed that ‘ghosted’ mode is not working with blocks, they are still displayed solid. After exploding them, they are rendered fine. Also ghosted mode is very slow right now with lots of blocks. (Work In Progress
(6.0.17136.10381, 5/16/2017)


(Steve Baer) #8

Thanks; I can repeat that bug and am investigating it today
https://mcneel.myjetbrains.com/youtrack/issue/RH-39428

Yes, I mentioned in the initial post that there is a known bug with respect to blocks that needs to be fixed.
https://mcneel.myjetbrains.com/youtrack/issue/RH-39146

There is a transparency bug as I mentioned in the initial post that needs to be fixed.
https://mcneel.myjetbrains.com/youtrack/issue/RH-39146
I believe all of the transparent issues that you are seeing are related to this bug. Hopefully we will get this issue resolved soon.

Thanks for testing everyone.


#11

Hi @stevebaer

Another issue I have noticed:
when being inside one block - all the other objects (outside block) are shown in gray (usual).
But now - when modifying one block - all other blocks in the drawing are shown with its current color and not gray.

Thanks,
Dmitriy


(Steve Baer) #12

Are you referring to editing of blocks?


#13

Yes, I am referring to the block.
But for a different color - I mean all blocks in the document, which are not nested in the current block.

Thanks,
Dmitriy


(Steve Baer) #14

Sorry, I’m still confused. Are you referring to the “BlockEdit” command?


#15

Hi @stevebaer

yes, I am referring to the BlockEdit command:

So, when I modify the block (with BlockEdit) - other blocks in the drawing are shown with an assigned color but should be with gray as all other objects ( being inaccessible).

Thanks,
Dmitriy


#16

I was trying to hide unnescessary circles on blocked acoustic panels (Approx 2000 on each panel) by packing all circles in a hidden layer. They keep being visible even if I hide the layer and display performance is a bit
better but not enough.


(Brian Gillespie) #17

RH-39428 is fixed in the latest WIP


(Steve Baer) #18

Thanks, I made a bug report for this at
https://mcneel.myjetbrains.com/youtrack/issue/RH-39488


#19

Steve, what do you think about the line quality here:


#20

Hi Micha, what do you expect in those areas?

I did a quick test with two surfaces AND the split curve is shown in white:
(I guess this is what you see as well, that the surface edge and the curves aren’t identically optimized)

And here the curve is hidden:

And here it is shown and hidden again (point is that either the green or the red edge is showing):

As you can see the surface edges are drawn in the same manner, but the curve isn’t using the same optimization settings (if any).

Edit: This was odd, viewcapturetoclipboard seems to use a different draw order than the viewport it self… or something is messing up the paste here as I can’t capture the reversed draw order with viewcapturetoclipboards, so I used another tool:


(Steve Baer) #21

I think the quality needs to be improved😀 Is there a couple curve in there as well as surface edges? Curves are not currently using GPU tessellation which is causing slight differences in depth biasing of the wires. Once curves are drawn using the same technique as surface edges, then the quality should improve


#22

Interesting, I see the edge artefacts at my project file, but not at a simple test file. Here a little part that shows the error - no curves in the scene.

DisplayIssue2.rar (716.8 KB)