But what would you expect to see once BlockEdit launches?
But what would you expect to see once BlockEdit launches?
Scaled content, just like when editing a uniformly scaled block
Hi Jorgen - and that would be essentially inert, except for attributes, is that correct?
I am not sure if that was in the english class I attended back in the day…
Joke aside, I don’t know what that means, but to me, as a user, editing a block that is 3D scaled to say 0.2 and editing a 1D scaled block that is only scaled 0.2 in it’s X axis should act the same.
I fully understand that this is a can of worms though, hence the needed warning.
Well, part of the can pf worms that I see is that say, for example, adding a fillet to a box that has been skewed by scaling into a parallelogram… would not work - could not be reverse-scaled and applied to the definition - as Rhino works now - but changing an attribute such as a color or layer or user text could.
Am I hearing “we want dynamic blocks”? Rhino blocks currently aren’t even at a baby stage. They’re in embryo stage. That’s in 2019. Not that it matters. Rhino was never an architecture/construction oriented CAD software. And it won’t fully be as long as RCPs detail views aren’t natively supported.
I mean AutoCAD dynamic blocks were rad back in 2005 as long as you had a triple quadros in SLI… /s otherwise you’re better off without that performance hog POS.
I guess part of what we are asking is to let user do weird stuff if they are ready to face potential consequences, by enabling non-uniformly scaled block edits. As you mentioned, just changing objects attributes is harmless, as well as many transform operations. Of course you can try to edit a block that has been transform-projected into a 2D space and these are the can-of-worms cases, but as long as you display a warning that editing non-uniformly scaled block instance may yield weird results, users should be fine. Or it can just fail if really weird stuff is being attempted.
Here is a test script that actually does just that - acts on any-transform block instance, and lets user fillet edge and add a box to the definition, which in turn gets updated in all instances. It is reasonably simple matrix transform play… So I assume block-edit could do the same, with its elegant UI, plus a warning…
sample file to try:
NU_BlockEdit_Sample.3dm (73.7 KB)
test_NonUniformBlockEdit.rvb (1.5 KB)
Finnaly someone said it!
Yes , for me it is so painfull that this wonderfull technology is soooo bad at rhino! I mean so bad that you even do not know what to start with!
If it is hard due to rhino math limitations then may be:
-Please add at least automatic rescale to uniform when double click on nonuniformly scaled block and back when it done and maybe it would be very usefull to keep ghosted lock-like ticks or edge lines of finall block during editing.
-Only mesh blocks ?! I am sure this is easy to implement with mesh objects only!
-Only polylines/curves blocks edit?
-Freeze objects in block during editing that cant be edited in non uniform scaled block!
I hope rhino devs will pay attention to that weak point.As i said before current block system keep many arch studios on skp+acad pipeline which is kind of primitive and boxy.
Hi Jarek - I did not try it yet - I believe you and I’ll take a look tomorrow - my point is that I can’t imagine it can be robust - imagine there is a feature near the edge - the fillet rail will be closer to or farther from the edge depending on the angle of the skew, so may impinge on the feature or not - differently in a skewed version than on the squared up one, or the fillet will be round in once case and not the other - that sort of thing.
Agree, it would be ridiculous to fillet edges in skewed block transform, can’t imagine it would be helpful. But this is just one of many cases, and in the others it would be perfectly fine (changing attributes, adding some objects to the block, moving a face, operating on really simple objects). The question is should these simple ones be banned, because the complex ones don’t make sense. I’d say NO
Hi Jarek - but adding objects - if you open a non-uniformly scaled block for editing and see the scaled objects - what happens to the added objects when the edit is finished? How does the definition absorb these? Reverse scaled?
We get into trouble as it is with solid editing- works great on boxes, but it is very easy to create a pile of junk… that is about the level of messiness, at best, that I’d expect. My preference of the moment is to suggest allowing positional and attribute changes - I’ll ask the devs to comment on anything more than that…
Some time ago, I wrote this up. Several people had contributed.
yup, see the added box sample in the above video. The “original” could stay as-is, the way current BlockEdit handles new object additions.
What the sample script does, is simply reading the xform of the transformed block, inverses it, uses that xform to put back the edited block objects to its no-transformed state, and replaces the original block definition by redefining the block in its not transformed state.
I’ll let go for now, I think there is plenty to look at if anyone from the devs team would look into it and needed input. Thanks for looking into it!
This objects adding to non uniformly scaled blocks with reverse scaling in original block seems pretty good workaround ! Then there is no need to edit geometry inside n-u scaled block if you can just create it outside and then add !
All this looks to me like we’re looking for an alternatively scaled 3dspace.
Instead of modifying the objects and the blocks themselves.
A way to manipulate the 3dspace.
Then all of a sudden we would’ve discovered the worm holes to other universes.
Hi guys - I am not trying to stand in the way of progress here, but I cannot imagine making geometry changes can be a good thing on NU blocks if there is not some significantly more sophisticated rebuild that takes place in the definition besides the scaling - Jarek, this is a reverse scaled fillet on your box example -
That cannot be a good or even remotely acceptable result, right? Users’ expectations, guaranteed, will be different than that.
Adding objects will have the same types of problems.
Hi Pascal, OK I give up!
Well I mean it sounds like what you’re really asking for is assemblies of family parts, trying to hack the “block” mechanism to achieve that is…not really going to work. I tried to do a much less ambitious version of exactly that at one point and…no it doesn’t cut it.
But it works in acad and in sketch up.
It is possible at least with meshes.
The main idea of block is PLACEHOLDERS.