That's correct.
I'm a major contributor, addicted user and proponant/advocate of ObjAsm32.
Almost all of my projects result in one or more totally new objects being published to OA32's ever-expanding public library, and invariably also result in extensions/enhancements and bugfixes to existing objects and macros.
Three reasons why I love OA32?

1. Rapid Application Development (through implementation of existing objects)
2. Interoperability with COM compliant HLLs (other people can use my stuff)
3. Retaining ASM as the underlying language (smaller, faster, more control where we want it)

And if I don't like some feature of this pseudo-language, or find some vital functionality is missing, I can make the necessary changes, and then petition Biterider to post them to the public.

The 'smart updater' service began as one of my side projects, we're abusing the HTTP 1.1 RESUME function to seek inside a remote zipfile, then we compare 'footprints' of the local and remote files, and build a list of the files that the user might wish to update, allowing them to download a subset of the zipped content, which is sent in the form of single zipfiles (just happens to be how zip architecture works inside a multifile zip).
It means that users can access the latest content on a daily basis without being forced to download the entire set of files.

Posted on 2009-09-16 00:30:52 by Homer
Today I made a small but important and powerful addition to the new D3D_SkinMeshManager class - specifically, to D3D_SkinMeshInstance.

Previously, we had a method called "Attach_To_Named_Bone", whose purpose is to attach a static D3D_MeshManaged instance to an animated Bone of a D3D_SkinMeshInstance.

There is now a new method called "Attach_Alien_To_Named_Bone".
It takes 3 parameters: pointers to an Output Matrix, an Input Matrix, and a String describing the Bone we wish to attach to.

We can use this method to drive arbitrary objects via their Body To World transform matrix, without needing to know anything about the object being driven... or rather, we can use it to drive arbitrary transform matrices.
The input matrix allows for a base rotation and translation of the attachment, with respect to that of the bone.



Posted on 2009-09-16 05:19:22 by Homer
I have refitted D3D_SkinMesh, D3D_SkniMeshInstance and D3D_SkinMeshManager to support proper Release/Restore when the render device is reset.
No memory leaks, and the objects retain their internal data throughout the reset (only the device-dependent pointers have changed when Restore has completed).

These new changes were tested in an updated DX_12_AttachedMesh demo.
Posted on 2009-09-19 19:21:20 by Homer
Reworked a whole bunch of objects used by GameEngine, adding small safety features like checking for NULL pointers at critical moments.... and re-implementing the 'Do Not Render' switch in the main App so that it doesn't attempt to render the 3D scene during a device reset cycle.
The result of these changes is that the application is once more rock solid, and anything that remains disabled will be re-enabled a piece at a time, allowing me to quickly identify any undetected issues (if any).

By eliminating problems methodically, I expect that debugging will remain 'uncluttered', even as the project grows in complexity and scope.
Posted on 2009-09-20 00:34:49 by Homer
Wow, cool, a day off work, and a Monday no less!

Enhanced the Release/Restore methods of SkinMeshInstance for improved state preservation during a Device Reset cycle.
The Release method notes the Animation Time of its anim controller.
Restore method advances the Restored anim controller to this Time, and also patches the pBoneMatrix pointers in any 'bone attachments' (accessories). Note this last step COULD have been avoided, IF I had preserved the BoneMatrix array across the Reset, which is quite doable, given that it is not a device-dependant resource.
For the moment, I am not preserving the full state of the animation controller (IE, per-track properties and event keys used for blended animations, are not preserved). And *none* of this stuff is being done for the SkinMesh reference object, only for managed instances.

Still, its a big improvement:)

Ugh PostScript... we must ensure that the engine does *NOT* try to advance the animation OR render while the Reset cycle is underway. In fact, the app should be doing as LITTLE AS POSSIBLE while we scramble to reload our resources. On multicore machines, we might find something else to display on the screen during the time that 3D rendering is disabled.


Posted on 2009-09-20 20:02:32 by Homer
Half way through my lovely monday off work.
Have not done anything else but gardening in the spring sunshine and relaxing.
This is not a day to waste inside on coding.

:thumbsup:
Posted on 2009-09-20 22:45:22 by Homer
Footnote: I changed SkinMesh to retain the pBoneMatrix array during reset, cool but we still need to patch the bonematrix pointers in attachments, because they point to matrices inside the frametree, not members of the aforementioned array.

Thinking of adding (reset-preserved) scaling to the root frame of the skinmesh frametree.
This way, we dont have scaling in our per instance transform (poison), but its present in all perframe combined matrices throughout the tree, and therefore, also in the output matrices.
And that is accepted by the DX Framed boundingsphere query and etc.

