Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Jul 2002
Offline Last Active Oct 09 2014 12:15 AM

Topics I've Started

Invalid internal pointers after startup

30 January 2014 - 03:57 AM

Hi, I've been playing around with bullet and bumped into a problem.

The collision shapes cannot be deleted right after they are created.


Here are some samples;


First the init:

coll_config=new btDefaultCollisionConfiguration();
coll_dispatch=new btCollisionDispatcher(coll_config);
overlap_paircache=new btDbvtBroadphase();
solver=new btSequentialImpulseConstraintSolver;
world=new btDiscreteDynamicsWorld(coll_dispatch,overlap_paircache,solver,coll_config);


pretty simple, from the basic samples.


And this is weird:

// Create the shape
btCollisionShape* shape=new btBoxShape(btVector3(1,1,1));
btVector3 inertia(0,0,0);
btTransform trans;

btDefaultMotionState* mstate=new btDefaultMotionState(trans);
btRigidBody::btRigidBodyConstructionInfo ci(5,mstate,shape,inertia);
btRigidBody* body=new btRigidBody(ci);

// And remove!
btCollisionObject* obj=world->getCollisionObjectArray()[0];
delete body->getCollisionShape();
delete body->getMotionState();
delete body;
delete obj;

The remove method is also from some basic sample.

But in this case the removeCollisionObject() references some uninitialized broadphase proxy pointer.


in btDbvtBroadphase::destroyProxy

The same happens with SimpleBroadphaseProxy.


the strange thing is, the whole thing works after the simulation is running for some time.



Did anybody have anything similar???


Physics and huge game worlds

16 January 2014 - 08:20 AM



Did any of you used Bullet in huge game maps?


I'd say loading all the 100.000 objects and feeding them into the physics engine is not an option.

First I'd go for dynamicaly load/add collision shapes within a certain radius of the player and remove them when they are out of "interest".

So the question is;

How rapid modification (add/remove) of the physics world affects the performance, and what about memory fragmentation?

Is it advised to implement some self made memory manager for this, or does the bullet handle it fine?

Also btBvhTriangleMeshShape takes some time to build the hierarchy, so  serialize or not to serialize??


thanks for any help smile.png

Debug -/ Release Differences

13 January 2014 - 11:01 AM


I'm just trying out bullet, and noticed that the "visual result" is different for debug and release.

Is that possible? Or am I missing something?

Very simple scenario, 4 boxes fall on top of each other.


Invalid values from VS

19 December 2013 - 08:05 AM


I'm trying to draw screen aligned quad with pre-transformed vertices and DrawPrimitiveUP.

Some weird is happening to the output values of the vertex shader:


Here are some samples:


The buffer consist of 4 vertices (screen corners) in the following format:

struct TVertex {
    float pos[3];
    float rhw;
    float uv[2];

The pos.xy are set to the screen corners, the pos.z is 0 and the rhw is 1. The UV members are 0,0/1,0/1,1/0,1

And drawing a trianglefan.


The vertex declaration is as follows:

const D3DVERTEXELEMENT9 dcl[]={

And a very simple shader to make the situation clear:

struct VSIn 
  float4 pos: POSITION;
  float2 uv: TEXCOORD;

struct VSOut {
  float4 pos: SV_POSITION;
  float4 spec: TEXCOORD0;

VSOut VSMain(VSIn input) {
  VSOut output;

  return output;

float4 PSMain(VSOut input): SV_TARGET {
  return input.spec;

I'd expect the whole screen to be white, but it's not!

It looks like the corners get these "spec" values:   (0,0,0,1) (1,0,0,1) (1,1,0,1) (0,1,0,1)


If I use a different register,

float4 spec: TEXCOORD1;

The whole screen is black, the input.spec value is (0,0,0,1)


The same shader works fine with "normal" projected transformation, but not with pre-transformed vertices.


What do I miss here??


Thanks for any help!


[Car physics] Force feedback and such enjoyment

18 December 2013 - 06:22 AM


I started playing with force feedback wheels, and as I noticed this is the point where most people had already given up or it's just simply out of their interest.

Anyway, I'm having a hard time finding good writings about decent force feedback "simulation", so I have to take the hard way, figuring it out.

Hopefuly some of you are also into this topic :)


Here are some notices and questions that arose:


- There is a strange behavior even if driving straight, the steering wheel wants to "go slalom", I noticed the same effect with some AAA driving game, but not with Gran Turismo. Maybe it's the toe-in or camber that generates some torque, which are not equal for both wheels and "magnifies" with speed. My quick solution is to have a dead-zone and some damping at the center, so I can release the wheel at 300km/h and not hitting the wall :)

But it feels there is no grip around the center. It builds up as I turn but not instantly.


- I'm using the good old Pacejka to get the aligning moment, but it not incorporates the caster angle, is that an important factor, or can that be neglected? Also, where should the Mz curve's peak be? At the peak of Fy's? Or should it go back to zero at Max Fy?


- Road surface feedback is what I did yesterday. I'm using constant force for aligning moment, so it seemed obvoius that I should add some "noise" to the current FF force depending on the surface, but it just doesn't make that rumble effect that I expected. Am I on the good way or should I turn my attention to custom FF effects?


That's all I can remember now, and thanks for every help, ideas and opinions...ect.



By the way, this is where I'm now: