PETROCKET

Ludum Dare 26

2013-05-09T08:25:00.002-07:00

Ludum Dare 26 Entry - Puzzle Cube

Ludum Dare 26 - PuzzleCube

I decided to enter into the 48 compo Ludum Dare 26 challenge where you make a theme-based game in 48 hours. The theme was minimalism, and I was going to apply that to my game by making the game simple and the look simple too - never did get around to audio.

You can download/play the game on Windows or OSX (sorry Linux) here:
http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=23254

It's a simple puzzle game where you try to get the ball to the top of the cube by maneuvering it around and through the cube. Also the rows of the cube rotate, though in this version they don't really work as intended and the player does not move with the rotated rows.

The game was built with Ogre3D in Visual Studio 2010.

I also live streamed my 5-6 hours of game dev on twitch here:

http://www.twitch.tv/petrocket/videos

Since then I have converted the game to iOS for touch devices and implemented most of the missing features, so that may be released as a free or cheap game soon. Here's a screenshot of the iOS version, still needs lots of luv, but it does have sound, rotating levels, infinite random levels and animations for all the movement.

iOS version

OGE & Planet Stuff

I haven't touched this in a while since becoming frustrated with the stuttering issues. I did make that physics sample that only has grid lines in it and when moving around the stuttering happens even in that minimal program. I haven't been able to solve it yet and got preoccupied with working on our other iOS game and client work.

Here's a couple updated screenshots of our iOS game with the new characters and graphics

iPad

iPhone

OGE And Game Updates

2012-12-12T17:05:00.000-08:00

Lots of game dev happening this fall, but most of it has been on our 2D port of the fireflies web game we made for the CDN contest last summer. The team at Bearhanded (where I work) decided to take our web game and make it a mobile game to be released before Christmas. Needless to say we decided to vastly expand on the original game, adding many more game objects, levels, pizzaz and eye candy yada yada.

Do you recognize the first level from our web version?

The graphics got a major overhaul, and as a minor note the characters in these Beta screenshots do not represent the final characters - those are still in progress. We also decided to have 3 trees in the initial release; the first tree has daylight levels in the middle of the day, the second tree levels take place at dusk and the third at night, which means we're going to add a whole new aspect to the game - dynamic shadows and lighting!

This level is ALL developer art, but it shows the colored lights and shadows effects.

There will also be pulley systems, bounce pads (disguised as red mushrooms), sap that you can sink into, enemy pushers, bombers, moths, worms, tubes, torches, cannons and maybe even more if we don't say "when" soon. We've added so much that we had to push back our release till early 2013.

This will be our companies first iOS game release so we're trying not to get our hopes up and just to make a game we all can be proud of, though recouping our investments would be nice.

Ye OGE (Open source Game Engine)

ye link

While all this 2D stuff has been going on, I've been working with Ralph on upgrading the libraries OGE uses and improving on the CMake build system. At this point, it appears to be working on windows 7 and linux, but not on OSX.

What's been holding back progress on the planet? Well, I've kinda decided to give OGE a real run for the money and see if I can't make it work before giving up and rolling my own, simpler game engine. I've got the latest planet stuff running in OGE, and have been creating sample projects to track down various major bugs like random thread/memory crash bugs and physics stutter bugs. Ain't no fun to play a game that stutters and I've noticed that stuttering seems to be a common problem when working with physics engines. If you're a physics or threading guru I would love for you to take a look at those parts of the OGE code.

This is my temporary MyGUI implementation in my planet test suite with the latest OGE (bogey tracker broken in this build!)

This is my little physics sample that I hope will help me nail the stutter bugs.

I've also added a version of the OGRE profiler to OGE and added optional profiling blocks to all the major systems for now. It doesn't really work like I would like, but it's better than nothing for now.

No fav games of 2012 post because I mostly just play one game - Natural Selection 2! They finally released it and it is super fun.

CDN 2012 Game "Fireflies" Postmortem

2012-07-29T11:33:00.001-07:00

This year the whole Bearhanded team decided to participate in the Christian Developers Network Speedgame. We created an online multiplayer game called Fireflies. The theme this year was "testimony" and we decided we wanted to do a multiplayer game with HTML5 and NodeJS. What came out of our brainstorming was a simple puzzle game where players control various types of game pieces and use them to get to the exit in each level. To accommodate the testimony aspect of the competition, we chose to show how each person's testimony is influenced by many people and so we created a sort of spiritual family tree in which each level starts out dark and after completing each level it lights up and the next level is unlocked. The idea being that God uses many people in our lives and in their lives to reach us with the gospel. When the whole tree is lit up, then the game is completed and the #parteh begins!

Level 1 is very straight forward no?

There are 5 levels, starting with simple puzzles and ending in some rather difficult ones. The final level is very difficult to beat by yourself, and even with three people it can take some time to finish.

Every game needs a jumping puzzle! #lies

Design

We took our design cues from games like Lemmings, Limbo, Botanicula and whatever was tossing around in our subconscious! Chris was the primary designer and Aaron took his characters and animated them using After Effects. Nate then took the animations and put them in the game.

Development

Fireflies was built with the following technologies & libraries

NodeJS - server game logic
NowJS - server and client networking
HTML5 - client audio and canvas support
CSS3 - text glow effects and drop shadows
Box2d - client physics
Cocos2d-javascript - canvas drawing
jQuery - various UI elements

I did all of the Javascript for the server and client using Aptana as my editor. This editor is free and good looking and the code completion is pretty decent. It's basically another flavor of Eclipse.

I love using dark text editor themes - if only it darkened the frame too #sigh

Chris used Tiled to build our levels and Nate used Zwoptex to make our sprite sheets for our animations. Both are free and support Cocos2d.

Simple, but it works and it's free!

Thoughts and ramblings

For anyone interested in using any of these technologies you should be aware of several things I discovered:
- Cocos2d-javascript is still very alpha, with lots of unimplemented features, many bugs or things that don't work in every browser, few working up-to-date examples and not very optimized. All that being said, it does work for simple things and it performed fairly well for our little game. To integrate box2d physics with cocos2d I had to modify the level import code to support reading polygon objects. Then in my client code I used the polygons to create box2d static shapes.

- NodeJS is really hot these days and can do some amazing things. No complaints here except that it uses Javascript. All the wonderful things you are used to with object oriented programming are imitated and asynchronous behaviors abound.

- NowJS allows you to easily synchronize variables between server and client and do remote procedure calls, however I quickly discovered that due to the asynchronous nature of NodeJS, using variable synchronizing would give random bad values and I ended up having to use remote procedure calls for everything. The groups feature is how we contain players in levels and it is super easy to do and useful and awesome.

- Box2d is made for realistic physics, not platformers. I really had to punch it in the face to get it under any semblance of control and the player input still feels awkward and annoying to me. Physics engines sound like an obvious choice when you're making a puzzle game, but when it comes to platformers you want a certain un-realistic feel for player input 9 times out of 10. So to bring box2d to its knees I had to

Use a ball for the players physics shape so it wouldn't get stuck and friction wouldn't be such an issue.
When the player is on the ground and not providing input, set the friction really high and use damping to slow the player down fast. When they move ease up on the friction.
When in the air, turn off friction and use a different damping or they'll get stuck on vertical walls.
Use impulses and not forces to get the player moving.
Turn off restitution or just use a tiny bit or you'll bounce all crazy.
Make sure your polygon world objects are created with the vertices in counterclockwise fashion or your player will fall through them.
Make sure the player's foot sensor isn't too wide or they'll be able to wall jump - unless you want this behavior - super meat boy anyone?

That's it for now - you can play the game at http://fireflies.bearhanded.com and the source code is available for download via the christiandevs.com website here.

In other news I will post about the latest OGE/planet updates soon and I co-authored a book on OGRE.

Spacescape for OSX, OGE gui and 2011 Games

2012-03-26T07:47:00.001-07:00

Let's hit the "games I played in 2011" first - btw I'm stealing this idea from nathan @ ntdb.org. I think every game developer should be required to do a post on games they played once a year! Brilliant.

Natural Selection 2 - naturalselection2.com

This has been my go-to game of late because it just keeps getting better and better with each new Beta release! If you haven't heard of this game, it is a remake of the original which pits alien forces against marines in a FPS & Strategy Game mash-up. Each team has a commander who plays the game from a top down perspective and deals with building, upgrading and collecting resources for the team. The commander on the marine side is also charged with directing, healing and keeping bullets available for his teammates. Each side accumulates resources through the game by building structures on resource nodes throughout the map. Resources can be spent on upgrades, or in the aliens case, for evolving into more sinister life forms.

The only minor downside of this game is that it isn't OSX compatible yet so a bunch of my friends can't play it because they drink the Koolaid!

The Elder Scrolls V: Skyrim - elderscrolls.com/skyrim

This is obvious no? Great graphics, huge expanse with variable gameplay, and I would be playing this a lot more if I weren't playing natural selection all the time. I really like how this game looks and the openness of the gameplay, my only gripe is that every dungeon seems to be the same type of experience: kill bad guys, kill boss, come out alive.

Left 4 Dead 2 - l4d.com

I started playing this with friends at work and had a blast! I did enjoy mindlessly killing zombies while drinking a beer after a day of twisting my brain this way and that. Great way to unwind and I keep it in my back pocket in case I don't feel like playing TF2.

Minecraft - minecraft.net

There are only two games that my wife and I both get and this is one of them. The creativity in this is addictive and it is the only game I have like this. I want to make a game as creative as this one some day - and I mean one that allows players to create and really use their imagination. Love. It.

Portal 2 - thinkwithportals.com

Played this in single mode and then co-op mode and enjoyed every minute. I simply couldn't stop playing it and it was so refreshing to have an action game with humor in it. I think Valve has the corner on the market in pulling together all the gameplay details and story line together, plus I just love puzzle games. Co-op mode was icing on the cake and I wish there were more longer campaigns.

