In this thread, I want to tell somebody in the McNeel team about two ideas for general large project management of Rhino and its spin-off’s.
\These suggestions are made generally for saving Rhinoceros’s NURBS functions as the main Rhinoceros’s working method, and spin architectural-prototyping-digitizing-etc facilities off to a completely new software apparatus.\
There could be possible to build an unbiased radiosity renderer based completely on per-vertex-coloured triangulative and tetrahedrative graphics representation. E. g., such renderer would make an unique 2d ray-catching mesh from a projection of 3d scene triangulation for each render, and then continuously refine it (and, maybe, refine the being rendered triangulation geometry of the scene too) according to the newly traced light paths groups.
After such “baking”, the final 2d triangulation image could be tone-mapped and exported to various formats (or even to a specific spherical panorama exploring map). Of coarse, there could be added some pre-rendering high-density bitmap texture tracing for further triangulation needs.
A new software product could be presented to the Rhinoceros community - “Mirabilihedrae”, or how do you want to call it… It should have all the “classical” geometry plotting process advantages of Rhino 5, Grasshopper, Bongo, etc - but, unlike Rhino, should be intended for working with 3d meshes, rapid prototyping facilities, 3d-scanning and other non-NURBS works.
In a few words, the Rhinoceros modelling methods could be remade separately exactly for NURBS design description, and for non-NURBS meshing and imaging in general.
Well, I can answer just now, along with adding some notes to the topic in future…
For example,
the user would be able to make HDR-like renders that are entirely scalable, instead of rasterizations that need resampling for each other randomly sized output;
the user would work with “static” model data such as non-parametrized triangulation rendering-scanning scenes - in one program, and with “dynamic” model data such as NURBS models with command history - in another;
there would be easier to manage memory-demanding projects such as architecture renders - in one certain manner, and operation-demanding projects such as industrial drawings - in another manner; both manners would have many similar features, and it would be easier to switch from one to another.
So, I just want to say that the actual user usually suffer from tons of complex procedures that are needed for managing completely different works in one program that is just overweight (this happens with Max and Autocad, for example) - while there is an opportunity to systematize such work more thoroughly.
E. g., the suggested multi-purpose systematization is intended to keep working with Rhinoceros easy - even in the age of totally digitized manufacture and media production. Practically speaking, several small Rhinos would do an extra-versatile work faster than one large Rhino can.
The trouble with your first point is that the process of producing a fully lit baked model - however it is technically done - is very time consuming. In fact, this kind of solution was something used in the 1990s - mainly because it was a way to do global illumination type lighting without using the generalised methods we tend to use today (path tracing).
The trouble with the radiosity approach is that it is O(n2). Which means, in simple terms, that as the model increases in side (and I note that you are talking about architectural scenes here - which are generally very large), the time to compute increases by a huge amount.
By contrast, modern methods are O(log n) - meaning they generally do not suffer from increased scene complexity.
So - in short. The radiosity type solution is slower, takes increasingly long as the model increases in complexity, and has to be recomputed from scratch whenever the geometry of any part changes.
In addition, a lot of memory is consumed by the data structures that are required to store lighting information on each mesh vertex. Especially if you are talking about 3d tetrahedral meshing…which is incredibly memory intensive.
This is why these kinds of solutions are mainly limited to analysis tools, where the input data is static.
You still didn’t provide any concrete examples. Tell me about someone who needs this - or would gain some kind of advantage - from having this kind of feature.
I clearly understand the problems you have described, and agree that classical complete radiosity calculation that was implemented for finite-time renders is an unacceptable solution for modern design challenges. I have been supposing that there could be some more flexible, adaptive, partial and incomplete methods of radiosity meshes and mesh-based 2d canvases processing - but if there are no such methods, then this my suggestion seems to be useless >_<.
Now, I have to answer to your question about the the people who need a separate, non-NURBS “sandbox Rhino”, smaller in spline plotting functionality than the original Rhinoceros is.
I can say that the users who may need the mesh I-O and script processing features without NURBS management are mainly the people who do not actually need Rhinoceros NURBS 3D “as it is” - e. g., those people who use it only for file reading & writing, data processing, retopologization, or only for using its plug-ins without touching the NURBS methods as they were originally invented. For example, among these users there are medical shape-representation engineers, catenary & framing engineers, interior-exterior & generative geometry architects, other CAE analysis plug-ins users, various general purpose 2d drafting geeks, 3d content managers, and so on.
So, there are general 2d-3d shape engineers, whose subject is the mathematical nature of a describable shape, and technical construction engineers, whose subject is actually is not a shape, but rather structure and material.
All my attempts of discussion on Rhinoceros destiny can be shortly described as a petition for diversification between those applications of Rhinoceros.
You can already do this - either by buying OEM Rhinos and building your own interface on it - like Matrix does - of if you just need file format I/O using OpenNurbs (like MoI)…
So what you’re saying, as I understand it, is that the functionality of Rhino should be split up into different products. How would this benefit anyone? Do you imagine that it would involve less cost to buy one of these “diversified” products.
Of coarse, I imagine that the diversified product (code name Mirabilihedrae) would cost at least half less than “original” Rhinoceros (just because it needs completely another geometry engine than Rhino NURBS needs). According to significantly smaller cost, it should be much more simple at spline plotting - while its model operation style, clickable command line approach, toolboxes, command history and snaps would stay nearly the same as in Rhino 4.0… Also, it could make some freedom from tons of adaptation to “pluggings” for the “original Rhinoceros” - and that could make original Rhino much easier (even faster and less hurried) to develop, and could make easier to use Rhinoceros WIP options ^___^.
Can you imagine Rhino NURBS 3d not sieged by Google SketchUp and Corel Painter users? I can. And I think this is definitely a way to a great benefit for both relative majority of Rhinoceros users and many McNeel developers…
(I am not a large-project manager - but I have already seen how barbarous the operation of non-NURBS Rhinoceros in Russia is (this is also applicable to any other countries where the native language is still actually not even partially ready for 3d computer graphics engineering discourse). In last 4 years I have learned that plenty of Russian users of Rhinoceros definitely no not need any NURBS math at all, and do not understand any benefit of NURBS approach to any drafting (although several people here just badly need original Rhino!). And, as the Russian CAD skills and workstyle partially can be roughly compared to French and German (since there was some CAD development in the Soviet Union - A. S. Con.\Kompas-3d, for example), then I can suppose that situation with Rhino in modern Russia is enough representative.)
In addition, I can guess that “Mirabilihedrae” spin-off would be suitable for volumetric sculpting aims (while as ZBrush is a surface sculpting system). This could be called “true 3d” - in comparison with “stereoscopic view” and “surface-based 3d modelling”.
So, the diversified low-cost “small Rhinos” would benefit many users who need only several functions of Rhinoceros interface which are very far from shape modelling. (They also could manage with all the RP & 3d-printing facilities).
This also would benefit people who want to stay with “large Rhino”, and give them more freedom from adaptation to the demands of “small Rhinos” users, which seem very specific to me.