Hidden and Conceptual View modes deactivate between sessions

Wondering if this is a common issue. It’s seldom that I open a project and don’t have to reassign the view modes in any detail views back to hidden or conceptual view mode. They almost always switch to wireframe between sessions. Since these are the two view modes I almost always use, it can get laborious to reset them for each new session. There’s another post where I first identified this issue (i can’t seem to search it up) and I’m wondering if I’m the only one experiencing it. Rhino, Va, and my computer are quite up-to-date, and this problem has persisted for well over a year from one computer to another, so it seems fairly well-entrenched. I believe the previous post contained a request from Va Support for a project from me where the problem exists, but my projects are big and stripping everything proprietary out of them and compressing and uploading - as I have often done for previous issues - can be laborious too. (But if it’s the only way out of this, I will do it again.) It’s hard to believe I’m the only one with the issue, as it’s been the case so consistently in my case.

Hi David,

As far as I know, this bug hasn’t been reported yet.

Rhino stores the display mode UUID in the 3DM. When a file is opened, Rhino looks for a display mode with the same UUID in the registry, and if it cannot be found, it switches to one of the default Rhino display modes (I guess Rhino also stores the UUID of the template display mode used to create the other display mode).

Are you using custom display modes created by your or you’re using the display modes that VisualARQ creates?

Do you disable Tibidabo or VisualARQ plugins? If Tibidabo or VisualARQ are not loaded, conceptual, hidden and realistic display modes (and their derivates) will not be available.


This a problem which crops up with Va and Tibidabo active.

I modify Conceptual to use AO and to render materials. I often modify Hidden go not show mesh lines.

I had some issues with it a while back when using modified Hidden line view styles. This was at least a year ago. When I would come back to them later they would default to Wireframe. No only that, but the modified view style itself wouldn’t work as well. I’m not sure if this is the same issue you are describing but I assumed at the time that it had something to do with changes to the view style code between updates.

I never really figured out what caused it. I now mostly used modified Arctic view styles and don’t seem to have the issue.

Hidden and Conceptual are the only modes I’ve experienced which will draw silhouettes along the edge of curving surfaces as well as consistently providing section fills (though they don’'t always follow the object display settings completely faithfully). Hence my use of those two modes almost exclusively, but not as default - I modify Conceptual to show AO lighting and materials.

Could my modfications be what’s triggering the issue, Enric? Can you recreate the issue?

Hi @djhg,

I tried to reproduce the issue, and I found a possible case: if the 3DM does not contain any VisualARQ data, and there is no VisualARQ panel open (“Levels” or “Sections”), Rhino will not load VisualARQ plugin when you open the 3DM. In this case, any VisualARQ display mode will not be available, so our display modes won’t be available, and Rhino will revert them to Wireframe.

Is it possible that the documents where you’re experimenting with this issue have no VisualARQ data inside?


It’s rare for me to have no Va data in a view, but it does happen.

The most frustrating recent case was in fact a project without Va objects. Every detail had a Va section or level active, but likely the only panels open when that project opens are layers, properties, and display.

If I keep a section and(/or?) levels panel open when Rhino most recently quits, would you expect the Va view modes to persist when a project opens? (Can’t test that just now - I don’t have access to the computer and project: It’s 11:30 pm, the show I am on is on hiatus, and my Rhino laptop is packed up for a few days.)

I can now say that on some projects where this problem exists, adding a vaobject somewhere in the project will fix it. However, it still happens regularly on projects with many vaobjects.

Hi @djhg,

Please, could you send us to visualarq@asuni.com one of the files where you get that error exactly in the state you have it before opening it and getting the error?

Are the Level or Section panels open when you get this error?

I"ll send a project. I’ll name the layout where the problem is common lately. If the issue happens, all the detail views will have reverted to wireframe when you open it. Each detail will have two windows on top of one another.

It opens with the layer panel open, and all detail views reverted to wireframe.

1 Like

I have uploaded a project and sent a link. it took a while as our Box account has been acting up. I identified the problem page on the email with the link. THings aren’t exactly as described above.

Incidentally, there is a Va wall in the project, but this issue persists (so the workaround provided earlier in this thread is no longer viable.)

1 Like

(A note here that Alfonso confirms this problem - by email - and submitted it.)

Hi @djhg,

I’ve been debugging your document, and it seems to work fine, as long as you always open the document on a Rhino with VisualARQ loaded. If by any reason, the document in opened in a Rhino where VisualARQ is disabled or not installed, or where your customized “Conceptual” display mode is not imported, Rhino will automatically revert those viewport/details to “Wireframe” it you save the document.

This happens because VisualARQ display modes are not persistent, and they are only available if VisualARQ is loaded.

Do you think this might be the reason?
Do you open the same document in multiple computers, where VisualARQ may not be installed?

Thinking in viable solutions:

  1. Make our display modes persistent, but they won’t look the same if VisualARQ is loaded. This solutions doesn’t solve the problem for user custom display modes.
  2. Store in the VisualARQ document data the display mode used in all details, so when the document is opened again, detect if any viewport/detail has been reverted, and set the original display mode. If by any means, the display mode is changed when VisualARQ is not loaded, it will be reverted to the VA display mode.

What do you think?



Thanks Enriq.
I go for many months without unloading the plugin, but conceptual view mode never persists between sessions. Neither does hidden view mode much of the time. Opening without Va loaded may exacerbate the problem, but it couldn’t be the main cause on my machine, which is the only one I use.

So your option number 2 seems best to me though i cant see how it addresses the cause of the reversion.

There has been some discussion about how to pass on display modes with the document in Rhino (independently of VA):

The outcome was more or less: the user should be able to choose where to store display modes: classically in Rhino options, or in a new pool of display modes that are stored with the document.

Ideally, VA display modes would follow the same system, so Asuni and McNeel might want to work together in this.
Forgive me if I’m saying something obvious.