Civilization V - civilization5.com

Bought this on sale and the graphics look great, but I don't have enough time to play it. My wife loves Civilization but her computer can't run this version as well, so she is sticking with IV for now. The gameplay changes don't bother me, and I actually kind of like them.

Team Fortress 2 - tf2.com

Always a classic. I play this mostly to unwind in a gore-free environment. Going free-to-play was a good move for Valve - I bet most of their players purchased the game a decade ago anyways.

Honorable mentions...

Lord of the Rings Online

This was the only MMO that I tried and I did enjoy it but you really have to spend a lot of time to do stuff in these types of games. The graphics are decent for an MMO and there is certainly a big community, especially after they went free-to-play, but when the Star Wars MMO came out, a lot of people went on hiatus to try that. Most of my guild friends did. I quit playing in 2011 and will probably not return until I have significantly more free time.

Tiny Wings

My favorite casual game. Simple, carefree and fun.

Sam & Max

I play through these with my wife on the TV sometimes when we're bored, the internet is down and the like. These are really fun little games and are fun to play with another person sitting beside you.

Sonic 2 for iOS

A classic from when I was a kid and played it on a Sega hand held. I cheat now to get to the higher levels that I couldn't get to when I was younger.

Counter-Strike: Source

I only downloaded this game and played it to see what was going on with the most popular online shooter game. More of the same. Graphics refresh was nice and I like the new maps, but I never really got into the original and stopped playing this one after a little while too.

X3

These games are like references for me and full of ideas I want to have at hand in space games that I make. The story lines are teerrrrrriiibbbllleee and the voice acting is equally bad, but the space graphics are pretty amazing. Eve Online also has some great space graphics, but I couldn't stand the gameplay and the MMO aspect was not enough to get me to pay a monthly subscription fee.

So that's it for the games I played - I may have played other games, but those are the ones I remember.

OGE GUI Experiments

In the world of game development I've been doing more work with GUI's in OGE. I added a console and a simple menu system to explore the ins and outs of the MyGUI library. I suspect it is causing some framerate issues, but I haven't been able to track those down yet. I'll probably post a video of the GUI additions later. I've also spent time trying to better implement input and physics for moving. In fact most of the GUI system I have created so far has been to allow me to tweak input parameters to get it to feel right. It still doesn't.

Spacescape on OSX

I actually managed to get a version of Spacescape to compile on OSX and run, but it has some major issues with masks and the whole build process was hell. Since I've been doing a lot of XCode programming with work projects I think I'm going to dispense with the QT framework and trying making a native Cocoa Spacescape app for OSX and a native Win app for Windows - sorry Linux!

I have learned, through opensourcing the code for Spacescape and trying the donation thing, that besides it being a nice little feather in your hat, the only thing you get out of open sourcing and giving away a small project like Spacescape is a bunch of thank yous and a ton of support requests. I intend to do a full write up with my thoughts on the whole business, but in short, I'm ready to attempt a different model. I think the next iteration of Spacescape will be closed source and I'll use a pay-what-you want model with some minimum to cover fees, support and future development.

CDN SpeedGame Postmortem!

2011-08-26T21:20:00.000-07:00

Would you believe it - I don't even have enough free time to make a little speedgame?!? Maybe I was over ambitious but I'll get to that.

So my entry into the Christian Developer Network's 2011 SpeedGame was going to be a Robot-Unicorn type game but with a cat. We each had to pick a verse as a theme for our game and I chose Proverbs 15:24 - the lolcat Bible version.

Proverbs 15:24 - Smrt kittehs go up, not down to da basement.

The basic gist of the verse is wise people are on a path leading upward and they turn away from death/hell beneath. I made a game about a cat that falls asleep during a thunderstorm and dreams that it is running away from the storm, jumping from platform to platform as the storm gets closer and closer. Really simple concept - I mean you just have two controls, jump and fire. Jump to stay on the platforms and fire to deal with obstacles in your way. The obstacles would slow you down and if your cat doesn't keep ahead of the storm approaching from the left side of the screen it gets soaked and you lose! This post is about the game dev process and the hiccups I had along the way that I'll share my solutions for and hopefully they will be helpful for other Ogre game devs.

But first - a simple rundown of the tools and libraries I used for the game:

- Ogre 3D graphics engine (duh)
- Box2D physics
- OpenAL audio
- Gorilla GUI
- OIS for input

- Blender 3D for models
- various free model and sound websites for the developer/test content

OK, so in the roughly 20 days we were given to do actual dev work on the project I decided to build a cross platform twitch based game. That was the first hiccup. I spent roughly 2/3 days just getting basic Ogre working on Windows, OSX and iOS. What I did was download the SDK for Windows, OSX and iOS and then I set up this folder structure to house it all.

- design <-- all my design files
- GameiOS <-- iOS specific XCode project
- GameOSX <-- OSX specific XCode project
- GameWin <-- Visual Studio 2010 project
- lib <-- Box2D and OpenAL libs/source
- media <-- all models, sounds, graphics etc.
- src <-- all the shared source code

Cross Platform Luv

Windows was cake to setup for just about all the libraries. iOS was a bit more difficult because you have to compile the libraries for the right architecture to run on the device and different ones to run in the simulator. OSX had issues with just working at all. I tried to use the XCode 4 templates to create a new project but even when I got it to compile it would crash on startup. Eventually I found that if I moved the log manager initialization to a line after Ogre::Root was initialized then the crash went away and I could proceed. So all that debugging on OSX and the extra iOS configuring took me a couple days of free time.

Oh, and OSX fullscreen mode just doesn't seem to work -- which was annoying because I had to restart my computer to regain control.

After getting the demo app working cross platform I put it all in a GIT repo (always a good idea to backup your code).

Physics Physics Physics

The next step was actually implementing the game, so I created prefab boxes in Ogre for the player model, the platforms, the bonuses and walls - everything and tried to hook up the Box2D physics. It wasn't that hard to create a Box2D hull for all the objects because they were all square initially - however I ran into major issues getting the Box2D step() function to be framerate independant. In fact, to this day the physics speeds are different on each platform even when I confine the framerate to roughly 60 fps, and this annoys me to no end! I even got a helpful hint from azrialelf on the Ogre forums that he just created a framelistener and told Box2D to step with the evt.timeSinceLastFrame as the time delta. This does work OK, but it still doesn't behave the same on all platforms and still seems to be affected by framerate somewhat.

One other big gotcha with physics on iOS and OSX is that the demo app run the main loop with a timer set at 60fps where as the windows run loop is not timer based and runs as fast as your gfx card can go. This really brought out the Physics step problems because my windows game would run at like 2000 fps and the physics wouldn't work at all while the iOS version would be really slow and the OSX version would be fast -- even though they used the same physics settings (they shared the same code). My plan to address this is to just tweak it so it feels OK on each platform and not kill myself trying to figure it out.

OpenAL Lacks Decent File Import Capabilities

OpenAL was surprisingly easy to set up for all platforms. The only issue I ran into was that there didn't seem to be builtin support for reading any audio formats - so I just grabbed some code off the internet for reading .wav files without ALUT. I did find solutions that involved using iOS/OSX libraries, but I wanted something that would work across platform. Eventually, I plan on adding the ogg vorbis file libraries and using those to load compressed audio files.

Blender? I barely know her!

The next step after I got the basic physics working with some silly sounds and keyboard/mouse input, was to create some models in Blender and get them in game. My idea was simple - create a platform object that had two meshes, one as the actual mesh and one that was the physics mesh. Sounded simple but was actually pretty crazy. Turns out making an object with two submeshes is actually no big deal. You just enter into edit mode for the object and select each mesh in turn and assign them to different materials. I named one material Platform and the other Physics. Then in my Ogre code after I imported the model I looked for the submesh with the Material name "Physics" and used the vertices from that Submesh for the Box2D Chainloop physics hull - oh yah, you have to use the latest version of Box2D from the repository to get this nifty hull type. The crazy thing about this process was I had to walk the edges in the Physics mesh to form a closed loop for the Box2D hull. Fun fun.

The biggest hiccup with Blender was getting the model with the two submeshes into Ogre with all the vertex data intact. When I used the latest version of Blender and the latest version of the Ogre exporter for Blender the files that were generated used shared vertex data, and when I tried to read that shared vertex data in Ogre it didn't exist! Crash-o-la. Solution? Use the older version of Blender and the older exporter that doesn't use shared vertex data and it works. Boom.

Silverback

I chose to use the Gorilla GUI for Ogre because it was two files! - and I saw it in action in the Ogre forums and had to try it.

It's super basic and you have to do everything, but it is fast and once you get a feel for what it can do it just makes sense. I also found the demo console app to be really handy.

In the End...

I just didn't have enough time to finish. I wasn't supposed to be working on this alone, but my other teammates had other things come up. None of the art or animations were made and I never added the background music and ambient sounds that would have really helped it. Of course, even a legit background would have helped!

I learned a lot from the experience and did have fun and plan on bringing the game to a releasable state in the future. Until then I will return to OGE, My First Planet and Spacescape dev work in my free time.

Let there be Bogeys

2011-07-06T18:40:00.000-07:00

(click to enlarge)

It hasn't been very productive these last few months. Got the usual family stuff that is, obviously, more important than this - but what I have done is experiment more with MyGUI and added bogey trackers to some mine objects.

The bogey trackers are actually 2D GUIe widgets and each corner of a box surrounding a mine is it's own widget. The performance ain't hot let me say that much. I'd like to also try 3D bogey trackers and actually put billboards in 3d space around the targets, but I kinda doubt that will be any faster.

