Why Sublime Text Is The Best Part Of My Day

July 16, 2012 2 comments

Aside from the sad fact that the above statement is absolutely true, Sublime Text really is quite (I humbly apologize) *sublime*. I was introduced to sublime by a co-worker at a point in time when the team at CDOT was looking for a good Javascript text editor. Now at first glance, sublime already looks a little different from other text editors.

For one, it has a minimap! If you’ve ever played a real time strategy game, you will be familiar with the concept of a minimap. If you haven’t the faintest idea what I’m talking about, a minimap is basically a small overview in which the game is typically rendered from bird’s eye view. In sublime, the same concept is applied to the text file being edited; a long overview of the file is placed to the right of the screen beside the vertical scroll bar. It’s such a slick concept! Keep in mind that the preview is fully syntax high-lighted, why don’t more editors do this! This is the biggest visual difference that sublime has from other editors.

What really makes sublime shine is its autocomplete engine, or there lack of. You see, sublime does NOT parse your files and build a tree in memory like intellisense; it simply looks over the current file, finds words that resemble the one that you are typing and suggests those words to you. For Javascript and other scripting languages, this is far better than what most other IDEs can offer. Even better, the list is clever enough to get out of your way when you don’t want a suggestion.

At the end of the day, it is this… niceness that I appreciate about sublime. It is a very concise, very small and very effective editor that gets the job done quickly and painlessly. Its settings files are all simple python. In fact, the whole thing is written in python. It has keyboard shortcuts for controlling how many tab groups you want in the current window. It has awesome regex support and a great search/replace tool (search results are shown in a file buffer in a file tab, like any other file). It has a slick project view/file tree and it also comes with a host of colour schemes; my favourite being a beautiful light text against dark background theme called Monokai that is on by default. Honestly, that scheme was almost enough to get me to switch to sublime immediately.

I’ve said enough about this wonderful text editor, TRY IT! http://www.sublimetext.com/

Euler Quaternions and the Trouble with Y-Up Space, Part 2

Welcome to my series of blogs about Eulers and Quaternions! This is part 2/2 of the series. See part 1 here. This series aims to talk about some of the difficulties that I’ve had in dealing with Euler <-> Quaternion transformations. In part 1, I talked about the difficulties around finding a transformation from Quaternion to Euler given a non-standard order of operations in the Euler and what it takes to actually derive the equations required to perform that transformation. We left off with equations that were useable; they did not however take into account the rotational singularities at the poles. For the unfamiliar, Euler rotations introduce two singularities into the space of rotations at the north and south poles of the rotation globe. As the Pitch approaches +90 or -90 degrees, the Yaw and Roll components degenerate further and further into a single rotational axis. This is known as gimbal lock.

As can be seen, the quickest way to detect for a singularity is to check if the Pitch component is +/-90. As detailed here (section Singularities), we can efficiently detect this by reusing our equation for pitch:

  • Θ, pitch: asin(-RPY12) = asin(2(q0q3 – q1q2))

Given the fact that at +/-90 degrees, sin(Θ) = 1/-1:

1 = 2(q0q3 – q1q2), -1 = 2(q0q3 – q1q2)

0.5 = q0q3 – q1q2, -0.5 = q0q3 – q1q2

So test = q0q3 – q1q2

If test is less than -0. 4999999 then we can assume a pitch of -90; if test is greater than 0.4999999 then we can assume a pitch of 90. We have a choice for what we could do with the degenerated yaw/roll rotational axis when a singularity is detected. Following in the footsteps of euclideanspace, I chose to put all rotation into the yaw. This means that we can assume an angle of 0 for roll. Applying all of this through our previous equations, we get:

When test > 0.4999999:

  • Φ, roll: 0
  • Θ, pitch: 90
  • Ψ, yaw: 2 * Math.atan2(q3, q1)

When test < -0.4999999:

  • Φ, roll: 0
  • Θ, pitch: -90
  • Ψ, yaw: -2 * Math.atan2(q3, q1)

