Archive

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.

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…”

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.

For the past little while, I’ve been working on a particular issue in Paladin’s issue tracking system. That issue proposes the creation of a configuration registry subsystem that will someday determine which Gladius subsystems execute and with which options.

At the moment, setting configuration options in Gladius is a bit of a mixed bag; this new subsystem should improve the state of things.

Trying to step along paladin’s unit test suite to get a handle on how the engine operates inside of firebug. Things are working out pretty alright when I don’t make the mistake of stepping into the line after the last line in the script because then… firefox crashes 😦

So far I’ve restarted firefox 3 times in the last ten minutes, I’m sure I’ll discover a workaround soon or just learn not to be stupid; anyone else have any similar experiences?

So I read about git and I deem git to be cool. I have prior experience with Mercurial and I’ve come to the conclusion that for all intents and purposes, git and Mercurial (hg) are roughly the same.

If you’ve never used a VCS before then git should be a pleasant learning experience. If however you’ve used something like SVN or Perforce for an extended period of time prior and have become very accustomed to the interface then git may be something of a shock for you.

In any case, try to use and enjoy it because it’s here to stay. A quick look at github’s user-base reveals a small army of over 1 million users (as of September 22, 2011). This user-base is reportedly rabid so if you don’t like git then git ready for a fight…

There’s a whole lot of useful stuff in Mike’s talk about Mozilla;
its history, the people behind it, the software they use, their wiki, bugzilla, etc…

David Humphrey’s talk was not technical at all and focused on the idea and practice of open source.

Overall, the talks didn’t really cover anything that we haven’t heard in some form before. However, a couple of things did resonate with me.

One of those things was Mike’s take on Mozilla’s mission. A point that he made abundantly clear was that Mozilla is an entity that really is all about its community. Whether it be browser development or any other kind of project, the Mozilla foundation’s one true commitment is to its community.

The community both drives Mozilla forward and acts as a torrent of innovation from which the foundation takes ideas which they then spearhead and throw back at the community to develop more fully. This is not how I previously perceived Mozilla and I applaud them for their community involvement.

The other point that resonated with me was something that David brought forward and developed in his talk, it was the idea that everyone, everyone, starts somewhere small. Let me put this in scope, I find it hard to believe that someone like David Humphrey, my OSD600 prof, a man that seems to live and breathe and preach open source, had at one point not known how to interact with the Mozilla community.

While obvious, the idea also seems so foreign and unexpected. This idea is refreshing and reminds me that anyone can participate in open source and that it truly is a global and wonderful effort.

Overall I found that the talks enhanced my knowledge about open source and Mozilla but didn’t really cover anything too new; what did you guys think? Drop me a comment to let me know 🙂