Yeah, unless it is stated “Free Viewer” or something like that, our IT department won’t allow it ![]()
But thanks, I will try the WiP to test markups as soon as I can
Yeah, unless it is stated “Free Viewer” or something like that, our IT department won’t allow it ![]()
But thanks, I will try the WiP to test markups as soon as I can
Hi Morteza,
For a lot of annotations this will work, but there are some cases where visibility state, clipping plane state, view mode would be necessary to be stored to annotate about a specific situation.
Also if you want to annotate about issues with a material, you need to also make sure you load that material.
Or if the most effective way to annotate a design issue or a collision is to move some parts out of the way in a saved position, or exploded view, you also want to save/restore that.
In other words, I understand that maybe you started with a subset of snapshots, to get around the technical debt already incurred in the snapshots code, but maybe you are now fragmenting the workflow and code even more?
As much as I love new tools, including this one, I much rather see development efforts to truly finish the job of existing tools that were never properly executed. For example: Snapshots.
These two main problems are preventing to use Snapshots as the tool we always wanted and we still haven’t received:
In summary: I’d love to see annotations fully integrated with snapshots and have it all working well, no bloat, no crashes.
Re: annotations. I like the idea of it, but I also see that the best use case for them is to have them synced with other users/team members. Then we can have a design review with the same Rhino file open and we can all sketch in a shared Rhino overlay whiteboard, and the annotations stay saved in the rhino file. Instead of our current approach of one user sharing their screen with a Rhino session, and we all sketch in Zoom annotation tools and take screenshots of those annotation in snagit and then save those in a shared Basecamp post so the person doing the design/modeling can go back to Rhino and try to puzzle together all the feedback to make modeling/design changes. Having it all saved inside the Rhino file would be sooo much better.
Thanks,
G
Yeah, this is THE problem with snapshots! I tried it once many, many years ago - and haven’t touched it since…
Not yet but it’s in the works
RH-87273 Markup: Continue a markup
Understood, I agree there are cases that can benefit from having markups save object states. That can be made optional. I’ll give it more thought.
RH-87700 Object state client for markups
We can keep working on improving Snapshots. Wether we end up using object states in markups or not.
Are these users marking up the model at the same time? I don’t know how we can sync up the files live among users without uploading your model/changes to our cloud (that’s something we don’t want to do)
That’s great! I think you guys should really get to work on those improvement then, ASAP. Ahead of, and with a much higher priority than any new features IMO.
Keep in mind that the Snapshots tool was released as a shipping product first in Rhino 6, circa 2018.
So here we are, 7 years later, with Rhino 6,7,and 8 shipped, and Snapshots is still pretty much a cluster——.
That tool is way too important to have been given so little attention by your team. Right now it can only be used as a very powerful tool in a burner file where you know you never want to keep working in that file again. That’s not cool.
This is the kind of stuff that drives me nuts about McNeel’s shipping culture. I really hope your team can think about the impact of these decisions and take stuff this more seriously.
I have some thoughts about markup, and easy networking, but they can wait. Let’s fix snapshots first. I’m going to practice what I preach: Priorities.
Thanks,
G
Yes!!!
The most important and fundamental question for me is:
Is Markup going to be about drawing in screen space only? That is, there will be no possibility to rotate the camera to see the drawing projected on any plane (or geometry) from a different perspective?
If so, will there be a separate command that will utilize the same techniques to draw in 3D? Or at least at given CPlane?
That’s the idea, things you draw during a markup are constrained to the camera plane, so they don’t really make sense in another view.
But you can see them if you like, try testShowMarkupLayers command and turn the markup layer on manually. I’m curious what you’d do with it
Doesn’t Sketch command just do that?
What about merging these two [Sketch and Markup] into a one more flexible command?
So one would use the MarkUp HUD to draw, and have an option to turn it into Curves…
That’s what basically markup command is. It sets the cplane, draws curves using sketch and saves a snapshot.
Sorry, but Sketch is on par with WalkAbout - rather useless.
Way too aggressive curve smoothing. I’m doodling with the mouse here. Especially the last drawn shape shows a problem with smoothing. Not to mention, that smoothing applied only once we release the mouse is not optimal, but ok, Rhino is a CAD software.
Drawed Shape
Curve smoothing of the Sketch command imposed once the stroke is finished.
Drawing is possible only on one object at a time, and it’s projecting curves on both sides of the geometry…
BTW
Without an eraser, all the sketching tools are useless too. Please remember the simple eraser. We really don’t have much to talk about without an eraser.
The Crayon app had a lot of concepts right, but also some flaws that I can’t recall right now. Anyway, it’s an abandonware, so not very reliable going forward.
Would it be possible to share a markup in some way? I’m thinking about a multi-user workflow where you can somehow add a markup to another person’s file.
You can save the 3DM file and share that, or have the 3DM models saved on a network or cloud drive. Is that what you mean?
I started a new thread here:
Is it now possible to edit a markup?
I couldn’t find a way so far…
It’s not possible to edit a markup after it gets saved.
Is it planned to add the option to edit a markup?