Real-Time Physics Simulation Forum

API refactoring (was ugliness)

2006-11-07T19:53:53+00:00

while generating the bt stuff a minor error happened. Just do a
Code:
grep bteral `find  *`
(while doing some substitution every "Gen" got replaced by a "bt" what produced a "GNU bteral Public License")

Noehrgel

That's a funny license
Note that there is no GNU GPL in the Bullet core sources (in Bullet/src). This only affects some unimportant front rendering in the Demo code.

Thanks for pointing this out,
Erwin

Statistics: Posted by Erwin Coumans — Tue Nov 07, 2006 7:53 pm

API refactoring (was ugliness)

2006-11-06T08:16:33+00:00

while generating the bt stuff a minor error happened. Just do a

Code:

grep bteral `find  *`

(while doing some substitution every "Gen" got replaced by a "bt" what produced a "GNU bteral Public License")

Noehrgel

Statistics: Posted by Noehrgel — Mon Nov 06, 2006 8:16 am

API refactoring (was ugliness)

2006-11-03T02:39:42+00:00

Many thanks!

I'll have a bit of time over the weekend - I'm getting my game back up and working with all of this refactored goodness.

Statistics: Posted by SteveBaker — Fri Nov 03, 2006 2:39 am

API refactoring (was ugliness)

2006-11-02T03:45:57+00:00

Hi Steve,

This has been fixed in SVN: btCollisionObject is a class now. Its members like m_worldTransform are not public anymore, and required set/getWorldTransform(). Also, btMotionState is required now, to synchronize world transform properly.

Thanks for the feedback. Hopefully no big refactoring changes anymore, so we can focus on improving quality and performance
Erwin

Bullet software makes distinguishment between classes and structs. The btCollisionObject is a struct at the moment, and for structs I allow direct data access.
Yeah - for simple structs with no member functions, I would also leave the member variables exposed - but btRigidBody is a CLASS (admittedly derived from a STRUCT). To all intents and purposes, it's a class with exposed internals.
More important, the world transform should be read/written by btMotionState. I'll probably remove the btRigidBody constructor that passes in a worldtransform, and you just pass the btMotionState (that contains the graphics worldtransform, including potential center-of-mass shifts etc).
OK - but the problem for application writers is that the only documentation of any use is the demo programs - and they don't seem to be using btMotionState. If the demo's don't use "best practices" then we can't expect application authors to guess what we expect them to do.

Statistics: Posted by Erwin Coumans — Thu Nov 02, 2006 3:45 am

API refactoring (was ugliness)

2006-10-28T19:00:21+00:00

Bullet software makes distinguishment between classes and structs. The btCollisionObject is a struct at the moment, and for structs I allow direct data access.
Yeah - for simple structs with no member functions, I would also leave the member variables exposed - but btRigidBody is a CLASS (admittedly derived from a STRUCT). To all intents and purposes, it's a class with exposed internals.
More important, the world transform should be read/written by btMotionState. I'll probably remove the btRigidBody constructor that passes in a worldtransform, and you just pass the btMotionState (that contains the graphics worldtransform, including potential center-of-mass shifts etc).
OK - but the problem for application writers is that the only documentation of any use is the demo programs - and they don't seem to be using btMotionState. If the demo's don't use "best practices" then we can't expect application authors to guess what we expect them to do.

OK. Let's put it on the todo, to modify all demos so they consistently use getCenterOfMassTransform and btMotionState. The demos are using btMotionState to synchronize the graphics for rendering, see DemoApplication::localCreateRigidBody.

Also, I will add this to the Bullet_User_Manual.pdf. Other feedback requests for reorganizing the Wiki so it becomes more useful and adding a User Gallery so users can share their work using Bullet better.

Thanks,
Erwin

Statistics: Posted by Erwin Coumans — Sat Oct 28, 2006 7:00 pm

API refactoring (was ugliness)

2006-10-28T17:21:36+00:00

Bullet software makes distinguishment between classes and structs. The btCollisionObject is a struct at the moment, and for structs I allow direct data access.

Yeah - for simple structs with no member functions, I would also leave the member variables exposed - but btRigidBody is a CLASS (admittedly derived from a STRUCT). To all intents and purposes, it's a class with exposed internals.

More important, the world transform should be read/written by btMotionState. I'll probably remove the btRigidBody constructor that passes in a worldtransform, and you just pass the btMotionState (that contains the graphics worldtransform, including potential center-of-mass shifts etc).

OK - but the problem for application writers is that the only documentation of any use is the demo programs - and they don't seem to be using btMotionState. If the demo's don't use "best practices" then we can't expect application authors to guess what we expect them to do.

Statistics: Posted by SteveBaker — Sat Oct 28, 2006 5:21 pm

API refactoring (was ugliness)

2006-10-28T04:53:37+00:00

From reading the demo programs, it seems that the only way to perform some operations on btRigidBody objects is to access the raw member variables of the base class (eg, the Demos/OpenGL/DemoApplication.cpp reads and writes 'm_worldTransform'). This is kinda nasty because it means you can't tell when one of these fields has been touched if you ever need to in the future.

There should be inlined access functions for these things with all of the member variables of public classes made 'private'.

(Also, there is a typo: m_ccdSweptMotionTreshold ...should be 'Threshold')

Thanks for pointing out the typo, I'll rename it.

Bullet software makes distinguishment between classes and structs. The btCollisionObject is a struct at the moment, and for structs I allow direct data access. However, I agree it is not a good habbit. We can clean this up, but in general some structs are really mostly public data, which is not intended to be private.

More important, the world transform should be read/written by btMotionState. I'll probably remove the btRigidBody constructor that passes in a worldtransform, and you just pass the btMotionState (that contains the graphics worldtransform, including potential center-of-mass shifts etc).

Thanks for the useful feedback,
Erwin

Statistics: Posted by Erwin Coumans — Sat Oct 28, 2006 4:53 am

API refactoring (was ugliness)

2006-10-28T03:42:44+00:00

From reading the demo programs, it seems that the only way to perform some operations on btRigidBody objects is to access the raw member variables of the base class (eg, the Demos/OpenGL/DemoApplication.cpp reads and writes 'm_worldTransform'). This is kinda nasty because it means you can't tell when one of these fields has been touched if you ever need to in the future.

There should be inlined access functions for these things with all of the member variables of public classes made 'private'.

(Also, there is a typo: m_ccdSweptMotionTreshold ...should be 'Threshold')

Statistics: Posted by SteveBaker — Sat Oct 28, 2006 3:42 am

API refactoring (was ugliness)

2006-10-27T03:09:52+00:00

In the sample programs, you have a lot of application program functions that start with the string 'glut' - that's not a wise move. The entire point of having all actual GLUT functions beginning with 'glut' is precisely to avoid the risk of some GLUT function coincidentally havintg the same name as some application function. If you go around calling application functions 'glutXXXXX' then you are asking for problems in the future.

(eg 'glutMotionFuncCallback')

Statistics: Posted by SteveBaker — Fri Oct 27, 2006 3:09 am

API refactoring (was ugliness)

2006-10-18T04:46:32+00:00

In src/BulletCollision/CollisionDispatch/btConvexConvexAlgorithm.cpp and in the CcdPhysicsDemo, there are references to:

m_ccdSweptShereRadius

Is that a typo? I presume it should be 'm_ccdSweptSphereRadius'.

Thanks for pointing it out Steve, it has been fixed in version 2.17

Erwin

Statistics: Posted by Erwin Coumans — Wed Oct 18, 2006 4:46 am