salut le Zamis

j'ai trouvés deux lib réalisant une encapsulation haut niveau de ODE, EZPhysics et OPAL

http://ezphysics.org/index.htm

http://ox.slug.louisville.edu/~o0lozi01 … /Main_Page

vous avez déja testé ? vous avez des conseils pour quelqu'un qui veux se lancer dans l'une des deux ?
des conseils pour choisir ?

voila, si personne a testé, je vous ferai un petit rapport avec mon avis quand j'en aurai un

J'ai commencé à utiliser OPAL depuis hier, et çà à l'air vraiment très bien. J'arrive à utiliser les primitives de base d'OPAL et à les rendre dans Irrlicht, par contre j'ai du mal à créer des objets "solides" à partir des meshs d'Irrlicht : les solides entrent bien en collision les uns avec les autres, mais ils finissent toujours par se traverser (un peu gênant pour les collisions avec le niveau... ). J'utilise ce code pour charger les meshs (il vient du site d'OPAL) :

//merely a wrapper that will iterate across an IMesh's buffers
bool IRRtoOPAL_AddMeshToSolid( opal::Solid* solid, irr::scene::IMesh * mesh )
{
    bool success = true;
    for ( int mb=0; mb < mesh->getMeshBufferCount() ; mb++ )
    {
        if ( !IRRtoOPAL_AddMeshBufferToSolid( solid, mesh->getMeshBuffer(mb) ) )
        {
            success = false;
            //still loads in more mesh buffers if there is an error
        }
    }
    return success;
}

//adds mesh shapes to an already created OPAL solid from an Irrlicht IMeshBuffer
bool IRRtoOPAL_AddMeshBufferToSolid( opal::Solid* solid, irr::scene::IMeshBuffer * meshBuffer )
{
    opal::MeshShapeData meshData;
    meshData.numVertices = 0;
    meshData.numTriangles = 0;

    meshData.numVertices = meshBuffer->getVertexCount();
    meshData.numTriangles = meshBuffer->getIndexCount()/3;

    meshData.vertexArray = new opal::real[3 * meshData.numVertices];
    meshData.triangleArray = new unsigned int[3 * meshData.numTriangles];

    // Copy vertex data.
    irr::video::S3DVertex*    normVerts = (irr::video::S3DVertex*)(meshBuffer->getVertices());
    irr::video::S3DVertex2TCoords* txrVerts =
        (irr::video::S3DVertex2TCoords*)(meshBuffer->getVertices());
    irr::video::S3DVertexTangents* tangyVerts =
        (irr::video::S3DVertexTangents*)(meshBuffer->getVertices());
    for (unsigned int i = 0; i < meshBuffer->getVertexCount(); ++i)
    {

        switch (meshBuffer->getVertexType())
        {
        case irr::video::EVT_STANDARD:
            {
                meshData.vertexArray[3 * i + 0] = normVerts[i].Pos.X;
                meshData.vertexArray[3 * i + 1] = normVerts[i].Pos.Y;
                meshData.vertexArray[3 * i + 2] = normVerts[i].Pos.Z;
            }
            break;
        case irr::video::EVT_2TCOORDS:
            {
                meshData.vertexArray[3 * i + 0] = txrVerts[i].Pos.X;
                meshData.vertexArray[3 * i + 1] = txrVerts[i].Pos.Y;
                meshData.vertexArray[3 * i + 2] = txrVerts[i].Pos.Z;
            }
            break;
        case irr::video::EVT_TANGENTS:
            {
                meshData.vertexArray[3 * i + 0] = tangyVerts[i].Pos.X;
                meshData.vertexArray[3 * i + 1] = tangyVerts[i].Pos.Y;
                meshData.vertexArray[3 * i + 2] = tangyVerts[i].Pos.Z;
            }
            break;
        default:
        {
            // you will need to handle the vertex type
            assert(false);
        }
        break;
        }
    }

    // Copy triangle data.
    uint16_t* meshIndices = (uint16_t*)meshBuffer->getIndices();
    for (unsigned int i = 0; i < meshData.numTriangles; ++i)
    {
        meshData.triangleArray[i*3 + 0] = meshIndices[i*3 + 0];
        meshData.triangleArray[i*3 + 1] = meshIndices[i*3 + 1];
        meshData.triangleArray[i*3 + 2] = meshIndices[i*3 + 2];
    }
    solid->addShape(meshData);

    return true;
}

void IRRtoOPAL_ReleaseSolidMeshData( opal::Solid* solid )
{
    if (solid)
    {
        //make sure to remove memory allocated for mesh objects
        opal::SolidData solidData = solid->getData();
        for (unsigned int i = 0; i < solidData.getNumShapes(); ++i)
        {
            if (solidData.getShapeData(i)->getType() == opal::MESH_SHAPE)
            {
                opal::MeshShapeData* meshData =
                    (opal::MeshShapeData*)solidData.getShapeData(i);
                delete [] meshData->vertexArray;
                delete [] meshData->triangleArray;
            }
        }
    }
}

Je sais pas si tu as testé cette lib, mais si c'est le cas, tu as certainement rencontré le même problème, donc je voudrais juste savoir si tu as trouvé une solution pour çà 

Dernière modification par Perceval (17-07-2007 15:29:04)

