Problems with creating cloth (0.9-33)

Hi,

I hope no one minds me posting it again, I thought maybe the sticky topic wasn't good place for that

Anyway, I use nxogre 0.9-33, physX 2.7.2 and ogre 1.4.2. I tried to create cloth using betajaen's cloth instructions from "NxOgre 0.9 - JSON the fourth serialisable format. - 0.9-28" topic - link to post http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=4292&postdays=0&postorder=asc&start=165#25879

Unfortunately, no luck, none of the code samples work, I tried it with several meshes, also with meshes from cakebox, but I aways ended up with assertion:

Assertion failed: (min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"

It looks like some problem with mesh created by NxOgre - can't calculate its bounding box.

Is it just me or maybe no one is using cloth in their applications? Any thoughts about what I can be doing wrong? Thanks in advance.

I use roughly the same setup as you, but try upgrading to Eihort 1.4.3, I think I recall something in Ogre causing that error.

Thanks, I'll upgrade and let you know if it solves the problem. I was going to upgrade anyway soon, but you gave me the right motivation

Well, I was almost sure, that upgrading Ogre will solve this problem, but unfortunately it didn't. I've done some testing and debugging, I've come closer to the problem, but I'm still not sure what is causing it.

The assertion is called in cloth::render method(nxogrecloth.cpp, line 941), in section that is responsible for updating the bounding box - mMesh->_setBounds(mAABox) - to be precise.

And now the funny part:
1. It does not happens when I add cloth to my scene(as I thought before)
2. It happens inside my rendering loop, during simulation - I don't use frame listeners, I manually call scene->simulate and scene->render
3. It only happens when using variable time step(time-step-method: variable)
4. And it happens after third loop...

I don't do anything special in my loop, the usual - input, physics, rendering...

Any ideas? Thanks.

Can you get the value of the bounding box at all?

Also, you really shouldn't manually call scene->simulate and scene->render like that, there are other things that are called outside the scene during that time, use it the intended way:

mWorld->getPhysxDriver()->simulate(deltaTime);
mWorld->getPhysXDriver()->render(deltaTime);

Sorry that It took me so long to reply, I was having some Internet connection problems.

First off all, when I wrote:
I manually call scene->simulate and scene->render
I actually meant world->simulate and world->render. Sorry for that, but thanks anyway, because I checked and noticed that PhysXDriver::simulate is little different then World::simulate - using it as it was intended now.

Second, if by Can you get the value of the bounding box at all?
you mean this call
mCloth->getWorldBounds(mNxBounds);

then no,

mNxBounds {min={...} max={...} } NxBounds3

min {x=-1.#IND000 y=-1.#IND000 z=-1.#IND000 }
max {x=-3.4028235e+038 y=-3.4028235e+038

And as I said, it only happens when using variable time step, forks fine when working with fixed...

PS. Currently working with:
NxOgre (NxOgre 0.9-34.Debug)
- PhysX => 2.7.2
- Ogre => 1.4.4 'Eihort'
- Platform => Windows Debug

I actually meant world->simulate and world->render. Sorry for that, but thanks anyway, because I checked and noticed that PhysXDriver::simulate is little different then World::simulate - using it as it was intended now.

Like you, i'm using variable time step and manually stepping the world but with my own scenecontroller (the stepper).
Try to clamp the elapsed time in the render&simulate calls to a maximum value (1.0/10.0 for example).

in pseudo code:

if( evt.timesincelastframe > 1.0/10.0 ) // 10Hz
{
FrameEvent fakeEvt;
fakeEvt.timesicelastframe = 1.0/60.0;
fakeEvt.timesicelastevent = 1.0/50.0;
world->render( fakeEvt );
world->simulate( fakeEvt );
} else
{
world->render( evt );
world->simulate( evt );
}


Hi, I'm back with solution and some observations

1. I managed to locate the reason of those crashes, but to be honest, I don't get why cloth had issue this - any other simulations worked fine.

2. I observed that cloth seems to be, how to put it, picky, choosy ?
--

1. Here are basic pseudocode samples for main loop. One of them works fine, another crashes when cloth is used in scene. See it for your self.

Fine:

Ogre::Real timeLastFrame=getTimer()->getMicroseconds()/1000000.0;

for(;;)
{
Ogre::Real timeCurrentFrame = getTimer()->getMicroseconds()/1000000.0;

mTimeStep = timeCurrentFrame - timeLastFrame;
timeLastFrame = timeCurrentFrame;

World->getPhysXDriver()->simulate(mTimeStep);
World->getPhysXDriver()->render(mTimeStep);

messagePump();
renderOneFrame();
}


Crashes:

Ogre::Real timeLastFrame=getTimer()->getMicroseconds()/1000000.0;

for(;;)
{
Ogre::Real timeCurrentFrame = getTimer()->getMicroseconds()/1000000.0;

World->getPhysXDriver()->simulate(mTimeStep);
World->getPhysXDriver()->render(mTimeStep);

messagePump();
renderOneFrame();

mTimeStep = timeCurrentFrame - timeLastFrame;
timeLastFrame = timeCurrentFrame;
}


As you can see, the only difference is placement of those two lines:


mTimeStep = timeCurrentFrame - timeLastFrame;
timeLastFrame = timeCurrentFrame;


This produces almost identical results (test run - two timer in one loop):

Crashes: 0.000000 || Fine: 0.000002
Crashes: 0.000002 || Fine: 0.008663
Crashes: 0.008662 || Fine: 0.255278

I tried to keep it short as possible, I hope this helps in any way.


2. Cloth seems to behave different when fps if higher. I created a scene: floor and 2 spheres - cloth and normal body. Cloth(deformable) lies on the floor, and the other body falls on it from above.

When running at ~90 fps, the cloth gets deformed as expected.
But, when running at ~500 fps, the body bounces back, like it would hit a rock, and cloth stays as it was (undeformed). Anything else is as it should be, I checked - falling body has the same velocity, so it must be something with cloth...

See it for your selfs:




Maybe someone will get to some conclusions.

And last but not least, thanks luis for the hint. Although your suggestion didn't solve my problem but I started looking closer on what time I'm passing and found that little thing in my timer that I described at the beginning of this post.

Cheers