Demo: Green Dragon

Articles with the tag: Input Handling

Input: mouse cursor head tracking

For realistic head movement, the cursor position shouldn't dictate the position. It should dictate a force or direction to which the head can aim over time. For realism, the dragon's head should be combined with a simulated or pre-animated idle motion, such as an occasional swaying motion. This can be achieved by blending animations and skinning using the combined armature animation matrix palette.

Still, here's a demo of the test mesh/armature working with direct position coordinates controlled by the mouse (using bezier-based IK):

Just for kicks, here's how the traditional IK tracks an interactively-moving point. It looks pretty smooth, perhaps smoother than the IK, but as constraints have not been implemented, it cannot be used to realistically model the dragon's head.

The lack of rotation also rears its head, and the mesh appears squashed.

Read More »

Input: mouse pointer control

Alright, let's get XY coordinates via the mouse to control the end of the curve using GLFW.

A possible angle for the final animated/simulated dragon head and neck:

The end bone and therefore the face is aligned with the rest of the neck, however. The head should be made to point more directly at the cursor, as well as the eyes.

[13/05/14 15:40]

Putting mouse coords in Input handler class, but these should be normalised for the IK solver animation so they can be converted easily into world coordinates. How will the IK node be aware of screen coordinates? Such coordinates will be useful for picking (the process of allowing the mouse access to objects in a scene by casting a "ray" from its screen position), so a general access point should be sought.

Collision detection nodes

Add BoundingNode which (model) nodes can inherit from ...

Read More »

Input struct referencing and dereferencing woes

OK, struct pointers require weird casting and dereferencing to get at the data. Is it more overhead than using a class with get and set methods, though? Must make separate test file for these things.

[02/02/14 01:52]

Maybe use an array intead of a struct, since they are all ints... Depends on whether homogenous structs are slower than arrays...

[02/02/14 02:37]

Hang on - the struct doesn't need to be a pointer, only its members.

[02/02/14 16:41]

The GLFW poller function is only called on key action, so it wouldn't be too bad to have it copy a few values to a struct. This must be done for objects to handle themselves, as the callback function's values are fleeting.

It's a lot of memory copying, yes, but then the positions of objects will constantly be changing too so ...

Read More »

Framework development: Composition versus Inheritance

Speed of calls

Tutorial framework's SceneNode object inherits from Mesh, Texture and other objects. This intuitively seems like a bad idea as one has to make sure different classes don't share member names.

It should speed things up, though, as it doesn't have to make pointer calls to owned Material object.

Solution: elements contain local non-pointer Material object member and copy the passed Material's data.


This can then be called from inside the game loop for real-time material changes.

This does make objects larger, however, whereas before they would simply contain a reference to the same material object and could be all changed by changing the material. This way they'd all have to be set individually.

Composition versus Inheritance

Apparently inheritance of implementation-only things is bad, and composition should be used.

i.e. TestWorld invokes GameEngine object. Is this composition, and is ...

Read More »

Page 1 / 1