Hello,
Je vais persister à dire que j'aime pas ses libs d'encapsulation ^_^.
Je trouve ça "con" d'utiliser une lib telle que Ode par l'intermédiaire d'une encapsulation qui risque de rajouter des bugs, qui va restreindre l'utilisateur à ce qu'elle propose et qui au final fera pas forcément gagner du temps.
Ca y est là j'ai mis le feu, la réplique de Jerry va être terrible .
Enfin ça reste mon avis personnel, je n'ai jamais réellement pris le temps non plus d'en utiliser une, mais pour l'instant ça me donne pas envie.

Donc mes questions sont les suivantes pour ceux qui testent :
Comment on gère le time stepping sous vos libs ?
Si je veux faire un effet de ralentissement à la matrix, ça reste aisé ?
Et enfin donné moi un excellent argument de vente avec se systeme plustôt que Ode en natif qui me permet une liberté totale de mon code ?

Comment on gère le time stepping sous vos libs ?

J'utilise un timer d'irrlicht pour obtenir le temps écoulé entre 2 pas de boucle, et je passe ce temps à OPAL via la fonction qui va effectuer la simulation :

sim->simulate(temps écoulé depuis la dernière simulation);

Si je veux faire un effet de ralentissement à la matrix, ça reste aisé ?

Bah, je suppose qu'il suffit de "blouser" OPAL en jouant sur la valeur du timer .

Et enfin donné moi un excellent argument de vente avec se systeme plustôt que Ode en natif qui me permet une liberté totale de mon code ?

J'aime bien cette lib car elle permet de faire des trucs avancés sans avoir à trop se casser la tête (en théorie en tout cas, j'ai pas encore eu beaucoup de temps pour tester la lib donc je sais pas si c'est effectivement le cas).
Quelques possibilitées d'OPAL qui me paraissent bien et qui, à moins que je ne me trompes (pas trop regardé les features d'ODE... ), ne sont pas réalisables aussi facilement avec ODE :
     - les breakables joints : juste une propriété qui permet de casser automatiquement les joints entre 2 solides quand une force suffisamment importante lui est appliqué.
     - les motors : on les paramètre au début, et après, on a juste à les activer/désactiver quand on veut (OPAL s'occupe tout seul d'ajouter les forces et torques nécessaires)
     - j'aime bien le système de détection des collisions sous forme d'évênements, qui ressemble beaucoup au système de gestion des évênements dans Irrlicht. Dans ODE si je me trompes pas, faut passer par des callbacks : çà marche aussi bien, mais je trouve le code moins clair.
     - la possibilité de sauver et de charger les paramètres des solides, des joints etc dans des fichiers xml
Autre argument : j'ai jamais utilisé d'autres librairies physiques, et je penses que cette lib est un bon moyen de débuter.
Enfin, pour défendre un peu les créateurs d'OPAL, faut savoir que cette lib a été créer non pas pour être utilisé telle quelle dans des jeux (même si c'est bien évidemment possible), mais plutôt pour faire du prototypage ou des outils d'édition physique. Donc je penses pas que c'est "con" de faire une lib comme çà

Copland :

Hello,
Je vais persister à dire que j'aime pas ses libs d'encapsulation ^_^.
Je trouve ça "con" d'utiliser une lib telle que Ode par l'intermédiaire d'une encapsulation qui risque de rajouter des bugs, qui va restreindre l'utilisateur à ce qu'elle propose et qui au final fera pas forcément gagner du temps.
Ca y est là j'ai mis le feu, la réplique de Jerry va être terrible .

MOUAHAH, ma vengeance sera terrible Copland

bon en fait quid des perfs, je sais pas, j'ai pas mesuré, par contre ce que je sais, c'est que j'arrive a faire de la physique simplement avec OPAL, et que c'est pas le cas avec les autres

Copland :

Comment on gère le time stepping sous vos libs ?

Tres simplement, suffit d'utiliser une fonction qui définit le time step; perceval l'a donnée dans son post

Copland :

Si je veux faire un effet de ralentissement à la matrix, ça reste aisé ?

idem que perceval

Copland :

Et enfin donné moi un excellent argument de vente avec se systeme plustôt que Ode en natif qui me permet une liberté totale de mon code ?

ben si tu étais vraiment contre les lib d'encapsulation, tu utiliserai pas irrlicht, tu prendrai OpenGL en natif et tu serai heureux ..
franchement le gros avantage de OPAL pour moi ce sont ces moteurs tout fait  :
tu as un moteur rotation qui donne la bonne force pour contraindre un axe a faire une rotation constante
un moteur qui donne toujours la meme force (donc la vitesse varie)
un moteur de gravité (cf Half life)
un moteur "fusée" etc etc

Bon, pour en revenir à mon problème (si çà intéresse encore quelqu'un ), j'ai testé davantage et apparement le problème ne survient que pour les collisions entre 2 solides créés à partir de meshs d'Irrlicht (aucuns soucis pour les collisions entre un solide créé à partir d'un mesh d'Irrlicht et une primitive d'OPAL). Par contre, çà marche absolument pas à partir des heightmaps

Conclusion : j'utiliserais les fonctions de mon premier post uniquement pour les éléments statics de mon niveau, et les autres objets seront tous controllés par des primitives d'OPAL.

Perceval :

Conclusion : j'utiliserais les fonctions de mon premier post uniquement pour les éléments statics de mon niveau, et les autres objets seront tous controllés par des primitives d'OPAL.

si j'ai bien compris tu as choisi de laisser tomber ODE pur ? yatta !

Ben moi j'ai jamais voulu utiliser "ODE pur" sinon j'aurais pas télécharger OPAL