I've also tried to smooth the input and framerate a bit more. In the process I implemented a mouse look system for the ships that is similar to the one in X3.

In the process I broke my multiplayer input so now client ships can't move, and there is still a bit of jitter when moving fast, ugh. I plan on attempting to fix the network bug and then do some renovations to the lasers & thrusters. After that it's some basic menus - joy! One of those menus should be a menu to jump to another planet or solar system, so that will open a whole new can 'o worms.

Here's a little vid I recorded - just shows the bogey tracker.

Helpful Mercurial Tips

2011-02-20T20:57:00.000-08:00

I spent a good bit of time trying to setup a Mercurial repository server on a Windows 7 Server that uses wamp.

I had to install TortoiseHg and Python 2.6.6 and the latest Mercurial in that order so that Mercurial would add it's libraries to the Python install. All that is important because the library.zip file that comes with TortoiseHg doesn't have the right Python modules you need to make the Mercurial hgweb.cgi work. Also I needed to install mod_wsgi on the wamp server which uses Apache. Lastly, here is my hgweb.cgi

    #!c:/Python26/python.exe
    #
    # An example hgweb CGI script, edit as necessary
    # See also http://mercurial.selenic.com/wiki/PublishingRepositories

    import os; os.environ["HGRCPATH"] = "C:\wamp\www\hg"

    # Path to repo or hgweb config to serve (see 'hg help hgweb')
    config = "c:\\wamp\\www\\hg\\hgweb.config"

    # Uncomment to send python tracebacks to the browser if an error occurs:
    import cgitb; cgitb.enable()

    from mercurial import demandimport; demandimport.enable()
    from mercurial.hgweb import hgweb, hgwebdir, wsgicgi
    application = hgwebdir(config)
    wsgicgi.launch(application)

Nobody Likes To Fly In Space - They Want To Drive

2011-02-20T20:54:00.000-08:00

There are a lot of arguments out there about how much "fun" realistic space physics are and I am a believer that it's annoying to have to deal with so many ways to maneuver and the concept of the ship pointing one direction while flying another with the engines off! So, I'd like to share with you how I decided to implement unrealistic but "fun" spaceship flying. Oh, and back in the day I did participate in the making of a game with realistic space physics.

Cassini Division 2004

To start with lets consider that most games use some kind of physics engine and those deal in forces primarily so we need to make each of the engines apply forces to the spaceship. But we can't stop there because that is the realistic way and controlling a for-real spaceship can be so challenging that you don't have much time to deal with anything else like, say, shooting. I mean, just think about all the controls you have to have in your ship to make your ship rotate in any direction and move in any direction! Now, I have considered a game where each spaceship has a pilot and a separate player as the gunner, but lets not get distracted...

The easiest way to fly in space besides autopilot is to make it like driving - something that most people are used to. You see, I want two things when I'm driving:

I usually want to be traveling in the direction my spaceship is pointing
When I hit the gas I want the spaceship to move, and when I let go I want it to come to a stop.

Handling the first issue is simple after you handle the second issue, just make the back engine the biggest and don't go putting big engines on the sides or front. The second issue is not too difficult either - apply dampening to the spaceship so that it acts more like it is moving through liquid/air than through a vacuum.

By applying the dampening we ruin realistic space physics, but make spaceships easier to control. Now since the ship is really moving through some kind of liquid/air it takes constant force to keep it moving and we now have an excuse for a fuel gauge and as an added bonus, when the spaceship enters the atmosphere or ocean we can use the same controls just fiddle with the amount of dampening.

Last thing I'd like to mention is the issue of 'max speed'. When we have dampening then the 'max speed' of a spaceship makes more sense and we have the excuse for putting spaceships in the game with more powerful engines - where with realistic space games you can fly incredibly fast in a tin can with the help of some gravity, you just can't start or stop fast.

Oh, and collisions should work with our physics plus dampening model too and keep all that space debris from moving off into infinity where nobody could tell that it was once part of a destroyed spaceship.

On a more practical note, here is how I implemented the above physics model in OGE with Bullet.
1. Use btRigidBody::setDampening() to set the dampening on the Bullet rigid body object
2. Use Bullet's internal tick callback to apply constant forces before the dampening is applied:
btRigidBody->applyCentralImpulse(velocity * deltaTime);
btRigidBody->applyTorqueImpulse(angular * deltaTime);

A New Year With New Goals?

2011-01-04T09:25:00.000-08:00

The end of last year was somewhat unproductive for me on the planet front. I was looking back at my calendar today and see that I spent most of my time doing real life work and being a dad. I also spent a lot of free time playing games too instead of making them.

The two things I did work on that were planet related were OGE and Spacescape. I made the developer list for OGE, and I might be the only active developer for now, but I hope that changes soon. I spent most of my OGE developer time working on the RakNet networking and Bullet physics systems and have been trying to get a minimal networking example working with a small player controlled spaceship, some exploding mines and a planet. Let's just say that networking + physics debugging can be annoying and I had no idea that making a spaceship NOT have Newtonian physics in space would be so challenging! - more on that later, maybe.

Spacescape got some bug fixes and minor features and I added the CMake build system to ease the pain for new developers and for me each time I develop on a new machine, especially one with a different OS like OSX. I also got my first and only Spacescape donation woohoo! and a bunch of feature requests, support requests and compliments.

On the table for this year are:
- Finish the OGE networking space example
- Re-asses and tackle placing objects on planets (vegetation, buildings, players etc)
- Fix planet underwater shaders
- Add simple clouds to planets
- Make the networking space example into a small game
- Release the planet plugin source
- Port Spacescape to OSX
- Divide Spacescape into "basic" and "advanced" modes so it is loads easier to use for the casual user.

Other possibilities include:
- Use acko.net method for computing planet normal maps
- Figure out additional light maps so we can have lights on the dark side of the planet
- Re-asses how distance/scale is handled when approaching the limits.
- Form a team of like-minded individuals

Hope you have a great start to the new year!

Planet Water Shader Tests & OGE

2010-06-30T09:29:00.000-07:00

First of all, I haven't posted in a while because I've been sick, then I got my new dev machine and was busy setting it up and playing games on it and other real life stuff.

So, water for this small planet has been difficult for me and I've tried a couple approaches and have yet to get something I like.

What I want:

reflections, refraction, transparency, specular, normal mapping
under water fog
fog color changes based on depth and distance

Here's what I've got so far (no reflection or refraction)

Video of planet water on YouTube

Reflection and Refraction

There is no reflection or refraction on the water because I don't know how I will manage that on a curved surface yet. I think what I will try first is only doing water reflection and refraction when you're close enough to the water that it appears to be more flat so I can use conventional techniques.

Underwater Fog

To support underwater I applied a fog to the pixel shader for the terrain based on the terrain depth under water. I have a outward facing sphere with a shader for transparency, normal mapping and specular. I also have an inward facing sphere with a shader for when you are underwater looking up at the surface from below.

Unfortunately, the fog shader on the terrain does not line up perfectly with the underwater inward facing sphere so you see cracks at the water edge where there is no fog. I think I can only fix this issue with post processing.

New Game Dev Machine

I got a new developer machine with an i7 processor and Radeon 5770. I tried to choose a middle of the road graphics card. You can see the new game dev machine specs and discussion on eggxpert.com

OGE

Lastly, I've spent a some time working with OGE which stands for "Open Game Engine". I've created a small RakNet plugin for it and have been trying to get a little client/server action going. This is a potential game engine that I might adopt for MyFirstPlanet, at least in the development stages to do all the audio, graphics, user interface, networking, gameplay, physics, and scripting that I would have to build myself. It supports OGRE as a graphics engine plugin so I shouldn't have to rewrite any of my graphics code.

I'll try to post again when I have a video to show of the network tests. It will mostly just be a couple clients on a server flying ships around in space over a planet.

Planet Terrain Shader With Atmosphere

2010-05-05T17:44:00.000-07:00

Before you read this post, if you have not watched Ysaneya's latest tech demo video go watch it now! It is amazing!

In the previous posts I described and published my latest atmosphere shader and I got some useful feedback and requests for information, which I thought I should include here:

- The atmosphere shader is applied to an inverted sphere that is drawn before the planet. This means that if you have a single atmosphere shell and a planet with no atmosphere shader added to it, then you will just see the atmosphere effect behind the planet. I go into how I've added worked in atmosphere shader code into my terrain shader later on in the post you are reading now.

- In the atmosphere shader the camera and light should be in object space, as should the vertices.

- The atmosphere is still not fully opaque when on the sunny side. It is opaque (not see through) at the horizon and gets slightly transparent as it approaches the sun so some stars still show through which may not be desired. I plan on addressing this later when I add other planets and moons. I'm concerned that if I make the atmosphere too opaque then you won't see the moon or planet (or large space ships!) out there, and if I make the atmosphere too transparent then you'll see too many stars on the day side. I may just end up darkening the skybox as the user gets on the daylight side of the planet, but I haven't gotten there yet.

Now, about the planet terrain. I create an 8 way blend look up table based on terrain slope and height. When the planet is first created I render to texture a medium resolution texture (512x512 currently) that blends 8 textures based on this look up table. When viewing the planet from far away I display this medium resolution texture, then when the camera approaches the surface I blend between this medium resolution texture and a shader that actually blends the 8 textures per frame, which is slower but looks better close up.

Too add the atmosphere effect to my terrain in the vertex shader I basically calculate the amount of atmosphere fog like this:

// atmosphere fog / haze attenuation
float3 camToPos = position.xyz- camPos.xyz;
float camToPosDist = length(camToPos);
float visibilityDistance = min(AtmosphereHeight,VisibilityDistance);
oAttenuation = saturate((camToPosDist - VisibilityDistance)/ (AtmosphereHeight + visibilityDistance));

