Are there are components of Rhino right now that you would consider worth rewriting in future releases? Even if it might break compatibility are there any parts that you think might benefit in terms of performance or user/developer experience?
1 Like
In a world of fantasy, I would write from scratch the interface and the command system to design both as a nodal console to control multi-document sessions. I would replace instances and blocks with modeling definitions like grasshopper scripts to be process-based/parametric and versionable. I would make all user interaction traceable to improve the user experience using an intelligent modeling assistant. I would hide all the technicalities with a semantic search engine that understands a controlled natural language of Rhino. I would also replace the metadata system (userText/documentText) with an ontology system. I would also rewrite the pipeline and interaction of the viewport to natively support VR and generalize widgets such as gumball to make menus/controllers within the viewport.
3 Likes
That sounds like a great idea. I would welcome more integration between Rhino and Grasshopper models and more command-line functionality. I don’t think anyone knew back then how successful Gh will become, but now being one of the primary differatiators from other CAD tools it would be splendid to see it trickle down to Rhino level.
I would also replace the metadata system (userText/documentText) with an ontology system.
Could you expand even more on the “ontology system”? I’m not very familiar with .NET ecosystem if that’s where it came from.
It has nothing to do with .Net. It’s basically how you describe things. If you design furniture, a chair will always have some associated data that describes it, a seat, legs or something that separates the seat from the floor, a possible back, etc, and this is universal so it does not make sense that each user has to create their own chair entity to label its production, because this also prevents intercommunication and automated measurement by the software. Another way of saying the same thing is that it should be oriented to data or objects or entities rather than purely to geometry with no associated real meaning. When we model a chair we can give it meaning, but if the machine can understand that meaning many doors are opened that a modern modeling engine should open and invite to enter.
1 Like
Interesting, so a bit more like BIM? Schema for Rhino objects? It surely would be a big undertaking though, but then where would you source it from? IFC standards? All the recent research in machine learning fields makes me wonder if databases for this kind of applications are somewhere available.
Still within this imaginary scenario it would be cool to see an AI model automagically recognizing and labelling components based on such a schema…
why cannot this be achieved with current key value metadata system just with addition of geometry containers. so you put two meaningless parts together in a “container” or assembly or group and you name that meta object, the container, “seat” and then put seat into another container attributed chair. its called hierarchy and each item can have more names or attributes (not strictly lineaer hierarchy). it is all about attributes and relations between objects. i dont get the ontology approach, whats the actual benefit or point
I guess so, I’m not an architect so I’m not familiar with BIM, but I guess it would be a generalization of that concept. I don’t think it’s necessary to wait for official standardization because in the end it’s just an authority bias. Rhino has enough of a presence in many industries that it can give the tools to the developers and be standardized organically by their respective experts. When you implement these things, you tend to focus on your scope of application or use, rather than generalizing “by the art of description/labeling”, but when several people do this, what they all share in common is what I understand as standard categorization. The only important thing from this non-authoritarian approach is that by system design, the schemes do not restrict their read/write, but that the schemes are a parameter of the database queries/mutations, so that instead of having rigid table based databases with descriptive limits, you can have graph based databases with enough flexibility to match the complexity of the objects.
For example, there is no reason why tools should be exclusively focused on geometric processes, since they are not usually an end in themselves, the end is to make a chair for example. But as there is no such thing as a chair as an entity, you cannot create tools that specifically receive or return a chair. If there are several plugins that make chairs, surely each one has its own version because there is no shared furniture scheme, then in order to communicate we need a converter, instead of speaking the same language. Same way, all that information becomes exclusive of the application, only your plugin or your workflow can read and write it from code, and this could not have to work in companies with several teams or several collaborators that each one does things in its own way, and imposing these things from top to bottom generates a lot of frustration, the standards are useful. Another reason is that the current way of putting metadata is terribly tedious because without a predefined structure you have twice as much work, one to create the structure and one to assign it, and if your schemes change it becomes a disaster quickly. You also can’t make an advanced model searcher that works for all users if all users use different ways to call the same thing. Another reason is that it allows you to automate a lot of little cool things, it’s not the same a model record or report, not even its own properties, if it corresponds to the entity “Product” or the entity “Sketch”, because if you label your model with the pre-existing label “Product”, you could have for example a generic report of manufacturing cost in a Rhino panel, and if is a more specific product as a “Chair” entity, this report would have specific details for the cost report of chairs. I could go on, but one really understand this when you face the limits of the Rhino’s superficial interpretation of metadata.
1 Like
you are tackling more standardization issue than technical principality how to get there. i am talking that the software should allow absolute freedom in the objects hierarchy and organization and intelligence. the most universal way is via keys values to the objects. combined with meta objects like geometry containers, rules and relations which create any level of intelligence within your model as you wish. terrible way is revits approach when you work with predefined rigid structure or relations between objects. suddenly you are caught up in the prison of developers wish not the designer/companies etc. soft ought to offer freedom and features such as atttributes rules relations hierarchie and with all that functionality you can adapt any standardization scheme of any kind or scale.
1 Like
Speaking of Revit, it’s ironic how as Ivan mentioned it works with a rigid schema and still falls behind Rhino by a huge margin in terms of performance (one would expect flexibility follow loss of performance, but I guess bad code is just a bad code in this case).
its probably bad code too but mainly it is terrible philosophy of approach. only great idea in revit is adaptive blocks wich can be driven more than just one point. the rest is huge mistake endorsed by malignant company taking us back in time. my hatred towards autodesk is infinite as curvature of space time in the blackhole. enough about this. back to topic. rhino lacks few essential things in order to build up proper intelligence in the model. object containers (you cant select teo objects and put them in cage) , parent child relationships (tell this object is this objects parent), advanced functionality in terms of keys and values (picklists, hierarchical pickslists, etc)
I wouldn’t necessarily condemn strict schemas altogether, sometimes you want to be explicit about your types, like Dani_A mentioned it may help us standardize communication. I usually wouldn’t spare a second thought when jumping on a Revit hatewagon, but here I think BIM tools can help us a lot.
Should we really try to “reinvent” walls?
Far from understanding me. I am not against key value pairs (I don’t know a better way) nor do I think the software should restrict anything nor is it simply about standardization, it is about the design of the metadata system, or if you want how you manage 3d model databases.
You can have a universal system without sacrificing freedom without having each user have to reinvent the wheel in each model, I don’t understand why so many people in this forum are so black or white. Those containers you are referring to are what I mean by entities, with the only difference that they have a reserved word that identifies them independently of the user, so that if another container is created with the same meaning you can overwrite and customize it, but whoever reads that object will always have expected properties, so that the machine can understand the knowledge in a model. It doesn’t make sense for Rhino to define a chair entity schema or any other non-abstract entity, but what it should do is generalize what at least the “product” entity, or the “version” entity, or the “author” entity should have as attributes, so that we share a language of entities (an ontology framework) with which to improve the software in many different ways.
1 Like
i do agree standardization is essential everywhere possible but the software should be just “framework” to employ such thing. not to be built around some standardization model because software when serving as platform should be general purpose in its core
but we are then basically saying the same thing. you are talking about two elements in order to improve design. element of standardization so you dont invent the same thing, name of thing, over and over and element of protocolization so we (we and machines, people and people) understand the same meaning under the same names.