plib-users

Re: [Plib-users] Where's the documentation

[LAVIGNE,ERIC <la...@uf...>]

Try this site:
     http://plib.sourceforge.net/whats_inside.html

You should understand in advance, though, that PLIB documentation 
isn't very easy to understand. Read the appropriate section of the 
above webpage. Look at the example programs that come with PLIB. 
Both of those will help, but you'll probably still need to ask 
questions on this list.

Good luck.
Eric

On Fri Dec 03 11:04:05 EST 2004, Adam Courchesne 
<ajc...@ho...> wrote:

> I downloaded the "Example and documentation" but there was no 
> documentation included in the tarball.
> :-(
> 
> ============================================================
> Adam Courchesne
> ajc...@ho...
> "There are 10 types of people in this world, those who know 
> binary and those who don't."
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading 
> now. http://productguide.itmanagersjournal.com/
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
> 
> 

[Plib-users] Where's the documentation

[Adam C. <ajc...@ho...>]

I downloaded the "Example and documentation" but there was no documentation 
included in the tarball.
:-(

============================================================
Adam Courchesne
ajc...@ho...
"There are 10 types of people in this world, those who know binary and those 
who don't."

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

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

[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

R: I: [Plib-users] triangles from branches

[Paolo L. <p.l...@ci...>]

> -----Messaggio originale-----
> Da: pli...@li... 
> [mailto:pli...@li...] Per conto di 
> Paolo Sacconier
> Inviato: domenica 7 novembre 2004 14.39
> A: pli...@li...
> Oggetto: Re: I: [Plib-users] triangles from branches
> 
> 
> Paolo Leoncini wrote:
> ...
> > Yes, I did it in the last six months. I'd like to make it 
> public after 
> > a generalization and cleaning of the code.
> 
> 6 months? woah! Seems an hard task! ;)

Yes it is when you want to implement a real life case (mesh order of 1M
vertices and 10k leaf objects, dynamics world order of 10 bodies, 100
contacts) of some industrial interest.

> 
> > I attached some code but was blocked by the list - just 
> tell me where 
> > to send it. At the end of the file there's the actual 
> 'entry point', 
> > i.e. given a node name load all the subtree leafs' geometry into 
> > corresponding ode trimeshes. There's a number of utilities 
> you could 
> > find useful for your ambitious task. Among leaf data the only to 
> > actually duplicate is indices (shorts in SSG, ints in ODE) 
> - the rest 
> > is a pointer to SSG vertices/normals structures.
> 
> We managed to fix our code, but if I'll fall in trouble again 
> now I know 
> whom aks for help.
> If anyone would like to see it jusk ask. Development is closed since 
> it's for a university course, but the code is under the GPL.

There's a site where one can post pieces of source code to let other
look at it - can anyone recall the address?

> 
> ...
> > Don't expect reliable collisions between trimeshes, at least for 
> > dynamics. Keep the gravity low, and use a very small step. Use the 
> > Quickstep instead of the WorldStep since with many contacts 
> the last 
> > quickly become unusable and sonn get stack overflow.
> 
> I noticed some trimeshes problems, so I ended up using planes, I was 
> lucky it's convex obj...

Look at James Dolan's patch
http://q12.org/pipermail/ode/2004-August/013632.html (not yet included
in a ODE distribution) which includes a perfectly working trimesh vs.
plane collider - it helps a lot and it's something incredibly missing in
ODE.

> I seem have a deep knowledge of the ode lib, are you involved in it's 
> development?

No, my knowledge remains at "user" level. But I really red the ODE
manual word by word. 

> > Furthermore don't underevaluate a hidden aspect: lasttransformation 
> > are
> > *important* for ODE trimeshes. I included my
> > update_trimesh_lasttransformation, which should be first 
> called with a
> > dSpaceID and a null body. Then it will recursively apply the proper
> > action on the trimesh data for each space's trimesh. It is 
> not called in
> > any place into the code excerpt, and you should call it after the
> > simulation step.
> 
> Sincerely I don't know what a lasttransformation is. ^^;

It is the mechanism to tell ODE about the "movement history" of a
trimesh (temporal coherence). Things go much better with trimesh when
you supply this information back to ODE.
This is a sample code to update the trimesh position/orientation after
the simulation step:

		const dReal *R = dBodyGetRotation( b );
		const dReal *pos = dBodyGetPosition( b );
		dTriMeshDataID TriMeshData = ...your pointer to trimesh
data;
		double bodyTransformationMatrix[16] = {
	
R[0],R[1],R[2],0,R[4],R[5],R[6],0,R[8],R[9],R[10],0,pos[0],pos[1],pos[2]
,1
		};
		dGeomTriMeshDataSet( TriMeshData,
TRIMESH_LAST_TRANSFORMATION, (void *)bodyTransformationMatrix );

> > Please feel free to contact me personally for further 
> hints, there are 
> > lot of them.
> 
> Probably I will!

You're welcome.

> > Good luck -
> 
> Thank you
> --
> Paolo Sacconier

Greetings -

Paolo Leoncini

Re: I: [Plib-users] triangles from branches

[Paolo S. <ax...@ti...>]

Paolo Leoncini wrote:
...
> Yes, I did it in the last six months. I'd like to make it public after a
> generalization and cleaning of the code.

6 months? woah! Seems an hard task! ;)

