Toy vehicles (again)

[Flix]

Hinge2VehicleDemo.jpg

This is mostly a restyling of the Hinge2VehicleDemo I made several years ago (further details here: http://www.bulletphysics.org/Bullet/php ... =17&t=4660).
I've just added a forklift and a generator of planar railway tracks (*).
For the restyling, I reused the libOpenGLSupport extension (in the OpenGLEx project subfolder), I introduced here: http://www.bulletphysics.org/Bullet/php ... =17&t=7159, and "btHACDCompoundShape.h" (same link) to perform convex decomposition of concave meshes at init time.
Hope you like it!

(*) Actually I've recently discovered that simple bridges work quite well with it.

[Edit:] There is probably an error in the source code. In file OpenGLEx/GlutDemoApplicationEx.cpp, in method GlutDemoApplicationEx::localCreateCollisionObjectByUnwrappingCompoundShape(...), please replace:

Code: Select all

const short collisionFilterGroup = GetDefaultCollisionFilterGroup(collisionFilterGroup,false);
const short collisionFilterMask = GetDefaultCollisionFilterMask(collisionFilterMask,false);
m_dynamicsWorld->addCollisionObject(co,collisionFilterGroup,collisionFilterMask);

With:

Code: Select all

const short collisionFilterGroup2 = GetDefaultCollisionFilterGroup(collisionFilterGroup,false);
const short collisionFilterMask2 = GetDefaultCollisionFilterMask(collisionFilterMask,false);
m_dynamicsWorld->addCollisionObject(co,collisionFilterGroup2,collisionFilterMask2);

Sorry for the inconvenience .

[CHAOS-THEORY]

are you kiddin me, CPU is not fast enought to bla bla...
Which means my CPU have a Special Core to handle TrickyTruck's physics? i didn't knew that lol

[Flix]

are you kiddin me, CPU is not fast enought to bla bla...
Which means my CPU have a Special Core to handle TrickyTruck's physics? i didn't knew that lol

If you look at the code:

Code: Select all

	static btScalar bulletFixedTimeStep(btScalar(1.)/btScalar(60.));
	static unsigned long frame(0);	// A simple frame counter
	++frame;


	float dt = (getDeltaTimeMicroseconds() * 0.000001);
    if (dt>6*bulletFixedTimeStep && frame>5)	{
		printf("Error. CPU is not fast enough to produce physic support at frame n.%d\n",frame);
		dt=0;
	}
	else m_dynamicsWorld->stepSimulation(dt,5,bulletFixedTimeStep);

you should understand that that message appears only if the max number of physic substeps is reached in stepSimulation(...) in a particular frame.

That simply means that your CPU is too slow to run the demo if this message gets displayed continuously for multiple frames. This is important to detect when physic cycles are "eaten" and the physic simulation is not good due to the lack of CPU power. In the demo this message appears for sure when you take a raycast screenshot (but for a single frame).

In short: if you see that message for a specific frame do not worry, otherwise your PC is really too slow to run the demo.

But, above all, for your interest, I don't sell CPUs and I'm not kidding anyone.

[CHAOS-THEORY]

Tricky trucks physics are more sofisticated then your's and i still cant get in mind that i can't play ur game which seems less CPU hunger. well thanks anyway keep selling CPUs lol

[c6burns]

Tricky trucks physics are more sofisticated then your's and i still cant get in mind that i can't play ur game which seems less CPU hunger. well thanks anyway keep selling CPUs lol

Your attitude is as bad as your CPU (mostly kidding)

[Flix]

I've made a small video based on the code I posted here, although I've added some extra features:


[Edit] I've added another video to show a different railway-circuit (with a bridge) that can be created using the same railway generator included in the source code: