http://www.gamedev.net/blog/515-journal-of-aardvajk/ Journal of Aardvajk Syndication Wed, 17 Apr 2013 20:56:31 +0000 support@gamedev.net (GameDev.net) IP.Blog 60 http://www.gamedev.net/blog/515/entry-2256309-3d-modeller-progress/
I've implemented a vertex shader system to deform the model according to up to four vertex weights that is all working fine. You can assign a colour to each bone and the screenshot shows the model coloured based on its vertex weights. In animation mode, you can position the skeleton and set keyframes, and the model is deformed accordingly. You can then assign the keyframes to an animation slider and playback the animation and so on.

I originally had a GUI to assign the weights a little like Milkshape with a list of comboboxes with sliders, but I've actually just removed this as it was fiddly and not easy enough to use. I'm not quite sure what I'm going to implement instead. I've been watching YouTube videos of how things like Maya and 3DSMax handle rigging but not yet quite seen what I'm looking for.

Once I've implemented this though that pretty much covers the animation system. I can then think about texturing, which is the main missing component at the moment. After that it is really just a case of tidying up and adding a few features here and there but the bulk of the work is done.

I'd also like to improve the vertex shader so I don't have to use a full matrix palette as it seems quite limiting in terms of how many bones I can support. I've been reading up about just passing quaternion and translation vectors into the shader instead and generating the matrices on the fly but not sure this is worth it since this only halves the memory required by my calculations.

Seems a shame that at the moment I can only support about 60 bones. Sounds like a lot, but I can imagine hitting that limit quite quick on a fully rigged biped with fingers. Not that I intend to make such models, but when you're working on a general editor, you like to be as flexible as you can. I may have to bite the bullet and fall back on software for the animation but would prefer to avoid this if possible.

Got a few slowdowns as well that I need to address. Performance is generally quite good as has been the priority all the way through but seem to be hitting some issues since I implemented the vertex shader that supports matrix-palette-based animation so need to address that.

That's all. Thanks for reading.]]> Wed, 17 Apr 2013 20:45:00 +0000 http://www.gamedev.net/blog/515/entry-2256309-3d-modeller-progress/ http://www.gamedev.net/blog/515/entry-2256219-3d-modeller-progress/
Charm (Character Modeller) is a Milkshape inspired low-polygon 3D model editor and animation package. Think Milkshape with a modern interface and additional features and you're almost there.

I've already finished the modelling tools and have just completed the skeleton animation system. I've not yet set up vertex skinning - that's next on the list, but the existing feature set is quite complete apart from that.

Features:

• Unlimited undo/redo
• Automatic reflection of model across an axis (with smoothing of joining vertices)
• Animation based on rotation and translation key frames and interpolation
• Usual set of model tools (move, scale, rotate, extrude edges/faces etc)
• Usual modellng operations (weld, split, split edge, snap together etc)
• All views fully customizable
• All views fully free-rotatable, including orthographic views (significant improvement on Milkshape)
• All views fully editable, including perspective views (significant improvement on Milkshape)
• Fully customizable keyboard shortcut system for all actions, selections etc

Not sure what kind of market there is for low-poly modellers these days. Mine is far simpler than Blender obviously but personally I don't find Blender easy to use so this simpler application may be of use to others.

Doesn't matter though, mainly written for my own use and for fun. Will need some models now I've started getting somewhere with 3D physics.]]> Sun, 24 Mar 2013 22:20:00 +0000 http://www.gamedev.net/blog/515/entry-2256219-3d-modeller-progress/ http://www.gamedev.net/blog/515/entry-2255636-character-controller-coping-with-slopes/
The controller tracks a floor face that it is currently 'on'. If no face is set, when the collision detection runs, if an object returns a separation vector with a Y value greater than a threshold, a ray is cast from the base of the capsule to see if it is directly underneath. If it is, the length of the ray from the capsule to the nearest face is stored, and the face is set to be the current floor face.

Each loop, if a face is set, a check is made to see if the distance from the capsule base to the face is greater than this distance. If so, the floor face is cleared and the object is considered to be in the air again.

Gravity is only applied each loop if there is no current floor face set.

The next part involved googling around for some maths to produce a quaternion representing the rotation from one vector to another. The movement vector is produced in response to velocity as if it is flat across a plain. But when a floor face is set, I compute a quaternion from (0, 1, 0) to the normal of the floor face, then extract a rotation matrix from this quaternion.

Then, when a floor face is current, the movement vector is just transformed by this matrix (the white cross in the image shows some test code to ensure this worked properly) and the capsule moves along the slope at the same speed it would have moved along a flat plain.

A small amount of tolerance when checking the distance is required to allow for smooth passing from one shape to another but generally this seems to work perfectly. Next up, I need to figure out how to have a maximum slope limit but we are certainly getting there.]]> Tue, 01 Jan 2013 10:15:00 +0000 http://www.gamedev.net/blog/515/entry-2255636-character-controller-coping-with-slopes/ http://www.gamedev.net/blog/515/entry-2255630-character-controller-development/
To address this, I do the collision detection and resolution in a loop that is capped at a maximum number of iterations but otherwise continues while the length of the collision resolution vector last returned is greater than a certain threshold. So it keeps resolving until the object is not colliding with anything. A cap of 10 is sufficient to resolve the case here, where the capsule attempts to move into the slope from underneath.

