Newest version not working for me

Coordinator
Jan 25, 2008 at 2:51 AM
Edited Jan 25, 2008 at 2:54 AM
I uploaded the current engine version and it isn't running. I'm breaking during the manager activation.

BaseManager manager = Activator.CreateInstance(type, new object[] { game }) as BaseManager;
if (manager == null)
{
     throw new Exception(string.Format("Manager type '{0}' was not found", typeName));
}

Here is the XML line that isn't working:
"QuickStart.Physics.PhysX.PhysXPhysicsManager, QuickStart.Physics.PhysX"

I'm not sure if I'll be able to upload my changes properly if I can't test them on the new code base. All I would be sure of is that it compiled properly.
Jan 25, 2008 at 3:13 AM
Did you install the PhysX System Software, like it says to in the change set notes? :)
Coordinator
Jan 25, 2008 at 3:23 AM
Install the what? Like is says in the what? :oP

Maybe I should do that....

By the way, when you use 'cpc checkout' you don't get to see the changeset notes.
Jan 25, 2008 at 3:26 AM
http://www.ageia.com/drivers/drivers.html
Coordinator
Jan 25, 2008 at 3:39 AM
We should post this info on the 0.19 page
Coordinator
Jan 25, 2008 at 3:43 AM
Here's my performance numbers for this build, just FYI:

Debug, ~19fps average
Release, ~120fps average

I think wrapping 512x512 texture around every box might be bad. One thing for sure, physX is definitely harsh on debug mode. Or even just physics on that many boxes, period.
Jan 25, 2008 at 5:39 AM
Edited Jan 25, 2008 at 5:40 AM
If you were using BE you would already know that you hadn't have PhysX and that you would need to install it (and where you could get it) :p
Coordinator
Jan 25, 2008 at 6:22 AM
Yes, I'm going to begin using it with my next patch. I wanted to get my input stuff in asap. Thanks for BE by the way.
Jan 25, 2008 at 1:53 PM
It's not PhysX itself that dislikes debug mode, it's the C++ compiler. The PhysX code itself is all release built, in all cases. Unlike the C# compiler that does jack for optimizations and relies on the JIT run-time, the C++ compiler will practically disable all optimizations in debug mode to create as close as possible to a 1 to 1 mapping between source code and generated assembly. Also, it does checks on STL containers and I'm sure C++/CLI adds its own checks that can bring it to a halt. I'm surprised the difference is so huge though. I get maybe a 50% difference, max. Not your order of magnitude difference.

PhysX actually handles boxes very well. On one core, I can set up a few box streams on the terrain (see BoxStream in SampleScene.cs) and get decent frame rates with 1600 of them. The bottleneck is the terrain. If you can localize the boxes to a small section (like BoxStream does, with a vertical stack), then it's great. But if you spread things out (like the BoxGrid in the sample), then is has to do a lot more terrain checks.
Coordinator
Jan 25, 2008 at 3:30 PM
Is there anyway to speed up the interaction with the terrain?
Jan 25, 2008 at 4:16 PM
Use a lower LOD on the terrain, or use less boxes. Code-wise, all of the important stuff is done in the PhysX binaries, so that's out of our control. But to be brutally honest, I don't believe any all-managed physics code (keeping the same functionality) would come even close to that performance.