[Sidefx-houdini-list] computing world space velocity
mobrien at pixar.com
Fri Jul 11 00:15:08 EDT 2008
> -----Original Message-----
> From: sidefx-houdini-list-bounces at sidefx.com [mailto:sidefx-houdini-list-
> bounces at sidefx.com] On Behalf Of Peter Bowmar
> Sent: Wednesday, July 09, 2008 8:32 PM
> To: sidefx-houdini-list at sidefx.com
> Subject: Re: [Sidefx-houdini-list] computing world space velocity
> I was also thinking that you might investigate the Object Position
> DOP, to import the objects' positions directly into DOPs, then Apply
> Data onto the "static" objects. That way the velocity is "native" in
> DOPs rather than calculated on points. I have no idea if this is
> appropriate for your scene though :)
I'll take a look at that.
> I do what Rangi does, if I need world space velocities etc, Object
> Merge them in then use that as the source for all subsequent work. I
> usually hide the original objects too (just turn off the Display flag)
> to avoid confusion.
That's what I ended up doing. It just took me a long time to get there.
What's strange to me about this is that we have a DOP sim that looks okay.
The TD wants to use velocity, and now it's not the sim that has to change,
but rather a new SOP network needs to be created in order to get that piece
of data. I'm not trying to be difficult, but it is rather odd.
> This has some additional advantage in that if you change your source
> objects, there is a single operator that needs updating (the Object
> Merge) which can have a note attached for other artists etc.
So, when someone is trying to learn Houdini, how do you describe to them
what a geometry container is? It seems like it's an area for computation. It
doesn't really correspond to geometry.
I'm not trying to be difficult. We are trying to learn Houdini without a
Houdini expert. Often figuring out these idioms is really difficult. Thanks
again for everybody's patience.
> I know little about Maya (except some of the API, strangely) so I
> can't help with comparisons. I do agree with Rangi's observations in
> this area too though.
> Peter B
> 2008/7/9 Rangi Sutton <rangi at kanuka.com.au>:
> > Michael O'Brien wrote:
> >> Hola~
> > Gudday.
> >>> -----Original Message-----
> >>> From: sidefx-houdini-list-bounces at sidefx.com [mailto:sidefx-houdini-
> >>> bounces at sidefx.com] On Behalf Of Rangi Sutton
> >>> Sent: Wednesday, July 09, 2008 7:17 PM
> >>> To: sidefx-houdini-list at sidefx.com
> >>> Subject: Re: [Sidefx-houdini-list] computing world space velocity
> >>> Antoine Durr wrote:
> >>>> There's a new option in the object_merge SOP in H9.1, where you can
> >>>> transform the geometry into the space of a specified object. I
> >>>> haven't tried it, but if you make yourself a world_object that has
> >>>> identity transforms, that /should/ work.
> >>> Just tried this, and you can object merge a sop back in to the same
> >>> object with using a "world" null that's at the origin.
> >>> But why do this!?! Perhaps you're only interested in the lenght of v?
> >>> That's about all I can think of.
> >> I want to use the velocity in a DOP simulation, or by a source POP;
> >> require a parameter "v". The velocity that is read from points by DOPs
> >> POPs isn't transformed, so velocity has to be computed in worldspace.
> > In both those cases I object merge into another static object with the
> > transform object set to "..", and use that to calculate v /and/ provide
> > the source for your simulations. That way the position and v attributes
> > are both in world space and it will make sense. You would contain your
> > POP network in this new object, or import back your dops here. You
> > therefore wouldn't want this object to have the transforms on it, or you
> > will get double transforms.
> >> It seems strange to me that you can't compute the velocity of an object
> >> without creating a scope outside of that object. To me, trail should
> >> some sort of option that tells it to compute velocity on something that
> >> manipulated by OBJ transforms.
> > I think that behaviour would encourage the mix of object/world space
> > attributes described.
> >> This is one of those things that just works in Maya. In Maya, I tell it
> >> inherit velocity, and I don't have to go back and compute the velocity
> >> hand. In Maya most values are available in both local and world space.
> >> someone who is trying to transition to using Houdini, it's really
> >> to grok.
> > The object / world space differentiation in Houdini is something that's
> > a bit difficult to at first, and when I'm introducing someone to Houdini
> > it's something I try to cover as early as possible. Just because it's
> > difficult to grok doesn't make it a bad thing. Once you do grok it, it
> > is both powerful and usable. In Maya I always found the lack of easily
> > switching spaces do be problematic in complicated scenes. But then I
> > haven't touched it for a while... maybe it is a better way to do things
> > Yes.. Houdini you often have to do some trivial steps by hand.. but I
> > find that also gives you loads more control when what you're trying to
> > achieve isn't trivial.
> > r.
> > _______________________________________________
> > Sidefx-houdini-list mailing list
> > Sidefx-houdini-list at sidefx.com
> > https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
Michael K O'Brien Production Engineering
Pixar mobrien at pixar.com
REMY: What is that?
EMILE: I don't really know.
REMY: You don't know... and you're eating it.
More information about the Sidefx-houdini-list