hi !

i want to set up something like a relax mesh, which does a reprojection to the original shape.
because of that i want to raycast to the unmodified shape of the mesh. is the only way to
do that, having a duplicate ? there are lots of cases where it would be nice to have
the ability to have the geometry (not components) cached as an attribute , or a similar mechanism.
that would allow us to use ops which have a geo input, and caculate values from another region of the stack.
or am i missing something ?

thanks in advance,
chris

Perhaps you could set up a non-simulated tree to store the unmodified position of each point in a custom per-point attribute. Then either freeze this tree, or make sure it’s always at the bottom of the stack. You can then grab the original attribute values from any other ICE op.

no, for the raycast node you need the geometry input ...

Ah, sorry, missed that. Are you sure you need to raycast though? If you’re simply interpolating between positions or locations it might be possible, or is there more to it?

i thought xsi is doing his relax feature by reprojecting the relaxed vertices
to the unmodified shape, which requires raycasting. dunno if you can get
an similar result by interpolating anything.
for me it was a theoretical case for the use of the raycasting to a unmodified
shape of the same geometry in the current frame and in my feeling duplicating
was not so nice.

Christian,

I think it might be possible to pull it off like this:

When you calculate your initial mesh relaxation, do not write your results back directly into the PointPositions. Rather store them in a new ICE Attribute.

That way you can still raycast against your unmodified mesh in the next step.

Then as the last step write out you results back into self.PointPosition.

Cheers,

Martin

yap… that’s what I would have recommended as well.

that was also my theoretical idea , but:
you´ve to raycast along the normal of the modified mesh.that means you´ve to calculate the normals by yourself . i do that by cross prod the neighbor edges, and average it.(polygon normals).that is easy if you only have triangles, but with polygons you have so many special cases, and ice is not providing all the necessary info (like neigbor polygons and which points
belong to it ...)
i can workout something that´s somehow working but it´s not an exact solution, like if you
let xsi calculate the normals by itself, which is the case if you use a copy of the mesh.

Ah all right, I didn’t think about that.

In that case you need to take a small detour:

- store the original pointPositions in a new Custom ICE Attribute (e.g. named ‘origStore’)
- do your smooth algorithm and store in to new ICE Attribute ( e..g ‘smoothStore’)
- set Point Positions to ‘smoothStore’
- retrieve Normals and store them into new ICE Attribute ‘smoothedNormals’
- set PointPositions back to ‘origStore’
- do your raycasting from ‘smoothStore’ along ‘smoothedNormals’

I got curious and tried it out on a randomized torus - check out the attached scene. ;-))

Cheers!

Martin

	Attachment
d109fab48d176ab3de80e3ebd4327df2.zip

thank you ,after i had thought about the generation of the normals,
banging my head on the wall, i had the same solution.
it had to be easier, sometimes it´s better if you do something else, and
don´t think about your problem - and if you get back on it, it´s much easier ;-)

cheers !!!

chris

ps:  got luck solving the udm thing ?

Yeah, it’s always like that, is it… ;-))

No , I’m quite certain that the UDM thing is not possible right now.

My gut feeling is that it might be related to the way the multi-threaded ICE graph is evaluated in relation to the rest of XSI. Probably the same reason why WriteICEAttribute() is not exposed in the SDK in the first place…

Cheers,

Martin