Saturday, May 30, 2009

Texas Storage

It's a box... you put stuff in it.

Sister gets married

Who's taking whose picture?



Sunday, May 24, 2009

Nap

Posted via Pixelpipe.


Friday, May 22, 2009

Taco Taco Juan


Here's a character I'm working on for an upcoming iPhone application.


Monday, May 18, 2009

Star Trek, Logical Smogical

Why such a big red ball when a little one would do?
Why are Romulan mining ships so bad ass?
Why be so vengeful when you could go save your planet?
Why bother with ships if you can teleport across the galaxy?
Why a giant red crab monster on an ice planet? And why not very coordinated on ice, its only lived there its whole life.
Why drill a hole to the core when you don't need to?
What would happen if the whole ball went up? Oh... just that?
Who's going to save the whales now?
How did, a group of miners on a mining ship mind you, they know when Spock would arrive through his time travel trip through a black hole? Is there some standard function for determining when he would arrive?
Where do you hide a ship for 25 years so the federation can't find it?

BTW, I really enjoyed the movie. It was great, even with these nagging questions.


Sunday, May 17, 2009

Two Weeks of Class

The week before last, Week 2, in my GSP-380 class we had to get OpenGL to render a rotating diamond shape with a light source. The image shows the result with a function being called to draw the triangle normals.


This last week was about DirextX. I don't know if I like DirectX. I think I approached it wrong, since I have some experience with OpenGL it seems really foreign. Regardless, for the assignment I had to get three spheres rotating around each other, like the sun, earth moon.



Thursday, May 14, 2009

4 wheels

Grandpa and Grandma got the boys a four wheeler. Its a little too fast or underpowered though, depending on the speed controll, but Aidan still liked it.



Thursday, May 7, 2009

Sales Slump

The idea that you can just drop your game in the iTunes App Store and make millions is probably a fallacy. Perhaps with the right marketing, and a good circle of friends and family, and a little luck, it is possible. I think we may have lost our chance for momentum. To my credit, I haven't done this before.

Here's a little detail on how the game, Board@Work, is doing. Its not as hot as I had hoped it would be. I found this cool website called MobClix that does some tracking. Below is a picture of it, along with our sales figures.



Apple takes a day to let you know about sales, so I'm hoping this gives a little insight into the future. Essentially, after a big slump on the 5th, we've started to climb. According to the ranking, its higher than previous so hopefully that trend will continue.

I think its a fun game, but I can understand why people might not give it a chance. I think

I've sent some free codes to some of the podcasts I listen to and enjoy the most, hopefully that will pan out. I've sent codes to Chad and the gang at the Video Game Show and Lono at his new gig, Respawn Radio. If we get mentioned, we may be able to get some traction.


Monday, May 4, 2009

LOD Calculations

The other day a coworker was asking me some modeling questions and I started spilling my philosophy like usual. He said he aims for 5 LODs (Levels of Detail) on his models. In my opinion, in the work we do, 5 is overkill. In fact, having too many LODs can hurt performance because that's 5 checks per model to determine which LOD to use (unless its a hierarchy driven LOD system, which maybe I'll get into in another post).
The basic idea of LODs is that as a model moves further away from your observer, the model's complexity decreases so you can gain some performance.
We eventually started talking about how to model smartly with appropriate LODs. I asked him what distances he was using in relation to his polygon counts.

The most basic concept for an LOD is that you switch a High Level Of Detail (HLOD) model with a simpler, lower detail model (fewer polygons generally speaking). The switch is usually instantaneous at a specified distance from the viewer. For instance, you may have a tree which is HLOD close to the camera. At 100 feet say, the models swaps out with a simpler model. And so on as you move further away. Eventually you can't see the model at all, so it can be completely hidden. The question you are probably asking is, how do you know when to switch those models?

The answer I've come up with requires some assumptions, some math and some basic information about your scene setup. I generally aim for 3 LODs at most, but this is arguable depending on model usage. Personally, I think less is better because it makes the modeler do more with less so to speak.

Here's what you need to determine:
- What is your desired Field of View (FOV)?
- What is your screen resolution?
- What is the size of your geometry?
- How big should the model be on screen when it switches LODs?

What is your desired Field of View (FOV)? I wont get into what FOV is here, but its basically the "zoom" of your camera. A narrow field of view, or smaller number, means the view is more telescopic, like binoculars. A large value, less than 180 degrees, is like a fish eye lens. To put it in perspective (no pun intended), in the first person shooter Call of Duty 4 the default FOV is 65 degrees. Call this value F.

What is your screen resolution? We could get fancy here, but I'm only interested in the horizontal number of pixels. A HD monitor would be 1920 pixels wide. Call this value R.

What is the important size of your geometry, S? Now models are not square, so what do I mean by size? Well, that's sorta up to you. Personally, I usually take into consideration how I expect to see the model. An airplane for instance might be long and wide, but not much height. Personally, I usually just take the largest value in relation to how I expect to see the model. For an airplane in a dogfight game I would use the wingspan, but for a game where you are on the ground, I would use the height since at larger distances that's how you'll most likely see them. Call this value S.

When should the LODs switch, or to put it another way, at what pixel width do you want the model to switch out? Call this value P.

Now here is the math part, I'll use a 25 foot tall tree with a diameter of around 8 feet as an example. The important size is its width because that is the bulk of the model, so S = 8. We'll start out by determining when can we hide the model completely? Let's assume we want to see that tree model until its screen presence is only, at most, 2 pixels wide. At that distance, we feel we can remove the model from the scene completely. At what distance would that tree model be represented by, at most, 2 pixels on the screen? Here's how you determine that distance:

Distance = S * R / ( P * 2 * tan( FOV / 2 ) )

For our 25 x 8 foot tree model:

Distance = 8ft * 1920pixels / ( 2pixels * 2 * ( 65deg / 2 ) )
Distance = 6028 feet

Wow! That's really far. So do you really want that tree to be visible up to that distance? If so, what does the model need to look like to represent that tree at that distance? Not much, its only 2 pixels big at this distance after all. You'd have a hard time distinguishing a 500 polygon model from a single triangle. Ultimately that's my point. In my experience, people model their low level of detail modes with too much detail. This method allows some insight into how to model as well as determining LOD ranges.

So now what? You need to determine the amount of detail you want on the screen and at what distance it is important to show it. If your LODs aren't constructed this way, you could be wasting a lot of performance.

For the tree, I assumed that when it reached 10% of the screen width (192 pixels), I want it to be its highest LOD. That corresponds with roughly 60 ft distance. From there to 2.5% screen width (50 pixels) is the medium LOD at 250 ft. The lowest LOD goes from there to 5 pixels, turning off at 2500 feet. Its debatable if you would want to divide this 3rd LOD further, vs trade polygons between the bottom two LODs. What I mean is that as the lowest LOD fades out to the distance, its polygons are less important. Depending on how you expect to see and use this tree model, you may want another LOD, or alternatively you can make the middle LOD last longer, essentailly allowing you to drastically reduce the lowest level of detail.

That brings me to my other point. This formula can also provide a modeler with a sense of what is important. Details that a modeler may include can be justifiably removed if their size in relation to their screen presence proves them useless, especially regarding reduction for LODs.

Of course, many engines today do more than just calculate specified distances. They can balance based on performance, allowing more detail if the frame rate doesn't suffer.