> I attached some code but was blocked by the list - just tell me where to
> send it.
> At the end of the file there's the actual 'entry point', i.e. given a
> node name load all the subtree leafs' geometry into corresponding ode
> trimeshes. There's a number of utilities you could find useful for your
> ambitious task. Among leaf data the only to actually duplicate is
> indices (shorts in SSG, ints in ODE) - the rest is a pointer to SSG
> vertices/normals structures.

We managed to fix our code, but if I'll fall in trouble again now I know 
whom aks for help.
If anyone would like to see it jusk ask. Development is closed since 
it's for a university course, but the code is under the GPL.

...
> Don't expect reliable collisions between trimeshes, at least for
> dynamics. Keep the gravity low, and use a very small step. Use the
> Quickstep instead of the WorldStep since with many contacts the last
> quickly become unusable and sonn get stack overflow.

I noticed some trimeshes problems, so I ended up using planes, I was 
lucky it's convex obj...
I seem have a deep knowledge of the ode lib, are you involved in it's 
development?

> Furthermore don't underevaluate a hidden aspect: lasttransformation are
> *important* for ODE trimeshes. I included my
> update_trimesh_lasttransformation, which should be first called with a
> dSpaceID and a null body. Then it will recursively apply the proper
> action on the trimesh data for each space's trimesh. It is not called in
> any place into the code excerpt, and you should call it after the
> simulation step.

Sincerely I don't know what a lasttransformation is. ^^;

> Please feel free to contact me personally for further hints, there are
> lot of them.

Probably I will!

> Good luck -

Thank you
--
Paolo Sacconier

Re: [Plib-users] triangles from branches

[Paolo S. <ax...@ti...>]

McEVOY, Nick wrote:
> Paolo Sacconier wrote:
> 
>>Unfortunately I've still problems, since somethimes the ssgInsect 
>>returns no collisions where shold be some... Is it possible that is 
>>because I have a shere smaller than the triangles I want to collide to?
> 
> 
> Its hard to say what is the problem without seeing your code, but
> I do vaguely recall I had the case where if I called getBSphere()
> the size & position of the bounding sphere was incorrect!?
> See http://sourceforge.net/mailarchive/message.php?msg_id=1153817
> 
> I never did work this problem out.  I ended up hard coding a known
> bounding sphere size and using ode to get the objects position.
> Then I fed my correct sgSphere information to ssgInsect().
> 
> Cheers,
> Nick

Finally we menaged to collect triangle data from ssg entities to create 
ode geoms, so I gave up with the ssgInsect.

Thank you anyway.
--
Paolo Sacconier

Re: [Plib-users] Building on Mac OS X

[Bernhard W. <bw...@ca...>]

> I've been trying to build pLib 1.8.3 on Mac OS X but it's not been
working.

have a look at the archive of this list. You will find a commentary of Steve
on exactly this topic. You will have to modify js.cxx and js.h slightly by
defining a constant _JS_MAX_OX_DEVICES and then putting this constant
instead of the variable kNumDevices. There is a problem with the allocation
of memory the way that js is implemented at the moment.

