• Create Account

Banner advertising on our site currently available from just \$5!

# bmarci

Member Since 05 Jul 2002
Offline Last Active Yesterday, 07:01 AM

### [Car Physics] Turbochargers and friends

14 January 2015 - 08:13 AM

Hi guys,

Does any of you have experience, idea or a good resource about turbo? Programming wise!

My first thought is to use the engine rpm/throttle position to approximate the amount of gas going out in the exhaust, and thus increasing the pressure in the intake part, maybe calculating some spin velocity of the turbines.
I don't have much clue if it's a linear function, or can I derive the power increase from the pressure.
The only useful figure I found was that the turbo increases the output torque by 30-40%

Some other question about lsd differentials. As far as I understand with clutch packed (eg. salisbury) the clutches provide the locking. All the docs I read assumed that when the torque bias ratio and preload were exceeded the diff opens and works as an ordinary open-diff, but I'm sure in this case the preload and clutches still work to lock the wherls. So there is no formulas to calculate this locking torque.

Also if I used some clutch friction just like in the gearbox, that would make the bias-ratio unneccesary, because it would be enough to check if the road reaction torques overcame the clutch torque.

Well, many confusion and white spots, but hoping for Kunos and the other experienced ones to pop up and enlighten my day ;)

thanks for any help and suggestion.

### 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);
solver=new btSequentialImpulseConstraintSolver;
world=new btDiscreteDynamicsWorld(coll_dispatch,overlap_paircache,solver,coll_config);

world->setGravity(btVector3(0,-9.81f,0));

```

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);
shape->calculateLocalInertia(5,inertia);

btTransform trans;
trans.setBasis(btMatrix3x3(1,0,0,0,1,0,0,0,1));
trans.setOrigin(btVector3(0,0,0));

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;
world->removeCollisionObject(obj);
delete obj;

```

The remove method is also from some basic sample.

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

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

Hi,

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

### Debug -/ Release Differences

13 January 2014 - 11:01 AM

Hi,

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

Hi,

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[]={
{0,0, D3DDECLTYPE_FLOAT4,D3DDECLMETHOD_DEFAULT,D3DDECLUSAGE_POSITIONT,0},
{0,16,D3DDECLTYPE_FLOAT2,D3DDECLMETHOD_DEFAULT,D3DDECLUSAGE_TEXCOORD,0},
D3DDECL_END()
};
```

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;

output.pos=input.pos;
output.spec=float4(1,1,1,1);
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!

PARTNERS