I don’t know how to categorize this post. Someone else can.
I don’t think I’m saying anything controversial. Rhino’s UI is clunky and feels outdated and inflexible relative to most other software. It takes only a few minutes using Unreal to say to yourself ooohhhhhh this is how panel snapping is supposed to be. My layout stays how I left it and it feels really robust and sensible.
Personal examples: I’m on a bit of a screen real estate kick since I work remotely. Why can’t we superimpose the command history on a viewport? Why can’t the layer window hide itself and pop out when you mouse over there? We waste a ton of space in the lower right. I think the viewport system is kindof old thinking. I really like how DWM works with tiling windows and space priority given to more most recently used viewports. I want more customizable hotkeys… Like in the model I want to be able to assign a hotkey to toggle a specific layer’s visibility.
I mostly am meaning instead of you guys having to write this stuff if the UI itself was open source we could implement our own solutions and then you could cherry pick the ideas that work and roll it into the commercial product.
That’d be a great project. Unfortunately, there’s way too much intertwining between the user interface and the core of Rhino right now. That, and the UI is written in a conglomeration of several UI frameworks (Windows: C++/MFC, C#/WinForms, C#/Eto) (Mac: C++/Cocoa, C#Eto).
One of the projects we’d love to do in a future version of Rhino (maybe not even in V8) is to start on a UI written in an easier-to-author programming language.
Also, the problem you mention about docking panels is tricky because we support third-party plug-ins. That makes all of the code infinitely more complex.
So, the short answer is: love the idea; it’s technically really hard at the moment.
So realistically we are talking about a new application that would use Rhino Inside? I.e. have to deal with viewport rendering and stuff ourselves. Start at zero. Like what’s the roadmap to achieve what I’m talking about if McNeel involvement isn’t in the cards in the foreseeable future?
Several successful third-party products have skinned Rhino in the past. Matrix is one example. It’s a massive undertaking. They tweak Rhino to hide all of its native UI (you can get there by hiding all the toolbars, closing all the panels, and turning off all the UI in Rhino > Options > Appearance) and then parenting the Rhino mainframe in their app.
I’m not sure Rhino.Inside is even feasible right now. I’ll let @stevebaer offer more details, but I think Rhino isn’t yet decoupled enough to let you create the UI elements that you’d need to get a basic product up and running based on Rhino. Let’s ignore everything and assume you’re starting from scratch. I don’t think you could even get to Rhino.Inside a C# application and create a document, viewports, and a command line.
So, given the route you want to take - this might just be plain not possible right now without our help.
I would not call this easy, or correct, but you could run Rhino inside a wpf, winforms, or eto app if you want to stick to .net. There’s even a viewpoint control. If you wanted to write the ui in javascript, you could run Rhino inside Electron. I imagine something could be done with cpython, but I’m not well versed there. Not condoning any of this, but is possible(ish).
Unless you fully implement everything else, and use Rhino Inside purely for the geometry kernel. If you’re inclined to develop an entire software, that is…
It would probably be a lot less work and resources to fix that problem than the huge effort of open sourcing this, so it’ becomes no one’s problem.
For for reference it would be good to see how thriving, fast and much better the development of some of the features of Rhino Layouts have being since it was made an open source project. How’s this RealDrawing thing going?
What else should McNeel open source? The fillet tool? The material editor? Openblocks? OpenClippingPlanes?
…I don’t see this being a solution. Not even close.
I tend to agree for the task of making improvements to Rhino in general. An “open source branch” to me would serve an alternative purpose as it would allow people to build new products on the Rhino platform. That said, we are still so far away from any of this being possible that this is just future tripping chat.
I’m all for that! In fact we have a few things that we would like to build ourselves. Future tripping aside, it’s also super unclear than any of them would be a clear business case. like most things 3D software I suppose.
i just wonder if constantly improving rhino which is based on historically outdated core is the most efficient way. i am not a programmer but i just can imagine as architect. once you get messy drawings it takes ages to clean them up, it is easier to start over. wouldnt it pay itself to develop rhino which would feel the same but would be buglesss and not limited to old core and in accordance with all newest coding standards. i mean russians developed their own geometric kernel from scratch not to be dependent on sienens parasolid. lets say you put down huge investment but at the end you have “rhino nextgen” wich would wipe out all limitations and pile of issues. this would cause huge migration wave from autocad and similar. this is what i hate about todays world. all software packages suffer from being built on 90s code which imposes huge limitatations. i just think this is dead end and one day nectgen soft must prevail and replace constantly upgraded autocads microststions rhinos … i just cant imagine the figure and one noones does it. develop nextgen package in parallel
Like… has anyone watched a recent zbrush video? I want to paint volume into a surface normal to it. Like push pull control points normal to the surface. I’ve done some GH that is an improvement but not practical for real work.