Any help is appreciated,
Abdo Haji-Ali
Programmer
In|Framez
---
Unsubscribe? Mail Majo...@Softimage.COM with the following text in body:
unsubscribe xsi
There's also issues around texturing if your operator changes its poly count
as a result of changes in its inputs. You can flag parameters that may
change the geometry's poly or point counts and texture projections
subsequent to your op will update but if one of the inputs affects it you're
in trouble. It'll cope if the poly count falls from what it was when the
projection was applied but if the poly count increases then a whole section
of your geometry won't get textured. Better, it'll crash the texture editor.
So the short of it is, your generator op will be fine so long as you don't
need to texture it. This is a huge shortcoming in my view, what models does
anyone build that don't need texturing? I've shelved a whole bunch of
plugins as a result.
Interesting.
Thanks,
> -----Original Message-----
> From: owne...@Softimage.COM [mailto:owne...@Softimage.COM] On
> Behalf Of Abdo Haji-Ali
> Sent: 12 December 2007 09:37
> To: X...@Softimage.COM
> Subject: Re: Updating clusters inside an operator
>
> Well actually I'm not using the texture editor,
[kim:-]
Possibly not, but anyone who subsequently does will have a crash. It would
appear that the cluster is remaining at its original size but the editor
thinks it's bigger, probably by inspecting the geometry, and is crashing
because it's overrunning storage bounds.
> But assuming that I'm not texturing the clusters
[kim:-]
I wasn't really referring to textured clusters - XSI doesn't actually do
that anyway, it applies projections to the mesh even if you've selected the
cluster - I was talking about uvspaces, which are clusters.
[kim:-] > (just applying a
> specific material on each one). How can I update the clusters in my
> operator?
[kim:-]
You can't. You'll need to apply a second operator to do that and you'll need
to have your primary operator send any size change information to the
cluster update operator using another output port.
> There's a type of cluster called "complete" cluster, that will always
> contain all the subcomponents of the object.
Problem is my clusters are not complete. Each one contains a subset of
the polygons (components) of the original polymesh.
> Unfortunately, simply using PolygonMesh::Set() is not enough, you will have
> to enforce cluster updates with the siClassifTopo flag.
> Then there's another problem: only new parameters can receive the
> siClassifTopo flag, so what if your operator is driven by multiple-control
> objects?
>
> You create a new parameter with a dummy operator that causes (topology +
> cluster) updates to the original operator. This 2nd operator will have the
> same portgroups and connections of the first operator, so (I suppose) Xsi
> should be able to evaluate everything consistently.
OK, I think I understand it now :)
Still my question stands though: Is there a way (even a workaround) to
update partial (not complete) clusters based on a given criteria?
Thanks a lot for your help, Michele.
On Dec 12, 2007 12:10 PM, Michele <miche...@gmail.com> wrote: