Updating clusters inside an operator

36 views
Skip to first unread message

Abdo Haji-Ali

unread,
Dec 11, 2007, 2:16:58 PM12/11/07
to X...@softimage.com
I'm writing a generator operator that generates a polymesh based on a
connected NurbsCurveList (something like CurveListToMesh). I would
like to create several clusters in the generated polymesh based on
some criteria.
The problem arises when animating the curve. In that case the topology
of the generated polymesh may change accordingly (new polygons may be
added or old ones may be removed) and the clusters become invalid.
My question is: Is there a way to update the clusters inside the
operator? According to the documentation of PolygonMesh::Set() in the
XSI SDK: "If this function is used on a polygon mesh with some
clusters and a topology change is performed, the caller is responsible
for updating the clusters", however the SDK doesn't mention a method
to do so.

Any help is appreciated,
Abdo Haji-Ali
Programmer
In|Framez
---
Unsubscribe? Mail Majo...@Softimage.COM with the following text in body:
unsubscribe xsi

kim aldis

unread,
Dec 11, 2007, 2:31:42 PM12/11/07
to X...@softimage.com
I went through this with TinyTHickness. Short answer, it can't be done.

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.

Michele

unread,
Dec 12, 2007, 3:13:57 AM12/12/07
to X...@softimage.com

I had this problem before, and I recently found a workaround.

First, add an animatable, siInt4 "null_parameter_update" parameter in your operator.
Then create an exact copy of the original operator, called "your_operator_topology_fix" - the only difference should be it's outputport type, which will be connected to "null_parameter_update".
Set the siClassifTopo classification to all parameters on both operators.
Connect "your_operator_topology_fix" to "null_parameter_update".
To enforce changes, the dummy parameter's should change its value all the time, so here's the Update that does it.

XSIPLUGINCALLBACK CStatus your_operator_topology_fix_Update( CRef& in_ctxt )
{
    OperatorContext oOp_ctxt( in_ctxt );

    long lUpdate = oOp_ctxt.GetInputValue( L"In_null_parameter_update", L"Group_update", 0 );
    lUpdate++;
    if (lUpdate > 99999998)
        lUpdate = 0;
    OutputPort oUpdate_parameter_out = oOp_ctxt.GetOutputPort();
    oUpdate_parameter_out.PutValue( lUpdate );

    return CStatus::OK;
}

This should work with multi-cluster-property-instance operators and will take care of updating any complete clusters on the object. Complete clusters need to be applied to the object after the operators have been connected, for some unknown reasons that's a requirement.

The only obvious limitation is that everytime you want to connect a new input, you need to add it to both operators, so portgroups and inputports will be evaluated properly.

Hope it helps,

Michele



2007/12/11, kim aldis <x...@kim-aldis.co.uk>:

kim aldis

unread,
Dec 12, 2007, 4:28:32 AM12/12/07
to X...@softimage.com

Interesting.

Abdo Haji-Ali

unread,
Dec 12, 2007, 4:37:23 AM12/12/07
to X...@softimage.com
On Dec 11, 2007 9:31 PM, kim aldis <x...@kim-aldis.co.uk> wrote:
> I went through this with TinyTHickness. Short answer, it can't be done.
>
> 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.
Well actually I'm not using the texture editor, I'm applying a texture
support on the clusters.
But assuming that I'm not texturing the clusters (just applying a
specific material on each one). How can I update the clusters in my
operator?

Abdo Haji-Ali

unread,
Dec 12, 2007, 4:41:23 AM12/12/07
to X...@softimage.com
Mmm... I must be missing something obvious here. How can this help me
update my clusters?
What I'm trying to do is to create a cluster for each plane in my
polymesh containing the polygons in that plane. The problem is when
the polygon count varies after applying the operator. How can I update
my clusters to contain the new polygons (or remove the old ones)?
Note that I'm not using complete clusters...

Thanks,

kim aldis

unread,
Dec 12, 2007, 4:51:53 AM12/12/07
to X...@softimage.com

> -----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.

Michele

unread,
Dec 12, 2007, 5:10:04 AM12/12/07
to X...@softimage.com

Hi Abdo, there's no way to update clusters via an operator, Xsi has to do that for you.

There's a type of cluster called "complete" cluster, that will always contain all the subcomponents of the object.

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.

Maybe I should have explained this in my previous post.

Hope it helps,

Michele



2007/12/12, Abdo Haji-Ali < abdo.h...@gmail.com>:

Abdo Haji-Ali

unread,
Dec 12, 2007, 5:20:35 AM12/12/07
to X...@softimage.com
On Dec 12, 2007 12:10 PM, Michele <miche...@gmail.com> wrote:
>
> Hi Abdo, there's no way to update clusters via an operator, Xsi has to do
> that for you.
Mmm... This is clearly a contradiction to the documentation of
PolygonMesh::Set() I mentioned earlier:

"If this function is used on a polygon mesh with some clusters and a
topology change is performed, *the caller is responsible for updating
the clusters*"

> 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.

Michele

unread,
Dec 12, 2007, 5:48:21 AM12/12/07
to X...@softimage.com
Yea, it's funny, you are responsible for updating clusters, but there are no methods to do that.
I guess there are no workarounds to update partial clusters.
I wonder if this will be doable in Xsi 7, via moondust or something else.

Michele




2007/12/12, Abdo Haji-Ali <abdo.h...@gmail.com>:
On Dec 12, 2007 12:10 PM, Michele <miche...@gmail.com> wrote:

Alan Jones

unread,
Dec 12, 2007, 6:15:18 AM12/12/07
to X...@softimage.com
Michele - this is some great info. I hear XSIBlog on calling you ;-)
Reply all
Reply to author
Forward
0 new messages