Wish: viewport proxies for blocks

Hallo,

as I am often working on very large and heavy scenes, I experience display performance problems on a regular basis. In 90 % of the scenes It is not the actual architecture (I do visualizations for buildings) but the accessories like cars, trees and people which cause the impact.
I already try play every trick i know of, but here is one thing that really would be a game changer for me:

Please make it possible to define a optical placeholder (display proxy) for a block, this way we could keep our scenes low on memory usage by using blocks and boost up the display performance by magnitudes (please see attached picture for demonstration…)
There should be an global button to enable or disable all display proxies, this way there won’t be a problem when we want to render the scene (construction with proxies enabled, turn off all proxies before rendering…)

Is it so hard to do?

please, please

Andreas

2 Likes

It’s good to see your post, like given.

I suggested imposters in: V6: Making a Better Block Manager (#14)

I’d guess that you could manually use ReplaceBlock for now.
I wonder if it could be scripted for your use, for now.

Wow, I just saw your post…
Impressive!

It has been a year since… :expressionless:

Thanks for your suggestion with the replace block command, but even when scripted this would take way to much time when working with hundred or even more blocks and therefore kill my workflow.

Ideally the proxies (or imposters…) would only affect the display and not the geometry to be rendered …

Best

Andreas

Hi Andreas,

It is a valid request and indeed with heavy scenes having a simple display version of a complex block can greatly help with the speed. Not sure how soon we could expect this implemented in Rhino though, but the good news is what @Brenda suggests is actually a valid workflow, with a bit of scripting help.

In any case I assume for each of your complex blocks you need to define a simplified ‘imposter’ version of it anyway. So the way to go would be to create some rule in your block naming standards. For example: Tree_01 (main detailed blocks), Tree_01–light (light version of it) or even Tree_01–lightest (super simple version). It could be a prefix or suffix, depending on your scene organization.

If you keep it organized this way, you can use the script attached. It automatically replaces the corresponding named block instances (you can use method to add prefix, add suffix or replace – replace can be used to remove prefix or suffix if you use “” (just hit Enter) as the replacer string.

I use this workflow on regular basis and seems to be working fine with good speed benefits, Obviously it is up to you to create the needed block libraries in heavy/light versions and keep your models organized.

hth,

Jarek

DIG_ReplaceCorrespondingBlocks.rvb (2.0 KB)

1 Like

Hi Jarek,

thank you for your tips and suggestions!

I will take a closer look at your script, however it is a workaround for a crucial functionality that should really be provided by rhino itself IMHO. I you said yourself this approach forces you to use a fixed syntax for your libraries, and every time you want to “have a quick render” you have to run the script, which creates additional waiting and overhead.

I used and still use the replaceblock command myself, I experimented extensively with octane proxy objects which work for this problem in general, but introduce other problems themselves…

What I find most frustrating is that I have the feeling like everything is already there in rhino…
Right now I do some Experiments with “setObjectDisplayMode” to change heavy meshes to boundingboxes, but there is no way that this is defined for all viewports and there are some other issues here, but basically I am able to create a scene with e.g. 400 trees in it each 600.000 polys
just by unchecking the “show mesh” feature and use the “setobjectdisplaymode” for the shaded view I can change the handling for this scene from “not useable” to “blazing fast”.

All which would be necessary is rhino to be able to globally define object visibility for all viewports, also while being selected, this way we could simple use our imposter (applied with a non renderable material) for display and the invisible mesh (which is placed at the same location) for rendering.

Take a look at the attached pic. It was created as I wrote before (altering the diplay mode + Setobjectdisplaymode) . It load within seconds, spins like crazy and renders like hell!

Hi Andreas,

As I said I agree it would be nice to have this feature native in Rhino, per your and @Brenda’s suggestion. I would also find that useful, if implemented well. How do you think this should work, if you were to create a tech spec for McNeel to get it done? I think it is more likely to get some attention if there is a clear description of how this would be implemented.
I can just guess right now - would each block have a 'imposter geometry" property where the ‘simple’ version geometry data could be defined, and while the imposted mode is on, that geometry would show up instead of main block geometry? Would that be defined per-block definition, per-block-instance or globally ?

In any case, this approach would also require extra work to get the simplified geometry prepared. The element of consistent naming would not be an issue then, compared to my current approach. At the same time the current approach gives you some more flexibility of even few more levels of simplification…

I am not sure if I understand well your display mode method - would you elaborate more on that?

I have one other idea that I have not tried but came to my mind as this is being discussed: how about making a block that consists of 2 nested blocks, each of them representing the detailed and simple geometry. Also, create 2 layers called BlocksDetailed and BlocksSimple (or whatever else works) and inside the main block, place the corresponding nested blocks on these layers. Obviously objects within the 2 nested blocks can reside on any other layers, but these two layers could be easily used to control the visibility switch between the detailed and simplified blocks. Thoughts ?

–jarek

Jarek, the last part of your description is similar to what I am trying to archive right now by modifying display modes, object display modes.

Right now I am quite surprised how far I came by this primitive aproach (although there are still many problems and drawbacks involved…)

My latest try is this :

Problem : Hires Polygon Mesh in Blocks slowing down the display pipeline
Approach: Make polygon mesh invisible, create some lines, curves that represent the volume for editing / display representation.

  1. Create new display mode.Name it invisible. Modify the settings, turn off all visibility settings, set edge thickness to 0 and so on.
    2.Make a new icon. Call it e.g. “set object mode to invisible”. Write the folowing commands into the command:
    -SetObjectDisplayMode
    m
    b (invisible, might be different in your case, just check…)
  2. Draw curves roughly representing your geometry
  3. Create a block containing your hires mesh and your curves, select the mesh, execute your new command (2.) in each viewport!

that is it basically, as I said there are still a few issues, e.g. this does not work out of the box on another computer but once you import the new display mode it works again…

I keep on working on this, attached please find the toolbar with the button and the display mode

best

Andreas

SetObjectDisplay.rui (7.4 KB)

invisible.ini (10.4 KB)

Here are two interesting numbers that should illustrate my point:

Testmaxpeed: 2.04 sek !

Polygoncount: 33.742.314 (33,7 Millions!)

Hi Andreas,

How about like Jarek suggests:
Have de block geometry divided over 2 layers:
One layer with full geometry and one with lowres representation?
You can switch visibility for the 2 layers.

-Willem

That’d be good if transform of a block on one layer affects the corresponding block on the other layer with the same transform…

/Nathan

Hello Willem,
As I was trying to say, this kind of approach forces you to turn these layers on before rendering …
Take a look at the scene described above, just imagine how long it would take rhino to redraw a viewport with 33 million polygons…-> nightmare!
With the workaround I described it would simply not be necessary. …

I have the scene right here on my machine, it is totally lightweight and responsive! Starting the render takes seconds…

Hi Nathan,

I’m referring to having a single block definition with objects in it that reside on different layers.
Turning those layers on or off will also show/hide the objects defined in the block.

-Willem

1 Like

Hi Andreas,

So you need a way to have a proxy in the viewport and only for the rendering the full mesh is used?

-Willem

Exactly

1 Like

Maybe someone from McNeel might say a few words here?

I have the gut feeling, that I might not be so hard to integrate at least a global visibility option into the object properties, given how far I came without coding…

an easy way to implement this could be two checkboxes in the object properties tab:
A - Object invisible in display but renderable
B - Object only visible in display but not renderable

this way everybody would have an easy to use method to define what content in a Block should be rendered and what would be used for display without having to fiddle with custom display modes and manual defined object display modes…

Andreas

Hi Andreas, Willem,

I ran a test on the theoretical idea I had, and it seems to work ok - it can be polished up further with some macro button or even scripting, but it works even without it. See attached test file and the description below. I know this will not replace fully implemented functionality native in Rhino and I support that wish, but maybe until Rhino 7 it could be a valid workflow :wink:

  1. create your 2 high- and low-detail blocks as a main block that consists of 2 nested block instances:
    1a) Block A - main, detailed one, its geometry can sit on any number of layers. Put the block definition on layer called “High_Detail”
    1b) Block B - simple proxy geometry - make the block geometry and block definition on layer called “Low_Detail”

  2. select both blocks and create your main block that will consist of 2 nested blocks A and B. This block definition can be placed on any layer or many different layers

  3. Now you can switch between High_Detail and Low_Detail layers to toggle between proxy and detailed block views with as many high- and low detail block instances as you wish without worry about naming conventions etc. These 2 layers are equivalent to your detailed/proxy toggle button.

  4. If you wish to never view detailed version (too heavy to redraw even once), for rendering you can use these steps (macro it as needed):

  • Run _SetRedrawOff command
  • Turn off Low_Detail Layer
  • Turn on High_Detail Layer
  • Render
  • Turn on Low_Detail Layer
  • Turn off High_Detail Layer
  • Run _SetRedrawOn command

