date:20081112

Re: [osg-users] Coupling luabind with OSG + Bullet

2008-11-12 Thread Gerwin de Haan

I don't use Luabind either but osgswig with Python instead. I sometimes
experience similar surprising effects when passing non-declared variables as
function arguments. In that case, the reason for this is often that the
scripting language garbage collector deletes the Vec3f after returning from
the function, essentially leaving any references to the Vec3 dangling. A
correct reference counting mechanism in the scripting binding should prevent
this in most cases.

The problem you're describing could have similar cause. So just to be sure,
try and define the Vec3f in the global scope and pass a reference as an
argument in your call.:
myvec= Vec3f(2,0,0)
entMan:createStaticEntity( ball, myvec, false )
Or, in this function, try and make a copy of the parameter values before
returning.

regards,
Gerwin


On Wed, Nov 12, 2008 at 8:14 AM, Dusten Sobotta [EMAIL PROTECTED]wrote:

 Hello,

 I've been working on an engine that combines sdl, osg, bullet, open al, and
 now lua for roughly 6 weeks.  Static and dynamic entity creation works well
 on the fly if handled with C++ code, however if I attempt to off-load this
 logic to lua, I run into problems.  Below is an example of code that is
 relevant to the problem:

 
 void entityManager::loadStaticEntityList( const std::string filename ) {

 lua_State *L = lua_open();
 luabind::open(L);

 luabind::module( L ) [

 luabind::class_osg::Vec3f(Vec3f)
 .def( luabind::constructor float, float, float () )
 ];

 luabind::module( L ) [

 luabind::class_entityManager(entityManager)
 .def( luabind::constructor () )
 .def( createStaticEntity, entityManager::createStaticEntity )
 .def(destroyAllEntities, entityManager::destroyAllEntities )
 ];


 if( luaL_loadfile( L, filename.c_str() ) || lua_pcall( L, 0, 0, 0 ) )
 throw could not load entity list;


 createStaticEntity( ball, osg::Vec3f( 0, 0, 0 ), false ); //direct
 C++ call; works!

 luaL_dofile( L, filename.c_str() );

 }
 ///

 ///
 void entityManager::createStaticEntity( const std::string type, const
 osg::Vec3f position, const bool dimension ) {

 entity * newEntity = createEntityP( type, position, dimension );
 _physicsManager-defineRigidBody( newEntity, type, false, dimension );

 entities[ newEntity-getRigidBody() ] = newEntity;
 staticEntities[ dimension ]-addChild( newEntity-getPAT().get() );
 staticEntityList.push_back( newEntity );
 }
 ///

 And here is the lua script I'm trying to run:

 --
 entMan = entityManager()
 a = Vec3f( 0, 0, 0 )

 --same call from within lua; crashes the engine if uncommented!
 entMan:createStaticEntity( ball, Vec3f( 2, 0, 0 ), false )
 --


 As you can see, a declaration of type Vec3f works from within lua, so I
 don't think that using Vec3f as a parameter is an issue.
 Might anyone know what's going on here?  I'm not very familiar with
 luabind, and even less familiar with getting it to play nicely with OSG.
 Any help would be greatly appreciated.



 Thanks for your time,

 Dusten

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] compositeViewer newbie question

2008-11-12 Thread Robert Osfield

Hi Dan,

On Tue, Nov 11, 2008 at 8:43 PM, Dan Small [EMAIL PROTECTED] wrote:
 We used the second approach you mentioned, threw all the views in one
 window,   not surprisingly the memory utilization went way down.
 Thanks for correcting our GL naivete.

 It seems tho that the 2nd approach also limits us to single-threaded only;
 would you concur?  We have an 8-core Dell we are running this on, and it
 would be nice to avail ourselves of the multithreading features if we can.

Well if you have one context your only have the ability to use one
graphics thread that drives one GPU so you are limited to a certain
extent, but this doesn't limit you on the cull traversal side - you
can use DrawThreadPerContext and
CullThreadPerCameraDrawThreadPerContext which will give you a little
speed up.

It's worth noting that unless you put your windows on a second GPU all
the traffic to the GPU will be serialized anyway, and its far more
efficient for the OSG to do this on one graphics context than have the
OpenGL driver try to chop and change between many contexts and many
threads filling the FIFOs, and only one graphics card being able to
drain it.  This all means that the one graphics thread is actually the
best use of GPU resouces.

The reduction in memory consumption and bandwidth to GPU requirement
will also get you lots of performance back.

 btw, I wasn't my intent to imply there was a bug in the OSG, only in that
 way that we were using it :)

No offence taken, I was just being try to clear about the causes and
possible avenues for a solution.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Particle system setInitialRotationalSpeedRange()

2008-11-12 Thread Robert Osfield

Hi Thom,

Thanks for the detective work. The change you've suggested as causing
the regression is r7961.

http://www.openscenegraph.org/projects/osg/changeset/7961

It's six months since I code this so it's a bit cold a topic so off
the top of my head I can't point to anything in a particular as being
the cause of the problems. I will have to sit down and step through
the code.

Thanks for pointing out that SmokeBox.osg reproduces the problem, with
the problem in front of me it's very difficult to spot issues in code.

Robert.

On Tue, Nov 11, 2008 at 11:21 PM, Jolley, Thomas P
[EMAIL PROTECTED] wrote:
Hi Robert,

I've looked into this a little further. It appears the changes you made to
ParticleSystem.cpp on March 17th is the reason for the behavior change. I
don't have a solution yet other than backing out the changes. I'm still
trying to understand what you're doing in the single_pass_render function
before coming up with a solution.

I think this problem was mentioned in an earlier thread around May.
See
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-May/011595.html.

To see the problem look at SmokeBox.osg with osgviewer (I'm using osg
2.6.0). The particles are rotating about the wrong axis (or at least a
different axis).

Tom Jolley

From: Jolley, Thomas P
Sent: Thursday, August 21, 2008 2:11 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Particle system setInitialRotationalSpeedRange()

Hi Erik,

I noticed the same thing about a week ago while upgrading an application
from osg 1.0 to 2.4. It was on my list of things to look into.

From: Erik Johnson [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2008 10:30 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Particle system setInitialRotationalSpeedRange()

There is certainly a change in behavior, although I can't pinpoint the
change in code yet.

Setting the rotational speed with (0, 0, 1):
OSG 2.2.0 - particles rotate like fans (pinwheels)
OSG 2.4.0 - particles rotate like a margarita blender (cork-screw)
OSG 2.6.0 - particles rotate like a margarita blender (cork-screw)

I guess I'm just wondering if this is the expected behavior? And I'm
surprised nobody has a problem with this.

Thanks,
Erik

Date: Thu, 21 Aug 2008 09:26:52 +0100
From: Robert Osfield [EMAIL PROTECTED]
Subject: Re: [osg-users] Particle system
setInitialRotationalSpeedRange()
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1

Hi Erik,

osgParticle has hardly been touched between OSG-2.2 and 2.6. Use svn
log to check which files have changed.

Robert.

On Thu, Aug 21, 2008 at 1:07 AM, Erik Johnson [EMAIL PROTECTED]
wrote:
Hi all,

It seems to me, back in the OSG 2.2.x time frame, that I could set the
initial rotational velocity of the RadialShooter and have the particles
pinwheel around their center point, while maintaining their billboard
orientation and face the Camera. Perhaps it was a rotation on the Y
axis.

Nowadays with OSG 2.4/2.6, setting the rotational speed will cause the
particles to rotate relative to the world axis and not in the
camera-relative axis.

65 matches

Mail list logo