Its a way to avoid scaling all the data at loadtime, while decoupling the scale from the root transform.
Someone can honk their horn anytime now, please comment.
Posted on 2009-09-20 23:29:18 by Homer
Added a new console command for (re)importing the world model.
Not likely to be used often, but cool for developing.
Posted on 2009-09-21 08:28:11 by Homer
I'm currently developing some stuff related to skinmeshes, too, and want to discuss the paths I took:
- I'd rather have anims and meshes in a custom format, rather than .x + D3DX . I find it really easier to manage and extend the animation and its rendering in different ways, plus I can later port+optimize the code easily to any current/future graphics API, even mobiles. Oh well, I use GL, to boot...
- keep the "vec3 pos" and "vec3 quatRot" in keyframes, not matrices. You can keep sin(quatRot.x*0.5) instead of quatRot.x in the animation-file, and encode the sign of the cos(quatRot.x*0.5) in the LSB of the sin()-result.
- decouple animations from model. Decouple bind-pose state from animations. Bind-pose contains the inverse-matrices and bone-names
- make a cache of matrices in a RGBA16f/32f texture if rendering crowds with instancing
- allow dual-quats to be derived and used
- let anim files specify whether a bone is used in it "weightInAnim real4 ?".
- have a proc to accept a vector of active motions and their envelope+rate+curframe . Sum their envelope*weightInAnim, normalize,  do weight-sum of local-space matrices; compute final local matrices.
- have the skeleton keep bones where we can attach objects, simply keep+use the world-space matrix to transform attached object. In code, not persistent attached-state.
Posted on 2009-09-21 09:42:08 by Ultrano
When they said "There is more than one way to skin a cat", they probably referred to a cat mesh :)
Posted on 2009-09-21 10:12:29 by Scali
:D Not only in the programming part, but in the modelling one, too: Physique/Skin1/Distance-to-bones^-16/Weightmap-per-bone/Influence-splines.

Anyway, any ideas/experience-tips from you Scali? A push in the right direction from the start is appreciated :) .
Posted on 2009-09-21 11:08:45 by Ultrano
Not really, at this point, I'm afraid.
I made my own exporter for 3dsmax skinning and animation, but that was years ago. I don't recall much in terms of implementation details.
Posted on 2009-09-21 12:21:02 by Scali
I'm not sold on the .x format either - custom templates or not.
I do find it handy as an intermediate file format (between Maya and my engine), I don't expect to get into bed with it.

I do support attaching of stuff to Bones... Hey, I wrote a demo of Tiny.x with a sword attached to its hand... that part was actually pretty easy, noting that I keep such associations outside of the frametree itself (I share reference skinmesh frametree across N instance objects, with instances owning unique animation controller interface cloned from the ref object, so touching the frametree with per-instance data is a Bad Idea).
I support any number of attachments per bone, and recently abstracted WHAT is being attached, so we can attach anything that has a transform matrix we'd like to drive (eg skinmeshes attached to other skinmeshes).

I've made some early steps toward an integrated "advanced skinmesh animation controller" which supports a lot more than the typical weight/speed/position per track data, however I was the only one who could understand and use it, so I'll be redoing that with input from the end users.

In the meantime, I am simply scripting the keyed events for track transitions and such.
And that reminds me, I added a Console command to execute a series of Console Commands from a textfile :)


Posted on 2009-09-22 02:34:41 by Homer
I'd like some feedback on the following code.
Please excuse my OA32 syntax and see the code itself, guys?

This idea is based on my recent minor epiphany that:
A- The camera view matrix only contains position and orientation - no other junk.
B- If we transpose the orientation, and negate the position, we have the worldspace orientation and position of the camera, and can shove them directly into a BodyToWorld matrix that describes the camera itself.

This is really my first lame attempt at angular constraint, based on my understanding that (ignoring position, scale, shear etc) 'the columns of the D3D orientation matrix describe the axes of the local coordinate system, IE, M00, M10 and M20 describe which way the local X axis is pointing, in WORLD space".

Here I am trying to clone the orientation of the Camera into my Player, while disallowing rotation about the World X and Z axes (only rotation about Y is accepted).

I do this naively, I have no formal education with respect to matrix maths.
Experience yes, education no. Understanding? Some.

;This method is used to rotate the Player to suit the Camera View.
;We are assuming that the Camera is tracking the Player !!!
;Rotation is applied only around the Y axis !!
;Player's XZ Orientation is Transpose(CameraView)
;Y is left at Identity
Method Player.Orient_XZ_From_View,uses esi
   SetObject esi
   mov eax,.pCamera
   ;X axis
   m2m .body.CurrentState.Orientation.m00, .D3D_Camera.mView.m00, edx
   m2m .body.CurrentState.Orientation.m01, .D3D_Camera.mView.m10, edx
   m2m .body.CurrentState.Orientation.m02, .D3D_Camera.mView.m20, edx
   ;Y axis
   fldz
   fst  .body.CurrentState.Orientation.m10
   fld1
   fstp .body.CurrentState.Orientation.m11
   fstp .body.CurrentState.Orientation.m12
   ;Z axis
   m2m .body.CurrentState.Orientation.m20, .D3D_Camera.mView.m02, edx
   m2m .body.CurrentState.Orientation.m21, .D3D_Camera.mView.m12, edx
   m2m .body.CurrentState.Orientation.m22, .D3D_Camera.mView.m22, edx
MethodEnd


