Layer States Issue

I’ve posted this on the VisualArq forum, but it may be a Rhino issue and since it will take 24 hours to get a response from VisualArq in Spain, I am posting it here too; I"m beginning to think it isn’t just a VisualArq issue. As you can see in the GIF below, the second layer state created from the viewport in the session doesn’t save/restore correctly. I think this might be the pattern, because if I create the same states in reverse order, it’s still the second one that doesn’t work. Rhino 6.7.18193.18031, BTW. I’ve uploaded the project to Drop Box and can upload it to the Mcneel site if a link is posted.

Hello - I can certainly make some state monkey-business happen - I’m not sure it is the same as what you see but it is not far off - thanks for the report.

And now I cannot duplicate it…

Here’s a start -


Thanks Pascal.

It’s important to say that layer state functionality is an important work-around for the following compounded issue:

Va tags print off centre and overlapping their bubbles; exploding generated views is the way around this. If a project is then saved/closed/reopened before the explosion is undone, all the myriad exploded bits have to be deleted apart from all the dimension and annotation and other elements in their midst. Without layer states to help with this procedure, time consuming difficulties can occur when making multiple prints (when difficulty is the most unwelcome.)

It’s worth mentioning that Rhino’s instability when dimensioning blocks (which Va Objects are) creates and compounds this sort of problem in two ways: A) Dimensions can’t stably exist in modeled objects so they can’t be regenerated with the view so have to be managed separately creating the issue above. And moreover B) If they could exist stably in modeled objects, the generated view (or Make2d if not using Va) wouldn’t be necessary in the first place.

The instability of dimensioning blocks requires many work-arounds like this while it defeats the possibilities of using the full features of Rhino in fabrication/construction - not just in Va, but in any other implementation of the application. It would be reassuring to know that addressing this was a development priority,.

RH-47376 is fixed in the latest Service Release