Hope that will be of help,

Bernhard


>
> The following is the Terminal output.
>
> Making all in js
> source='js.cxx' object='js.o' libtool=no \
> depfile='.deps/js.Po' tmpdepfile='.deps/js.TPo' \
> depmode=gcc3 /bin/sh ../../depcomp \
> g++ -DPACKAGE=\"plib\" -DVERSION=\"1.8.3\" -DSTDC_HEADERS=1  -I. -I.
> -I../../src/util    -g -O2 -Wall -c -o js.o `test -f js.cxx || echo
> './'`js.cxx
> In file included from js.cxx:23:
> js.h:97: error: data member may not have variably modified type `
>    io_object_t[jsJoystick::kNumDevices]'
> make[2]: *** [js.o] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all-recursive] Error 1
>
>
> configure works fine but I can't build it. Is there a way to bypass
> js? I don't have a joystick anyway.
> -- 
> <Arthur/>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
>

[Plib-users] Building on Mac OS X

[Arthur W. <ar...@gm...>]

I've been trying to build pLib 1.8.3 on Mac OS X but it's not been working.

The following is the Terminal output.

Making all in js
source='js.cxx' object='js.o' libtool=no \
depfile='.deps/js.Po' tmpdepfile='.deps/js.TPo' \
depmode=gcc3 /bin/sh ../../depcomp \
g++ -DPACKAGE=\"plib\" -DVERSION=\"1.8.3\" -DSTDC_HEADERS=1  -I. -I.
-I../../src/util    -g -O2 -Wall -c -o js.o `test -f js.cxx || echo
'./'`js.cxx
In file included from js.cxx:23:
js.h:97: error: data member may not have variably modified type `
   io_object_t[jsJoystick::kNumDevices]'