You can get a better feel for this by following the derivation on the euclideanspace page. We now have a complete chain to convert a quaternion into a Y-Up Euler rotation! What’s nice about this is that we can now transform any order-of-operations Euler rotation into any other order-of-operations Euler rotation by transforming the first Euler representation into a quaternion then deriving the equations for getting an Euler rotation back from a quaternion with the second Euler representation. ie Roll, Pitch, Yaw into Yaw, Roll, Pitch, etc…

Hopefully this helps somebody out there because it sure as hell stumped me when I initially ran into this problem. Thank you for reading.

A Scalable Solution Part Two: World Reference Frame

In part one of this series, I talked about scaling objects in the local reference frame and why that process is relatively simple. In this post, I will be introducing scaling in the world reference frame as well as detailing some of the differences between the two types of scaling. I will also be detailing some of the complexities as well as a possible implementation.

World reference frame scaling is somewhat more complex when compared to scaling in the local reference frame. As the name implies, this method scales an object against the world reference frame. This is not as simple as it sounds as there are some subtle complexities.

As an operation, scaling in the world reference frame is lossy if other operations such as move and rotate are performed between the scale operations. This is somewhat similar to rotating an object in 3D. In 3D rotation, rotating an object about a set of axes in some order produces a certain result where changing that order would change the final result. When scaling against the world reference frame, one needs to keep in mind that the object may rotate or scale imbetween operations while the world reference frame remains fixed. When scaling groups of objects against the world reference frame, it is also expected that the difference between their positions and the position of the centroid of the group will also scale in the same way as the objects themselves. This does not map very well to the independent transform controls typically offered by most 3D engines today; instead, we will most likely have to create and maintain our own transformation matrix, feeding that to the rendering engine on render time.

We would like to allow the user to scale an object or groups of objects in local and in world reference frames. A relatively simple way to implement this is by storing all transformations in a single transformation matrix. To retrieve the axes for scaling in local reference frame, the transformation matrix is decomposed and the rotation component is used to compute the three axial vectors. In world reference frame, decomposition is not required as the axial vectors are simply the unit vectors of the world’s reference frame ([1,0,0], [0,1,0], [0,0,1] respectively). In either case, the scale is applied by calculating a scale matrix from the axial vectors and some specified scale amount. The scale matrix is then applied to the current transform matrix thereby giving us the object’s new transformation matrix.

This is how an object is scaled in the world reference frame.

This implementation requires that scale and rotation be stored as a combined transform matrix. A side-effect is that scaling in the world reference frame may change rotation. I was against this idea initially as it felt like the “purity” of independent scale and rotation values is being lost, not to mention the performance hit of the frequent matrix compositions and decompositions. Having said that, I don’t think that there is another way for this to be done. Not to mention that scaling in the world reference frame against an arbitrarily rotated object is essentially a skew operation. Comments from more experienced hands on this subject would certainly be appreciated.

Euler Quaternions and the Trouble with Y-Up Space, Part 1

May 25, 2012 1 comment

Yesterday I did something that I didn’t think I was capable of. It involved quaternions, matrices and a decent amount of math. Let’s start with the problem definition:

  • We have a system that tracks rotations using quaternions
  • We would like people to be able to use Euler coordinates (Tait-Bryan angles if you’re picky)
  • Our world is Y-UP

Doesn’t sound too hard. In fact, half of it was fairly easy. Turning a set of Euler coordinates into a quaternion is as simple as creating three quaternions using angle axis pairs derived from the incoming Euler rotation. For us, the three Quaternions were as follows:

  • [Angle: Yaw, Axis: [0, 1, 0]]
  • [Angle: Pitch, Axis: [0, 0, 1]]
  • [Angle: Roll, Axis: [1, 0, 0]]

We create a combined rotation quaternion by conjugating the three quaternions together in the following order:

Roll * (Pitch * (Yaw) * Pitch-1) * Roll-1