I don’t use Rhino Render engine (or any other rendering inside Rhino other that Neon and OpenGL render) but seems to work over here with quick tests. Here is the test file that should help to explain this method: tree_sample.zip (2.7 MB) Renders ok here and the detailed geometry consist of over 50 million polys.

best,

Jarek

1 Like

Hi Jarek,
Thank you very much for your input, I will take a closer look at your approach next monday.

Have a nice weekend

Andreas

In Vray you just have to create a proxy, save it in a rhino file, load it in your scene as istanced block , then put all the block istances in a New layer, Named “Blocks”; Now you can turn off the original Layer and you can’t see the blocks in the scene, but they will be rendered.

Hi Andreas - I don’t know how practical it is, but if you make a display mode that uses bounding box display (i.e. the display degrades to bounding boxes when the view is manipulated) then setting the objects inside the blocks to use this mode ( BlockEdit then SetObjectDisplayMode) may do the trick. Other objects will retain their display as usual - no bounding boxes.
(I mean this as a ‘for now’ possible workaround, not a solution…)

-Pascal

Hello Pascal,
That is basically what I am experimenting with right now, first I tried the bounding box approach but then found my current way causes less problems and you can get better representations of the geometry …
As I said, it already works pretty well although there are some issues…

E.g. while dragging , copying the blocks the hires meshes become visible temporarily and thought slow down the display…

I will report back on Monday

Who is the display pipeline guy at McNeel?

Best

Andreas