 | | | R: Running commands from inside scriptedOp | R: Running commands from inside scriptedOp 2005-03-16 - By Michele
Back
The realflow flowmesh importer seem to work exactly in this way, loading
a sequence of .bin files via a compiled operator, setting the geometry
(polygon, vertex, uv, weightmaps) data of the object on frame change.
Maybe you can do something similar if you know how to read .obj files.
> -- --Messaggio originale-- --
> Da: owner-xsi@(protected) [mailto:owner-xsi@(protected)]
> Per conto di Luc-Eric Rousseau
> Inviato: mercoled� 16 marzo 2005 16.33
> A: XSI@(protected)
> Oggetto: RE: Running commands from inside scriptedOp
>
>
> I think what you want to do makes sense, but the reason why I
> wouldn't see this as a task for scripted operators is that
> this data doesn't really need to be reloaded from disk and
> recomputed everytime the time changes. So for my part I
> would have written a one-shot script to loads the
> objects/plots the shape/shrink wraps/etc which only needs to
> be run if the .obj file change.
>
> > -- --Original Message-- --
> > From: owner-xsi@(protected)
> > [mailto:owner-xsi@(protected)]On Behalf
> > Of Sean Dunn
> > Posted At: Saturday, March 12, 2005 7:09 PM
> > Posted To: xsi
> > Conversation: Running commands from inside scriptedOp
> > Subject: RE: Running commands from inside scriptedOp
> >
> >
> > Well, there is a reason why I would want to run a command
> that creates
> > an object in a scripted operator:
> >
> > I'm trying to create a scripted operator plug-in that will
> load a file
> > stored on disk, per frame, that is in the .obj format, For example..
> >
> > water.0001.obj
> > water.0002.obj
> > water.0003.obj
> > water.0004.obj
> >
> > ..and then change the geometry that the scripted op is
> > applied to (just
> > a cube, for example), to mimic the topology of the loaded
> object. I'd
> > like to do things this way so I can keep everything under the object
> > level. I think it's the cleanest solution, since the
> currently applied
> > materials and other operators on the object are automatically
> > applied as
> > part of the operator chain.
> >
> > Given how XSI does things (and I acknowledge it does make
> > sense) I think
> > the best thing to do would be to write my own .obj loader (and not
> > instantiate an actual object) as an operator instead of using
> > an XSI obj
> > import command.
> >
> > The high level reason why I'm doing this is so I can export
> > fluid object
> > animations (or anything else for that matter) out of other
> > packages as a
> > sequence of .obj's and then operate on them in XSI, per
> > frame. I haven't
> > found anything out there that lets me do this.
> >
> > I'm not expecting it to be the fastest thing in the world,
> but it will
> > get the job done.
> >
> > Sean
> >
> >
> > -- --Original Message-- --
> > From: Luc-Eric Rousseau [mailto:lucer@(protected)]
> > Sent: Friday, March 11, 2005 6:58 PM
> > To: XSI@(protected)
> > Subject: RE: Running commands from inside scriptedOp
> >
> > It generally makes no sense to call commands and create
> objects in an
> > operator, although we haven't and aren't planning at this time to
> > block callings things that aren't safe in an operator.
> >
> > The point of an operator is that it is a function that is
> > called to make
> > modifications to an existing object. So given a set of
> inputs, which
> > means input connections and the parameters of the operator
> at a given
> > time, it produces a result on the object connected to the
> output. It
> > must not do anything else and have side effects elsewhere other than
> > modify the object directly connected to the output. When
> the operator
> > is evaluating, it is because XSI is running through the scene
> > graph for
> > some reason (ex. to create the opengl display), it is evaluating the
> > output object and finds that the inputs to the operator are
> > have changed
> > since the last time the operator has produced the output object. It
> > evalutates the operator to get the output result that matches these
> > inputs. It follows that for a given set of inputs, a well-behaved
> > operator will always produce the same results. If the
> operator has a
> > side effect like modifying something unrelated elsewhere,
> > it's a little
> > bit l!
> > ike pulling dish plates from the bottom of a pile while
> > someone adding
> > new plates on top, the work will never be done. Evaluating
> the scene
> > graph would loop infinitely.
> >
> > Depending on what you're doing, which you give no details of
> > below, it's
> > possible that you want a one shot deal thing, for example a
> > script that
> > runs once to create a bunch of things for depending on the values of
> > objects through time. You can loop through time and evaluate
> > the scene
> > there, you can probably hook to events, or you can use the
> > on-frame-change script which is called during playback, all
> > of which are
> > executed outside of the scene graph evaluation, and therefore
> > can cause
> > new scene graph evaluations.
> >
> >
> > > -- --Original Message-- --
> > > From: owner-xsi@(protected)
> > > [mailto:owner-xsi@(protected)]On Behalf
> > > Of Sean Dunn
> > > Posted At: Friday, March 11, 2005 1:30 PM
> > > Posted To: xsi
> > > Conversation: Running commands from inside scriptedOp
> > > Subject: Running commands from inside scriptedOp
> > >
> > >
> > > I can't be the only person who has ever wanted to run a
> > > command (in this
> > > case creating an object) from inside a scripted operator. The
> > > documentation says one can't use commands/notifications
> > during Update
> > > evaluations. XSI does actually run the command. A couple
> > > times. And then
> > > it dies a very firey death involving lots of dialogue clicking.
> > >
> > > Is there an elegant workaround?
> > >
> > > One way I could do it is to append the text of commands
> > onto a custom
> > > parameter off the scene root, and then write a script
> that evaluates
> > > that custom parameter string every frame. But, I'd rather
> keep all
> > > logic in the scope of the operator itself (or the object it
> > resides in). Is
> > > there a clean way to schedule commands to run outside the
> > scope of the
> > > Update?
> > >
> > > Sean
> > >
> >
> > ---
> > Unsubscribe? Mail Majordomo@(protected) with the following text in
> > body:
> > unsubscribe xsi
> >
> >
> > ---
> > Unsubscribe? Mail Majordomo@(protected) with the following
> > text in body:
> > unsubscribe xsi
> >
>
> ---
> Unsubscribe? Mail Majordomo@(protected) with the following
> text in body:
> unsubscribe xsi
>
>
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
|