Re: [CPP] Storing data in a compileOp
| Date : Mon, 12 Dec 2005 14:54:55 +0000 |
| To : XSI(at)Softimage.COM |
| From : Alan Jones <skyphyr(at)gmail.com> |
| Subject : Re: [CPP] Storing data in a compileOp |
Thanks for your help.. That's not what I'm trying to do. I'll put it from the ground up so it will hopefully make sense.
It's for feathers in this case. My plan is to have a mesh and a second copy of the mesh - I'll call them base and cage meshes. The cage mesh will be approximately a push of the base mesh ( though it doesn't need be - could be set as you like). The important bit here is that they are topologically (is that even a real word?) identical. You'll then place your objects to be constrained near the surface of the base mesh. The constrained object will need to store a pointLocatorData (the XSI format for the closestLocations thing) and a vector for it to use in later lookup. The line that goes from the closestPoint of the base mesh to the equivalent point ( i.e. the center of polygon 3214 or whatever) on the cage mesh. Changes to this direction will be used to reorient the constrained objects and movement of the point on the base mesh will be used to reposition the constrained object.
For this to work I'd need to know the initial relative positions of the base and cage mesh. Ideally I'd like to store a copy of the Geometry (i.e. the XSI geometry class object) but I've resigned myself to being unable to do this and so will just have extra copies of the mesh for this. I would store the verticies, but then I can't do a lookup using the pointLocatorData which defeats the point. ooo actually I could just store the initial direction vector in the compiledOp of the constrained object like everything else - sweet - ok that's the problem sorted if I can get a good permanent storage solution.
So the other things I need are the pointLocatorData and the position vector that's in tangent space for each one. If I did use a userdatablob would it create a performance impact by the time I had thousands of constrained objects? Though by performance impact impact I mean compared with some way of storing the data in the custom operator. The performance doesn't have to be great as I can just have a group to hide most of the feathers during animation - it just has to not be so ridiculous that rendering will become impractical. Worst case scenario I can use parameters for both of the vectors - though I still really need to store a binary pointLocatorData and have it remain between saves. Though once that's solved I may as well use a struct with the vectors as well.
Thanks for any ideas.
Cheers,
Alan.
On 12/12/05, Guy Rabiller <guy(at)alamaison.fr> wrote:
> ../.. will this data persist between saves? ../..
No. Your class is deleted when the Operator is deleted, so everything 'disappear'.
> ../.. I've been assuming all this time that init is
> called on creation and term on deletion. Is that
> the case or is it called everytime I load up the
> scene as well? ../..
When your load up the scene, the Operators are created by XSI, so you've been assuming right.
> ../.. Was hoping to avoid a blob due to the number
> of simultaneous copies I'll be using of this and I'd like
> to try keep setup as simple as possible ../..
The setup or the coding ? :-)
Just to be sure I understand what you are trying to do:
You have 2 mesh objects, and you want to Constraint one object to the second object, so that one vertice of the Constrained object is at a certain distance and in the normal direction of one vertice of the Constraining object ? Or do I have all wrong ?
Still it's unclear why you would want to call your class/operator methods/functions from outside the operator.
--
guy rabiller | 3d technical director (at) LaMaison
Alan Jones a écrit :Hi Guy,
Thanks for that - just to check I've followed - I have my operator class and it stays as is - then I just use it to create an pass data through to my other class which has any additional functionality I want?
Seeing this position is the offset I thought I may want to change it to whatever the current difference is. hmmm actually I just realised something - I've been assuming all this time that init is called on creation and term on deletion. Is that the case or is it called everytime I load up the scene as well? i.e. will this data persist between saves?
Cheers,
Alan.
On 12/12/05, Guy Rabiller <guy(at)alamaison.fr > wrote:
> ../.. The data should persist until I
> delete the compiledOperator. ../..
This should be automatic, as long as you use a class for your compiled operator rather than directly using the callbacks.
First create a Class wich has the 3 members Init/Update/Term with similar arguments as of the callbacks.
Then when in the operator Init callback, create a new instance of your class then
CYourClass* pYourInstancePointer = new CYourClass();
inCtx.PutUserData( (CValue::siPtrType)pYourInstancePointer );
pYourInstancePointer->Init(inCtx);
In the Update and Term, retrieve your pointer:
CValue::siPtrType pUserData = in_ctx.GetUserData();
CYourClass* pYourInstancePointer = (CYourClass*)pUserData;
and either
pYourInstancePointer->Term(inCtx)
or
pYourInstancePointer->Update(inCtx, outPort)
Now your Class can contain any public or private members/properties, and it will be persistent until you delete the operator.
> ../..I'm making a customOperator that will be working ../..
I meant why would you want to call the function from outside of your Class/Operator ?
--
guy rabiller | 3d technical director (at) LaMaison
Alan Jones a écrit :Hi Guy,
The data should persist until I delete the compiledOperator.
I'm making a customOperator that will be working as a constraint and I want to store the initial position of the point being constrained relative to another point (using pointLocatorData and a vector in tangent space) so I want to store both of those pieces during the init function. Then later I was to grab those - check the changed position of the point it's relative to and figure out the new location.
Cheers,
Alan.
On 12/12/05, Guy Rabiller <guy(at)alamaison.fr > wrote:
> ../.. I'd like to store some data (a vector)
> in my compiled op for it to reference later ../..
Define 'later' ?
How 'far' the data(s) should be persistent ?
> ../.. is there a way to call my own functions on the class ../..
Why would you do that ?
--
guy rabiller | 3d technical director (at) LaMaison
Alan Jones a écrit :
> Hi All,
>
> I'd like to store some data (a vector) in my compiled op for it to
> reference later - though I don't want the user to see it.
>
> I've looked at the init function - which seems like a good enough
> place to start, but can't seem to find a nice place to keep it. Is
> adding my own variables to the class going to break anything? or is
> that how I should be doing it?
>
> It might be nice to be able to change it from a command too - is there
> a way to call my own functions on the class if I add them or is
> update, init and term or I can really work within.
>
> Thanks for any help.
>
> Cheers,
>
> Alan.
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
--- Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body: unsubscribe xsi
--- Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body: unsubscribe xsi
- Follow-Ups:
- Re: [CPP] Storing data in a compileOp
- From: Guy Rabiller <guy(at)alamaison.fr>
- Re: [CPP] Storing data in a compileOp
- References:
- Storing data in a compileOp
- From: Alan Jones <skyphyr(at)gmail.com>
- Re: Storing data in a compileOp
- From: Guy Rabiller <guy(at)alamaison.fr>
- Re: Storing data in a compileOp
- From: Alan Jones <skyphyr(at)gmail.com>
- Re: [CPP] Storing data in a compileOp
- From: Guy Rabiller <guy(at)alamaison.fr>
- Re: [CPP] Storing data in a compileOp
- From: Alan Jones <skyphyr(at)gmail.com>
- Re: [CPP] Storing data in a compileOp
- From: Guy Rabiller <guy(at)alamaison.fr>
- Storing data in a compileOp
| DATE: | << | >> | THREAD: | << | >> | INDEX: | Main | Thread |
|---|
- Previous by Date: RE: Launch Time investigation
- Next by Date: RE: Launch Time investigation
- Previous by Thread: RE: Launch Time investigation
- Next by Thread: RE: Launch Time investigation
- Index(es):
| Search the XSI List archives here or use the advanced search form to search across mailing lists. Searching help is available. |