stacking boxes in 1.53

[PJani]

I created very simple performance grapher.

Here is screen shot in bottom left side are PerformanceTick results. Performance counter uses MICROSeconds[us].
And simple graph of WORLD_UPDATE. other graphs are not jet implemented.

[Julio Jerez]

Ha ok for what I can see nothing that can nor be solve, the dynamics does not seems to be problem, it is low 2 milliseconds
I see your force call back is about 1 millisecond are you doing a lot of work on it?
The collision is the biggest problem it is on the high 10 milliseconds, but we can remedy that.
When you add the graphic for each of the systems, we can have a better picture, but that seem to be a fair judgement of the situation.


I see the collision narrow phase takes the majority of time as the cylinders settle on the terrain.
Cylinders are an expensive collision shape because they take a lot of time to go to rest and the contact catching almost never help because they have perfect smooth surface and the keep rolling.

Cylinders are good for when you need perfect rolling behavior but it is better approximate them with convex shape of a finite number of faces. You can approximate the cylinders with a 12 or 16 side convex Hull.
I beleive that t if you do the time in collision will be cut in more than Half.

Also now that you can see the profiler you can try switching the different solver mode.
Mode 1 is the fastest.
Also try switching to SIMD and Multithread and you can see what is better.

But the most important is that you use a cheaper shape if you are going to have some many cylinders packed together.


If you do teh tes with convex or maybe even with boxes , an dif it run better, then let us see if we can optimize teh cylnder/ cylender collision.
Besically Cyyliden/ Cylder is vert cheap bu I am usin a general conve hul/Conve Hul with take a lot of time.

This is similar to the Marc demo when I was also using a general convex/Convex for Ellipsoid and it was slow, but after when I added the special code it became fast.
First we need to see if that is the problem before proceeding.

I never thought the people will use so mane of the Smooth shapes, I was expecting the convex hull to be the main collision shape,
I am positive we can make 4 to 5 time faster, with a close form dedicate Cyllider collision solver.
I never optimized the close from shapes, but having a test case is a good motivation for doing it.

can you send me the executable of that demo, so that I can work on uptimizing the cylinder with a test case?

[tiresius]

I never thought the smooth shapes would be slower than a convex hull. I always assumed the included shapes were highly optimized in the engine, and a convex hull would be slower. Well, you learn a new thing every day, I guess.

[PJani]

Hmm, these are all convex hulls(becouse i build automaticly all collisions and i dont have template system for collisons(for now)). all 400 of them are convex hulls one is TreeCollision
And i will try to send you another demo, becouse this project s really really heavy(boost python manager, threads, sound manager, vehicle manager,...) more than 30k of lines.

force callback is like this so i can add force

Code: Select all

void PhysicObject::forceCallBack(OgreNewt::Body* m_pBody,float t,int ThreadID)
{
    Ogre::Vector3 g = Ogre::Vector3(0,(-9.803),0);
    //!OUTSIDE FORCE
    //!/////////////////////////////////////////////
    if(isTouched)
    {
        while(!m_Torque.empty())
        {
            FORCEPAIR f = m_Torque.front();
            m_Torque.pop();
            m_pBody->addTorque(f.first);
        }

        while(!m_LocalForce.empty())
        {
            FORCEPAIR f = m_LocalForce.front();
            m_LocalForce.pop();
            m_pBody->addLocalForce(f.first,f.second);
        }

        while(!m_GlobalForce.empty())
        {
            FORCEPAIR f = m_GlobalForce.front();
            m_GlobalForce.pop();
            m_pBody->addGlobalForce(f.first,f.second);
        }

        while(!m_Impulse.empty())
        {
            FORCEPAIR f = m_Impulse.front();
            m_Impulse.pop();
            m_pBody->addImpulse(f.first,f.second);
        }

        isTouched = false;
    }

    //!BOUYANCY
    //!////////////////////////////////////////////////
    OgreNewt::Body::buoyancyPlaneCallback boostbnd_bouy_pln_cbck = boost::bind( &PhysicObject::waterPlaneCallBack,this,_1,_2,_3,_4,_5);
    m_pBody->addBouyancyForce( 1000, 0.001519, 0.000001519 , g, boostbnd_bouy_pln_cbck);

    //!GRAVITY
    //!///////////////////////////////////////////////
    //!Fg = m * g
    Ogre::Real mass;Ogre::Vector3 inertia;
    m_pBody->getMassMatrix(mass,inertia);

    Ogre::Vector3 gravitation_force = g * mass;
    m_pBody->addForce(gravitation_force);


}


[JernejL]

I never thought the smooth shapes would be slower than a convex hull. I always assumed the included shapes were highly optimized in the engine, and a convex hull would be slower. Well, you learn a new thing every day, I guess.

They are optimized, but they never go to rest because they keep on rolling due to the shape, same as spheres, if you had a perfect sphere and a octagon sphere, the octagon sphere would stop rolling and go to rest earlier, because it is more rough and has more distinct flat surfaces that can stop it, your problem is, that cylinders don't go to rest and they remain active simulated bodies.

[Julio Jerez]

I never thought the smooth shapes would be slower than a convex hull. I always assumed the included shapes were highly optimized in the engine, and a convex hull would be slower. Well, you learn a new thing every day, I guess.

They are in the sense that if you want to make a smooth cylinder with a convex hull you will need so many point that it will be very big in memory and will end up being slower.
But if you make small shape like 12 of 16 division obviously will be very rough and but the collision will be much faster since it will ne have to emulate the smooth surface.
but you are right after 1.5 I stopped optimizing the smooth surfaces and put all the effort in the convex since it can solve all collision but at the expense of more iteration for smooth surfaces.
I guess the rule will be if you need a cylinder use a cylinder, but if you need a shape the approximate a cylinder then a hull will be better.

It does no matter because like Pjani said he is using convex hulls, the only question I have is how big the convex are?
How many points per shape, are you trying to make a smooth surface by a high degree of texelation?
Do you have a debug dispel so that we can see how complex those barrel shapes are?
Or maybe can you run a test say replace the Hull shape for Box Shape since they are very small and see if the performance get better?

I am suspicious of eth performance graph getting higher and higher over time.
The last time a Have a bug like that was win my CPU fan fall if and every time I run a program the uses he CPU the heat slowed it down,
I like to see if the performance curve settle or if it keep going higher and higher.

[PJani]

Hmm, im trying to get working visual display of bodies but no luck.
This barrels are low poli so the convex hull should be very rough.

The graph starts after few moments slowly falling down(autosleep steps in). My cpu is not overheating and i am very sure.

I created the same thing with boxes and i found out the graph is much lower and few fps better performance.

[Julio Jerez]

The graphics going up staditly does no look good.
I like to see more diffrence on this like see what happen wien to se two cores, and SIMD,

Also what happen if you dispersing the bodies over the terrain?
to see whe it the different in performaces?