Tested out Viz Pro some over the new year. Nice work development team!
Even as a work-in-progress, Viz functions just as expected and already adds some value and utility to the SKP platform beyond what can be achieved with the task or operation oriented plugins traditionally available for SKP.
I am a 6 year Grasshopper for Rhino user, 3 year Solidworks user, 2 year Sketchup User, and have tried out Dynamo, for Revit. Viz Pro might not have the UI polish or exotic components built yet, but the core parametric functionality is very much there. Viz is more parametrically capable than Solidworks right now hands down. Viz has equal paramatric capability to Revit, whether using Dynamo or just building parameters into vanilla Conceptual Massing Components. While there is no competing with the 6 or 8 years of development time Grasshopper has had, Viz already has 70% of the core parametric functionality. Amazing. and its only in early Beta! Im going to have to buy this plugin for myself if not for work as well.
Wish list of improvements as development rolls along:
-analysis nodes for all major primitive geometry types (tangent frame, curvature degree, segment lengths, srf area, volume). Flexibility of input data types is always helpful here. T value, pt, uv are all invaluable in different modeling situations. Analysis for almost all primitives in Grasshopper take place in their own bespoke components in the analysis tab. Viz seems to be baking some of this information into the output of many of its primitives. For instance, line through multiple points in Viz outputs the line, but also tangent frames at the t-value for each point used to construct it. If this happened for all measurable parameters on all geometry primitive nodes, there might not actually be a need for an analysis tab as all of that information would be contextual. Whatever UI form it takes, some degree of geometry analysis is a must for calling the tool set complete.
-wider variety of ways to generate all primitives in Viz. For instance, vectors can currently only be defined by two end points. A vector primitive node that used pt, direction, and length would have a lot of utility. Right now Move requires a vector input, and creating a vector requires 2 end points; so using Move effectively requires 2 point inputs. If the translation is simple and only in one axis you can just create these end points by modifying the base point XYZ components, but if the translation is not orthogonal, you end up in a catch 22. The end points required to make a vector used to move an object in a non-orthogonal direction can only be derived from a vector or line that is already in hand. Another way to approach this would be to build the Move node to accept a broader variety of input data types. For instance, move could also be specified with just a base point, normal, and translation distance.
-Solving for interpolated geometry conditions is a significant challenge right now. Some modeling programs address indeterminate geometry with applied constraints; no matter how model entities flex, they still maintain constraints such as point/line/line intersection, line/point normal. This is how Solidworks operates. Grasshopper operates by giving you access to all of the metadata of the model primitives through the analysis tab, and allows users to build up these geometric relationships of its associative primitives off of those analysis tab metrics. Viz seems to be going the more bottom-up approach like Grasshopper. Critical functions to see here in the final Viz build would be Boolean tests for inclusion of points within all primitive types, point intersection output for line/line or line/surface, and line output from intersection of surface/surface. Things like that.
Imma stop there, but this is obviously a very exciting tool.
Matt