position - The vertex position in object space
camPos - The camera position in object space
AtmosphereHeight - Atmosphere sphere radius minus terrain sphere radius.
VisibilityDistance - At distance = 0, fog is 0 at distance = VisibilityDistance, fog = 1

In my fragment shader I do this:

// gradient0 is a look up table like atmosphere gradient but two pixels high. 
// Top row is atmosphere gradient and bottom row is sun color gradient
float4 sunColor = tex2D(gradient0,float2(uv2,1));
float4 atmosphereColor = tex2D(gradient0,float2(uv2,0));

// how transparent is the atmosphere?
float transparency = min(AtmosphereTransparency,attenuation); 

// get diffuse amount from 8 way texture blend and apply lighting with normals
// or shadow map/light map
...

// get atmosphere contribution    
float3 atmosphereAmt = (atmosphereColor * sunColor * (transparency + (transparency * shadow)));

// add in atmosphere
outColor.rgb = (diffuse.rgb * sunColor * (1.0 - transparency)) + atmosphereAmt;

I use a constant called AtmosphereTransparency to make sure that the atmosphere contribution is no more than a certain amount. I use 0.3 because it looks OK, but on a really dense atmosphere you might want a higher amount.

Here's the full terrain shader you see in the videos when the camera is on the surface - this is the one I use for Ogre3d not for FX Composer.

void main_vp( float4 position : POSITION,
float2 uv       : TEXCOORD0,

out float4 oPosition : POSITION,
out float2 oUV1    : TEXCOORD0,
out float3 oLightDir : TEXCOORD1,
out float  oBlendAmt : TEXCOORD2,
out float  oUV2    : TEXCOORD3,
out float  oAttenuation: TEXCOORD4,

uniform float4x4 worldViewProjMatrix,
uniform float4 camPos,
uniform float4 lightPos,
uniform float AtmosphereHeight,
uniform float VisibilityDistance     
)
{
oPosition = mul(worldViewProjMatrix, position);
oUV1 = uv;

// directional light
oLightDir = normalize(lightPos.xyz);

// dot product of position and light in range 0..1
float posLength = length(position.xyz);
float3 normal = position.xyz / posLength;
oUV2 = (dot(oLightDir, normal) + 1.0) * 0.5;

// atmosphere fog / haze attenuation
float3 camToPos = position.xyz- camPos.xyz;
float camToPosDist = length(camToPos);
float visibilityDistance = min(AtmosphereHeight,VisibilityDistance);
oAttenuation = saturate((camToPosDist - VisibilityDistance)/ (AtmosphereHeight + visibilityDistance));

// start blending between low res texture and high at 512 units out
float blendStart = 512.0;
float blendEnd = 0.0;
float blendDistance = blendStart - blendEnd;

oBlendAmt = max(0.0, camToPosDist - blendEnd);
oBlendAmt = min(1.0, oBlendAmt / blendDistance); 
}

And here is the fragment shader:

sampler diffTex0 : register(s0);
sampler diffTex1 : register(s1);
sampler diffTex2 : register(s2);
sampler diffTex3 : register(s3);
sampler diffTex4 : register(s4);
sampler diffTex5 : register(s5);
sampler diffTex6 : register(s6);
sampler diffTex7 : register(s7);
sampler blend0 : register(s8);
sampler blend1 : register(s9);
sampler diffuse0 : register(s10);
sampler gradient0 : register(s11);

float4 getBlendedSample8(in float4 weights0, in float4 weights1, in float2 diffUV) 
{ 
// use w,x,y,z order because PNG uses pixel format A8R8G8B8
return tex2D(diffTex0, diffUV)  * weights0.w +
tex2D(diffTex1, diffUV)  * weights0.x +
tex2D(diffTex2, diffUV)  * weights0.y +
tex2D(diffTex3, diffUV)  * weights0.z +
tex2D(diffTex4, diffUV)  * weights1.w +
tex2D(diffTex5, diffUV)  * weights1.x +
tex2D(diffTex6, diffUV)  * weights1.y +
tex2D(diffTex7, diffUV)  * weights1.z;
}

void main_fp(
float2 uv : TEXCOORD0,
float3 lightDir : TEXCOORD1,
float  blendAmt : TEXCOORD2,
float  uv2 : TEXCOORD3, 
float  attenuation : TEXCOORD4,

uniform float AtmosphereTransparency,
uniform float tileFactor,

out float4 outColor : COLOR
)
{
float4 sunColor = tex2D(gradient0,float2(uv2,1));
float4 atmosphereColor = tex2D(gradient0,float2(uv2,0));

// how transparent is the atmosphere?
float transparency = min(AtmosphereTransparency,attenuation); 

// get the texture color and lit value
float4 diffuse = tex2D(diffuse0, uv);
float shadow = diffuse.a;

// FYI YOU MAY NOT WANT TO DO THIS IN YOUR SHADER
// make ambient dark on side where light is
// and light on the side where it is dark
float3 ambient = sunColor * (1.0 - uv2);

float4 blended =  getBlendedSample8(tex2D(blend0, uv), tex2D(blend1, uv), uv * tileFactor);
diffuse = lerp(blended, diffuse, blendAmt);

// now shade based on the normal
diffuse.rgb = ((1.0 - shadow) * diffuse.rgb * ambient) + (diffuse.rgb * shadow);

// get atmosphere contribution    
float3 atmosphereAmt = (atmosphereColor * sunColor * (transparency + (transparency * shadow)));    

// add in atmosphere
outColor.rgb = (diffuse.rgb * sunColor * (1.0 - transparency)) + atmosphereAmt;
outColor.a = 1.0;
}

Atmosphere Shader Update And Tree/Grass Test

2010-04-28T06:50:00.000-07:00

I've gone and made the atmosphere shader more complex, sorry. The basic idea is still pretty straight forward, but I added mie scattering to the pixel shader and added extra code to fix issues with the atmosphere being too transparent when near the surface of the planet (stars were showing through).

Also, I worked on pre-calculated/static shadow maps for the terrain and used those with the grass and trees. JohnJ created Paged Geometry, which is built for 2d heightmaps, but I semi-adapted it so that each face of the planet cube has its' own paged geometry instance. Here's a video of that:

Note: the atmosphere shader in this video is the old atmosphere shader so the atmosphere is still too transparent on the sunny side of the planet

It has issues like, the billboard trees don't display right when viewed top down and they don't fade out based on height like they should. Also there is an abrupt transition from one paged geometry instance to the next when you cross over from one cube planet face to another. I may just have to roll my own simplified version.

And now, here is the NVIDIA FX Composer shader for the current atmosphere shader I'm using:


// outer atmosphere radius
float AtmosphereRadius <
 string UIName =  "Atmosphere Radius";
 string UIWidget = "Slider";
 float UIMin = 0.0;
 float UIMax = 10000.0;
 float UIStep = 1.0; 
> = {1200.0f};

// planet surface radius
float SurfaceRadius <
 string UIName =  "Surface Radius";
 string UIWidget = "Slider";
 float UIMin = 0.0;
 float UIMax = 10000.0;
 float UIStep = 1.0; 
> = {1024.0f};

// this is the sun position/direction
float4 gLamp0DirPos : POSITION < // or direction, if W==0
    string Object = "Light0";
    string UIName =  "Lamp 0 Position/Direction";
    string Space = (LIGHT_COORDS);
> = {10.0f,10.0f,10.0f,1.0};

// this is the atmosphere 2d gradient
texture gTex  <
    string ResourceName = "AtmosphereGradient";
    string ResourceType = "2D";
    string UIName = "Gradient Texture";
>;
sampler2D gTexSampler = sampler_state 
{
    Texture = ;
    Filter = MIN_MAG_MIP_LINEAR;
    AddressU = Clamp;
    AddressV = Clamp;
};

// this is for setting where the horizon should fall on the sphere
float StretchAmt <
 string UIName =  "Stretch Amount";
 string UIWidget = "Slider";
 float UIMin = 0.0;
 float UIMax = 1.0;
 float UIStep = 0.01; 
> = {0.25f};

// this is for mie scattering
float Atmosphere_G <
 string UIName =  "Atmosphere G";
 string UIWidget = "Slider";
 float UIMin = -1.0;
 float UIMax = -0.5;
 float UIStep = 0.001; 
> = {-0.95f};

float4x4 WorldViewProj : WorldViewProjection;
float4x4 ViewIXf : ViewInverse;
float4x4 WorldXf : World;


