Warning: strpos() [function.strpos]: needle is not a string or an integer in /nfs/c01/h08/mnt/32378/domains/data-tribe.net/html/wework4her/index.php on line 71
trabajamos para ella !
sproadic thoughts on CAD 'history' engines 
Saturday, September 13, 2008, 10:30 AM - Maya.c++.api., Tessellations, production pipeline
Posted by Administrator
McNeel's recent and exciting announcement of its plans to enable scripting within its grasshopper feature, caused a revisit of Maya's inherent 'history' engine and its associated graph(ical)-editor (hypergraph).

Images show a possible outcome of using the Maya history engine and the corresponding node-network / graph.

Thanks to celifan of noctua for writing the Delanuay Triangulation plug-in for maya and sharing the source code.

The videos also show a custom 'node' that divides a curve into equal direct-distance divisions. The node also outputs tangents and normal at these points. No rocket science here except for celifan's node that enables constrained DT. Our previous attempts in using qhull and tetgen with Maya were implemented as run-once MEL commands unlike Celifan's which is a 'dependency node' that enables history.

A cursory overview of various parametric (CAD) engines / platforms (Microstation GC, Catia /DP /Virtools, Grasshopper, Maya etc) highlights a few common features.Each platform has its strengths w.r.t items below and therefore a natural place in the production pipeline.
1. Number of in-built operational 'blocks' that deal with geometric operations, measurement and evaluation of CAD data.
Grasshopper, Catia and GC seem to offer very CAD relevant geometric operational blocks, as also precise measurement options. Maya suffers on this end.However, Maya features fairly extensive overall support including geometry types(NURBS,subDs,and meshes), algebraic operations, rendering operations, system I/O etc.
2. Mechanism construction of logical dependencies between operational blocks.
Grasshopper promises to add script operations to make and break logical connections between blocks. GC offers a robust debugging interface as also a C-style scripting language (GC script) to achieve this. Catia uses catScript and vbScript for the same. Maya offers MEL and python whilst Virtools is uses Java.
3. Mechanism of adding custom operational blocks.
A Scripting language is one such mechanism.
One can stick a custom GC script within the dependency chain in GC. 'Reactions' are similar mechanism in Catia to trigger custom vbScript. MEL scripts can be triggered within Maya graphs with some imagination.

However, one might quickly encounter the limits of such mechanisms and might need to explore lower-level languages whilst dealing with larger amounts of data.

GC apparently supports access to lower-level C-based kernel as explained in this article by Stylianos Dristas. My guess is grasshopper would expose a dotNet / c# sdk. Catia offers a c++ SDK, but is quite expensive and probably not an easy excursion. Maya features an extensively supported (documentation, community support and production proven) python and c++ access to its engine. This allows for a possible (and easier) integration of third party code such as academicians as also libraries such as CGAL, Boost etc.
4. Robustness of 'associavity'.
Catia and GC offer well formed geometric 'associavity' whilst Maya, can produce errant results and thus failure of the history chain.Grasshopper should potentially offer the same safeguards as rhino / openNurbs core, which is typically reliable.
5. Interactivity and time per evaluative cycle.
In seemingly inverse proportion to above, Maya produces a fairly fast cycle and thus allows for interactive manipulation of large history chains and geometric information. Grasshopper also seems to fair well in this regard.

It appears the choice of a poison and focus depends on nature of design endeavor , resource constraints, familiarity etc. Nonetheless, exciting times of computationally inclined architects!

Thanks to Chikara Inamura, Nils Fischer and Cristiano Ceccato for thoughts / inputs.
7 comments ( 33 views )   |  0 trackbacks   |  permalink   |   ( 2.8 / 498 )

Cells, demi-regular tessellation et al. 
Sunday, March 9, 2008, 04:17 PM - Geometry, Tessellations
Posted by Administrator
video is in realtime
Shows the execution of MEL prototype of dividing the included area of a given input curve into smaller cells.

A free player from tradebit.com

A free player from tradebit.com

collection of recent code-sketches on areas of research interest including demi-regular tessellation, Cell division etc.

5 comments ( 14 views )   |  0 trackbacks   |  permalink   |   ( 2.9 / 462 )

Command line computers: Maya.Qhull.surface evolver.tetgen.isosurf. 
Monday, February 25, 2008, 07:41 AM - Geometry, Tessellations
Posted by Administrator

A free player from tradebit.com

A free player from tradebit.com

A free player from tradebit.com

Analytical computation, as an instrument to generate geometry and evaluate its ‘performance’, is inherently dependent on ‘meshes’ or node based geometry. The attempt on this short-term research was to understand the functioning of node-based geometry, text-based polygon file formats, types including Delaunay , Voronoi, half-space intersections, convex hulls etc.

In view of the lack of access to Maya's internal triangulation engines, the research concentrated on wrting simple translators to access external, command-line executables such as qhull,tetgen and surface evolver.Tetgen has so far proved to be most useful, in that it can be compiled into either an executable or a dll. ie. supports both standard MEL 'system' calls and c++ api calls from within Maya plugins. Further, tetgen also supports constrained delaunay triangulation.

Although resulting triangulated meshes do not support regular poly-modelling workflows, they provide interest as reference objects.They are also useful in geometric problem solving, eg: prim's algorithm.
3 comments ( 10 views )   |  0 trackbacks   |  permalink   |   ( 2.9 / 458 )

Interactive UVN transposition : Maya 
Wednesday, January 30, 2008, 06:37 PM - Maya.c++.api., Geometry, Tessellations
Posted by Administrator
videos are in real-time
Shows attempts to create an interactive tool that transfers meshes from the UVN space of a reference surface(usually flat, :. uvn = xyz) to that of another.

'Uses' (as seen in videos) relate to 'flowing' multiple components on a 'host' surface, transferring a user-generated triangulated / quad mesh unto a given surface etc.

Second video also includes the use of Maya-Qhull interface, to generate meshes.

5 comments ( 31 views )   |  0 trackbacks   |  permalink   |   ( 2.9 / 593 )

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |