Rhino 8 Development

What’s this new percentage nonsense way to calculate value of a piece of software?

In a typical product development project (a complex one) the total industrial design time is about 5% of the time/effort. Make that 0.1-1% if it’s a very te by thing. So should we just stop using good software me side of that.

Should we all just use SolidBarelyWorks for a 100% of the time of that 0.1 to 5% of the effort? Or should we use tools that allow you to create the design intent and differentiation that will help your brand/client/employer make products that are differentiated from all the me too crap out there?

G

All I’m saying is that I’d like to be able to use Rhino more in the development process. Right now, I can’t. I have to switch quite early to something else, and Rhino 7 did nothing to change that.

Unless I misunderstood you, it sounds as if you’re happy to use Rhino for just a small part of the job. And if that’s the goal of Rhino, then fine, I guess. But I thought Rhino was supposed to be a complete solution for some… and right now, attempting such a thing is a pain.

I think you bring excellent points, and I agree with your desire to make it more useful.

I’m just realistic that such massive improvement would take a development team probably 3-5X of what McNeel has now, and will only be useful for people doing Industrial design type of work. Even though I would welcome that (that’s what we do), I think Rhino could go out of business pleasing us. It’s a lousy/demanding(no pun intended by me saying this)/small market to be in.

It makes more sense to play extremely well with MCAD packages first. For example, I cannot open a Step/Parasolid Assembly change a hard to model thing in Rhino and export it back out maintaining its structure/assemblies/naming/colors intact. I want that waaaaay before I want them to build a draft-angles/fillets/shelling/Boolean Division for Chuck to have an army of typists.

Blocks are overdue and they would help everyone. Including McNeel because we could all work with much smaller files if those things were half useful.

Also working really well with world class rendering plugins like Octane and Vray should be a much higher priority than any pet projects in rendering. Same goes for a seamless integration/livelink with Blender/Zbrush/Unreal/etc.

My thinking: Let’s pick battles where we can all win.

I’m happy to pass on shelled parts of money-making designs to Fusion, Solidworks, our clients’ engineering teams or some offshore supplier.

G

4 Likes

Well, then. :wink:

-more robust booleans and overall reliability of operations
at the moment i am always tensed when i run the command if it is gonna fail again or not, get rid of all possible far from origin problems (6 still had some, probably 7 too)
-blocks
complete new way of handling them, have nesting in mind, instancing, uniqueness, hierarchies, assemblies, implement natively in gh, just inspire from other programs, there is a chance to do it all over again and in unparalled way
-constraints
constraints would open many many doors to new possibilities (parametric blocks…)
-drafting and annotations
ordinate dimensions styles, multileaders …many many more… just look at autocad and implement the features even better. rhino 7 just brought literally nothing new in this department
-dynamic, live views, section views, sections
no make 2d, select objects or depth of view, driving curve (would cover sectionviews along curve as well as basic sections and views) and direction of projection, rules (according to attributes) for which objets have what type of fills, hatches, special rules if section part is in contact with nothing make line thicker…
-enhanced BIM functionality
employ attributes heavily in any job, there are plenty ways how to enhance the functionality and use attributes for whatever organization of the model
i have complete picture how it should be but thats not for this overall suggestions thread, advanced reports from the model
-clipping of external references
been mentioned in more than one thread. it should have been in 6 already
-clipping objects
not just planes, advanced functionality in this department
-snaps to intersections and objects
curve curve srf srf crv srf
-blending with euler spiral
there is no way right now to create really smooth transition between curves, euler spiral connects two curves with matching curvature gradually
-silly stuff
you cant batch plot layouts to pdf in version 7. there are probably more silly things like this which makes look rhino like baby weak rhino.

+UI improvements (dark mode within native new modes maybe)
i think it would be nice if new version would come with cleaned tracked issues from previous version. if that is even possible :smiley:

8 Likes

GoZ.

Hi Ryan,

Whilst it’s not an official GoZ Solution - I have made a grasshopper plugin to optimize the workflow between Rhino & Zbrush:
https://www.food4rhino.com/app/chameleon

Chameleon - Zbrush Live Link Tutorial from Marc Gibson on Vimeo.

Hope this helps!

Cheers,
Marc

2 Likes

I would LOVE to see a native Rhino incremental array (on crv, between crvs, on srf, on crv on srf, etc) that doesn’t require Grasshopper or another plugin.

1 Like

Since McNell is using Cycles, better integration with Blender.

1 Like

Customize Cycles materials with Grasshopper like node in Blender is my dream

1 Like

We would love to have object-specific clipping work in 3D. This would be a game changer for us. Add my vote for this.