void main2VS(
    float3 pos : POSITION,
    uniform float4 lightPos,
 
    out float4 oPosition: POSITION,
    out float2 oUV: TEXCOORD0,
    out float oAlpha: TEXCOORD1,
    out float3 oCamToPos: TEXCOORD2,
    out float3 oLightDir :TEXCOORD3
    ) 
{
    float4 Po = float4(pos.xyz,1);
    float4 Pw = mul(Po,WorldXf);
    float3 position = Pw.xyz;
    float4 camPos = float4(ViewIXf[3].xyz,1);
 
    oPosition = mul(Po, WorldViewProj); 
 
    float radius = length(position);
    float radius2 = radius * radius; 
    float camHeight = length(camPos.xyz);
    float3 camToPos = position - camPos.xyz;
    float farDist = length(camToPos);
 
    float3 lightDir = normalize(lightPos.xyz);
    float3 normal = normalize(position);
 
    float3 rayDir = camToPos / farDist;
    float camHeight2 = camHeight * camHeight;
 
    // Calculate the closest intersection of the ray with the outer atmosphere
    float B = 2.0 * dot(camPos.xyz, rayDir);
    float C = camHeight2 - radius2;
    float det = max(0.0, B*B - 4.0 * C);
    float nearDist = 0.5 * (-B - sqrt(det));
    float3 nearPos = camPos.xyz + (rayDir * nearDist);
    float3 nearNormal = normalize(nearPos);

    // get dot products we need
    float lc = dot(lightDir, camPos / camHeight);
    float ln = dot(lightDir, normal);
    float lnn = dot(lightDir, nearNormal);

    // get distance to surface horizon
    float altitude = camHeight - SurfaceRadius;
    float horizonDist = sqrt((altitude*altitude) + (2.0 * SurfaceRadius * altitude));
    float maxDot = horizonDist / camHeight;
 
    // get distance to atmosphere horizon - use max(0,...) because we can go into the atmosphere
    altitude = max(0,camHeight - AtmosphereRadius);
    horizonDist = sqrt((altitude*altitude) + (2.0 * AtmosphereRadius * altitude));
 
    // without this, the shift between inside and outside atmosphere is  jarring
    float tweakAmount = 0.1;
    float minDot = max(tweakAmount,horizonDist / camHeight);
 
    // scale minDot from 0 to -1 as we enter the atmosphere
    float minDot2 = ((camHeight - SurfaceRadius) * (1.0 / (AtmosphereRadius  - SurfaceRadius))) - (1.0 - tweakAmount);
    minDot = min(minDot, minDot2);
  
    // get dot product of the vertex we're looking out
    float posDot = dot(camToPos / farDist,-camPos.xyz / camHeight) - minDot;
 
    // calculate the height from surface in range 0..1
    float height = posDot * (1.0 / (maxDot - minDot));
 
    // push the horizon back based on artistic taste
    ln = max(0,ln + StretchAmt);
    lnn = max(0,lnn + StretchAmt);

    // the front color is the sum of the near and far normals
    float brightness = saturate(ln + (lnn * lc));
 
    // use "saturate(lc + 1.0 + StretchAmt)" to make more of the sunset side color be used when behind the planet
    oUV.x = brightness * saturate(lc + 1.0 + StretchAmt);
    oUV.y = height;
 
    // as the camera gets lower in the atmosphere artificially increase the height
    // so that the alpha value gets raised and multiply the increase amount
    // by the dot product of the light and the vertex normal so that 
    // vertices closer to the sun are less transparent than vertices far from the sun.
    height -= min(0.0,minDot2 + (ln * minDot2));
    oAlpha = height * brightness;
 
    // normalised camera to position ray
    oCamToPos = -rayDir;
 
    oLightDir = normalize(lightPos.xyz - position.xyz); 
}

float4 mainBPS( 
    float2 uv : TEXCOORD0,
    float alpha : TEXCOORD1,
    float3 camToPos : TEXCOORD2,
    float3 lightDir :TEXCOORD3,
    uniform sampler2D TexSampler
) : COLOR {
 
    const float fExposure = 1.5;
    float g = Atmosphere_G;
    float g2 = g * g;

    // atmosphere color
    float4 diffuse = tex2D(TexSampler,uv);
 
    // sun outer color - might could use atmosphere color
    float4 diffuse2 = tex2D(TexSampler,float2(min(0.5,uv.x),1));

    // this is equivilant but faster than fCos = dot(normalize(lightDir.xyz),normalize(camToPos));
    float fCos = dot(lightDir.xyz,camToPos) * rsqrt( dot(lightDir.xyz,lightDir.xyz) * dot(camToPos,camToPos));
    float fCos2 = fCos * fCos;

    // apply alpha to atmosphere
    float4 diffuseColor = diffuse * alpha;
    
    // sun glow color
    float fMiePhase = 1.5 * ((1.0 - g2) / (2.0 + g2)) * (1.0 + fCos2) /(1.0 + g2 - 2.0*g*fCos);
    float4 mieColor = diffuse2 * fMiePhase * alpha;
  
    // use exponential falloff because mie color is in high dynamic range
    // boost diffuse color near horizon because it gets desaturated by falloff
    return 1.0 - exp((diffuseColor * (1.0 + uv.y) + mieColor) * -fExposure);
}

technique technique1 {
 pass p0 {
     ZEnable = false;
     ZWriteEnable = false;
     CullMode = CCW;
     AlphaBlendEnable = true;
     SrcBlend = One ;
     DestBlend = InvSrcAlpha;
     VertexShader = compile vs_3_0 main2VS(gLamp0DirPos);
     PixelShader = compile ps_3_0 mainBPS(gTexSampler);  
 }
}

Possible Improvements
- pre-calculate camera height, camera height squared and other such variables. you should notice that a lot of the vertex shader code would be the same for every vertex including calculating horizon distance, camera and light only based calculations and parts of the sphere intersection calculations.
- simplify mie scattering equation and remove hdr
- when the camera is inside the atmosphere we no longer need to calculate the atmosphere closest intersection so the program should switch to a simpler version of the shader once inside.

Known Issues
- transition from outer atmosphere to inner atmosphere is not smooth. I suspect this is due to my atmosphere being an un-realistic size so I had to add a tweak amount so that the transition point is actually a bit inside the atmosphere at a point where only the inside of the sphere is visible to the camera. At the point where the camera is the same height as the atmosphere, it can still see the outside of the atmosphere shell.
- when on the surface of the planet looking back at the horizon it looks more like a painted shell than a spherical haze
- when you get really close to the edge of the atmosphere on the side facing the sun there is an artifact that appears that I haven't fixed yet.
- there are banding issues in the sky gradient when on the side of the planet facing the sun that I haven't solved yet and I think they're related to the color choices in my gradient, but I'm not sure.

If you have any suggestions, improvements or bug fixes please let me know in the comments!

Sphere to Cube Mapping

2010-04-23T07:58:00.000-07:00

The following unit cube to unit sphere mapping is nice because the resulting sphere vertices are distributed somewhat evently:

Math Proofs: Mapping a Cube to a Sphere, by Phil

Here's the c++ version where x,y,z are the cube coords and sx,sy,sz are the sphere coords:

sx = x * sqrtf(1.0f - y * y * 0.5f - z * z * 0.5f + y * y * z * z / 3.0f);

sy = y * sqrtf(1.0f - z * z * 0.5f - x * x * 0.5f + z * z * x * x / 3.0f);

sz = z * sqrtf(1.0f - x * x * 0.5f - y * y * 0.5f + x * x * y * y / 3.0f);

Recently, I've been working on the reverse mapping (from unit sphere to unit cube) and have come up with this solution:

First determine the cube face the sphere point projects to. This step is simple - just find the component of the sphere vector with the greatest length.

Next, for each face, take the remaining cube vector components denoted as s and t and solve for them using these equations, which are based on the remaining sphere vector components denoted as a and b:

s = sqrt(-sqrt((2 a^2-2 b^2-3)^2-24 a^2)+2 a^2-2 b^2+3)/sqrt(2)
t = sqrt(-sqrt((2 a^2-2 b^2-3)^2-24 a^2)-2 a^2+2 b^2+3)/sqrt(2)

You should see that the inner square root is used in both equations, so only do that part once.

Here's the final function with the equations thrown in and checks for 0.0 and -0.0 and the code to properly set the sign of the cube component - it should be equal to the sign of the sphere component.