This is the majority of it solved now. Just need to deal with gravity and standing on/walking up slopes now. At the moment, the object moves very slowly up slopes and slides back down if a naive gravity is applied. Need to figure a way to do this better, then the basics of character controller stuff is done.]]> Sun, 30 Dec 2012 14:38:00 +0000 http://www.gamedev.net/blog/515/entry-2255630-character-controller-development/ http://www.gamedev.net/blog/515/entry-2255613-christmas-adventures-with-gilbert-johnson-and-keerthi/
Funny, would have expected the infinite loop to occur around the curves, not the flat features. Seems to be the other way around.

Oh, happy Christmas every one. Spending it on my own with geometry this year.

[EDIT] Finally, seem to have cracked it .

For some reason in my implementation, there are certain faces on the Minkowski difference that I can't seem to get the simplex to resolve correctly when the shapes are disjoint to find the simplex closest to the origin, which is used when checking for the minimum separation vector between two shapes overlapping by only their margin.

This provides a far more accurate MSV than using sampling vectors around a unit cube, which is the fall back when the shapes overlap by greater than the margin - this is because GJK fails to find the closest simplex to the origin when the shapes intersect.

However, it seems that if I fail to compute a MSV with the GJK, I can then just fall back on the unit-sphere sampling method and this seems to return a consistent result along the face, so you still get a smooth sliding between the shapes.

The idea is to just step around a unit sphere creating normals and then project the furthest point on the Minkowski sum in that direction onto the vector. This provides the closest point on the Minkowski sum from the origin to the surface of the sum. Obviously you can only use vectors around a sphere to a fixed level of granularity although the operation is pretty cheap per vertex - assuming the vectors are precalculated, it is basically a dot product and a vector multiplication.

This will be even further improved by implementing an idea from Bullet - in addition to the unit-sphere vector checks, provide some "preferred" vectors based on the shape - these would be the negated face normals of polyhedrons for example. If the unit-sphere vectors do not directly coincide with these vectors, these vectors should "win" the test.

Huge amount of scope for improvement but all in all, I'm very happy to be sitting here on Christmas day 2012 having finally achieved something I've wanted to accomplish for about ten years - correctly detecting and resolving a collision between two convex 3D polyhedrons.

[EDIT]



All gets a bit easier now. Trivially implemented a support function for a cylinder and a slightly rotated cube (implemented as a polyhedron). The red pyramid is controlled by the keyboard and correctly collides with and slides around the three green volumes.

The next step is to provide each volume with its own transformation but this is trivial to implement without considering optimisations, which I'm not for now. Just take the normal into the support function, inverse transform it by the shape transform, get the result then transform the result by the transform.

I'm already doing something similar with the position, adding it to the result in the support so the point is calculated in local space but transformed to world space before returning. Obviously in the case of position, this has no effect on a normal so there is no need to inverse transform it first. Once we add in rotations for the volumes, it becomes necessary but easy enough to do.

I'm going to wait till this is fully working before I start to worry about making it more efficient. At the moment it has a lot of scope for improvements in this regard but that will be fun for later.

It will be interesting to see if I can build a reasonable character controller based on a capsule using this system - something I never managed using Bullet. I'm thinking somehow that we want a capsule sitting on a line segment perhaps but that is a problem for another day.]]> Tue, 25 Dec 2012 16:07:00 +0000 http://www.gamedev.net/blog/515/entry-2255613-christmas-adventures-with-gilbert-johnson-and-keerthi/ http://www.gamedev.net/blog/515/entry-2255606-visualising-3d-minkowski-sums/
Something that was very handy during working out the 2D version of the algorithm was that I could sweep around a circle to generate an approximate set of points on the Minkowski sum and draw it as a polygon, so I could then draw the simplex I was refining.

So the first step for implementing a 3D version has been to create a method that can generate a mesh from a shape given only a support function. It works by sweeping directions around a unit sphere to generate the vertices, then stitching these into triangles, taking advantage of the fact that we know the order the vertices were added and rejecting any degenerate triangles that are formed.

Above is an image of a capsule built by combining two spheres, using the maximum dot of the point with the direction of each in the support function, but the mesh generator can work with any shape that you provide a support function for, so will be ideal for also visualising the Minkowski sum.

It creates a few more triangles than are actually needed so would require some refinement if it was to be used as anything other than a visualisation tool but is fine for these purposes.]]> Sun, 23 Dec 2012 23:19:00 +0000 http://www.gamedev.net/blog/515/entry-2255606-visualising-3d-minkowski-sums/ http://www.gamedev.net/blog/515/entry-2255486-i-can-haz-gjk-algorithm/
Its one of those things that is not as complicated as it seems.

The two shapes in the example above are composites formed by combining two simpler shapes. The beauty of GJK is that only the support function of the shape is required, and it is trivial to combine two support functions to produce a "shrinkwrap" hull around two or more existing shapes.

