I hope it makes sense.
Keep in mind that PolygonMesh::Set is really slow, especially after 50K-100K
triangles or more.
Probably it's going to be slower than anything else your rf-import plugin
does, including reading geometry datasets from disk.
This workaround slows everything down a lot more, but at least you can
disable it if you don't always need to update UVs.
Another option is to wait until Soft implements
ClusterElementCollection::PutArray or makes Cluster::IsAlwaysComplete work
with customoperators.
Or maybe someone else has found a better/simpler workaround for this
limitation...
Ciao,
Michele
------=_Part_53735_23307745.1169873704166
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div>
<p>Hi Etienne, simply setting the correct flags won't help you afaik, both for self-installed or SPDL-based operators.<br>You can update cluster property elements, but only when cluster elements don't change.</p>
<p>From the link that Adam posted:<br>"XSI currently does not fully support custom topology operators. The problem is that any cluster or cluster property will not properly update when a topology operator adds or removes points that belong to the cluster. In the worst case XSI may crash. Hence custom topology operators should only be used in the more limited scenario of objects that do not have any clusters. Once the geometry is ready it would be possible to freeze the object to remove the custom topology operators (but leave the result of their evaluation), then to add the clusters and other operators"
<br> <br>To work around this limitation, I use a (truly painful) trick.<br>Here's a "simplified" explaination:<br>- NOTE - So far this thing has proven to be safe (but slow). Please note that any mistakes done in the implementation of the technique might crash xsi.
<br>- NOTE - Use this workaround at your own risk. Remember to debug for memory leaks and implement some serious error handling routines.</p>
<p>a) Create a polygonmesh cube, delete all it's polygons and create a single 0-area triangle.<br>b) Add a complete cluster and a texture projection.<br>c) Freeze the object.<br>d) Split your operator in three operators: (1) one "main" operator that does the calculations and returns a parameter value containing <number of triangles-1>, (2) another operator that sets the geometry, (3) another operator that sets the UVs.
<br>e) Apply operators to the polygon mesh in the following order:<br>- "main" operator,<br>- an "ExtrudeComponentAxis" operator (with the "Duplicate Polygons" parameter set to true),<br>- "geometry" operator,
<br>- "uv" operator.</p>
<p>The "main" operator will write its output value into the "subdivs" parameter of the "ExtrudeComponentAxis" operator, forcing xsi to refresh the number of cluster elements based on the number of duplicated triangles (custom operators can't do that, but xsi operators can).
<br>After the "ExtrudeComponentAxis" operator has updated cluster elements, you overwrite the geometry with your custom "geometry" operator, and then fill the cluster property with the "uv" operator.
</p>
<p>All these operators will have the polygonmesh connected as input, and because of this they will be evaluated in the correct order.<br>The "uv" operator also needs the cluster as input as well as the cluster property.
</p>
<p>At this point you need the 3 operators to ble able to exchange informations and do the calculations only once (instead of 3 times) when their input connections change.</p>
<p>To do this, you'll need to have the 3 custom operators inside a single DLL, and build a linked list of customoperator instance pointers, mapped against customoperator instance UniqueNames.<br>This linked list needs to be inside the DLL global space, so everything inside the DLL can access it.
<br>Each element of the linked list will contain (1) a pointer to an xsi operator instance, (2) a CString variable and (3) a pointer to the next element in the list.</p>
<p>Everytime the "main" operator is instanced in the scene (Init), you'll add an entry in this map, set the entry's customoperator pointer to the current "main" customoperator pointer and set its CString variable to the UniqueName of the "main" customoperator instance.
<br>From within the "geometry" and "uv" operators, you can browse the pointer map, looking for the UniqueName of the corresponding "main" operator, which is located on the same geometry object. Once you find it, you can access it via the entry's customoperator pointer.
<br>You also will have to take care of deleting the linked list entry when a "main" operator instance is deleted.</p>
<p>I hope it makes sense.</p>
<p>Keep in mind that PolygonMesh::Set is really slow, especially after 50K-100K triangles or more.<br>Probably it's going to be slower than anything else your rf-import plugin does, including reading geometry datasets from disk.
<br>This workaround slows everything down a lot more, but at least you can disable it if you don't always need to update UVs.</p>
<p>Another option is to wait until Soft implements ClusterElementCollection::PutArray or makes Cluster::IsAlwaysComplete work with customoperators.</p>
<p>Or maybe someone else has found a better/simpler workaround for this limitation...</p>
<p>Ciao,<br>Michele<br></p></div>
------=_Part_53735_23307745.1169873704166--
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