void cubizePoint(Vector3& position)
{
double x,y,z;
x = position.x;
y = position.y;
z = position.z;

double fx, fy, fz;
fx = fabsf(x);
fy = fabsf(y);
fz = fabsf(z);

const double inverseSqrt2 = 0.70710676908493042;

if (fy >= fx && fy >= fz) {
double a2 = x * x * 2.0;
double b2 = z * z * 2.0;
double inner = -a2 + b2 -3;
double innersqrt = -sqrtf((inner * inner) - 12.0 * a2);

if(x == 0.0 || x == -0.0) { 
position.x = 0.0; 
}
else {
position.x = sqrtf(innersqrt + a2 - b2 + 3.0) * inverseSqrt2;
}

if(z == 0.0 || z == -0.0) {
position.z = 0.0;
}
else {
position.z = sqrtf(innersqrt - a2 + b2 + 3.0) * inverseSqrt2;
}

if(position.x > 1.0) position.x = 1.0;
if(position.z > 1.0) position.z = 1.0;

if(x < 0) position.x = -position.x;
if(z < 0) position.z = -position.z;

if (y > 0) {
// top face
position.y = 1.0;
}
else {
// bottom face
position.y = -1.0;
}
}
else if (fx >= fy && fx >= fz) {
double a2 = y * y * 2.0;
double b2 = z * z * 2.0;
double inner = -a2 + b2 -3;
double innersqrt = -sqrtf((inner * inner) - 12.0 * a2);

if(y == 0.0 || y == -0.0) { 
position.y = 0.0; 
}
else {
position.y = sqrtf(innersqrt + a2 - b2 + 3.0) * inverseSqrt2;
}

if(z == 0.0 || z == -0.0) {
position.z = 0.0;
}
else {
position.z = sqrtf(innersqrt - a2 + b2 + 3.0) * inverseSqrt2;
}

if(position.y > 1.0) position.y = 1.0;
if(position.z > 1.0) position.z = 1.0;

if(y < 0) position.y = -position.y;
if(z < 0) position.z = -position.z;

if (x > 0) {
// right face
position.x = 1.0;
}
else {
// left face
position.x = -1.0;
}
}
else {
double a2 = x * x * 2.0;
double b2 = y * y * 2.0;
double inner = -a2 + b2 -3;
double innersqrt = -sqrtf((inner * inner) - 12.0 * a2);

if(x == 0.0 || x == -0.0) { 
position.x = 0.0; 
}
else {
position.x = sqrtf(innersqrt + a2 - b2 + 3.0) * inverseSqrt2;
}

if(y == 0.0 || y == -0.0) {
position.y = 0.0;
}
else {
position.y = sqrtf(innersqrt - a2 + b2 + 3.0) * inverseSqrt2;
}

if(position.x > 1.0) position.x = 1.0;
if(position.y > 1.0) position.y = 1.0;

if(x < 0) position.x = -position.x;
if(y < 0) position.y = -position.y;

if (z > 0) {
// front face
position.z = 1.0;
}
else {
// back face
position.z = -1.0;
}
}

I posted a stackoverflow question and got a lot of help from there and from mathoverflow too. I used wolframalpha.com to get the equations for s and t.

My thanks to gmatt and Leonid Kovalev!

Tri-Planar Texturing On A Sphere And Spacescape Release!

2010-03-17T19:06:00.000-07:00

Applying an animated normal map to a sphere is a problem. You have stretching issues and if using a cube-to-sphere mapping you have uv direction issues. The only solutions I know of to solve these is to do perlin noise in a shader, a 3d repeating noise texture(?) or do tri-planar texturing and use a 2d texture map, which is what I've done here.

I used the code from this GPU Gems 3 article and added a second bump map and animated them by updating the vertex uv coords and the results are decent.

Now there are no visible seams on the sphere and the bump map is pretty evenly spread across the surface. Also when it animates you don't have any visible seams due to opposing uv directions because of the way tri-planar texturing blends the uv maps. This blending does mean, however, that where the cube edges meet on the sphere you get most of the stretching and the bump map is more random. This side affect is OK for water because I want the bumps to look random.

I still have to deal with a bunch of issues including the fps hit this shader brings with it. Now instead of 2 normal map texture look ups per pixel there are 6 - 1 for each of the 3 axis and there are 2 normal maps. On top of this I have texture look ups for the atmosphere color, sun color and the water depth and I haven't even tried adding reflection or refraction.

I've pasted the FX Composer .fx HLSL file at the bottom of this post if you want to try it out.

Also, I have released the Spacescape skybox tool and uploaded the source code to sourceforge.net/projects/spacescape!

The tool is rather complex and so I plan on writing some tutorials & tips to help answer some questions that have been coming up.

Here's an intro video:

Here's the tri-planar sphere.fx file code for NVidia FX Composer. NOTE: this is not my water shader, just the tri-planar stuff and it has a slider called OFFSET that you can drag to see how the bump map animates.

/************* UN-TWEAKABLES **************/

float4x4 WorldITXf : WorldInverseTranspose < string UIWidget="None"; >;
float4x4 WvpXf     : WorldViewProjection < string UIWidget="None"; >;
float4x4 WorldXf   : World     < string UIWidget="None"; >;
float4x4 ViewIXf   : ViewInverse   < string UIWidget="None"; >;

float3 Lamp0Pos : Position <
string Object = "PointLight0";
string UIName =  "Lamp 0 Position";
string Space = "World";
> = {-0.5f,2.0f,1.25f};

float OFFSET <
string UIWidget = "slider";
float UIMin = 0.0;
float UIMax = 1.0;
float UIStep = 0.001;
string UIName =  "Offset";
> = 0.0;

texture normalTexture  <
string ResourceName = "water-normal.png";
string ResourceType = "2D";
string UIName = "Water Normal Texture";
>;
sampler2D NormalSampler = sampler_state 
{
Texture = ;
Filter = MIN_MAG_MIP_LINEAR;
AddressU = Wrap;
AddressV = Wrap;
};

/************* DATA STRUCTS **************/

/* data from application vertex buffer */
struct appdata {
float3 Position : POSITION;
};

/* data passed from vertex shader to pixel shader */
struct vertexOutput {
float4 HPosition : POSITION;
float3 UV  : TEXCOORD0;
float3 UV2  : TEXCOORD1;
float3 WorldNormal : TEXCOORD2;
float3 LightVec : TEXCOORD3;
};

/*********** vertex shader ******/

vertexOutput simpleVS(appdata IN) {
vertexOutput OUT = (vertexOutput)0;

float4 Po = float4(IN.Position.xyz,1);    
float3 Pw = mul(Po,WorldXf).xyz;
OUT.HPosition = mul(Po, WvpXf);
OUT.LightVec = (Lamp0Pos - Pw);

OUT.WorldNormal = Pw;

// OFFSET is used to preview what animation would look like

// first uv for large waves
OUT.UV = ((Pw + 1.0) * 0.5);
OUT.UV.xy +=OFFSET;

// second uv for small waves
OUT.UV2 = ((Pw + 1.0) * 0.5);
OUT.UV2.xz +=(OFFSET * 2.0);

return OUT;
}

/********* pixel shader ********/

float4 simplePS(vertexOutput IN) : COLOR {

float3 blend_weights = abs( IN.WorldNormal );   // Tighten up the blending zone:  
blend_weights = (blend_weights - 0.2) * 7;  
blend_weights = max(blend_weights, 0);      // Force weights to sum to 1.0 (very important!)  
blend_weights /= (blend_weights.x + blend_weights.y + blend_weights.z ).xxx;  

float4 blended_color; // .w hold spec value  
float3 blended_bump_vec; 

// Compute the UV coords for each of the 3 planar projections.  
// tex_scale (default ~ 1.0) determines how big the textures appear.  
float tex_scale = 4.0;
float tex_scale2 = 8.0;
float2 coord1 = IN.UV.yz * tex_scale;
float2 coord2 = IN.UV.zx * tex_scale;
float2 coord3 = IN.UV.xy * tex_scale;
float2 coord4 = IN.UV2.yz * tex_scale2;  
float2 coord5 = IN.UV2.zx * tex_scale2;  
float2 coord6 = IN.UV2.xy * tex_scale2;   

// Sample color maps for each projection, at those UV coords.  
float4 col1 = float4(1.0,0,0,1);  
float4 col2 = float4(0,1.0,0,1);  
float4 col3 = float4(0,0,1.0,1);  

// Sample bump maps too, and generate bump vectors.  
float2 bumpFetch1 = tex2D(NormalSampler,coord1).xy - 0.5;  
float2 bumpFetch2 = tex2D(NormalSampler,coord2).xy - 0.5;  
float2 bumpFetch3 = tex2D(NormalSampler,coord3).xy - 0.5;  
float2 bumpFetch4 = tex2D(NormalSampler,coord4).xy - 0.5;  
float2 bumpFetch5 = tex2D(NormalSampler,coord5).xy - 0.5;  
float2 bumpFetch6 = tex2D(NormalSampler,coord6).xy - 0.5;  

// (Note: this uses an oversimplified tangent basis.)  
float3 bump1 = float3(0, bumpFetch1.x, bumpFetch1.y);  
float3 bump2 = float3(bumpFetch2.y, 0, bumpFetch2.x);  
float3 bump3 = float3(bumpFetch3.x, bumpFetch3.y, 0);

float3 bump4 = float3(0, bumpFetch4.x, bumpFetch4.y);  
float3 bump5 = float3(bumpFetch5.y, 0, bumpFetch5.x);  
float3 bump6 = float3(bumpFetch6.x, bumpFetch6.y, 0);   

// Finally, blend the results of the 3 planar projections.  
blended_color = col1.xyzw * blend_weights.xxxx +  
col2.xyzw * blend_weights.yyyy +  
col3.xyzw * blend_weights.zzzz;  

blended_bump_vec = bump1.xyz * blend_weights.xxx +  
bump2.xyz * blend_weights.yyy +  
bump3.xyz * blend_weights.zzz;

blended_bump_vec += (bump4.xyz * blend_weights.xxx +  
bump5.xyz * blend_weights.yyy +  
bump6.xyz * blend_weights.zzz) * 0.5;

float3 N_for_lighting = normalize(IN.WorldNormal + blended_bump_vec);
return saturate(blended_color) * dot(normalize(IN.LightVec),N_for_lighting);
}

/*************/

technique main
{
pass p0
{
VertexShader = compile vs_3_0 simpleVS();
PixelShader = compile ps_3_0 simplePS();
ZEnable = true;
ZWriteEnable = true;  
CullMode=None; 
}
}

/***************************** eof ***/

Spacescape - Now With Billboards

2010-02-17T19:37:00.000-08:00

(click to enlarge)

Just a minor update - I've added billboard sprites to the mix where as before I was just using point sprites. I also added an extra line to the noise shader like this:


noiseSum = pow(noiseSum / powerAmount);

This allows me to control the slope of the noise gradient so it is more steep or more gradual, which is something I needed for masks.

The image above really taxes my system (3-4 fps). It has 12 layers: one ridged noise mask for the brightest stars, then another for the middle level of stars and then two more ridged noise haze layers and the rest are mixes of billboard and point stars.

For kicks I threw the generated skybox into the planet app and it's definitely a bit over the top and low-res/blurry. Still it is "fun"

(click images to enlarge)

As usual, I uploaded these images and more to the My First Planet gallery.

I re-implemented writeToFile() in the plugin so I can save to files. I also added a writeToMaterial() function to the plugin so I can preview the skybox in ogre.

One thing I've noticed is that the resolution of skybox really affects the brightness of small stars. When I save a 2048x2048 skybox out the single pixel point stars are crisp, but get lost when imported into a program with a low screen resolution. So you kinda have to take that into account when making the skyboxes. It might look great at the resolution on your monitor, but not at the resolution on someone else's monitor. This is where the writeToMaterial() function will be useful so you can preview the skybox at different resolutions to see if it works OK at low resolutions.

I might mess with the mipmap generation for lower levels so that stars don't loose their brightness as quickly when the high resolution image is scaled down.

Here's a sample generated skybox (click for 1024x1024 version - open in new window):
right

left

top

bottom

front

back

And here's a funny little screenshot of what a skybox layered sphere looks like from the outside (not the same as the one above):

Introducting Spacescape! A Space Skybox Creator.

2010-02-15T20:59:00.000-08:00

Spacescape is a tool that uses Ogre to create / generate space scene skyboxes. The way it works is a camera sits inside a number of user defined layers / shells. Each layer can be a bunch of point sprites ( for stars), or a noise field (for nebulas/haze etc.) You can define how many stars you want and the color based on distance. In the screenshots I'm posting there are 7 layers. 3 of the layers are regular blue/white stars, 1 is a few red stars, 2 layers are ridged fbm noise of different colours and the 3rd layer is regular fbm noise used as a mask to make stars cluster by darkening regions of space.

This has been a really fun tool to make and I still have a lot left to do like the GUI. At present it reads in xml config files or you can use the plugin api to manipulate the skybox via code. Did I mention this will be an Ogre plugin too? I plan on releasing the plugin and tool as soon as I get a GUI and finish refactoring the save to file code.

How it works

Making a bunch of point sprites is easy. I use an Ogre::ManualObject for that with pointSprites enabled on the material.

For making the haze I create an inverted unit sphere and use a glsl shader on it that implements fbm and ridged fbm noise using Perlin's improved noise (not simplex noise). Lintfordpickle at britonia-game.com has a good explanation with code samples about how fbm and ridged fbm noise work

To create the skyboxes I just create a camera with FOV set to 90degrees and render to texture the six images of the skybox. I have it set up to render to texture the mipmap levels too, so if a user wants to save a dds file with mipmaps they can, or they can just save out the six individual images. With the Ogre plugin it will also be possible to not save out the file but just tell the plugin to create a skybox with a given config file and use it in your own application.

Here's some more images (click to enlarge - you'll need to in order to see the stars better):