This is all that is required to produce a quaternion from a set of Euler coordinates. Now, we also had to retrieve Euler coordinates from a given quaternion. This is more difficult than taking Euler coordinates and converting them into a quaternion as the task requires a fairly solid understanding of the math. This too would be simple, if it weren’t for the fact that the entire Internet agrees that Z-Up is the way to go for Euler/Quaternion conversions. From what I could tell, the equations for converting a rotation quaternion into a Y-Up Euler coordinate do not exist! (On the internet).

To my shock, horror and dismay, this meant that I had to derive the equations myself. Needless to say, this was a daunting task. But, after an arm and a leg… and the other arm… and the other leg… and parts of my face/body and an assortment of pieces from whichever organs remain… I was victorious. My glorious victory over the maths was quite euphoric.

First, let’s talk about why Y-Up Euler coordinates are so different from Z-Up Euler coordinates. The idea behind Euler coordinates is that given three angular values, you apply three rotational transformations in a predetermined order around three dynamic or constant axes (depending on convention) and arrive at a destination rotation.

Rotational transformations are not commutative, that means that applying them in a different order will produce a different rotation all-together. I won’t get into why that is but it has to do with the fact that the space of all 3D rotations is something akin to the surface of a 4 dimensional hypersphere and applying a rotation is like traveling from one point on the surface of that sphere to another surface point while always remaining on the surface. (Feel like going for a dip in some advanced math? Read here).

The effect is that a rotation quaternion composed from rotations around axes in the order ZYX is fundamentally different from one composed from rotations in the order YZX, which is what we want. So, the equations must be derived. I won’t delve very much into why the following works as that could take several blogs. First, we must build a rotation matrix that will compose our Euler coordinates in the order that we want. This is as simple as getting the angle-axis matrix formula and plugging some numbers into it. That formula is the following:

Where c is cos(θ), s is sin(θ) and C is 1-c, θ is the angle of rotation and (x,y,z) are the vector components of the axis. This is taken from here . By plugging in axis and angle, we construct three rotation matrices:

Yaw, about [0, 1, 0], angle sign Ψ (Psi):


Pitch, about [0, 0, 1], angle sign Θ (Theta):


Roll, about [1,0,0], angle sign Φ (Phi):


Now, we multiply the matrices together in the order (Roll)(Pitch)(Yaw), producing the following:


Next step is to refer to the Quaternion -> Rotation matrix formula:


This formula was taken from here. The quaternion components are [w, x, y, z] -> [0, 1, 2, 3]

Finally, to retrieve the Euler coordinates we must match the matrix form of the rotation quaternion to our RPY rotation matrix exploiting cells where the values are easy to retrieve. In this case, the values are as follows (Notation, Matrix Row Column where row and column are in the range [1,3]):

  • Φ, roll: atan2(RPY32, RPY22) = atan2(2(q0q1 + q2q3), q0q0 – q1q1 + q2q2 – q3q3)
  • Θ, pitch: asin(-RPY12) = asin(2(q0q3 – q1q2))
  • Ψ, yaw: atan2(RPY13, RPY11) = atan2(2(q0q2 + q1q3), q0q0 + q1q1 – q2q2 – q3q3)

This is almost enough. What is left is to test for pitch singularities (+90, -90) and treat them specially. Since this blog has gone on for far too long, I will stop now as what has been given is certainly enough to get a similar system working. In my next blog, I will detail how we could cheaply test for the singularities and what we could do in that case. You can do some advance reading on that here.

A Scalable Solution Part One: Local Reference Frame

May 10, 2012 1 comment

Blog Reading Requirement: you need to know what a reference frame is, from wiki:

“A frame of reference in physics, may refer to a coordinate system or set of axes within which to measure the position, orientation, and other properties of objects in it, or it may refer to an observational reference frame tied to the state of motion of an observer. It may also refer to both an observational reference frame and an attached coordinate system as a unit…”

Read the source article here.

In this series of blog posts, I will be talking about scaling 3D objects in their local reference frame and in the world reference frame. In part one, I will be introducing the topic and detailing scaling in the local reference frame. In part two, I will be introducing scaling in the world reference frame as well as detailing some of the differences between the two types of scaling. I will also be detailing some of the complexities as well as a possible implementation.

