Hi, Is there anything that can be done to increase responsiveness in Layouts when clipping planes are used in details? Rhino slows to a crawl when selecting and responding to commands when I use clipping planes in this way. It’s frustrating because there is a lot of goodness there when using all solids with clipping planes for creating section views.
Thanks,
Eric
Yeah, I would love to see layout speed in general get some love going forward. Numerous details alone will result in a sluggish layout, then add clipping planes or shadows, and things get painful. I know it is asking a lot of the display pipeline / card, but I’ll say it again, I would be happy to have some clunky looking details which might need to be refreshed for critical viewing or printing if it got me speed (as long as I could still do all the things I normally can do to a regular detail, pull dims, double click into it, etc.)
Sam
I have this happen a lot as well. For V6 I would love to be able to bake details; create a bitmap image or vectors from a detail as placeholders for the detail. The user could manually update the details at will.
-Willem
The “bake to texture” concept is pretty much the idea that I am hoping to explore for V6.
This wouldn’t really be something that the user controls, but is more of an under the hood optimization that we would do where the texture would get refreshed when objects change in the model or zoom levels get changed. The user shouldn’t even be able to tell that we are using image tricks.
Hi Steve,
Great!
Could you please 
consider to expose this to the user,
one way or another.
I imagine a _BakeDetail feature (with an option remaining to “refresh” the detail manually)
It would open-up options to keep layouts/pages as they are,
Easily present variations in material/light/setup.
eg: Currently we need to
With a feature to Bake a detail (at a set DPI or as vectors(sort of like an illustrator export)) the above would be done is just 2 steps.
-set up a view
(create annotations)
done
my2c
-Willem
If we are talking about baked details, perhaps think about the possibility of allowing a detail to be set to a renderer output. The current “thing” around the office is rendering out each detail, then placing that finished, pretty render on top of the detail it matches to pull dimensions. That way they get a really slick looking sheet (albeit all raster expect the dims). It would be nice if this could be more automated. This would also probably require each detail to have a badgeresque render settings manager.
Sam
It could work something like this example?
Wow. There are some very desirable features in that demo. I can’t stress enough how much I would like the option for Layouts in Rhino to be a separate file format like that (and like SolidWorks also). I really don’t like cluttering up my beautiful 3D models with 2D section work and detailing. It makes it difficult to share models with people because they are forced to filter all that out if all they want is geometry and not the documentation. I really like the idea of being able to import different data sets into one 2D document. I really like the ability to export the layout document as a ‘flat’ dwg file.
Most of this is possible in Rhino now but is not simple.
Eric
Yes, wow!!! I really hope we will get something similar in Rhino as well! It would save so much time - every day…
Philip
I love the ideas posted above!!! I run a pretty fast workstation, but yet I can’t make full use of the more processor intensive display modes like Technical when I am using multiple detail views on a large complex model. Being able to FREEZEFRAME or BAKE a detail view that retains all of its dimension snaps and uses little computer resources would be a HUGE improvement!!!