It's not meant to be optimal, it's meant to be easy to read, so don't whine about that :P

I'm keen to understand exactly how to constrain orientations, not just to the world axes, but to arbitrary axes (hinges), how to implement a 'cone constraint' (ball joint), and so on. My physics engine only supports spring constraints right now, this would be a huge bonus to support angular constraints of various kinds.

Posted on 2009-09-22 08:12:15 by Homer
Yea, it's generally a good idea to use the object hierarchies such as skeletons or other parent/child relationships only for storage.
You should think of animation as a preprocessing step. You use the hierarchies to come to a final world matrix for every level of the hierarchy, so that you have then 'flattened' the hierarchy into a single space, and just a list of objects to render.
This is also an interesting candidate for multithreading. You could process multiple hierarchies at the same time, as they will mostly be independent (there might be depedent parts, eg when one object is attached to another, or when you want to aim one object towards another, but you generally have to do them in the proper order, so you'll need some kind of multi-pass scheme anyway, where you reduce the dependencies one step at a time).
Posted on 2009-09-22 08:33:10 by Scali
Btw, I think you're missing a fldz in the Y-axis in your code.
What is the code supposed to do exactly?
I mean, all I can see is a 3x3 transpose, where the Y-axis is assumed to be (0,1,0)?
Assuming that the matrix is orthonormal (that is, all columns are vectors of unit-length, and all columns are perpendicular to eachother), then yes, the matrix does define the spanning axis of the space, and yes, in that particular case, the transpose is equal to the inverse.
A rotation matrix is always orthonormal by definition, because rotation (around the origin) doesn't affect scale, shearing, position or anything. As such, the columns of the matrix are always unit length.
Posted on 2009-09-22 10:09:09 by Scali
Nah, I'm not missing a flz .. I used fst, and left it on the fpu stack for a second bite at it.
But anyway - it didnt work, and the reason is obvious.
The three columns form the OrthoNormal Basis of some orientation, and I'm stepping all over the orthonormality by forcing the Y column to identity.

I stated that my intention was to orient a body such that the body's worldspace orientation is that of the camera, but only apon the XZ plane.
I also mentioned WHY I was transposing , and WHAT I was transposing.
I appreciate the feedback regardless.

Posted on 2009-09-22 17:30:48 by Homer

Nah, I'm not missing a flz .. I used fst, and left it on the fpu stack for a second bite at it.


Yea, x87 is evil :)


But anyway - it didnt work, and the reason is obvious.
The three columns form the OrthoNormal Basis of some orientation, and I'm stepping all over the orthonormality by forcing the Y column to identity.


True, you can't use arbitrary rotations and just set Y to identity. Y is only identity when you are rotating around the Y axis. Since you didn't specify what kind of rotations you were using, it was hard to make out whether this behaviour was intended or not (you did say that you wanted to constrain your rotations, I just didn't recognize your code as such, that's where I lost you. I expect constrain-code to look way different, see below).
If you want to force Y to identity, then you can normalize the other two axis to make it an orthonormal base again. Not sure if that works or gives the result you were aiming for however.

Constraining rotations generally isn't done this way though. You normally wouldn't want to use rotation matrices anyway, because they're rather clumsy and unintuitive. Usually you'll want to use angle/axis pairs or quaternions to represent rotations. After all, an orientation is a single vector.
You can extract this information from an orthonormal matrix. I believe D3DX actually provides functions for that.
This way you could for example just create a projection of the rotation axis into a plane, remove one of the components from the axis, clamp the components of the axis to a certain range... that sort of thing.
Then you generate a new matrix from the resulting orientation.
Posted on 2009-09-23 03:51:24 by Scali
I acknowledge that there are many good reasons to use quaternion rotation and not many reasons to use matrices.
In this case, I am merely experimenting with what I can do with data that I have extracted from the view matrix. I've used it to extract frustum information, and I've used it to find the Camera's worldspace transform matrix.. I was wondering what else I might be able to leverage out of it.


I've been shifting some code around in the Physics Simulator component of my GameEngine project.
In particular, I have been moving slabs of code from the Simulator core into the CollisionBodyInstance object where they properly belong.
The code I moved implements the resolving of manifold collision contacts for entities involved in collisions, with or without friction.


Posted on 2009-09-23 09:21:07 by Homer
The earliest version of my PhysicsEngine was not designed to cope with instancing of physical entities.
Although the current version IS built with instancing in mind, theres a bunch of legacy code that needs moving and adjusting, because the focus of the engine has shifted a lot since the early days.
My physics engine was based partly on the Cyclone engine, partly on the Bullet engine, and partly on the random musings of a guy called Richard Chaney (No, the OTHER Dick).
Richard was the first to introduce me to 'DSpace', and explain clearly the difference between Diagonalized BodySpace and regular BodySpace, and why Diagonalized space is a better place to be working.
I took his work further, by manipulating the BSpace representation such that BSpace and DSpace are the SAME space, eliminating some more math operations.
Posted on 2009-09-24 01:14:43 by Homer