Wish:
Bug-free direct editing. Right now cylinders that have notches in them can’t be extended, for instance. Direct editing is a great time-saver but I’m reluctant to use it because I often don’t discover the garbage it created until later/too late. This is really a bug I guess, not a new feature/wish.
Wish:
BlendSrf - ability to define continuity (beyond G0) of the end shapes to connected surfaces. Does that make sense? Right now, the ends of a blendsrf don’t align to anything (I can drag the handles, but not define a continuity.)
Wish:
Really good surfaces with more than 4 sides with continuity, somehow (maybe something automatic based on the new Sub-D technology?)
Wish:
Pascal’s ProjectObjects built-in, with improvements (ie, right now the surface being projected onto needs to extend far enough to at least cover the bounding box of the item to project - it would be better without this limitation. And history would be great.)
Wish:
Rebuild - option to retain continuity along surface edges
Wish:
Tool to modify continuity of all edges of a surface in one shot (or, all edges that are within tolerance of other surface edges? Something like that.)
Wish:
Mirror plane (similar to mirror plane in Alias Studio as I remember it.) This would be a special surface that would show a visual mirror of everything you are working on (regardless of display mode) so that you can work on half of your project and see the other half update immediately/real time. It’s not like history because it would be real-time even when doing things like direct-editing polysurfaces.
Hi Peter - thanks, I’ll get these on the heap. I don’t know about ProjectObjects being made real, especially without the need for the object extension… it is a major hacketty-hack. I know it can be quite useful, it’s just done is such a dumb way, I don’t know if there is a real-programmers way to make it better. I’ll ask (again)…
For now, I plug-in-ized it and made it quite a bit faster for complex projections…
Thanks for the improvements to ProjectObjects (and for making it work in V6!)
Btw, the drag&drop problem I mentioned earlier about the blocks plugin might be a real thing. I am not able to drop the projectobjects plugin into an existing file with geometry in it. I had to close what I was doing, reopen Rhino and then I dropped it in a fresh instance of Rhino and it was fine.
As a user I can tell you that I prefer “useful”. I’m not very interested in real-programmers way to make it better. One can imagine how that might make it less useful.
In terms of real world usefulness the deformation of objects in one axis while leaving the other 2 axis unchanged should have been a primary deformation tool long ago.
I don’t know why the thinking at McNeel lately seems to be that Rhino users are so much more competent than Rhino developers. The user can be expected to work around the limitations but heaven forbid that the developers would have to deal with that. All that is needed is to extend the projected bounding box where it misses, which is usually only at corners. This is not rocket science.
The beauty of Project Objects has been that it accurately preserves the XY dimensions of polysurfaces while deforming only in the z direction without creating dense surfaces that have inaccurate trims. So please none of that developer magic that creates dense inaccurate geometry.
It is quite useful. How else would you make something like the Rhino Logo conform to a curved surface without creating undercuts that can make it impossible to machine or mold?
It took longer to make the curvy surface than it did to project the Logo on to it.
Yep, that was what the user for whom I made this thing originally needed - - along the same lines there’s a ‘ConstrainNormal’ command line setting on FlowAlongSrf in V6 that should be useful as well.
That feature is really not very useful to anybody interested in accuracy. If you don’t care about the exact size and shape of the projected object and the distortion that Flowing introduces isn’t a concern, then it might be useful to someone. And besides, that won’t work when you need to project objects onto a polysurface.
I tried the V8 version Its nice that you have the options on the command line so that you don’t have to Enter them all every time the command is run, but the “project to bottom” option is missing. That’s an important feature . This picture shows why:
The surfaces with the green X’s are drafted surfaces. The flanges are required to be of constant thickness at the top of draft. Those are not so easy requirements to fulfill. You could project curves onto the surfaces and use ExtrudeTapered, but that results in dense unusable surfaces. The better way is make the drafted surface (planar surfaces in this example) from the flat curves and project the surfaces onto the bottom of the flange surface.
Of course the part markings can be also made by projecting surfaces that are made from flat curves (using project to top).
I could add a few more to your list
But I repeat what I wrote before:
I don’t know why the thinking at McNeel seems to be that Rhino users are so much more competent than Rhino developers. The user can be expected to work around the numerous limitations but heaven forbid that the developers would have to deal with any of it.
@jim - jim,
If the target is a box, would the ‘far side’ projection end up inside the box (or any object that presents more than one target location to the projection direction) or on the back face of the near side of the box, or on the outside of the box on the farthest away side?
Is red or blue more useful in this example if the flying saucer is a single polysurface?
I don’t really recall any situation ever coming up that PO projected to surface(s) I wasn’t expecting to be the target. I see that in V5 it would be the blue surface when project=bottom. That would be OK for me
Often I only work on the surfaces that are relevant to what I am currently doing so I don’t think I would care much if someone else would want the red to be the result.
This is on the pile - the bug track item is not public, I don’t know if that is how it has to be but for now, I’ll add your comment.
This is partly handled in that if you MatchSrf with History, a rebuild is allowed and the matching updates.
MatchSrf allows all four edges of a surface to be matched at once (MultipleMatches option) Of course it is not always possible to match adjacent edges if the target surfaces are not also G2 but it does make the attempt.
BlendSrf - ability to define continuity (beyond G0) of the end shapes to connected surfaces. Does that make sense? Right now, the ends of a blendsrf don’t align to anything (I can drag the handles, but not define a continuity.)
Actually, I’m looking for continuity beyond G0 when blendsrf-ing between trimmed surfaces. Right now, the ends are G0. See attached.ends of blendsrf.3dm (281.6 KB)