A note about dithering:
I've had a tough time figuring out what to do about gradient banding with dark colors in the space backgrounds. Without some kind of dithering or noise the gradient is very obvious. You can see the banding clearly in all the videos and screenshots I've posted prior to this post. The skybox I was using before was generated with blender and spiced up in photoshop, but there was no dithering on the haze so it's really ugly. To get around this with Spacescape, I provide the option to dither a noise layer by a controllable amount and this seems to make the banding issue go away.

The plan is to use this plugin in MyFirstPlanet to let users design their own space skyboxes easily too.

Hopefully, I'll have a demo and some source code posted in the next week or so.

New YouTube Channel For Planet Dev Videos

2010-02-06T11:17:00.001-08:00

I started the petrocket YouTube channel and am posting dev videos there for now. I like Vimeo, but YouTube now allows HD videos and I think it has a larger developer audience.

Here's another quick video I uploaded to test the HD quality. Sorry for the jerky camera movement.

Simple Flexibile Atmosphere Shaders

2010-01-24T19:10:00.000-08:00

Uploaded a video of the effect

First, why no posting since September? Well, in October my wife went into pre-term labor so she was on bed rest and that meant I had to become a mom till our son was born late November. Then in early December it was holiday madness and new baby madness!

Slowly, after the holidays I started work on the planet again. I've mostly been converting it to an Ogre Plugin and refactoring it. I'll do a separate blog post about the architecture of the plugin later I hope, but for now this post is about my work in NVidia FX Composer 2.5 working on some flexible atmosphere shaders.

If you don't know, my earlier shaders were based entirely off Sean O'Neil's free atmosphere shaders. Now, Sean does things the right way, which is why his work looks so good! His shaders represent the atmosphere of the earth very accurately. The one thing that prevented me from cutting and pasting them into my project was they rely on your atmosphere radius being a certain ratio to the surface radius (an earth sized ratio). My atmosphere's are much exaggerated so it didn't really work and I was kind of lost in all the math.

Side note:If you're ever struggling with this stuff I highly recommend you contact him because he's very kind and helpful.

So I started work on a shader that isn't mathematically correct, it just uses a look up table for the blend colors based on 2 things:
- dot product between the camera and the light
- dot products between the two sphere intersections of a ray from the camera to the vertex being drawn and the light.

Here's the 32x16 look up table for the atmosphere shell.

On the horizontal axis values on the left are used when the point on the atmosphere is pointing away from the sun and values on the right are used when the point on the atmosphere is pointing toward the sun. The vertical axis values are for blending between points near the surface of the planet (bottom) and points at the edge of the atmosphere (top).

So here is a side view of the planet that shows the gradient well.

To calculate the color to use on the horizontal axis I use this:


float StretchAmount = 0.5;
ln = dot(lightDir, farVertexPosition);
lnn = dot(lightDir, nearVertexPosition);
lc = dot(lightDir, cameraPosition);

ln = max(0,ln + StretchAmount);
lnn = max(0,lnn + StretchAmount);

uv.x = saturate(ln + (lnn * lc)) * saturate(lc + 1.0 + StretchAmount);

So when the camera is between the planet and the sun ln will be 0 and lnn will be 1 and lc will be 1 so you'll get uv.x = 1 (the blue color of the atmosphere). When the camera is on the back side of the planet ln will be 1, lnn will be 0 so uv.x would be 1.0 (the blueish color of the atmosphere) from the back too except the saturate(lc + 1.0 + StretchAmount) bit scales the value based on lc, which would be -1, so -1 plus 1 + stretch amount = 0.5, so uv.x ends up being 0.5 and you end up seeing the redish colour.

The StretchAmount is used to determine where the sunset should begin.

I also multiple the color by the height so it fades out as the atmosphere gets thinner, and also multiply by another amount so values at the back of the sphere fade out. This value is defined by:


    float StretchAmt2 = 0.5;

    float ln2 = max(0,ln + StretchAmt + StretchAmt2);
    float lnn2 = max(0,lnn + StretchAmt + StretchAmt2 );
    float alpha = saturate(ln2 + (lnn2 * lc));
    
    float finalAlpha = height * alpha;

I wanted to have the alpha fade out after the point at which the sunset starts and this allows for that. Notice it is basically identical to the uv.x calculation it just offsets the ln and lnn values so that I can control when to start fading out the atmosphere. If StretchAmt2 is 0 then the atmosphere will be faded out by the horizon, a value of 0.5 is what is used in the pictures and it lets the atmosphere fade out about a quarter way around the back of the planet.

The surface shader uses a smaller 32x2 gradient map.

The top row corresponds to the atmosphere color and the bottom row corresponds to the sun color. Horizontal values correspond to the dot product between the surface position and the sun position.

Currently the pixel shader color output comes from this:


outColor = (diffuse * sunColor) + (atmosphereColor * min(AtmosphereTransparency,attenuation)) * sunColor;

The AtmosphereTransparency is how transparent I want the atmosphere to be, and presently I'm using 0.4 based on personal preference.

Lastly, the attenuation factor is based on the distance from the camera to the vertex being drawn and the code to calculate it is this:


float vd = min(AtmosphereHeight,VisibilityDistance);
outAttenuation = saturate((cameraToVertexDistance - VisibilityDistance)/ (AtmosphereHeight + vd));

VisibilityDistance is the minimum visibility distance so you can adjust it for personal taste. A large visibility distance will give the atmosphere a very thin impression and a small visibility distance would be a very dense atmosphere.

Here's a boring picture from the surface:

Next step is to put these shaders into Ogre and see how they look. Until then, don't forget to read the NVidia GPU Guide and ATI GPU Guides every night before you go to bed.

How Much Memory Does This Planet Need?

2009-09-12T10:43:00.000-07:00

These are the numbers I'm using for the planet in the video and below are estimates of how much uncompressed memory would be needed for a planet with these properties:

