Re: [simspark-devel] PAL_draft

[Hedayat V. <hed...@ai...>]

Hi,
> Hmm, in that case, we should think about whether PAL is really the
> best choice for us. We could only take it as an inspiration and
> implement our own, hopefully more complete, abstraction for the
> engines we would like to integerate (ODE, Bullet, and PhysX in my
> case). What do you think?
I'm not sure, maybe Ben knows better than me now. What do you think Ben?
I think we should try to reuse the available code as much as possible; 
but in that case I think we should feel free to modify PAL as we wish. 
So, we will probably come up with a derivation of PAL inside our project 
or (depending on the PAL developer) we will essentially develop PAL 
alongside our project.

 
/*"Zigorat Team" <zig...@gm...>*/ wrote on 10/21/2008 12:37:06 AM:
> Hi all
>
>   I agree with Joschka on restructuring directories and cleaning up 
> the codes.
OK, I'll start with a suggestion and some questions. First, my proposed 
directory structure (still needs work!):

spark/
    doc/
    plugin/
    kerosin/
    oxygen/
    salt/
    zeitgeist/
    spark/
    utility/
    test/
        agenttest/
        coretest/
        ...
        (test apps)
    data/
        rsg/  (including common rsg files like boxspheres/ directory)
        ros/
    windows/
    macosX/

gendot/

rsgedit/
    res/
    doc/

soccer/     (propose a better name: simspark-soccer, rcssserver3d, ... ?)
    doc/
    agentspark/
    monitorspark/
    simspark/    (I think we should rename this application, 
rcssserver3d might be a condidate!)
    plugin/
    data/
        rsg/
        ros/
    linux/
    windows/
    macosX/

Now, some questions:
1. Are we going to use a new build system (instead of autotools)?

2. Do we want to separate building spark from other apps? Currently in 
simspark CVS, spark and contrib directories have separate build 
structures (you should build them independently). This way, we can split 
the server package to more than one package: a library package (spark 
directory, creating simspark package), rsgedit package, and rcssserver3d 
package. But something like gendot is too small, so we may put such 
small applications in a directory (like contrib/ directory in simspark 
CVS),  maybe with a name such as "simspark-utilities" or  a better name. 
Another option is to rename spark/test/ to spark/apps/ and put gendot 
there.
But if we are going to provide a single package containing all source 
code,  having one build system for the complete project might be better 
and is simpler for the users.

3. spark's libraries (kerosin, ...) might be moved to spark/lib/ 
sub-directory!

>   There is a slight problem I've been noticing since a long time ago, 
> which the ruby files with the options in them, are installed in 
> typical application installation folder, like /usr/local/bin, which 
> makes it hard to change the simulators options, as they are needed. I 
> suggest some of the configuration files be moved to the local folder 
> of ~/.rcssserver3D/
I think it's a good suggestion. We can do what is currently done with 
files such as kerosin.rb: copying the installed configuration files into 
~/.rcssserver3D if they don't exist, and using ~/.rcssserver3D files 
when available.


Good luck,
Hedayat


>   That would even working easier for teams which use network based 
> user accounts and each member does independent jobs from the others 
> (thus needing his own configuration, like testing a trainer for future 
> purposes).
>
> Cheers
> Mahdi
>
> On Mon, Oct 20, 2008 at 5:33 PM, Joschka Boedecker 
> <jos...@am... 
> <mailto:jos...@am...>> wrote:
>
>     Hi all,
>
>     On Oct 20, 2008, at 9:49 PM, Hedayat Vatankhah wrote:
>
>     > Hi,
>     >
>     > Ben <lgp...@16... <mailto:lgp...@16...>> wrote on
>     ۰۸/۱۰/۲۰ 12:18:33:
>     >> Hi,
>     >> >What is the current status of the conversion?
>     >> It's just a try and I think 'PAL' itself is not mature, some
>     >> interfaces are missing, for example, 'dJointFeedBack',(maybe lost
>     >> for *general*) and strange properties of a certain physical engine.
>     >>
>     > Yes, the last time I checked PAL (a year ago), I found that it have
>     > a lot of functionality missing (different things for different
>     > engines) and it seems that it have not been updated since then. I
>     > guess it doesn't have composite body support for ODE for example. I
>     > think I've sent an email to this list and talked about it. Anyway,
>     > working on PAL maybe still provide some time savings for us.
>
>     Hmm, in that case, we should think about whether PAL is really the
>     best choice for us. We could only take it as an inspiration and
>     implement our own, hopefully more complete, abstraction for the
>     engines we would like to integerate (ODE, Bullet, and PhysX in my
>     case). What do you think?
>
>     >
>     >> >It seems that a significant part of the utility functions are
>     still
>     >> >missing, like most of the mass calculation function in
>     body.cpp etc.
>     >> >That's to be expected, as it's tedious work..
>     >> Yes, that's really tedious.
>     >>
>     >> >Further we should put it into a new CVS branch to make it
>     easier to
>     >> >follow development.
>     >> I think so ;-)
>
>
>     I would suggest that before we start the new development, we might
>     want to move our sources into the SVN at the simspark project (I
>     activated the SVN yesterday), restructuring the directories, and
>     cleaning up in the progress (for instance, purge legacy projects like
>     rcssmonitor3d-lite, etc). Let's maybe try to come up with a plan for
>     the directory structure as a first task.
>
>     Cheers,
>     Joschka
>