Maybe spend a couple of hours to understand and combine the two scripts. Create custom toolbar and button and make the button run the script?
That doesn’t sound like much work for a developer or someone who codes but it seems like a lot more than two hours’ work for someone who knows nothing of coding (like me, for example.)
What frustrates me is when someone is assuming that people don’t have desire to learn because they are not willing to code every simple stuff by their own. Especially, when there are a lot of users asking for the same functionality to be added/fixed/enhanced.
A day for all of us have only 24 hours and some people just want to keep healthy proportions in time spent between designing or actual work and workarounds, coding their own tools.
I can agree upon that nowadays with current tools, being a 100% designer is not the best strategy. But when it comes to highly demanded, not very customized tools and options (like one mentioned in this thread) it is alright to aks for them.
This is an opinion from the person who finds a lot of satisfaction in forging his own tools. Unfortunately, at the end of the day, the design is what I am asked for (and what my initial goal was) and no one cares if I made myself a script in the meantime.
There is always not enough time for the good design and a need for smart tool is what brings people to Rhino. Many of them are hoping that with Rhino they can spent more time on their work, but instead of too often they are hearing that it should be the opposite - more time on custom tools/less on the design.
And again, I would like to emphasize that I personally like to spend time on developing tools, getting to know them better, but sometimes it goes to the extend that is ridiculous.
I got a huge respect for this community and their plugins - especially for the grasshopper, but I understand the frustration of some users.
On the other hand…whatever.
I am back to hatching manually for Section FIlls.
I’ve found that Section Tools will too easily corrupt itself if it’s present in a detail window. Some actions (I’m not sure all of them, but one is copying a detail window) causes all project Section Tool elements to suddenly become present in Layout Space and disappear from Model Space.
Yes, you cannot trust third-party plugins to do what you want them to do. (even if the 3rd-party is McNeel themselves)
Btw, you should start a new thread reporting this issue under
section tools category in this forums.
I keep looking for one but still can’t find it.
I believe it’s under
Serengeti as a sub-category
Hmmm…I am mistaken apparently.
Just create the thread under
Perhaps because Section Tools is still under development it has not its own category yet.
@Asterisk @Bogdan_Chipara @djhg @osuire @wolfius
I want to revisit this topic because I have some ideas to make hatches in drawings (semi) automatic with a script. I’m thinking about making different hatches based on material or other to be defined criteria (in principle target at use in layout space but might also work in model space).
So I wonder on which criteria you would imagine hatches to be different. Do you do this per object properties, material, user text, layer or maybe otherwise? A simple example file would also be helpful.
Well, I’m thinking It should be like everything else in Properties. Default should be By Layer, then By Parent or custom.
this is what visualArq enables. But yes, Rhino would ideally have that (without an additional plugin that is used to a small part of its potential)
Since I will solve things with a script I won’t be able to add these kind of things to the Rhino interface. But I might be able to assign a marker to objects that I can read out in a script to use for deciding which hatch it should get.
In that case the workflow would be to first add markers to objects in the scene that you don’t want to have hatch based on the layer it is on. Of course it also means I need to figure out what is the best way to assign a hatch pattern to a layer since there is currently not such association.
Btw the script will only serve as a workaround and will in the best case be a prototype to explain what we want to have implemented in v7
Well, best to have it in the interface, so maybe it should be done in V7, together with snapping on the resulting hatch boundary.
I fully agree this would be the best. Until that time I aim to make something useful that can reduce the pain of waiting for that to happen. Snapping to the boundary might be simply a matter of extracting the fill surface edges although I have no idea what happens with those curves if they are flush with the clipping plane.
What I have in mind would be (after a to be defined set-up) a two button solution. One to (re)generate all hatches for all clipping planes and one to remove them from the model.
is it really that difficult to implement such simple funcionality once well and for good ?
I am running to these issues right now too.
Fills only work with basic geometry. Not on geometry within the blocks, which is a bug definately.
Make sure the display mode shows fills.
The strange thing here is that I made a custom tool that extracts the clipping data and it appears that the clipping data for many objects are available, just not visible in the view.
@wim do you know who that should be addressed to? It seems like a bug.
And I have also noticed that the clipping data is shown facing the wrong way:
these little bugs then cause that unpleasant biting emotion that the program is not so reliable when you come across them. i am falling in love with rhino and suddenly there is this little stupid thing but nothing is perfect in this world … i still think when a function like clipping plane is introduced it should have been already tested so it works flawlessly from day 1
I can only agree with you. That feeling of having something great at your fingertips but not being able to grab it, it’s a sensation I often get with Rhino. Come on McNeel solve these little bugs please. You are really close to have the best 3d tool for designers.