I’d appreciate an answer on the question below:
Some very important features that are currently missing:
Are those features going to be shipped with R9?
We can look at these issues.
Associative hatches. In Rhino 9 hatches do respect history. If record history is turned on the hatch will keep up with the boundary. A second way of doing it it to use the Hatch properties to turn on the boundary. Then the boundary draws and belongs to the hatch itself.
Hatch pattern rotation per custom Cplane? So when adjusting the Rotation the current Cplane is an option?
Hatch scale section style can be scaled in multiple ways. Hatches that are Model Hatches will print a specific size in all cases. Layout hatches will scale based on print scale essentially at print time or on layouts which technically already are at print scale. Do you have an example for this one?
I think different Hatch scales per detail would need to use the multiple layer and isolate per detail. Although an example would be great to see here too.
Okay, so two options here: 1. the boundary curve during the hatch creation is the associated curve 2. the boundary curve in the hatch properties - meaning the section style boundary with the checkbox . Sounds good.
Let’s say we are drawing a floorplan in world top and we set the hatch rotation to 45 deg. Now we wanna print something (or simply work on) with a different custom cplane. The hatch rotation always should be 45 deg in all the cplanes we are working. Like a global setting. If this is not something that everybody would like to have as a setting to work with, then at least to have the option to set the rotation as global. In architectural drawings it’s the standard. Dynamically changing the cplane we work is essential but it should have added functionality with the hatch rotation as well. This way it would work in cplanes of all angles. For example a custom cplane sectioning a dome at a tangent point etc. Adding to this, personally I am working with VisualArq plugin, which is going to inherit such functionality in the VA objects styles etc. It’s crucial.
Related to cplanes functionality, knowing that it’s not relevant to hatch, placement of VisualArq tags, columns, furniture, guides etc, on custom cplanes is being handled -as far as I understand - internally by the VA plugin because of the limits in cplane functionality. Due to this fact we are limited on presetting the plane we wanna work to the world cplane, by rotating the survey in a way it suits us, but this way the dynamic scope of cplanes becomes useless and we work statically by deciding everything from the start. What if we must change the placement of the building by 3 degress, and we wanna work in a different cplane? We should re-rotate everything, which is a mess - VisualArq wise, because of dependencies of the guides and other VAobjects. These limitations are related to VA but in my opinion are because of the Rhino mechanisms. Maybe @fsalla has more to say about this.
Also a related thread in VisualArq is this: section-style-print-color-thread. I do not know if hatch properties is a separate subject from section-styles tecnically.
It’s about the desire and necessity of setting section style properties by layer, like the dialogue below (or even enchanced in some way):
Maybe @ng5_Alex would like to add more on this.
I meant setting the boundary curve section style print width in mm instead of width scale and the same for the pattern width. Based on the desires of the posted above thread, everything should be handled in our opinion by layer settings.
Right now we do now have the ability to differentiate the hatch or hatch boundary print width and color, among different setups, like model, layout, detail1, detail2 etc. This way we cannot work with different scales among different setups, that going to be printed
@scottd Does this info help in anyway to future improvement steps? Do you think the above would get implemented in R9? Is there any estimate date for R9 launch?
Hello,
in this post while discussing section style options, i have described why i think that in general managing almost everything through layers simplifies the UI, adds more control, speeds up changes and is compatible with already existing functionality.
Hope this adds to the discussion.
best
alex.