As an artist, the ability to scale groups of objects is fairly important when working with 3D models. When scaling an object, it is done against a known axial reference frame; typically, the two most useful reference frames are the world reference frame and the local reference frame and they are vastly different. The local reference frame changes as the object is rotated while the world reference frame never changes. I will take this blog to elaborate on some of the challenges and requirements involved in implementing these manipulations as well as giving a possible implementation.

Local reference frame scaling is the simpler of the two as it is performed against the local reference frame of the object that is being scaled. With groups of objects, it is expected that each object in the group is scaled against its own local reference frame as opposed to the reference frame of the group. It is also expected that the positions of the objects in the group will not be affected by the scaling operation.

This scaling method is simple because it only involves applying a scaling transform against the 3 known axes of any given object. This means that the scale parameters can be stored as 3 floats. During frame rendering, the transform could be applied after position and rotation have been applied; this fits in with the rendering pipeline of most 3D engines and means that one could simply alter the scale parameter present on a renderable object in most 3D engines.

In part two, I will be introducing world reference frame scaling and what complexities may arise from allowing the combination of the two methods. Thank you for reading.

Release 0.4 – Not so much a bang but a whisper

December 13, 2011 Leave a comment

Here we are at the bottom end of OSD600. This course has been fun and has taught me a lot. This is why it is all the more unfortunate that my 0.4 release is not nearly as atomic as my 0.3. For my 0.4, I had 2 projects to work on alongside another course. One project was migrating XSS Me from the current tab-based threadpool implementation to Web Workers. This didn’t go so well. The conclusion of my research into Web Workers deemed them unusable for XSS Me’s requirements. So instead, a very minor fixup was in order.

As for Paladin, as usual, quite a lot of work went into the configurator. The configurator is now closer than ever to landing but still has not landed. This iteration, quite a number of changes went into the configurator. I’ve itemized the changes below:

  • Store/load now accept named parameters
  • Configurator objects were receiving undefined guids, now test suite fails if that happens
  • ConfNode is now it’s own require module
  • Configurator constructor is now not stored on engine
  • Configurator attempts to test for db caps on engine startup
  • Logger is now accepted as a construction option
  • Configurator now picks up default.js
  • /gladius/gameID is now just /id
  • Error handlers now introduced to indexeddb function hierarchy
  • Try/catch around sensitive areas

I will continue to work on XSS Me and paladin.

Release Details:

XSS Me:

commit: 731fe1563f97ab3951a5c799257a9acaea945cd3

issue thread: https://github.com/SecurityCompass/XSSMe/issues/3

pull request: https://github.com/SecurityCompass/XSSMe/pull/4

Paladin:

commit: 4539a66ee3a5ac6a38c420c089781f66e4120eb7

issue thread: https://github.com/alankligman/gladius/issues/21

pull request: https://github.com/alankligman/gladius/pull/52

Release 0.3!

November 23, 2011 Leave a comment

Whew! It’s been a while but my 0.3 has now been released! In this release, I’ve been working on Paladin/configurator subsystem. By now, it has become quite mature and achieves all required functionality. Also being used is IndexedDB as the load/store backend. Also important is that the codebase has now been brought up-to-date with the rest of the engine.

Changelog:

  • Added comments to all of the Configurator tests that didn’t have any. Improved some of the comments that were there before as well as improving some test structures slightly.
  • Removed Cookie.js from the engine. Cookies are no longer used as load/store backend, now replaced with IndexedDB.
  • Many functions had vague local variable names; their names have been improved.
  • load/store are now both asynchronous.
  • Added config/default.js for local configurations that need to be baked into the engine.
  • Configurator now uses gameID to load/save configurations.
  • Brought Configurator codebase up-to-date.

commit: a94ea288daabd84ea222a5a08da78ec4095479b3

issue thread: https://github.com/alankligman/gladius/issues/21

pull request: https://github.com/alankligman/gladius/pull/52

I also have some work to do for XSS Me but that has taken a back-seat to the work on Paladin. Currently, the plan is to dedicate most of 0.4 towards XSS Me. We’ll see how this all pans out.