I could I suppose, but what I really want from this is something that is 
portable. That's why I put so much effort into making this a node which could 
be local to the object constrained to the path. I'll give it some thought.

Thanks

--
Joey Ponthieux
LaRC Information Technology Enhanced Services (LITES)
Mymic Technical Services
NASA Langley Research Center
__________________________________________________
Opinions stated here-in are strictly those of the author and do not
represent the opinions of NASA or any other party.

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Stephen Davidson
Sent: Monday, July 08, 2013 3:27 PM
To: softimage@listproc.autodesk.com
Subject: Re: path constraint via ICE

Why not have a null follow the path, and have the object position constrained 
to the null?
That way you can also control the center of the scale, and the object scaling 
will
not effect the position, since it is based on the null position.

On Mon, Jul 8, 2013 at 10:49 AM, Ponthieux, Joseph G. (LARC-E1A)[LITES] 
<j.ponthi...@nasa.gov<mailto:j.ponthi...@nasa.gov>> wrote:
An update. I have managed to piece together a "constrain on path" node which 
operates directly from the local or parent object(as opposed to being applied 
from a cloud or secondary object). I currently have path constrain position and 
tangency working on a normalized path. I also have it supporting a crude 
velocity along path in units per second.

What I don't have working at this time is up vector and scaling. Apparently if 
I scale the object this affects position and is not desirable. My guess is that 
this is due to the same inversion/ transposition requirements to the matrix 
which is necessary to make the constraint position and tangency work when the 
node is applied locally to the constrained object. I just need to get the 
scaling inversion worked out I think.

I managed to get the normalization(what Paul was referring too) working through 
the Normalized U to Curve Location node but it requires a high accuracy 
level(steps) to precisely match SI's core path constraint  1:1. When structured 
as strictly normalized  its very reliable, but is also slow to process at a 
high step count.  I tried to have it  switchable between param and normalized 
modes but ran into stability issues here. What is really needed at this point 
is for the core UV To Location node to be compiled to support both param and 
normalized interpolation in real time. Not really sure why this is not standard?

If anyone has any suggestions on how to address the scaling problem, it would 
be appreciated.

--
Joey Ponthieux
LaRC Information Technology Enhanced Services (LITES)
Mymic Technical Services
NASA Langley Research Center
__________________________________________________
Opinions stated here-in are strictly those of the author and do not
represent the opinions of NASA or any other party.

From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 
[mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>]
 On Behalf Of Johan Forsgren
Sent: Thursday, July 04, 2013 12:55 PM

To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: path constraint via ICE

Thanks guys, I finally got some time to look into it yesterday, and it worked 
like a charm, someday when i get some time of i think im going to redo this 
effect but this time around make it unsimulated. It feel like I don't really 
get the inner working of strands yet, and this would be a great way to remedy 
this.  For now this works great :)

On Saturday, June 29, 2013, wrote:
If you want to have a % driven 'path' constrain as these examples are a 'param' 
type constraint, Its more complex.
If you have a null constrained in the middle, and you pull one end of a curve, 
it wont react on a param. (unless it only has 2 points) but with a % version, 
it will always stay at 50% of the length so slide along the curve.
I managed to get one working using Nest's Strandfitting compound and the fit 
bezier node, but it would be nice for this to be exposed without the faff.
Paul

From: olivier jeannel
Sent: Friday, June 28, 2013 12:57 PM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: path constraint via ICE

Even better :)

Le 28/06/2013 12:22, Edy Susanto Lim a écrit :
Hi,
If we use object as an upvector, then we don't need the Increment Rotation with 
2 vectors compound. We can just use 'Direction to Rotation' node.
-tangent as 'Point At'
-the position difference of the upvector object position to the curve position 
as 'Up Vector'

Cheers,
edy

On Fri, Jun 28, 2013 at 5:58 PM, olivier jeannel 
<olivier.jean...@noos.fr<mailto:olivier.jean...@noos.fr>> wrote:
I don't know the official way, but since the tangency will control the rotation 
on one axis, you just need to add a second Set Rotation that look UP on another 
axis.
Like this :
(Local vector set to 0, 1, 0 )

Le 28/06/2013 10:49, Morten Bartholdy a écrit :

Pretty cool Alan! So tangency is controlled in the Increment Rotation node - 
how would I control the upvector, say with another null?

To better understand how it works, how come it is necessary to key the null to 
zero rot and pos for it to work?

Morten

Den 26. juni 2013 kl. 16:45 skrev Alan Fregtman mailto:alan.fregt...@gmail.com:
http://s3.darkvertex.com/hlinked/ice/ICE_example_kinematics_pathOrCurveUConstraint.png

Maybe something like this? You may need to do more to deal with the upvector 
better if your curve complexity is intense.


On Wed, Jun 26, 2013 at 10:34 AM, Ponthieux, Joseph G. (LARC-E1A)[LITES] < 
j.ponthi...@nasa.gov<mailto:j.ponthi...@nasa.gov> > wrote:
Is there a way to perform a path constraint using ICE?

I'm certain that it can be done but I can't find a task or tool prepackaged to 
do this.


Thanks

--
Joey Ponthieux
LaRC Information Technology Enhanced Services (LITES)
Mymic Technical Services
NASA Langley Research Center
__________________________________________________
Opinions stated here-in are strictly those of the author and do not
represent the opinions of NASA or any other party.







--
Edy Susanto Lim
TD
http://sawamura.neorack.com



--
Sent from my fax machine.



--

Best Regards,
  Stephen P. Davidson
       (954) 552-7956
    sdavid...@3danimationmagic.com<mailto:sdavid...@3danimationmagic.com>

Any sufficiently advanced technology is indistinguishable from magic

                                                                             - 
Arthur C. Clarke

[http://www.3danimationmagic.com/3Danimation_magic_logo_sign.jpg]<http://www.3danimationmagic.com>

Reply via email to