Continuing the discussion from Update toolbars in all rhino instances:
… this is the equivalent off selling a pickup-truck where the instruments are all messed up in chaos
… and advertised as 4x4 but had no Differential
this would be this case Is the subsurface UV mapping problem being addressed?
… and the van’s roof top was desintegrating…
This one’s was last answered by Steve in 2014: “I will try to, Need to engineer some time first.”
I’m loosing 20% of the time just with the toolbar chaos and latency regarding moving large drawings due to snap, ortho and other “rather long lags”…
…wonder how would it be like in Russia. With all that degrading infrastructure… and that Russian Geometric Kernel - Wikipedia
It looks horrible!!! isicad :: Russian 3D-kernel RGK: Functionality, Advantages, and Integration
Well…the thing with rants is that they’re funny even if I’m completely wrong and have the answer right in front of my round red nose
…meanwhile I’m wondering if I should kill a rhino instance that irrenponsivelly whitish for quite a while…
Just for moving a tiny topological mesh
If you are going to rant, please do it all in one post instead of seven…
This post is an overview…
Feel free to respond in the original linked posts
PS: I vote you’re allowed to curse by the way
If you’ve been following the forum, you might have noticed many posts where it has been mentioned that the the toolbar system is going to be completely revamped for V8. Until that system is actually up, working and testable in the WIP, it’s difficult to know which bugs have been addressed and which haven’t…
This post still does not contain enough details or an example of what you are trying to achieve (despite the fact that they were asked for).
Probably. If you can reproduce the problem consistently, create a bug report and post it here or send it in to tech.
This is just the general slowness with large scenes where “snaps” and even “ortho” becomes irresponsible. You’ll have to wait a while until “Tabkey” get’s an orthogonal lock.
In this case my new but “on board” GPU might have part of the guilt but…not all for sure
Maybe that post got a little convoluted but puting it simply… how to project (meaning positioning in this case) a selection of block instances to a surface …and and of course have the choice to orient not only by surface normal but world.
A useful use case would be to project vertically Trees on a terrain surface.
By the way:
Is there a block insertion Snap?
Is there a way to reset block instance transforms?
When using the Gizmo, is there a choice to transform object (namelly block instances) relative to it’s local coordinates?
If I have 3 or 4 rhino instances and want to change something in the “toolbar layout” how should I go on saving that? If I save changes in my own toolbar file how can I reload that in the other rhino instances?
There’s no “refresh” in Options->Toolbars, I can only close and open it again… and lose some positional parameters.
Is there a way to refresh toolbars that I’m missing?
Also, I’m not sure but… does Rhino automatically update toolbar files? When? can it overwrite my explicit toolbar file update?
Yes, that’s the way it works currently. You can save the .rui file in one instance and then close (without saving ) and re-open in the others, but that’s painful. There is currently no mechanism to do this differently - I have no idea if the V8 version will be changed in this regard.
Other settings update between open instances immediately, but the toolbar layout is a complex combination of two different files - the toolbar file itself plus the individual positions. Lets say you have two instances of Rhino open on a setup with two screens - one of the screens has Rhino maximized and the other doesn’t. Now you add or modify a toolbar in one instance. Rhino doesn’t necessarily know where to put the toolbar in the other instance - it needs to ‘guess’. I don’t know how this stuff gets solved.
That used to be the case for the default.rui at one time, but AFAIK it does not get overwritten anymore. Custom workspaces (saved under another name) never get overwritten during SR updates.
If I understood correctly, the whole concept of default.rui will be going away for V8.
Currently, here in V8, with the system not yet public, the latest instance to close determines what the toolbars will look like on the next one to open - this is the same as V7.
How should it work, if different from that?
However, updates to toolbars from McNeel will be reflected in the next builds automatically, there will be no need to update ‘manually’.
I think he wants to work like settings do currently, i.e. as soon as a change is made in one open instance, all the other open instances update immediately.
Ah, yeah - on Windows that is less straighforward, and may come, but on Mac that should happen automatically with the new system, currently at least.