Utilities Example for ElementSensor

Also works on Polygon, BSplineCurve

Lars,

How did you manage to get the Element Sensor to work for a BSplineCurve? is there access to the ElementSensor's underlying geometry control point to pass as DPoint3D for points or poles? If you have an example showing how to implement this for a BSplineCurve it would be much appreciated.

Regards,

Mark

Yes Mark. I don't have a file on my hand right now. But you can create an elementSensor on a B-spline curve (drag and drop the element into the SD is the quickest way) and then right-click the SD node to watch the element sensor. Its property list will be similar to what you see of the B-spline curve in the element info dialog. Unfortuantely, the poles of the B-spline curve in EC Properites is quite deep to fetch but yes they are Dpoint3ds.

HTH

-Xun

Hi Xun,

Probably questions for the platform guys, not GC, but I'll ask anyway:

EC Properties:

1. Deep fetch: Is there anyway to publish/pre-fetch or de-nest etc the information that GC needs? This reminds me of Maya 2011's published Assets, which exposes/unhides variables contained in an inserted Asset for use in 'master' model. I guess, Mstn's B-Spline schema would need to allow for, and synchronise duplicate properties? Or just some pointers? Or, is it a 'simple' case of getting Platform to change the BSpline EC data structure/interface so that the DGeometry is 'shallow'?

Actually, publishing itself as a tool is interesting.

2. Can Element Sensors also be used to write to raw geometry using EC properties?  The user can already edit raw geometry properties in the Elem Info panel like x,y,z, rotation etc, and see Mstn update the element on screen. Should be easy for GC to do this as well? Element Censors :-) I can see the ability to keep raw 'non-algorithmic' geometry out of the 'script' while retaining control of some of their properties, being very valuable. Maybe even a way to drive (or interact with) 'medium-raw' elements like Feature Solids / DDD?

3. Is GC capable of writing or publishing EC Properties, to be included with the geometry it generates? There would be a lot of info that would be useful for the follow-on workflows (both manual and automated) to hook into. Even relatively simple things like just including some semantic clues i.e. naming, or embedding some local coordinate systems / LOD attributes, would help the downstream 'post-script' work a lot.

It's a pretty sure bet that some of this 'downstream' geometry would end up being used to feed other GC graphs via ES', maybe even resulting in some 'interrupted' cyclical graphs.

4. Publishing variables are often used in MCAD to help to prioritise or layer constraints solving, change propagation graphs. Constraints solving is expensive, so keeping the number of variables at the 'top' table of expressions to the published ones, seems like a good thing to do. I guess this wouldn't matter in the initial stages, where there might only be one script/graph in the model. But, as things progress, there will be inevitably be multiple graphs, tons of raw geometry/annotation etc, smart geometry from others etc, that will all need propagation management.

Catia's Knowledege Advisor seems to use a central 'expressions table' to manage/synchronise all its variables. I think most of the variables are still contained in the individual graph/objects, that may be changed by manual mods to the objects or thru Reactions. But, there is also the option to use Rules, whereby the 'triggers' are not dependent on having the all the 'graphs' active with all their contained variables loaded/live/reactive.

This 'top level' expressions table driving/triggering rules-based changes also reminds me of MS researcher Erik Meijer's 'marble diagramme'. I doubt Catia or Inventor's iLogic uses MS' Rx Framework or functional reactive programming, but a lot of the 'push'-based, asynchronous, event-based techniques associated with 'cloud computing' seem equally applicable to making dataflow apps like GC more event-aware / useful.

The 'push/pull' 'mathematical duals' style of programming is also intriguing. I wonder if it can be used to automatically reverse the solving direction, so that GC can switch solving directions based on what node is being manipulated graphically on screen by the user. Sort of like the IK/FK switching that animation packages provide these days. Or 'composably' link one database to another? Rx supports LINQ. LINQ can link to events....

Regards

Dominic

Dominic:

1. Deep fetch:  ... "Or, is it a 'simple' case of getting Platform to change the BSpline EC data structure/interface so that the DGeometry is 'shallow'?"

On GC side when we interpret EC properties, we could potentially make the EC data to be shallower but first it may confuse user and second we will have to rely on a never-could-be-perfect strategy to do so.

2. Can Element Sensors also be used to write to raw geometry using EC properties?  

I was once thinking of this and could possibly call it Element Writer (Element Sensor is guaranteed to be non-intrusive). But it was never made to the high priority list.

3. Is GC capable of writing or publishing EC Properties, to be included with the geometry it generates?

Yes, if you create notation property(s) for a feature(s), the notation property value is/are written to the underneath element(s) as EC Properties. You may check it with a simple test to create a GC line feature with notation property and see the corresponding EC properties of the line element in element info dialog.

4. I need more of your explanations of "Publishing variables".  Is it relatively equivalent to GC graph variable? Must it be the root of graph/sub-graph or it could be the leaf of a graph?

Cheers

-Xun