I’ve been intensively testing Layouts and Drafting in Rhino 8 lately, I admit there’s a lot of work done, but my concern is how object - view - clipping plane - section style dependency seems to be designed, what controls what.
In another thread, I wrote about the fact that such a strong separation of Detail views and Model views causes duplication of many settings. The obvious counter-example is Revit. It’s really easy to customize each view in Revit without worrying about ruining another view.
The reality is that in the project at some point every object will be displayed/sectioned in more than one way. In my test scene, I’m trying to create several views with a different Section Style for each object. I had to do it using Clipping Planes, which meant that each group of objects with the same Section Style had to have its own Clipping Plane in each view! It is not possible for an object to have the Section Style “Custom” in one view and “By Clipping Plane” in another view. This is a huge problem.
There may be something like a Clipping Plane Section Style, but the primary should be some kind of material, or Section Style of the object, and the secondary method override by the View.
It may be difficult to show this issue but the current system is limited and complicated. Not to mention all this clicking in small menus.
Struggling a lot to override one object Section Style in just one View and not affect any other View
Starting View - take a look at Object 2, after I try to override how it looks in View 3 I would need to get back to View 1 and View 2 and create a dedicated clipping plane for that object to bring back its Section Style
I am asking all architects and not only to carefully look at the McNeel proposals on how Section Styles should work.
It seems to me that the current system might scale badly with the size of the project.
I agree this is painful, but it is what we have so far. I’m hoping to eventually have per detail section styles on layers just like we have per detail colors and visibility. We can also try other techniques to define section styles on details based on feedback like this.
Per Detail Layer Section Style will certainly help, it will not be enough to solve all cases, but this is a must-have, thank you for bringing that option.
People may organize their models differently but at least when using Visual ARQ different types of building components are on separate Layers (Walls, Doors, Windows, etc). So, in that case, Rhino Layers serve the same role as Categories in Revit – and these can be displayed very differently in each Revit View.
Default Visual ARQ Layer organization
I would also think about connecting Attribute User Keys with Section Styles, Display Color, Display Mode, etc.
People organize their Layers and decide which geometry should be on a given layer based on how it’s comfortable to work on a model. This doesn’t mean the same Layer assignments/structure are ideal to decide about display properties. These two structures may not be the same.
Trying to solve this problem might be using Object Properties together with Attribute User Text to steer Display Overrides and Section Styles in Viewports. In the Viewport Properties, I should be able to filter objects based on the Key/Value and assign all sorts of display overrides to them.
My ultimate idea is that there shouldn’t be such a hard distinction between Model Viewports and Detail Viewports and to all Viewports I should be able to assign some view preset. In the topic from the first link, I called it the View Set.
The main reason is that precise, different display settings are important for the design, and modeling stage and not only for printing/export.
I did some example using new Grasshopper components. This is a simple case with only one override based on one Key/Value match.
The main problem is that these components are not Viewport aware, they make global changes - ability to do per View Display changes would be extremely beneficial. Also, this is made in Grasshopper, not in the dedicated GUI - this solution has its strengths, it’s very flexible. I wish we could attach Grasshopper definitions to execute runtime tasks to Viewports, Named Selections, etc. - similarly, as it is possible with Blueprints in Unreal Engine. Expose something to GUI and have quick access to edit those definitions.
This solution executes live but it makes global changes (not per View), there is big performance hit (probably to be solved), needs to be present in the currently open GH definition to be executed
I don’t know if I get you right.
Some list of Keys and Values might be pre-defined in Rhino but the best would be if a user could also make some display overrides based on custom Keys and Values.
I remember once I needed to graphically distinguish curves longer than x but shorter than y - very easy to set up in Grasshopper but it would be best to have such filter incorporated into Viewport Properties so it can run in the background.
Preferably there should be some filtering logic (and, or, not, etc). Generally, even complex multiple-criteria filtering is well suited for the Grasshopper visual coding approach but the results of that need to be somewhat attached to the specific Viewports.
Once attribute-based display overrides are there I bet users will constantly ask for different criteria that would steer it. There are already more calculated text fields in RH8 but there will never be enough.
First, Jakub means, objects/parts should have all sorts of custom definable parameters, as key/value pairs. VisualArq brings it’s own custom parameters, but actually, Rhino’s attribute user text is quite the same - just key/value pairs.
In VisualArq, you can define parameters per object style
so that a new part with that style has these params automatically. However, they can also be defined per object.
Although VisualArq targets architecture, this is something useful for any industry.
Second, graphical/display options (in general) should be applicable per viewport/detail/layout, and work with definable filter rules, which can also read custom parameters.
In e.g. ArchiCAD, this is called ‘Graphical overrides’. You can have any number of such sets, and each can have any number of filter rules, affecting lots of display options for a view. This is a very powerful way of defining different looks of views. Filter out objects, give them different colors, font size, materials… anything goes.
In Revit, this is achieved by View Templates. Boils down to the same.
This whole topic is massive.
I fully agree with Jakub, that the given system is too complicated and convoluted. Not intuitive. Good point in time to think all this through very thoroughly and lay the foundations for the Rhino versions to come.
Per Detail Layer Setting with the ability to apply a Layer State to the Detail seem inline with Rhino’s Layout methodology, which is more like Autocad than Revit in a general.
This aspect could be further developed as workflow in grasshopper with access to viewports and layer states natively. There has been progress towards this already with GH1 Model Viewport Type being added, with the goal to expand viewport access in mind.
Ok, I’ll just make up a sample to see if I understand what you are after.
There would be UI for defining how objects should appear in a given viewport based on their user text. In that UI you would add
Length is greater than 2
Curve color = green
Point size = 2
Length is greater than 4
Curve color = red
Point size = 4
When a curve is drawn, then display would look at it’s user text and see if a Length key exists. If it does and the value is something that can be parsed into a number, then the value determines if the curve should be the display mode’s color, green, or red. The display does not look at the actual length of a curve, it just looks at the keys in the object’s user text list.
The same goes for points. If a Length key exists, then the size is drawn based on the value
All display mode options would be available in this UI for things that could be changed.
Is this the concept you are after? Am I missing something?
Maybe I mixed different ideas that’s why it was confusing.
One part was about new Grasshopper components that can modify the display properties but not in per Viewport manner, If I understood @Japhy , this might be possible in the future.
Another part was about something which deserves a separate topic. Embedding Grasshopper definitions to Viewports the same as Blueprints in Unreal Engine are embedded to Actors or to Levels, similar to this are Grasshopper Styles in Visual ARQ where objects are GH driven.
Grasshopper based Key/Value live listener could do quite sophisticated filtering and Graphical Overrides which would be very difficult or impossible to set up in a simple GUI.
Example of custom GH View Override:
All objects that have specific Key are checked if they are within distance to some Point in the scene.
If they are not - they are red. If they are within reach, they are checked again if they are visible from that point (then they are colored green) or covered by an obstacle (colored yellow).
This might be a useful automatic graphic override system when doing e.g. urban planning. Such logic is easy to build in Grasshopper and it would be very beneficial to have this logic embedded to only one Viewport. Users could have this as a floating viewport on different monitors while the main viewport would display just normally so regular modeling tasks could be executed. There might be a situation in which user will have e.g. 4 custom floating viewports on the side showing graphic overrides based on different complex criteria.
Embedding this complex GH Graphic Overrides to specific Views would be handy because right now only one Grasshopper definition can be displayed at the time, so currently definitions like that need to be copied & mixed into one Grasshopper canvas where other definitions might be developed.
I’ve always been hesitant on doing this due to the potential for harmful code being introduced and executed just by opening a 3dm file. This is also a reason text fields are not a free for all with regards to what can be executed. If you install a plug-in to achieve this then that is fine. The base Rhino product doesn’t really have that luxury.
Could there be some kind of switch to enable/disable this functionality?
When opening files from the internet I would have this option disabled and enable it for working in a safe environment. Grasshopper is such a goodie that it’s a pity to miss that opportunity.
In Excel, there is a warning and even a separate file format for spreadsheets with macros - probably because of the same concerns, so you know even before opening the file.
Of course this can all be done and many programs have gone down this path of providing some sort of dialog that everyone ignores only until it becomes a real problem. I’m not opposed to this idea; only pointing out that it will take a lot of careful thought.
By the way, do you think would it be possible to have per Modelling Viewport Hide Objects? Now it’s only possible to do per Detail View. Filter Key/Value based object hiding in modelling viewports would be very welcomed.
For this to be useful I think Rhino should have a better View browser first, similarly as it has for the Layouts. In programs like Revit you can have hundreds of VIews that you are sure will not be modified by accident. You can also group them to your liking and easily open/close additional.
Viewports in Rhino are more just a windows with a view, it’s easy to “mutate” them.
I’m paying close attention to this for obvious reasons. And I really appreciate the footwork that’s being done on WIP. Only recently am I actually pushing R7’s layouts to their full potential. They are very similar to AutoCAD’s but perhaps with extended functionality.
I only recently discovered that I can add a ‘Layout’ tab to the main sidebar:
This is actually way quicker to manipulate compared to ACAD.
Rhino in it’s current form gives you A LOT of options to work with. The caveat is that you more or less have to come up with your own system that works for you. Yes in Revit you just create the views… and it’s good but it isn’t perfect.
A well set-up ACAD drawing is easier to navigate for myself than most Revit projects. The same applies for Rhino.
I’ve had trouble adjusting to Rhino layouts for mainly two different reasons: 1) I’ve barely used them and 2) Incorrectly assuming that they behave closer to ACAD’s than they actually do. Management of saved views as well as a few other aspects is key to getting them to work. For someone who’s really into the project, it’s far from too much to manage, but passing a project on to someone junior or who’s not really into it… could be a disaster.
All the ideas mentioned are good ideas. Some of the features requested can actually be solved by using existing features (such as Layer States, which I’ve used extensively in AutoCAD but had no idea they existed in Rhino until recently). Layers also have ‘VP’ options exclusive to each viewport.
Don’t let the above paragraph devalue anything that’s been stated, and not nearly everything suggested can be worked around simply by mucking around with the layers. But you’d be surprised.
Making too many changes to the presentation system will make it next to impossible to open R7 files in R8. Tell me again how great Revit is when you can’t upgrade the file and also can’t access the version of Revit the file was created in?
