WISH : highlight of GH geometry in Rhino display improvement

Replies to This Discussion

Permalink Reply by David Rutten on September 1, 2015 at 8:15am

I think selected points and curves are drawn on top of everything else in Rhino. That is one way to solve this, the other is to draw them only slightly in front of where they actually are so that they'll occlude other geometry in the same place, but not geometry that is well in front. Rhino also behaves differently when the 'shade-highlight selected' options are on.

The preview of GH1 is such a mess that it's hard to see exactly what small changes would improve it. Perhaps it's time to start talking about GH2 previews as they should work, without the baggage of GH1? I certainly haven't settled on the features I'd like to include, but here's a list of things I want to try (for better or worse):

1. Components can be marked as 'construction' components, they will draw their previews in very subdued colours and possibly dashed curves/dithered meshes.
2. Components can be assigned a specific preview colour which overrides the document default. I'm not sure whether this per-component-setting should only apply to unselected previews or not.
3. Custom data can be assigned to individual objects (single curves, breps, points, etc.) that can override the default preview settings. For example a Curve can have the custom data
   ...
   PreviewThickness=3
   PreviewColour=Teal
   ...
   which would cause it to be displayed with a specific thickness and colour (again, should the colour remain teal if the curve is selected?). Different objects will be able to support different settings, so this is both very powerful and very much an expert feature.
4. The preview settings will be more advanced than just a single colour, they will support different colours for wires and meshes, thicknesses for curves/edges/naked-edges etc.

Am I making it too complicated? Am I forgetting vital stuff? Clearly there's nothing in here about drawing stuff on top of other stuff, so that may need some attention.

Permalink Reply by Olivier Suire on September 1, 2015 at 8:53am

Hi David,

My point is mainly that when geometry-generating components are selected, they should all be highlighted in the Rhino viewport, be there other geometry on top of them or not.

Regarding the preview of objects, I would seize the opportunity to prepare objects for baking :

A special "Object attributes" component could be created which would include typical Rhino attributes and user attributes (the under-used "User texts").

Any geometry-generating component would have an input for this "Object attributes" component.

In the absence of input data, the objects would have the default GH display style.

For the time being, I use the "Human" and "Elefront" tools, but I wish that management of properties was much more tightly integrated into GH.

Side question : Is there any plan to support blocks in GH 2 ?

Cheers,

Permalink Reply by David Rutten on September 1, 2015 at 2:50pm

Blocks are tricky, because they are such a tight part of the Rhino file. It doesn't really make sense to make copies of blocks the way that meshes, curves and breps are handled across the Rhino/GH boundary. There's a number of ways this can be implemented, but each has its own drawbacks:

• Grasshopper could use the names of blocks, and then whether or not the block exists and what it looks like will depend on what 3dm file is loaded.
• Grasshopper could define it's own block data type (collection of geometry and a transform), then when those instances are baked they turn into Rhino blocks.

It is also not at all clear that the memory benefits of block can be carried over to GH. All components which operate on -say- breps, would either need significant amounts of additional code to be able to deal with blocks or blocks need to be converted into Breps for every iteration. That would be either difficult from a developer point of view or very expensive from a memory/processor point of view.

What benefit are you hoping to get with blocks? Or, what problem do you think having blocks in GH will solve?

Permalink Reply by Olivier Suire on September 2, 2015 at 2:29am

Hi David,

For the funky lampshade crowd up to the Architects of Play-Doh-inspired sky-scrapers, most models are composed of truck-loads of distinct parts ; blocks are irrelevant there.

But in more down-to-earth constructions like ours , there are many repeating parts, and blocks are the best way I know to manage them.

With blocks, we are able to automatically count our parts and sub-parts, generate bills of materials, and - cherry on the cake- we can export to STEP which can be opened in parametric CAD systems like SolidWorks used by many of our sub-contractors, allowing them to make industry-standard documentation for their workshops.

Blocks will appeal to all those Architects and Engineers who design buildings which fit somewhere between the rigid floor-wall-roof designs induced by Revit and the bleeding tooth fungus-shaped corporate headquarter buildings (often shown as the pinnacle of what can be achieved with GH).

Blocks bring joy in repetition.

Cheers

Permalink Reply by David Rutten on September 2, 2015 at 4:55am

So it sounds like the second option would be best for you. The ability to create a part in Grasshopper (or maybe import it from somewhere), make a gazilion copies of that part and give each a custom transformation, then bake them to a document as Rhino blocks, so they can be exported.

There's still significant complication here with nested blocks, as that requires a single repository of block definition geometry, though potentially it would be possible to figure out whether two pieces of geometry are exactly the same and can thus both use the same block def.

If you do not expect to be able to use those blocks inside geometry components such as Intersect, Area, Closest-Point, then it would be very do-able to implement that.

Basically what I'm trying to figure out here is whether support for blocks needs to be part of the core code or whether they can be added later as just another data type. I don't expect you to tell me which :), but I do need specifics about how you plan to use blocks and what you expect them to be able to do.

Permalink Reply by Matt Gaydon on September 2, 2015 at 5:29am

Hi David and Olivier,

Just thinking about this in some-ways the current group component are some-ways towards being blocks. Admittedly they are not named and you can not remove or a replace an item within them or find out what they are made up other than in the rhino preview, but you can move them orient them etc. 

So maybe the start would be a set of option to name and edit groups etc, then maybe a convert Group to Block component of some type for baking. Maybe this is already possible Elefront or similar will have to check.

Thanks

Matt

Permalink Reply by Olivier Suire on September 2, 2015 at 8:01am

I plan to build geometry using GH, then make a "GH block" , and then apply transforms to populate the model with all the instances that I need.

It wouldn't make much sense to me to copy objects all over and turn them into blocks afterwards.

Why not treat blocks just like any other object in GH : first, they are "GH block instances", until they are baked, at which point they become Rhino Block instances ?

If it comes at the cost of not being able to perform operations like Intersect, I can live with that.

I can see these components essentially sitting on the right-hand side of my definition, just before the brand new GH2 "Bake" component ;)

Permalink Reply by David Rutten on September 2, 2015 at 12:03pm

Ok, I understand your specific need now, and Matt is right in that what is needed is an improvement of the Group data type. When Grasshopper groups are baked they need to be able to utilize existing Rhino block definitions that may already exist in the document. They would also need an additional transform field which makes populating a scene with groups a far more economical process.

Can you add a new post in the Pain Points mega discussion and link to this discussion?