Getting v1.7 samples to run with OpenGL?

Hello.

I have the OGRE 1.7 SDK installed, and a long time ago I had compiled 'BuggySwires', which is NxOGRE version 1.7 .

I had recently mistaken it for version 1.6 , but it is 1.7 as the file NxOgreVersion.h shows below:


#ifndef NXOGRE_VERSION_H
#define NXOGRE_VERSION_H

// Some parts of this file is automatically generated.

#define NxOgreVersionMajor 1
#define NxOgreVersionMinor 7
#define NxOgreVersionBuild 3527
#define NxOgreBuildName "Sparked"
#define NxOgreBranchName "BuggySwires"
#define NxOgreVersion 170
//~~ mtime 14f14839cbde1ed467e39090c978cd9e

#endif


What I found was that all the samples I installed into the sample browser run properly when I configure OGRE to run with the DirectX back-end. But as soon as I configure the sample browser to use the OpenGL back-end, the NxOGRE samples that try to render cloth, crash the sample browser.

This problem was already mentioned and known.

I'd like to keep using OGRE SDK version 1.7 . But because my OGRE install on this box is the SDK, and not of the custom-compiled variety, it's limited to using DirectX 9, while it could in principle be using OpenGL 3.2 , which I'd much prefer. My box supports OpenGL 4 and Dx 11.

And so my real question is, did Betajaen ever find out why his cloth samples crash in OpenGL mode? If he did, then maybe I could simply apply whatever correction(s) to the NxOGRE source code are needed, to get everything rendering in OpenGL mode?

Thank you in advance,
Dirk

I'm sorry to bump my question eagerly.

I'm assuming that Betajaen's 'makeCloth()' function should really do a reliable job at creating (8x8) cloth objects.
It's not easy to see, where the malfunction might be creeping in...

I'm based on PhysX 2.8.4

One attempt I've made to solve this problem, was to UNcomment the lines in NxOgreCloth.cpp as below :

bool Cloth::advance()


/**/if (mDrawnAtLeastOnce)
{
mRenderable->drawClothFast(mMeshRenderable, Bounds3::from(bounds));
}
else
{/**/
mRenderable->drawCloth(mMeshRenderable, Bounds3::from(bounds));
/**/ mDrawnAtLeastOnce = true;
/**/}


which tells the rendering engine to use drawClothFast() after the first frame. This must have been intended to reduce the load on the CPU/GPU, after the code was stable. I recompiled nxogre, recompiled critter, placed the new NxOgreDebug.dll into my OGRE\bin\debug folder, which is where some of my OGRE Sample Browser samples are located, placed NxOgre.dll into OGRE\bin\release, where all my samples are located, and then realizing that the demos are statically linked to critter, also recompiled them in administrative mode. Amazingly, NxOGRE and its samples still work! I got one demo to compile on the side, which had failed to compile earlier... I see that drawClothFast() is nevertheless drawing slowly enough, to recompute the vertex normals each frame.

But I did not solve my initial problem... {:-/}

When I run OGRE\bin\debug\SampleBrowser_d.exe , with OpenGL selected, and try to run the sample named "Cloth with external Forces", I get no output from the command window, but get a pop-up window telling me "This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information."

If I then click on the Retry/Debug button, the debug process itself closes leading to the Windows 7 error message, again with no output to the command window. Abort simply closes it with no apparent further error message.

What I tried next, was to define a replacement for the ABORT_IF_EMPTY macro in CritterRenderable.cpp , naming mine SKIP_IF_EMPTY. What mine did differently was not to execute

{ mBox.setExtents(Ogre::Vector3::ZERO, Ogre::Vector3::ZERO); }

before doing

{ return ; }

each passing frame cycle .

I was hoping that a timing issue on initialization was causing an unneeded abort, and that later frames would spell a recovery, maybe with a funky cloth mesh due to interaction with my other modification.

What I found to my disappointment, was that the crash still took place, only that it took place worse. I.e. a half-rendered Sample Browser window continued to persist for several seconds after the crash, suggesting that it was doing my SKIP_IF_EMPTY an embarrassing number of times (maybe at 6000 FPS?)

And so that pretty much concludes what I can do. Critter is clearly calling ABORT_IF_EMPTY, because the vertex count has dropped to < 3 , and the vertex count stays < 3 . But I still don't know why .

Dirk

I've looked at the code very carefully. There exists a certain style here, in which NxOGRE is layered on top of PhysX, and Critter layered on NxOGRE, an then the Tutorial Samples layered on top of Critter, which poses a danger for a 'circularity problem' to arise. The references to 'createCloth()' and that function's cohorts, don't just send me on a wild goose chase, they may actually send the CPU on a wild goose chase.

At one point the functions check to see whether the Cloth object and/or mesh already exist, as a possible way of breaking such a loop. But then in another part of the code, an NxOGRE class inherits this ability from PhysX - where it must ultimately come from. And then if PhysX should fail to provide a cloth object, the derived class may just send the CPU around another lap of this loop that I suspect.

Hence with PhysX 2.8.4 , the odds are very high that this base may not know, how to create a Cloth object if the rendering system happens to be OpenGL instead of DirectX. And then the code keeps trying and trying where there is no way. Basically, the only thing that allows the program to exit gracefully from this, may be the ABORT_IF_EMPTY macro, which I experimented with so naively by turning it into a SKIP_IF_EMPTY operation, which allowed for the loop to get more severe.

And so the only way I might get cloth to work with OpenGL, might actually be through a PhysX SDK upgrade. But I will never do that on this machine, because that can and will break so much code I've got.

Dirk