Half the battle with a 3D version is going to be working out how the heck to visualise it. But fear is much reduced now I have a 2D version working. Home grown physics engine, one small step closer.]]> Fri, 30 Nov 2012 23:14:00 +0000 http://www.gamedev.net/blog/515/entry-2255486-i-can-haz-gjk-algorithm/ http://www.gamedev.net/blog/515/entry-2254965-opus-3d-update/
Thought it was about time I gave you all an update on Opus, my 3D modeller. Despite the lack of journalling, there has been a huge amount of work done and a great deal accomplished, so I'm going to have to talk about the features over a few posts. Thought I'd kick off my talking about how the scripting system works - this is turning into a very successful experiment.

Qt has a very robust and fast scripting system built in. It is EMCA script, which is a subset of Javascript, so is dead easy to pick up and Qt combines it with its metaobject system, particularly the slot system, to make interfacing between the application objects and the script pretty easy once you know how.

So pretty much everything in Opus is implemented in terms of an Action, which is an extension of Qt's QAction. The actions are loaded into a library class from an XML file on start up, and can be created and modified via the options dialog, as shown above.

In addition to setting the name, icon, text, status bar text and so on, you can also modify the script associated with the action. The script consists of a main function, actiontriggered, and also some optional handlers that are called in response to what I call application events - e.g. the model changing, the state of the undo buffer changing etc.

Since the script API includes methods to set the name and enable state of the actions themselves, this means that actions can respond to application contex, for example the Undo action only being enabled when it can undo, or the Select All action only being available when there are unselected sections etc, all without any hardcoding.

There is a growing and already pretty rich script API that gives you access to the application state, the model and the view that triggered the action. As I go along, I'm finding more and more core features are being implemented entirely in script without having to touch the C++. For example, Select All, Select None and Invert Selection I just implemented without having to modify any code.

The main menu and the toolbox (top-right) have their contents loaded from XML files as well. Each entry just specifies the action it relates to and everything else is handled by the action details.



Tools display a panel of controls when selected but in addition to the hard-coded options (the axis widget in the image above), you can then specify additional controls in the interface.xml file as well. For example, in the image above, the implementations of the methods to move the cursor are implemented entirely in script, then the label and row of buttons, each linked to an action, are added completely dynamically via the interface.xml file. Later I may provide a GUI within the application to modify these.

So far, all the major tools are implemented except Extrude but I'll talk about those in more detail some other time. I'd also like to describe the interpretation of the Command pattern I've used here to implement unlimited Undo/Redo as I've found it works very well.

Excuse all the dodgy icons by the way. I found a zip of PNGs of a load of Vista icons online that I'm just using as placeholders at the moment.]]> Sat, 18 Aug 2012 02:22:00 +0000 http://www.gamedev.net/blog/515/entry-2254965-opus-3d-update/ http://www.gamedev.net/blog/515/entry-2254770-still-alive/
The bones of the rendering is done. I'm developing the user interface using a mixture of scripting and native code that I'll describe in more detail when I have the energy but suffice to say it is going to be extremely customizable.

Hope you agree it looks pretty. Will post a more detailed entry soon.]]> Tue, 03 Jul 2012 21:39:00 +0000 http://www.gamedev.net/blog/515/entry-2254770-still-alive/ http://www.gamedev.net/blog/515/entry-2254621-opus-3d-revisited/
I've been developing the above for the main workspace area. It's a SplitWidget. You can take any child widget and split it horizontally or vertically, making it clone its child widget. You can also remove widgets, collapsing their split back down. I'm working on a system to maximize a widget to the entire area of the split widget manager window and restore it.

It'll mean a nice, flexible central area for the package. I've just been running a sanity check that randomly splits and collapses widgets for about two hours and nothing leaks or gets lost so seems pretty stable. A child widget just derives from SplitWidgetChild and implements the obligatory virtual clone() method and you're good to go.

I seem to be suffering from the common phenomena that is a variant of the inner platform effect - when developing with Qt Creator, you tend to end up wanting your application to look like Qt Creator, since it is so damn sexy, hence the tool bar design. This application will be Windows only since I'm using Direct3D for the rendering (no, I don't want cross platform and don't want to use OpenGL but thank you anyway) but Qt makes the development cycle far faster and more flexible. I use it all day at work for our software, which is progressing very well incidentally, and am fully converted.

I'm in the process at work of writing bindings for QScript, based on EMCAScript, to be able to script a lot of the work our software does via scripts stored in our database. With this in mind, I'm going to skip the whole horrendous DLL plugin approach I was starting to use with the Win32 version of Opus and provide all the plugin support via Javascript.

I've noted, by the way, that the amazing intellisense of Qt Creator seems very less amazing when using non-Qt code. I guess the reason Creator always seemed to outshine VS in this respect is because it is more domain-specific. Oh well, it still rocks.]]> Wed, 16 May 2012 22:12:00 +0000 http://www.gamedev.net/blog/515/entry-2254621-opus-3d-revisited/