make[2]: *** [js.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1


configure works fine but I can't build it. Is there a way to bypass
js? I don't have a joystick anyway.
-- 
<Arthur/>

Re: [Plib-users] Re: link plib into code on mac osx

[Bernhard W. <bw...@ca...>]

On 29 Oct 2004, at 14:14, Steve Baker wrote:
> I think there is something stranger than this going on. Probably,
> the compiler puts an automatic 'extern "C" { ... }' around header
> files that it thinks are lacking that for some reason beyond the
> compiler writer's control - but gcc/g++ doesn't do this for
> Windows or Linux - so why would it do that for the Mac?
>
> I think we need to understand what's going on a bit better before
> we start installing PLIB in non-standard (for PLIB) places because
> if Mac users start relying on the headers being in some bizarre
> location, they'll write code that's not portable to other OS's
> and other OS's code won't work for them - and that's not acceptable.

Fair enough! And I am definitely not specialist enough to see even the 
simple consequences.

Nevertheless, all C++-headers in OS X (so all the standard C++ 
replacements for C libraries like "cstdlib", "cstdarg", "cmath" of for 
example all the stream-headers like "iostream", "fstream" and 
"sstream") are to be found in the path /usr/include/gcc/darwin/3.3/c++ 
anyway. So it wouldn't really be a bizarre location for other C++ 
headers to be in.

One more thing that I found though. In the tar-package of plib, the 
symbols "puSetColor" and "puSetColour" in "pu.h" are defined as inline 
as can be checked in the /src directory of the untared library. For 
some strange reason, the "pu.h" that is installed in the /usr/include 
directory is missing the "inline" keyword in front of these symbols. 
That causes severe problems when the header "pu.h" is included in more 
than one module in the project. I am not sure why the /usr/include file 
is missing this keyword but the error can be mended by simply putting 
"inline" in front of the symbols declaration as it was in the /src 
file.

Bernhard

Re: [Plib-users] Re: link plib into code on mac osx

[Steve B. <sjb...@ai...>]

Bernhard Windisch wrote:
> This is a follow-up to the problem presented to the list. I managed to 
> find a work-around to solve the problem that the gcc-compiler didn't 
> seem to recognise the plib header files as being C++.
> 
> Indeed, the whole problem disappeared by creating a soft link in the 
> /usr/include/gcc/darwin/3.3/c++ directory pointing to the 
> /usr/include/plib/-directory.
> Could it be the case that the compiler on Mac OS X assumes that the 
> headers presented in /usr/include/ are C headers? And would it therefore 
> make sense to create the plib-headers directory when using "make 
> install" directly in /usr/include/gcc/darwin/3.3/c++ instead of in 
> /usr/include?

That still doesn't make sense.

As I said before:

>> But think about this - the header file is being "#include"d into the
>> source for your application. The compiler doesn"t "recognise the language
>> of pu.h" - it takes the ASCII characters inside that file and inserts them
>> at that point into your application file. Then the resulting ASCII stream
>> is compiled using whatever language the application is written in. The
>> compiler doesn"t *see* included files as things to be compiled in their
>> own right.

I think there is something stranger than this going on. Probably,
the compiler puts an automatic 'extern "C" { ... }' around header
files that it thinks are lacking that for some reason beyond the
compiler writer's control - but gcc/g++ doesn't do this for
Windows or Linux - so why would it do that for the Mac?

I think we need to understand what's going on a bit better before
we start installing PLIB in non-standard (for PLIB) places because
if Mac users start relying on the headers being in some bizarre
location, they'll write code that's not portable to other OS's
and other OS's code won't work for them - and that's not acceptable.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

I: [Plib-users] triangles from branches

[Paolo L. <p.l...@ci...>]

> -----Messaggio originale-----
> Da: pli...@li...
> [mailto:pli...@li...] Per conto di
> Paolo Sacconier
> Inviato: luned=EC 25 ottobre 2004 16.23
> A: pli...@li...
> Oggetto: [Plib-users] triangles from branches
>=20
>=20
> Hi,
> I'm new to this mailing list. I'm trying to use plib together with ode
> (www.ode.org) dynamics engine, did anyone have some=20
> experience with it?

Yes, I did it in the last six months. I'd like to make it public after a
generalization and cleaning of the code.

> My main problem is that I need to access the triangle data for a given
> object (ie a branch entity, which contains data loaded from a=20
> model in=20
> .ac format) to create the geometric rapresentation for the ode's=20
> collision detection system. Is there a simple way to reach these=20
> informations using plib api? I couldn't figure out from the docs.

I attached some code but was blocked by the list - just tell me where to
send it.
At the end of the file there's the actual 'entry point', i.e. given a
node name load all the subtree leafs' geometry into corresponding ode
trimeshes. There's a number of utilities you could find useful for your
ambitious task. Among leaf data the only to actually duplicate is
indices (shorts in SSG, ints in ODE) - the rest is a pointer to SSG
vertices/normals structures.

It creates a geomtransform and the related geom with the transformation
along the path from the root to the node. Keep in mind that a ODE body
requires absolute positioning, while the set of transformation+geometry
in SSG put your object already in its absolute position. When you'll get
either the body position, or the geom one, you cannot put it into the
SSG transform node directly. I suggest to 'subtract' the body position
(and orientation of course) from the transformation+geometry bundle, so
that the geom pos-orient just represent the offset from the body. This
is not done in the code for clarity, and it's not so easy to accomplish.

Don't expect reliable collisions between trimeshes, at least for
dynamics. Keep the gravity low, and use a very small step. Use the
Quickstep instead of the WorldStep since with many contacts the last
quickly become unusable and sonn get stack overflow.

Furthermore don't underevaluate a hidden aspect: lasttransformation are
*important* for ODE trimeshes. I included my
update_trimesh_lasttransformation, which should be first called with a
dSpaceID and a null body. Then it will recursively apply the proper
action on the trimesh data for each space's trimesh. It is not called in
any place into the code excerpt, and you should call it after the
simulation step.

Please feel free to contact me personally for further hints, there are
lot of them.

> TIA.
> --
> Paolo Sacconier

Good luck -

Paolo Leoncini (p.leoncini a_t cira.it)

[Plib-users] =?ISO-8859-1?Q?Re:_link_plib_into_code_on_mac_osx_=A0__?=

[Bernhard W. <bw...@ca...>]

This is a follow-up to the problem presented to the list. I managed to 
find a work-around to solve the problem that the gcc-compiler didn't 
seem to recognise the plib header files as being C++.

Indeed, the whole problem disappeared by creating a soft link in the 
/usr/include/gcc/darwin/3.3/c++ directory pointing to the 
/usr/include/plib/-directory.
Could it be the case that the compiler on Mac OS X assumes that the 
headers presented in /usr/include/ are C headers? And would it 
therefore make sense to create the plib-headers directory when using 
"make install" directly in /usr/include/gcc/darwin/3.3/c++ instead of 
in /usr/include?

Thanks for the various help,

Bernhard



Steve Baker wrote:

Bernhard Windisch wrote:

  > It is completely right that the compiler doesn"t recognise the 
language
  > of pu.h. The problem is that the application IS indeed written in C++
  > and has been compiled using g++-3.3 without any problems as long as I
  > don"t include the header pu.h.

  But think about this - the header file is being "#include"d into the
  source for your application.  The compiler doesn"t "recognise the 
language
  of pu.h" - it takes the ASCII characters inside that file and inserts 
them
  at that point into your application file.  Then the resulting ASCII 
stream
  is compiled using whatever language the application is written in.  The
  compiler doesn"t *see* included files as things to be compiled in their
  own right.

  So - it seems that your application is being compiled as C code - and
  not C++.  Perhaps your application code is sufficiently C-like that 
it"s
  being successfully compiled as C - until you include some header files 
that
  are more certainly in C++.

  Why that should be, I"m not sure.

  > g++ -g -I/usr/include/gcc/darwin/3.3/c++ -c MePSim.C

  The ".C" extension (capital C) certainly indicates to the compiler that
  the code should be C++ - is it possible that something on the Mac is
  forcing the filename into lowercase before passing it to the 
compiler??!?

  Try renaming the source file to .cc or .cxx

  Another slightly odd thing is that the first error the compiler notices
  is:

   > /usr/include/plib/ul.h: In function `void ulEndianSwap(short 
unsigned int*)":
   > /usr/include/plib/ul.h:336: error: declaration of C function `void
   >   ulEndianSwap(short unsigned int*)" conflicts with
   > /usr/include/plib/ul.h:327: error: previous declaration `void
   >   ulEndianSwap(unsigned int*)" here

  ...well, there are a LOT of C++ language features earlier in ul.h that
  ought to have been flagged by the compiler if it thought it was
  compiling C.

  ---------------------------- Steve Baker -------------------------
  HomeEmail: <sjbaker1@ai...>    WorkEmail: <sjbaker@li...>
  HomePage : http://www.sjbaker.org
  Projects : http://plib.sf.net    http://tuxaqfh.sf.net
              http://tuxkart.sf.net http://prettypoly.sf.net
  -----BEGIN GEEK CODE BLOCK-----
  GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
  V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ 
y++++
  -----END GEEK CODE BLOCK-----

[Plib-users] Re: triangles from branches

[Juhana S. <ko...@ni...>]

>From: Paolo Sacconier <ax...@ti...>
>
>I wrote a function that uses the algorithm that you and Wolfram suggest:
[ ... ]
>but I fear that I have to handle also the transformation nodes to get 
>right vertices positions.

Other scenegraphs seems to have graph walkers which does the job.
The walker maintains the current transformations. User only request
the next node in the graph. There could be a couple of ways to
command the walker: (1) when the node is a subtree, we should be able to
skip it, and (2) we should be able to jump off from the current
hierarchy level to one level up (to the next node after the subtree
from which we jumped off).

The other solutions suggested seem to be more suitable to your problem.

Juhana
-- 
  http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
  for developers of open source graphics software

RE: [Plib-users] triangles from branches

[McEVOY, N. <nic...@ba...>]

Paolo Sacconier wrote:
>Unfortunately I've still problems, since somethimes the ssgInsect 
>returns no collisions where shold be some... Is it possible that is 
>because I have a shere smaller than the triangles I want to collide to?

Its hard to say what is the problem without seeing your code, but
I do vaguely recall I had the case where if I called getBSphere()
the size & position of the bounding sphere was incorrect!?
See http://sourceforge.net/mailarchive/message.php?msg_id=1153817

I never did work this problem out.  I ended up hard coding a known
bounding sphere size and using ode to get the objects position.
Then I fed my correct sgSphere information to ssgInsect().

Cheers,
Nick

Re: [Plib-users] triangles from branches

[torcs <to...@fr...>]

Steve Baker wrote:
> Paolo Sacconier wrote:
> 
>> Hi,
>> I'm new to this mailing list. I'm trying to use plib together with ode 
>> (www.ode.org) dynamics engine, did anyone have some experience with it?
> 
> 
> Take a look at the TORCS project - it uses PLIB and ODE.
> 

Well, in fact ODE is not used for TORCS, the collisions
are managed by SOLID (http://sourceforge.net/projects/freesolid),
but the objects and the transformations have to be duplicated
between PLIB and SOLID :-(


Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
               TORCS - http://torcs.org
             The Open Racing Car Simulator
         AKA The Other Release Coming Soon (Skin'r)
            How soon is soon ? (RaceBlizter)
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Re: [Plib-users] triangles from branches

[Paolo S. <ax...@ti...>]

Steve Baker wrote:
...
> Take a look at the TORCS project - it uses PLIB and ODE.

I will. Until now I saw the nick's solution and I tried to implement it, 
  since it doesn't need to access the triangle data.

...
> Well, you need to walk the tree structure of the model using things
> like getNumKids() and getKid(n) at each node and using isAKindOf to
> recognise whether you have a leaf node or a branch node...for example:
> 
> 
> void processObj ( ssgEntity *n )
> {
>   if ( n == NULL ) return ;
> 
>   if ( n -> isAKindOf ( ssgTypeLeaf() ) )
>   {
>     ssgLeaf *l = (ssgLeaf *) n ;
>     ....DO SOMETHING WITH THE TRIANGLES...
>     return ;
>   }
> 
>   ssgBranch *b = (ssgBranch *) n ;
> 
>   for ( int i = 0 ; i < b -> getNumKids () ; i++ )
>     processObj ( b -> getKid ( i ) ) ;
> }
> 
> ssgLeaf nodes contain the triangles - there are member functions
> to get the indices of the three vertices of the N'th triangle
> (getTriangle) and to retrieve the vertex, colour, normal and
> texture coordinate given a vertex index:  getVertex()/getColour()/
> getNormal()/getTexCoord().

I wrote a function that uses the algorithm that you and Wolfram suggest:

static void getTriangleData( ssgEntity * ent, dReal * vertices, int * 
indices, int *vert_offset, int *ind_offset ) {
	int i,j;
	if (ent->getNumKids() == 0){
		ssgLeaf * le = (ssgLeaf *) ent;
		int ind_start = *ind_offset;
		int ind_max = 0;
		for (i=0; i<le->getNumTriangles(); i++) {
			short int ind[3];
			le->getTriangle(i, &ind[0], &ind[1], &ind[2]);
			for (j=0; j<3; j++){
				indices[*ind_offset+j] = ind[j];
				if (indices[*ind_offset+j]>ind_max)
					ind_max=indices[*ind_offset+j];
				indices[*ind_offset+j] += ind_start;	
			}
			(*ind_offset)+=3;
		}
		for (i = 0; i < ind_max; i++) {
			float *vert;
			vert = le->getVertex(i);
			for (j=0; j<3; j++){
				vertices[*vert_offset+i*3+j] = (dReal) vert[j];
			}
			(*vert_offset)+=3;
		}
	}
	else {
		ssgBranch * br = (ssgBranch *) ent;
		
		for (i=0; i<br->getNumKids(); i++){
			getTriangleData(br->getKid(i), vertices, indices, vert_offset, 
ind_offset);
		}
	}
}

but I fear that I have to handle also the transformation nodes to get 
right vertices positions. And I have no idea how to calculate the exact 
dimensions of the arrays I should pass to this function. Just for the 
indices I used:

static int getNumIndices(ssgEntity * ent) {
	int i, num = 0;
	if (ent->getNumKids() == 0){
		ssgLeaf * le = (ssgLeaf *) ent;
		return (le->getNumTriangles())*3;
	}
	else {
		ssgBranch * br = (ssgBranch *) ent;
		
		for (i=0; i<br->getNumKids(); i++){
			num += getNumIndices(br->getKid(i));
		}
		return num;
	}
}

Since I didn't find any simple way to check if the triangle data I get 
with this method are correct (of course when I use this data I get wreid 
collisions :)) I gave up...

Maybe torcs people have found a solution.
--
Paolo Sacconier

Re: [Plib-users] triangles from branches

[Paolo S. <ax...@ti...>]

McEVOY, Nick wrote:
...
> I have created a few ode-plib projects at:
> http://users.bigpond.net.au/ndmcevoy/
> 
> Unfortunately I have been so busy lately that I have not had a chance
> to work on anything new. :(

I was already looking at your solution :)

...
> 
> Most of my applications approximate the .ac model using ode primitives
> e.g. box & sphere.  I have code to determine collisions of ode box/sphere
> against my plib .ac terrain model.  ode takes care of collisions between
> its primitives.

Since I was not able to get the triangles of the object I want to 
collide to from plib, I used ssgInsect to do the collision detection and 
then create the ode contact joint with the given triangle as you do in 
tuxwaveracer.
Unfortunately I've still problems, since somethimes the ssgInsect 
returns no collisions where shold be some... Is it possible that is 
because I have a shere smaller than the triangles I want to collide to?

> Anyway you can download my source code (e.g. TuxWaveracer) and have a
> look yourself if you like.  None of my projects are very polished or
> completed (except for MarbleTower - nb. MarbleTower has a bug in the
> collision code - which is fixed in TuxWaveracer).
> 
> Cheers,
> Nick

Thank you for your help!
--
Paolo Sacconier

RE: [Plib-users] triangles from branches

[McEVOY, N. <nic...@ba...>]

>Hi,
>I'm new to this mailing list. I'm trying to use plib together with ode 
>(www.ode.org) dynamics engine, did anyone have some experience with it?

I have created a few ode-plib projects at:
http://users.bigpond.net.au/ndmcevoy/

Unfortunately I have been so busy lately that I have not had a chance
to work on anything new. :(


>My main problem is that I need to access the triangle data for a given 
>object (ie a branch entity, which contains data loaded from a model in 
>.ac format) to create the geometric rapresentation for the ode's 
>collision detection system. Is there a simple way to reach these 
>informations using plib api? I couldn't figure out from the docs.

Most of my applications approximate the .ac model using ode primitives
e.g. box & sphere.  I have code to determine collisions of ode box/sphere
against my plib .ac terrain model.  ode takes care of collisions between
its primitives.

Anyway you can download my source code (e.g. TuxWaveracer) and have a
look yourself if you like.  None of my projects are very polished or
completed (except for MarbleTower - nb. MarbleTower has a bug in the
collision code - which is fixed in TuxWaveracer).

Cheers,
Nick

Re: [Plib-users] triangles from branches

[Steve B. <sjb...@ai...>]

Paolo Sacconier wrote:
> Hi,
> I'm new to this mailing list. I'm trying to use plib together with ode 
> (www.ode.org) dynamics engine, did anyone have some experience with it?

Take a look at the TORCS project - it uses PLIB and ODE.

> My main problem is that I need to access the triangle data for a given 
> object (ie a branch entity, which contains data loaded from a model in 
> .ac format) to create the geometric rapresentation for the ode's 
> collision detection system. Is there a simple way to reach these 
> informations using plib api? I couldn't figure out from the docs.

Well, you need to walk the tree structure of the model using things
like getNumKids() and getKid(n) at each node and using isAKindOf to
recognise whether you have a leaf node or a branch node...for example:


void processObj ( ssgEntity *n )
{
   if ( n == NULL ) return ;

   if ( n -> isAKindOf ( ssgTypeLeaf() ) )
   {
     ssgLeaf *l = (ssgLeaf *) n ;
     ....DO SOMETHING WITH THE TRIANGLES...
     return ;
   }

   ssgBranch *b = (ssgBranch *) n ;

   for ( int i = 0 ; i < b -> getNumKids () ; i++ )
     processObj ( b -> getKid ( i ) ) ;
}

ssgLeaf nodes contain the triangles - there are member functions
to get the indices of the three vertices of the N'th triangle
(getTriangle) and to retrieve the vertex, colour, normal and
texture coordinate given a vertex index:  getVertex()/getColour()/
getNormal()/getTexCoord().


---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-users] triangles from branches

[Wolfram K. <w_...@rz...>]

Hi!

>I'm new to this mailing list. I'm trying to use plib together with ode=20
>(www.ode.org) dynamics engine, did anyone have some experience with it?

I heard of it, but have not used it myself yet.

>My main problem is that I need to access the triangle data for a given=20
>object (ie a branch entity, which contains data loaded from a model in=20
>.ac format) to create the geometric rapresentation for the ode's=20
>collision detection system. Is there a simple way to reach these=20
>informations using plib api? I couldn't figure out from the docs.

One way would be to recursively go down the tree and use getTriangle
and getVertex. This returns the data in a very simple format (all
triangulated, all vertices unique etc), but can be used on any leaf
node, so code usin it is very short.  Have a look at ssgSaveTri.cxx
for example code.

>TIA.

Bye bye,
Wolfram.

[Plib-users] triangles from branches

[Paolo S. <ax...@ti...>]

Hi,
I'm new to this mailing list. I'm trying to use plib together with ode 
(www.ode.org) dynamics engine, did anyone have some experience with it?

My main problem is that I need to access the triangle data for a given 
object (ie a branch entity, which contains data loaded from a model in 
.ac format) to create the geometric rapresentation for the ode's 
collision detection system. Is there a simple way to reach these 
informations using plib api? I couldn't figure out from the docs.

TIA.
--
Paolo Sacconier

Re: [Plib-users] link plib into code on mac osx

[Steve B. <sjb...@ai...>]

Bernhard Windisch wrote:

> It is completely right that the compiler doesn't recognise the language 
> of pu.h. The problem is that the application IS indeed written in C++ 
> and has been compiled using g++-3.3 without any problems as long as I 
> don't include the header pu.h.

But think about this - the header file is being '#include'd into the
source for your application.  The compiler doesn't "recognise the language
of pu.h" - it takes the ASCII characters inside that file and inserts them
at that point into your application file.  Then the resulting ASCII stream
is compiled using whatever language the application is written in.  The
compiler doesn't *see* included files as things to be compiled in their
own right.

So - it seems that your application is being compiled as C code - and
not C++.  Perhaps your application code is sufficiently C-like that it's
being successfully compiled as C - until you include some header files that
are more certainly in C++.

Why that should be, I'm not sure.

> g++ -g -I/usr/include/gcc/darwin/3.3/c++ -c MePSim.C

The '.C' extension (capital C) certainly indicates to the compiler that
the code should be C++ - is it possible that something on the Mac is
forcing the filename into lowercase before passing it to the compiler??!?

Try renaming the source file to .cc or .cxx

Another slightly odd thing is that the first error the compiler notices
is:

 > /usr/include/plib/ul.h: In function `void ulEndianSwap(short unsigned int*)':
 > /usr/include/plib/ul.h:336: error: declaration of C function `void
 >   ulEndianSwap(short unsigned int*)' conflicts with
 > /usr/include/plib/ul.h:327: error: previous declaration `void
 >   ulEndianSwap(unsigned int*)' here

...well, there are a LOT of C++ language features earlier in ul.h that
ought to have been flagged by the compiler if it thought it was
compiling C.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-users] link plib into code on mac osx

[Bernhard W. <bw...@ca...>]

Sorry, I should read properly...

But no that isn't what is happening,

-Bernhard


On 23 Oct 2004, at 13:46, Frederic Bouvier wrote:

> Bernhard Windisch wrote :
>
>>> extern "C" {
>>> #include "plib/ul.h"
>>> #include "plib/sg.h"
>>> }
>>>
>>> -Fred
>>
>>
>> Unfortunately that doesn't work either.
>
> I was not trying to tell you what to do, but warn you about a possible 
> pitfall. You *shouldn't* have this header in an extern "C" clause 
> because they
> are C++. Perhaps you included them in another header that is in such a 
> clause
>
>> These headers are written using C++. For some (unknown) reason, the 
>> compiler thinks that they are written in C, then tries to read them 
>> as C and finally complains because he cannot understand them.
>
> -Fred
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users