1 Like

I’d like a PASTE command frorm Blender to Rhino.
Also procedural textures

2 Likes

Rhino already has procedural textures…

Copy paste from Blender out does not exist as far as I know. Maybe image data.

Re the wish to have clipping by object:

If clipping can be done by objects, can we then have, as a side effect, some boolean subtraction history? I mean, if we can have objects (clipping objects) that are invisible but that can cut volumes from other objects, can we also have those objects work as part of boolean operations? That way, we don’t have to ‘cut’ out areas of objects but instead can maybe define an object as a ‘negative’ object, and anything it intersects could be cut away.

I’m not explaining this well, but basically I’m talking about Rhino having ‘negative’ objects, like IronCAD has (see this video) - that way, the subtractive object is always around and I can modify it with history to change the shape of the ‘hole’ that I’ve created without untrimming or any of that hoopla.

2 Likes

My list:
Matching Subds to nurbs surfaces
Subd Crease fade / variable crease
Subd radial symmetry
Solids as negative shapes (like this)
Better tools for solving complex patches/intersections

Some little things:
FitCrv: an option to preserve tangency at ends
MatchCrv: an option to flip crv to match (like in blendcrv)
ExtrendCrv: an option to just leave extension without the original curve
Dimensions - an option in the dimensions properties dialog to use those settings as default

3 Likes

Oh, and I’d like this script to become an official tool: Pascal’s Project Objects script. Only changes I’d make would be to get rid of point limits (but make sure escape works) and to implement history.

This! +1

Real world scenario: We are doing a perforated sheet facade, with non-uniform perforation patterning.
To boolean and maintain surfaces + render meshes of hundreds of sheets, with each hundreds of perforations - is unthinkable. Low resource clipping or ‘void’ objects that would just visually occlude a small part of the geometry would be really useful.

And as a side note: VisualARQ objects have these ‘booleans with history’ already, and they work great. Computationally heavy, but with a small set of booleans, they work nicely.

This is pretty much how NURBS polysurfaces already work. Notice here that if I boolaen difference cylinders out of a box, explode, and turn on control points, you’ll see that the geometry of the cylinders is still there. I can bring back the cylinders by running one of the untrim commands. Or, If I run ShrinkTrimmedSrf, Rhino will rebuild those cylinders to be only what is needed to make the trimmed surface.

Advanced clipping with object exclusion–like the current clipping planes–should work with anything and everything in your scene: Point objects, Curves, Surfaces, PolySurfaces, SubDs, and Meshes. It should work with Make2D and and Layouts.

Boolean with history is a valid but separate conversation.

I understand this problem and am constantly troubleshooting it. If the goal is purely visualization, I will apply the perf pattern as a texture with transparency to an untrimmed surface and it works great for rendering. If you are generating drawings for documentation, it game becomes ‘how to trim the fat’ or how to get rid of extra geometry that isn’t needed for the drawings. Take my example above - each of those plates are made up of 15 trimmed surfaces and 69 edges. I will often do away with showing material thicknesses with perf panel drawings by just using single surfaces. This makes my plates above 1 trimmed surface with 13 edges and really shaves down the file size. _SelVisible is also very helpful when getting rid of objects that aren’t being seen in a drawing. I know this isn’t a one-size-fits-all solution but my point is that I suspect negative shapes aren’t going to help you.

1 Like

Hi, dear Santa Claus…:slight_smile:

I really would like, Parametric Blocks,
A gh def could be embeed inside as a block.
As grasshopper display panel, a block could have his own accessible parameters…

So multiple block based on the same definition could be displayed on the same rhino file according their own parameters…
And it will be dynamic, for variations…

A wish but I am sure this could find many application, for users which are manipulating products with “variations”, In my case, interior design purpose

8 Likes

Boolean history does some of what I’m asking and would be useful, but in the case of objects that aren’t cylinders, there’s a lot that I can do with negative shapes than with boolean history. For instance, I can edit the shape of the negative object in any way I’d want to and it would still be a negative shape. And instead of ‘losing’ history or having Rhino misinterpret my history wishes, my ‘negative’ shape is always negative until I tell it not to be.

My goal is almost never visualization, so textures aren’t going to cut it. And I almost never produce drawings, so clipping objects aren’t very useful to me either. But negative volumes would be amazing. If I can’t get those, then boolean history might be useful.

This has my vote as well.
Some type of archiving a project [similar to 3ds Max “Save as archive”] would be much welcomed.

Saving the project as a whole, with textures, materials, Gh definition…].

I would’ve sweared that Rhino was able to save a project as an archive, until recently when I actually needed it.

3 Likes