I base that statement on observation of comparative performance of the available modes in microsoft's skinning demos, the ones that shipped with the dx sdk. I intend to use the gpu for per-pixel radiosity transfer and soft shadows.


Posted on 2009-07-03 09:11:23 by Homer

I base that statement on observation of comparative performance of the available modes in microsoft's skinning demos, the ones that shipped with the dx sdk. I intend to use the gpu for per-pixel radiosity transfer and soft shadows.


Well, I haven't checked out the DX SDK skinning samples (I suppose their examples are often written for clarity's sake, the shaders are usually not optimized... they even do the world/view/proj matrices separately in shaders, in many cases... That's one way to suck the performance out of your GPU :)), but as you see, I made my own implementation of skinning... Does seeing that performance change your mind in any way? Because it's clearly WAY faster on a GPU than on a CPU.
Posted on 2009-07-03 09:19:23 by Scali
I'll leave the option open to perform skinmesh animation on the gpu, the major drawback being that I no longer have easy access to the transformed geometry for collision detection purposes, if I decide I'm willing to compromise on the quality of collision detection against animated skinmesh, which sounds likely, then the gpu will clearly be the way to go.

I'm not getting far with porting in (the collision detection portion of) my physics engine, I keep changing my mind about exactly what kind of interactive interface I want (eventing model being the main point of contention).
Until I settle on exactly what I want, I'm just fumbling between RadASM IDE and pen/paper.
I don't consider it a waste of time when compared to (re)writing crap code a half dozen or more times while attempting to converge on the grand design.

So I'll fumble away for another day or two, rearranging the bones until they match the structure of the animal in my mind, then I'll start shovelling the code into place.

Posted on 2009-07-03 23:19:15 by Homer

I'll leave the option open to perform skinmesh animation on the gpu, the major drawback being that I no longer have easy access to the transformed geometry for collision detection purposes, if I decide I'm willing to compromise on the quality of collision detection against animated skinmesh, which sounds likely, then the gpu will clearly be the way to go.


Well, I think it's highly recommended to use lower resolution meshes for physics than for rendering. You can easily render millions of polys per frame, but doing collision detection on all of them is a different story. Besides, the precision isn't really required. Collision detection is always an approximation anyway.

Another thing is that it may be smarter not to do collision detection in world space (which in the case of skinned meshes may not be an option, but for everything else it should be). You could just bring one object into the object space of another, which probably saves you a lot of transformations (with bounding volumes you can probably eliminate most object-to-object tests long before you actually start testing on a triangle-for-triangle basis... and even then, you could use hierarchical bounding volumes to only test the nearest part of the mesh).

You might also want to use a slightly different format than for rendering anyway. You don't need anything but the vertex positions themselves, and perhaps the normals. Everything else doesn't really have meaning (make it more compact, improve caching, reduce bandwidth). On the other hand, you may want extra mesh info that has no meaning for visualization (like the already mentioned different detail and some kind of hierarchical bounding volumes perhaps).
Posted on 2009-07-04 01:45:15 by Scali
Well, I came up with a novel way to detect collisions quickly on convex polytopes, after analyzing the GJK algorithm.
It involves an exhaustive binary tree of 'mesh features' which allows me to quickly identify the closest pair of features on two potentially colliding bodies.
I'm tempted to implement it, as it looks to be several time faster than GJK.
The result, for each body, is a 'binary sphere tree', which has one feature in each Leaf node, and collision detection involves a 'dual tree walk', which is basically no more expensive than walking either tree.
Posted on 2009-07-04 08:25:55 by Homer
I've finished porting the 'timecore' (the main Physics Simulator object) into my GameEngine class.
Previously, the simulator was in charge of a single list of all the physical entities in my World.
Now, it can process a given (sub)set of physical entities, which for me will mean 'one subspace worth'.
This will allow me to disable collision testing / physics for subspaces which don't contain a moving entity, essentially extending the World partitioning scheme to the physics simulation.
This might not sound like a great idea at first, unless you know that my collision engine exhaustively tests all combinations of two bodies in the 'broadphase' collision test.... its an O2N kinda deal.
I have introduced a constraint: A body may only collide with World surfaces and other Bodies which are in the same subspace.
This is not strictly accurate, I'll need a special behavior for bodies that are near portals.
But this constraint greatly reduces the number of bodies involved in a given round of collision detection.
And that should translate into an overall speedup of several orders!

Posted on 2009-07-05 00:54:53 by Homer

This might not sound like a great idea at first, unless you know that my collision engine exhaustively tests all combinations of two bodies in the 'broadphase' collision test.... its an O2N kinda deal.


O(N*N) even, I suppose.
Posted on 2009-07-05 12:29:46 by Scali
my typo :P


Posted on 2009-07-06 01:20:55 by Homer
The architecture now looks something like this:

GameEngine
|               |
Simulator  =>  BSPGenerator
|                        |
CollisionBodyInstance =>  CollisionBody

Posted on 2009-07-06 08:49:49 by Homer
Progress is slow, partly because I find the work tedious right now, and partly because I'm making relatively major changes to the architecture, including some new support for tetrahedron-based volumes.
Posted on 2009-07-09 08:34:03 by Homer
Work continues - the CollisionBody baseclass is pretty much ready to rumble, the port is starting to look more like something and less like a mess.
Posted on 2009-07-11 05:09:25 by Homer
I'm adding code to CollisionBody which manipulates its Reference Mesh...
I am interested in ensuring that the Center of Mass coincides with the Center of Rotation (ie, the Origin 0,0,0 in BodySpace).
And I am interested in rotating the Ref Mesh such that the Inertia Tensor is Diagonalized (ie, the Principle Axis of the body is oriented along a major cartesian axis).

