plib-users

[Plib-users] passing more than one value to psl scripts

[Gerald F. <gf...@tu...>]

Dear plib community,

I am currently evaluating several scripting engines on their 
suitability for controlling simple animations in our VR framework ( 
http://velib.kyb.mpg.de ), and psl seems to be a promising candidate 
due to its small footprint and support of massive quasi-parallelly 
running scripts. For our purposes it is necessary to pass each frame a 
   larger number of variable values (e.g., 6 float values containing 
an object's position or orientation or 16 values of a transformation 
matrix) to the scripts. I succeeded in accessing these data 
individually by writing access functions that return just one specific 
ordinate, but I could not find a mechanism to pass a complete array. 
It seems pretty cumbersome and like a lot of overhead to need 6 or 
even 16 function calls for such an initialization.
Since psl as part seems to be designed for 3D applications, I am just 
wondering whether there is a more efficient mechanism for doing that. 
Can I somehow pass an array?
If not, I've found that there is a class pslVariable which already has 
the ability to handle more than one value. If extension functions 
could return such an object, this would seem to me like a more 
flexible solution.

Thanks for any idea or comment
Gerald

Re: [Plib-users] passing more than one value to psl scripts

[Jonathan W. <jtw...@in...>]

On Thu, 2004-11-25 at 11:31 +0100, Gerald Franz wrote:
> For our purposes it is necessary to pass each frame a 
>    larger number of variable values (e.g., 6 float values containing 
> an object's position or orientation or 16 values of a transformation 
> matrix) to the scripts. I succeeded in accessing these data 
> individually by writing access functions that return just one specific 
> ordinate, but I could not find a mechanism to pass a complete array. 
> It seems pretty cumbersome and like a lot of overhead to need 6 or 
> even 16 function calls for such an initialization.

I've been pondering the same question, and the best idea I have been
able to come up with is to use an int value as a handle with each unique
value representing an sgVec or sgMat, then writing wrapper functions for
all the lowlevel sg functions. so for example if I wanted to add two
vectors I could use:

in c++

sgVec3 position;
sgVec3 offset;
sgVec3 result;

sgAddVec3(&result, &position, &offset);

or in psl

int position_handle = pslGetVec3Handle("position");
int offset_handle = pslGetVec3Handle("offset");
int result_handle = pslNewVec3("result");

pslSgAddVec3(result_handle,position_handle, offset_handle);

There would be some added overhead in matching hashes, but hopefully
most of it could be simplified to only happen once per script.  I
haven't tried this out yet, so I have no idea if it would work.
Any suggestions?

-Jonathan

Re: [Plib-users] passing more than one value to psl scripts

[Gerald F. <gf...@tu...>]

Jonathan Wheare wrote:
> I've been pondering the same question, and the best idea I have been
> able to come up with is to use an int value as a handle with each unique
> value representing an sgVec or sgMat, then writing wrapper functions for
> all the lowlevel sg functions. so for example if I wanted to add two
> vectors I could use:
>  in psl
> 
> int position_handle = pslGetVec3Handle("position");
> int offset_handle = pslGetVec3Handle("offset");
> int result_handle = pslNewVec3("result");
> 
> pslSgAddVec3(result_handle,position_handle, offset_handle);
> 
> There would be some added overhead in matching hashes, but hopefully
> most of it could be simplified to only happen once per script.  I
> haven't tried this out yet, so I have no idea if it would work.
> Any suggestions?

This is an interesting workaround solution I did not think about. I am 
pretty sure it would work. Nevertheless, to my mind psl lacks here 
some functionality to make the language truly elegant. For my current 
purposes accessing single float values is sufficient, however, a 
respective extension of psl could make scripts much more efficient 
(which would be in accordance with the library's design goals). I see 
two different solutions: either allowing arrays as return parameters, 
or the addition some additional basic data types such as vec2, vec3, 
vec4, mat2, mat3, mat4 similar to the OpenGL shading language.
It would be very interesting to hear some comments from the original 
author whether there are plans for such extensions or objections 
against them.

Regards
Gerald