|
Written by Ryan Juckett
|
|
Sunday, 16 May 2010 00:00 |
|
 I've been on a bit of a color science kick lately and transferring from one color space to another becomes a common operation when you want to properly play with digital color values. Normally we just think of digital colors as RGB values, but there are many ways to numerically describe a color. Just opening PhotoShop's color picker lets you choose colors as HSV, Lab, or CMYK values in addition to the standard RGB. If you're a bit more adept with PhotoShop, you've may have even ventured into the Color Settings which has even more options including which version of RGB that your image will use. It is this concept of multiple RGB spaces that I'm going to focus on.
|
|
Last Updated ( Wednesday, 26 May 2010 02:46 )
|
|
Read more...
|
|
|
Written by Ryan Juckett
|
|
Sunday, 02 May 2010 06:32 |
Having just written a parser for TGA image files, I had the pleasure of learning that the storage method for color data was not clearly defined by the documentation and that the few pieces of example code I could find all contained bugs. In an attempt to rectify the issue, let's walk through the different ways color data can be packed into a TGA file and how to read it back. |
|
Last Updated ( Sunday, 02 May 2010 09:28 )
|
|
Read more...
|
|
Written by Ryan Juckett
|
|
Sunday, 11 April 2010 22:27 |
|
 I decided to get a little framework set up that would let me play around with some graphics code. As a result, I decided that step one would be to get everyone's favorite test model, the Stanford Bunny, loaded and rendering. I'd never actually used the bunny or any of the other Stanford models before so after a little research into where to access them and what format they were in, I came up with a "pipeline" for loading them into my application. I wouldn't call it a great solution, but it worked pretty well for getting something up and running to play with.
|
|
Last Updated ( Wednesday, 14 April 2010 08:16 )
|
|
Read more...
|
|
|
Written by Ryan Juckett
|
|
Wednesday, 14 April 2010 06:21 |
|
 I recently wrote a text parser for Wavefront OBJ files and once I got it all up and running, I was surprised by the performance. I tend to be somewhat performance conscious when writing code so after realizing I had somehow created the slowest OBJ parser known to man, I was perplexed. It was taking 20 seconds to load the Stanford Bunny (4.83MB as an OBJ file with exported normals).
When parsing a 3d mesh from an OBJ file, it is optimal to collapse equal vertices into an indexed list. This is one of the more complicated steps so my suspicion was that something went wrong there. I was using a hash table to do the comparisons so it should have been fast. I disabled that section of code, and timed the load again. It barely affected the result.
Another common pitfall when parsing files is getting stalls from seeking through the file itself. I had already taken that into consideration and just loaded the whole thing into memory for processing. I was out of ideas and decided to profile the load and see what I had done wrong. I learned that almost all of my time was spent in strlen which was a big red flag considering I never even called strlen during my entire load.
|
|
Last Updated ( Wednesday, 14 April 2010 08:19 )
|
|
Read more...
|
|
Written by Ryan Juckett
|
|
Monday, 13 April 2009 00:00 |
|
 Inverse kinematics (IK) solvers often become mathematically intensive or computationally expensive with long kinematic chains or when functioning in higher dimensions. I am going to cover an approach to solving IK that is easy to understand, handles any number of joints, and is easy to implement in any dimension. We will walk through a two dimensional example and I'll present sample code to perform the algorithm.
|
|
Last Updated ( Sunday, 02 May 2010 06:30 )
|
|
Read more...
|
|
|
|
|
<< Start < Prev 1 2 Next > End >>
|
|
Page 1 of 2 |
Home