My physics engine currently expects that Inertia Tensors are Diagonalized (and so could be stored as a Vec3 rather than a Mat33), and that the Body's center of mass is at its Origin.
By enforcing these conditions in the BodySpace representation of the Mesh (its bindpose), I can eliminate 'Diagonalised BodySpace Matrices' from my Physics calculations, which keeps open the option of accelerating Tensor-dependent computations by replacing Matrix functions with their Vec3 equivalents, and allows me to continue using my existing physics implementation without a huge overhaul to compensate for D-space. Thankfully, I've written a D-Space dependent physics simulator previously, so I saw this catch coming, and I'd already decided on this workaround.

Also, I've read some interesting arguments AGAINST using RK4 numerical integration in favour of traditional Euler integration (with smaller steps)  !!! My existing integrator is Euler, so I'm happy to leave it that way, I did code an RK4 integrator, but it's not a feature of this physics engine.

Posted on 2009-07-12 02:58:52 by Homer
It's worth noting that the elimination of 'diagonalising matrices', and the speedup and memory saving obtained, come at a cost... I won't be able to construct 'compound' bodies from a set of simpler ones with arbitrary rotations.
However, I don't see this as a problem since I'm supporting importing of arbitrary meshes as rigid bodies.
Posted on 2009-07-13 10:33:14 by Homer
This thread will be idle until the Physics code catches up to the GameEngine.
Please see my Physics 2009 thread until further notice.
Posted on 2009-07-15 02:19:03 by Homer
Found some lurking problems in the Portal Discovery code.
A couple of small bugs, and a flaw in my implementation.
Having corrected these bugs, my three current test models all process perfectly.
But the last one does not render correctly, and one of its textures is shared.
Maybe I forgot to export UVs or something dumb like that.
Posted on 2009-07-20 11:35:27 by Homer
Oh, I had just forgotten to correct the texturenames in the model datafile.

Found another bug involving 'fake' portals being detected and removed from the main list of portals, but not from the portal-ref lists in each of the leafnodes connected by that portal.
This meant that I had references to dead objects laying around to give me pain.

Everythings working lovely now, I rewrote my portal render code to draw the Portal polygons as 3D lines, rather than tesselating them into filled triangles, and I added some more onscreen information (text tells you which Leaf you (the camera origin) are in, and how many Portals (exits) are associated with this Leaf.

This really brings the demo to life as you cruise around in the more complex world models.
Starting to feel like a game engine :)
Posted on 2009-07-21 00:09:32 by Homer
Today I added my first console command - GOTO N
This command teleports the Camera to the center of the given subspace.
I'm not sure how useful this will be, but its nice to be able to zap yourself back into the world model if you accidentally get lost in the infinite void outside of the world model !

Still looking forward to adding some collision handling, but since the camera is not connected to any kind of physical entity, and I don't have any other entities to play with (except those crazy spinning tiger meshes, which are not collidable entities), it would probably be a good idea to add commands/controls for creating physical reference bodies and their physical instances, and manipulating them in worldspace.
Once I have something to play with, I can think about collisions.

The collision detection engine is built into the physics simulator, so get used to seeing me posting both in this thread and in the physics thread in regards to these related topics.
Posted on 2009-07-22 04:23:28 by Homer
It's been slow progress over the past week, mostly due to problems integrating networking support (which resulted in a new OA32 update - now available!), because I have not been able to devote as many hours to coding this week (I am self employed, demands fluctuate) and because I've got a nasty cold which has put a damper on my enthusiasm and a cap on my concentration span.

I've written myself some design notes in regard to implementing of networked physics, with consideration of common clientside hacks used to cheat in today's online games.

I've added two buildtime switches to the GameEngine.
The first determines whether we are building a Client or a Server application.
And the second determines whether its a Release build, or a private Developer (editor) build.

The main application class was duplicated and modified, such that there are now Client and Server classes, one of which is included based on switch #1.

Both versions of the app class have been provided with NetEngine support (OA32's iocp-powered networking engine), however the two classes have quite different resource requirements now, and so various objects have been removed from each class, and not from the other class.. for example, the Server contains no Console support.

Speaking of which, theres a new Console command: "connect hostname portnumber" - the client and server are able to establish a network connection, but that is as far as I got.
I should have some basic packet exchanges working by the end of the day.
Posted on 2009-08-01 22:17:12 by Homer
Today I eliminated what I believe was the last bug in the current implementation.
It caused some Portal polygons to be split unnecessarily, generating a few more polygons than required.
Also, I've identified a number of improvements in the base algorithms which should yield a nice fat speedup, both in the BSP generator and in the render engine.

Attached is a screenshot which shows what portals SHOULD look like in the orthogonal test world #3 (well actually, we dont DRAW portals, this is only to demonstrate that there's no weirdness).
Attachments:
Posted on 2009-08-13 03:16:04 by Homer
Today I implemented a snazzy FirstPerson Camera , under some control bits so I can add ThirdPerson and other camera modes, and lerp between them if I want.

Now its a lot more fun to navigate the current test world as a disembodied camera :P

I guess simple camera/world collisions should be next, although im tempted to continue with adding more camera modes and getting a player avatar onscreen...
Posted on 2009-08-17 04:32:20 by Homer