Patch Size (# vertices on a single patch edge): 33
Max Depth of Quad Tree: 5
Texture Size Per Patch: 128 x 128

Assuming I could use a single height map, normal map and tangent map and sample them by using geomipmapping:
16 bit height map memory = 6 faces x ((33 verts per patch x 2^(max depth + 1)) - (2^(max depth + 1) - 1))^2 x 2 (because 16 bit)
= 6 x ((33 x 64) - (64 - 1))^2 x 2
= 6 x (2049 x 2049) x 2
= 6 x 8,396,802
= 58,777,614 bytes

8 bit normal map memory = 6 faces x ((33 verts per patch x 2^(max depth + 1)) - (2^(max depth + 1) - 1))^2 x 3 (for x,y,z)
= 6 x (2049 x 2049) x 3
= 75,571,218 bytes

tangent map is the same size as normal map

128x128 textures memory: this is a summation for each level or you can just calculate the amount needed for the deepest level and multiply by 1/3rd for a ceiling estimate (same estimate used when doing mip mapping) because each level is one mip map level lower than the level below it.
= 6 faces x texture size x num patches at lowest level x num bytes per pixel
= 6 faces x (128 x 128) x (2^(max depth + 1))^2 x 3
= 6 x (128 x 128) x 4096 x 3
= 1,207,959,552 bytes
ceiling = 1,207,959,552 + (1,207,959,552 / 3) = 1,610,612,736 bytes

So the total is:
58,777,614 + 75,571,218 + 75,571,218 + 1,610,612,736
= 1,820,532,786 bytes

So just under 2 GB for a single planet and nothing else. While 2GB is not an unreasonable amount of RAM to ask a gaming rig to set aside these days it is still too much if you want to have a lot of other models, animations and textures loaded. That's why I've been working on resource management more than anything else.

I would like to allow the entire planet to be custom made and loaded from disk rather than just generated on the fly and I'd like to be able to support a combination of both. The idea is that a planet starts out randomly generated and then get's customized by the artist - this should work well in cases where you have a couple continents and the rest is ocean floor, or where you have a moon that is not customized at all. No reason for your artists to spend time on the ocean floor usually, and hopefully they can tweak the generation parameters to get close the the type of land formations they want.

Really, I could load the height map into memory and always generate the normals and tangents based on the height map. The textures would be too large to keep all in memory at once so I would still have to load/unload those as needed.

Alternately, I could scrap the whole texture per patch thing and go back to some blended texture pixel shader based on a blend map that is the same resolution as the height maps ( 6 x (2049 x 2049) x 8 layers = 201,523,248 bytes)

MyFirstPlanet Video

2009-09-05T18:39:00.000-07:00

Here's the first video showing the planet with textures and atmosphere shader. I used fraps (windows only) and recorded it while running in OpenGL mode. DirectX would probably be smoother but I haven't ported the shaders to HLSL yet.

My First Planet - Work In Progress - Ogre3d Engine from petrocket on Vimeo.

Now I'm still working on a simple way to pull terrain patch textures and normal maps from the disk when they're available instead of creating them on the fly - this way I hope to be able to modify the diffuse textures and customize the planet (so easy to say, so hard for me to do).

My first idea is to create a resource pool for the terrain patch diffuse images and normal map images and then load files from disk into those resource pools as need from the build thread. Not sure if this will work well enough because it may just not be loading enough images in advance to keep ahead of demand.

I should probably create a second thread that is a low priority thread with an entirely different quad tree based on the camera position in the future (assuming the user keeps moving in the same direction). I could update this quad tree and load images for this future position when the real camera position based quad tree isn't updating/building (and when would that be???)

Water Shader Update & Atmosphere Added

2009-08-25T08:04:00.000-07:00

I reintegrated the atmosphere shell/shader and updated the water shell with a heightmap of the terrain under it so I can have the water depth affect the transparency and color and I think it adds a lot - although now everything looks tropical - which I don't mind.

Water Depth Effects:

Also I made my underwater texture have fake caustics (static) on them which is subtle but nice:

Fake Caustics texture:

From Above:

And here are some pictures of the atmosphere and water shader together from various spots on the planet.

You can view all the My First Planet Images in the gallery section on my website

Notes:
- I pretty much eliminated banding in the generated terrain texture images by increasing the resolution of my terrain height maps from 8bit to 16bit.
- The atmosphere still has problems and needs tweaking - there is no sun and the sky to space transition is too abrupt amongst other things.
- PSSM VSM shadows slowed the frame rate down too like 30-40 fps so I left them out for now.
- I need to solve the issue of how noticable texture repeating is from up in the atmosphere and I need to add some noise to the texture generation to make things more interesting.

Mipmapping RTT in Ogre3D and Look Up Table Filtering

2009-08-12T19:46:00.000-07:00

Two things to write about in this post about the texture generation. First of all, when you create textures via render to texture in Ogre3d you do not get mipmaps auto-generated for you. Strangely enough, DirectX still seemed to do some kind of mipmapping, but OpenGL did not. To implement it in Ogre3d you have to do a render to texture for each mipmap level you want to generate. Here's how I did it...


for(unsigned int i = 0; i <= numMipMaps; ++i) {
    // select mipmap level
    target = mTexture->getBuffer(0,i)->getRenderTarget();
    target->setAutoUpdated(false);

    if(target->getNumViewports()) {
     // get an existing viewport
     mViewport = target->getViewport(0);
    }
    else {
     // add a new viewport 
     mViewport = target->addViewport(mRTTCam);
     mViewport->setClearEveryFrame(false);
     mViewport->setOverlaysEnabled(false);
    }
    // render the quad
    mSceneMgr->manualRender(
            &mRenderOp, 
            mPass, 
            mViewport, 
            Matrix4::IDENTITY, 
            Matrix4::IDENTITY, 
            Matrix4::IDENTITY, 
            mBeginEnd //issue a _begin and _end render call
    );
}

The results were decent - not as good as hardware generated mipmaps, but better than no mipmaps and yes, it does affect the speed. Rendering 2 mipmaps isn't so bad a hit but rendering 6+ becomes noticable - sorry I don't have any hard numbers.

Secondly, I was trying to combat texture banding due to the low resolution of the height maps, slope maps, and look up table. I use filtering on the height maps and slope maps so those are blended decently, but the look up table couldn't be filtered because the look up table is really 16 look up tables combined into one texture. When I introduced filtering on the look up table the banding would be lessened but I'd get artifacts where there was bleed between look up tables. Recall the look up table texture is a 1024x256 texture that is 4 256x256 textures end on end horizontally. So the horizontal access is all that really matters because vertically there is no bleed (the texture address mode is set to clamp, not wrap). The horizontal access is the slope value and so what I did was compress the slope value and center it on the middle of the look up table texture so instead of values being from 0 - 255, now they are from 15 - 239 so I don't have to worry about bleeding artifacts anymore (no pun intended).

Here's a couple before/after images showing how the trilinear filtering on the look up table improves the banding issue:

Without filtering...

(click to zoom in)

And with filtering...

(click to zoom in)

Thoughts:
1. How can I use Multiple Render Targets to render textures faster - group them up so I can render 4 textures with one shader?
2. How can I cheaply introduce noise to the altitude and slope values to make the blending better and more random looking?
3. Why is the terrain slightly blueish and dark?
4. When should I work atmosphere and water back in.

Planet Terrain Texture Generation Optimization Continues

2009-08-08T12:55:00.000-07:00

I put a lot of profiling code in Ogre's SceneManager::manualRender() function and in SceneManager::_setPass() as well as in the GL_RenderSystem::_render() function etc. Turns out my profiling code in GL_RenderSystem seems to have skewed my profile results.

Profiling the code wasn't giving me many optimization ideas so I took another approach. You know how when you have slow code sometimes you just cut parts of it out till you find out what is slow about it - not the best way to optimize but it can give you some insight when you don't fully understand the design and implementation of libraries you are using (Ogre3d in my case). I could see from the profiling results that it would be good to focus on the Render To Texture(RTT) code so I started removing all the texture look ups in my RTT shader except one and the timing/stuttering issues improved noticeably. I started by adding back in each texture look up one by one to see if adding a certain texture brought back the stuttering/slowness.

It seems that some of my terrain textures were 1024x1024 while the rest were 512x512 (I have 16 terrain textures that get blended in the RTT shader). So I converted those to 512x512 and that helped - and it seems that going above ~8 512x512 textures gives unacceptable slowness and more stuttering. For some reason this is only an issue with OpenGL Render System not DirectX Render System which seems to handle 16 blends fine with no stuttering and faster render times. I may look into this more later because I think I need at least 12 terrain textures.

I might try having several large shared height maps and slope maps - one per cube face to start - instead of one small height map and slope map per terrain patch. I just like the simplicity of the current approach, but it is probably going to be too slow.

Also, I've moved up to the latest Ogre release v1.6.3

Lastly, I tried GLIntercept which was very nice and easy to use and can output textures, all the OpenGL calls and lots more. Did I mention it's free?

At some point I need to start saving rendered terrain textures and height maps and normal maps to disk then reading them back from disk instead of generating them every time.

OpenGL Render To Texture 10x Slower than DirectX

2009-07-26T19:38:00.000-07:00

That's my main problem right now. It takes roughly 10 - 20 times longer when I call mSceneManager->manualRender() when using OpenGL in Ogre instead of DirectX (9).

After getting my app running in DirectX, I used NVidia Perfhud to debug the framerate spikes - only to find that DirectX is vastly outperforming OpenGL! So now I can't really afford gDEBugger ($800), so I'm stuck with inserting my mini-profiler into the GL_RenderSystem code to figure out what parts are slowing down etc. That will be a good experience and help me get more familiar with Ogre RenderSystem calls.

Misc Notes:
- Make sure you play around with your RenderSystem configuration settings. I had set my Display Frequency to 59 and that caused the framerate to be cut in half. Dunno why I had it set to that value.
- With OpenGL you don't need the RenderSystem to issue _begin() and _end() frame calls, but you do in DirectX.
- Fixed a bug where when writing dynamic textures I was using pointer math and it was messing up my textures in DirectX. I switched to using array notation and it fixed the issue. Haven't spent much time figuring out why I was having so much grief with that (it worked fine with the OpenGL RenderSystem).

Next, I plan on profiling the GL_RenderSystem to figure out those RTT issues, and upgrading to the newly released Ogre version 1.6.3!!

Optimisation Fail

2009-07-21T18:43:00.000-07:00

This is a maintenance/progress blog post so nothing exciting really. I just try to post a few times a month as any developer keeping a journal should.

I got rid of the vertex buffer and texture resource pools and created a mesh pool and each mesh has its' own vertex buffer and textures so the same thing is accomplished and the mesh resource manager is now way simpler. I used to have std::maps with pointers to the meshes in each list depending on what stage the mesh was in (needs building, built, and visible, cached and cache build) - now I have 3 std::vectors for 3 lists: needs building, built and visible.

The lists are stored in an array like this:

std::vector mMeshLists[3];

The built and visible lists are in index 0 and 1 and I swap them periodically like this:

mVisibleListIndex = (mBuiltListIndex + 1) % 2;

And the build list is always index 2.

Unfortunately, the app is still too jerky. Creating the textures on the graphics card is taking too long, generating the heightmaps is taking too long and it's not smooth even though I'm using threads for all the non-opengl stuff. Most of the time spikes are now happening in Ogre so I will probably have to add some profiling there to figure out what's going on.

Also, I switch over to DirectX 9 so that I can use NVidia's Perfhud tool to help me analyze how the graphics card and cpu are being utilized. That's been fun.

The only major bug I have at the moment is that the Render To Texture code that generates the terrain texture for each patch isn't working in DirectX right. My dynamic heightmap texture is not being created correctly and I don't know why yet. I have been experimenting with different pixel formats to no avail yet.

I'm almost thinking of doing another simpler version of the quad tree planet that uses geomippmapping and the planet size is restricted to 1025x1025 vertices per side - or maybe 2049x2049. This terrain is taking too much of my time to code that should be spent on other important game things!