thank you for reply carsten. > yes, for almost all OpenSG objects there is a *Base class, it is > generated from a description in the .fcd files in the OpenSG source tree > and contains all the boilerplate code. > One thing that is ensured by this code is that when osgInit runs a > prototype instance for every type is created from which all "user" > instances are cloned. The call stack you posted seems to imply that the > crash happens during the prototype creation/initialization (which is > triggered from osgInit). Since the PhysicsBoxGeom makes calls to ODE > during its prototype initialization, ODE must be initialized before > OpenSG, i.e. the call dInitODE must be before osgInit. dInitODE is called before osgInit.
> if t contains garbage values it seems the ODE call dGeomBoxGetLengths > did fail, I'm guessing because ODE is not initialized? this is logical prediction, but initialization has been already done. > The physics library does not register an init function, so the number is > not changed. ok. i understand. i am investigating continuously about this problem, and i found that other physics objects initialization are ended succesfully.(PhysicsBody, and PhysicsGeom, and so on) but only PhysicsBoxGeom is failed. do you have any other point? Thank you. On Wed, 04 Aug 2010 11:06:01 -0500 Carsten Neumann <carsten_neum...@gmx.net> wrote: > Hello, > > Kazuhiko Kido wrote: > >>> Adding a call to dInitODE() at the top of main in the two test programs > >>> makes them work for me. > > i have already added a dInitODE at the top of main. > > did you put it before the call to osgInit() ? > > > For debug, i made contrib/physics and OSGBaseLib libraries on VC2008. > > I tried to add only three of the following codes in the OpenSG sample > > program run correctly before i made, and linked these debug library. > > Then duplicate the behavior. > > > > 1. #include <OSGPhysics.h> > > 2. Add "dInitODE();" at top of the main > > 3. Add "PhysicsHandlerPtr physHandler = PhysicsHandler::create();" at > > middle of the main > > > > > > following is the stack when the test application is crashed. > > > > osgInit (OSGBaseFunctions.cpp:line 303) > > returnValue &= (*osgInitFunctions)[i](); (OSGBaseFunctions.cpp:line 454) > > PhysicsBoxGeomBase::createEmpty (OSGPhysicsBoxGeomBase.inl:line 87) > > newPtr(returnValue); (OSGPhysicsBoxGeomBase.inl:line 91) > > result->onCreate(); (OSGFieldContainerImpl.inl:line 253) > > PhysicsBoxGeom::onCreate (OSGPhysicsBoxGeom.cpp:line 79) > > PhysicsBoxGeomBase::setLenghts(tmpPtr->getLenghts()); > > (OSGPhysicsBoxGeom.cpp:line 83) > > dGeomBoxGetLengths(tmpPtr->id, t); (OSGPhysicsBoxGeom.cpp:line 99) > > return Vec3f(t[0], t[1], t[2]); (OSGPhysicsBoxGeom.cpp:line 100) > > <===== t[0] overflow!!(-1.#QNAN00) This is the reason of crash. > > > Question: > > 1. "PhysicsBoxGeomBase::createEmpty" is called as initial function. Is it > > right? I don't use "PhysicsBoxGeomBase" in source code. > > yes, for almost all OpenSG objects there is a *Base class, it is > generated from a description in the .fcd files in the OpenSG source tree > and contains all the boilerplate code. > One thing that is ensured by this code is that when osgInit runs a > prototype instance for every type is created from which all "user" > instances are cloned. The call stack you posted seems to imply that the > crash happens during the prototype creation/initialization (which is > triggered from osgInit). Since the PhysicsBoxGeom makes calls to ODE > during its prototype initialization, ODE must be initialized before > OpenSG, i.e. the call dInitODE must be before osgInit. > > > 2. If this function call is valid, the reason why such a overflow occurs? > > and how to avoid this? > > if t contains garbage values it seems the ODE call dGeomBoxGetLengths > did fail, I'm guessing because ODE is not initialized? > > > The number of initial function (osgInitFunctions) is 6. Strangely enough, > > even if the physics library class is not used in a source code, then the > > number of initial function is still 6. > > The physics library does not register an init function, so the number is > not changed. > > > My developing environment is VC2008(not SP1), so i try to install VC2008 > > SP1 and try again. > > hm, not sure if that is a problem, but it shouldn't hurt either ;) > > Cheers, > Carsten > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Opensg-users mailing list > Opensg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensg-users -- <> ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
