I have a new PC computer and this is a milestone for the development for BGE and my racing game. Finally I can to some more quality screen capture, and the first ones to show you are - area lights!
As soon as I saw Arkano22`s implementation of area lights in gamedev.net forums I knew Blender must have it in GE! This is a slightly modified version of Arkano22 technique, the biggest differences are the smoother light falloff and specular reflection glossiness variations based of the reflecting surface properties and distance, and of course - the texture support!
video showing how to set-up them:
win32 build: https://dl.dropbox.com/u/11542084/Blender246AreaBuild.zip
Labels
- shaders (26)
- Blender (10)
- Racing game (10)
- BGE Candy (5)
- DoF (5)
- 3d models (4)
- bokeh (4)
- volumetric (4)
- platformer game (3)
- sky (3)
- BGE Air Race (2)
- SSAO (2)
- raycasting (2)
- status (2)
- WebGL (1)
- stereo 3D (1)
- tron (1)
- tutorials (1)
- webcam (1)
November 16, 2012
October 29, 2012
RGP day 9 - physics
So today I am doing something completely different I've done so far - the physics system. It is the next big challenge aside from the track coordinates and AI.
For collision detection and simpler stuff I will be relying on Blender's Bullet Physics system, but more advanced things - track space constraints, hover spring-damper system, vehicle handling and behaviors I will have to write from a scratch. And as an artist I am very good at it :P. Fortunately we have an Internet and there are a lot of really helpful resources for this.
The first thing I tried to implement was a mass-spring-damper system. I will be using it to make the vehicles levitate above the ground/racetrack surface. The idea is to cast a ray from the vehicle's vertical axis down. If it collides with a surface the spring-damper simulation will run and apply the calculated force to the vehicle.
The most helpful resource I found had an actual Blender Game Engine implementation already :). HERE is the link where I found it. It is done by Sebastian Korczak, same guy who is making the Burster - a web browser plugin to allow publish and play Blender files online. I will be using it at one point of development to show off the progress.
So after some changes I had a nice springy levitating box.
Another thing I managed to create - a force field that will keep the race car close to speedway's surface, thus preventing the vehicle to fall off the track surface even if the speedway is oriented upside down.
blend file HERE
For collision detection and simpler stuff I will be relying on Blender's Bullet Physics system, but more advanced things - track space constraints, hover spring-damper system, vehicle handling and behaviors I will have to write from a scratch. And as an artist I am very good at it :P. Fortunately we have an Internet and there are a lot of really helpful resources for this.
The first thing I tried to implement was a mass-spring-damper system. I will be using it to make the vehicles levitate above the ground/racetrack surface. The idea is to cast a ray from the vehicle's vertical axis down. If it collides with a surface the spring-damper simulation will run and apply the calculated force to the vehicle.
The most helpful resource I found had an actual Blender Game Engine implementation already :). HERE is the link where I found it. It is done by Sebastian Korczak, same guy who is making the Burster - a web browser plugin to allow publish and play Blender files online. I will be using it at one point of development to show off the progress.
So after some changes I had a nice springy levitating box.
Another thing I managed to create - a force field that will keep the race car close to speedway's surface, thus preventing the vehicle to fall off the track surface even if the speedway is oriented upside down.
blend file HERE
October 28, 2012
shader based cube environment mapping
I present you a pure shader based cube environment mapping. It might be useful for those who, for whatever reason, does not have "samplerCube" texture type support in their engine or want some more flexibility or customization for envmaps. It is a tiny bit slower than the proper version and mip-mapping is not working well, so it is pretty much useless.
This paper helped me a lot: http://www.cs.wustl.edu/~cmg/content/papers/jgt2007em/jgt2007em.pdf
Anyways, the input can be 6 separate textures or cube environment map Blender style. A standard OpenGL style alignment is on the way.
shader HERE
screenshots are in previous post :)
This paper helped me a lot: http://www.cs.wustl.edu/~cmg/content/papers/jgt2007em/jgt2007em.pdf
Anyways, the input can be 6 separate textures or cube environment map Blender style. A standard OpenGL style alignment is on the way.
shader HERE
screenshots are in previous post :)
October 23, 2012
//status update 04 & RGP day 8
Lots of good stuff has happened recently. I am waiting for my new custom laptop to get shipped from US, so finally I will be able to normally screencast the process of the development of my racing game ..and to actually play my game. As a real tech geek I will also write a short review of it :)
Not much has happened to RGP since the last post and I believe the real process will start whenever I will be on my new rig.
Here is the list of stuff regarding RGP:
- So for the outdoors lighting in the game I will be using a procedural sky model originally presented in 2002 GDC by Naty Hoffman and Arcot J. Preetham. Implementation by Simon Wallner seemed to be the best one I could find and I have already got it working in BGE (see it HERE). I thought I was quite satisfied with the results, but just few days ago some guy asked for an assistance regarding the sky shader as he is implementing it in UDK4 engine. It turns out I had seen his works numerous times and visited his portfolio earlier, be sure to check it out HERE <- awesome stuff! Anyways he also pointed out that it lacks the distinct sunrise feel to it so I took another look at the shader. After few modifications I came up with a nice sunset/sunrise effects.
- I also added a Uncharted2 filmic tone mapping operator from John Hable's GDC presentation and implementation of it from HERE. I really Hope I can add a real HDR support in BGE someday.
- Another feature I have been trying to replicate in BGE is generation of cubemap environment maps in real-time. I did it by simply rendering textures from 6 cameras and then combining them in a shader. It is slow but works! A simplified and optimized version of it I might use for reflection in the game.
- And the last but not least - a pseudo lens flare by John Chapman (implementation from HERE)
blends:
both files also feature point light scattering by Miles Macklin.
realtime cubemap:
https://dl.dropbox.com/u/11542084/realtime_cubemap.blend
lens flares:
https://dl.dropbox.com/u/11542084/flare_playground_3.blend
screenshots:
the upgraded sky model
real time cube environment mapping
lens flares
Battlefield3 style dusty lens
light directly into lens
Not much has happened to RGP since the last post and I believe the real process will start whenever I will be on my new rig.
Here is the list of stuff regarding RGP:
- So for the outdoors lighting in the game I will be using a procedural sky model originally presented in 2002 GDC by Naty Hoffman and Arcot J. Preetham. Implementation by Simon Wallner seemed to be the best one I could find and I have already got it working in BGE (see it HERE). I thought I was quite satisfied with the results, but just few days ago some guy asked for an assistance regarding the sky shader as he is implementing it in UDK4 engine. It turns out I had seen his works numerous times and visited his portfolio earlier, be sure to check it out HERE <- awesome stuff! Anyways he also pointed out that it lacks the distinct sunrise feel to it so I took another look at the shader. After few modifications I came up with a nice sunset/sunrise effects.
- I also added a Uncharted2 filmic tone mapping operator from John Hable's GDC presentation and implementation of it from HERE. I really Hope I can add a real HDR support in BGE someday.
- Another feature I have been trying to replicate in BGE is generation of cubemap environment maps in real-time. I did it by simply rendering textures from 6 cameras and then combining them in a shader. It is slow but works! A simplified and optimized version of it I might use for reflection in the game.
- And the last but not least - a pseudo lens flare by John Chapman (implementation from HERE)
blends:
both files also feature point light scattering by Miles Macklin.
realtime cubemap:
https://dl.dropbox.com/u/11542084/realtime_cubemap.blend
lens flares:
https://dl.dropbox.com/u/11542084/flare_playground_3.blend
screenshots:
the upgraded sky model
real time cube environment mapping
lens flares
Battlefield3 style dusty lens
light directly into lens
October 2, 2012
RGP day7
so I've taken enough rest and today I am moving from "planning and preperation" to "sketching and concepting" phase of the development process.
here is a fast 30 minute draft of shaping up the feel and scale of the desert planet. I will do a series of these.
Aside of the art part, today I tried Moguri's BGUI, which I will use for menu and some of in-game HUD. It looks very promising, but will require some intensive learning for me to get used to it. I am also planning to create a custom lighting engine with atmospheric scattering, aerial perspective, weather system, moon phases, etc. I will then build physics and handling mechanism on it. After I will publish first pre-alpha demo to try out.
here is a fast 30 minute draft of shaping up the feel and scale of the desert planet. I will do a series of these.
Aside of the art part, today I tried Moguri's BGUI, which I will use for menu and some of in-game HUD. It looks very promising, but will require some intensive learning for me to get used to it. I am also planning to create a custom lighting engine with atmospheric scattering, aerial perspective, weather system, moon phases, etc. I will then build physics and handling mechanism on it. After I will publish first pre-alpha demo to try out.
September 12, 2012
//status update 03 & RGP day 6
it`s been a while, but no worries - the racing game project and BGE Candy is progressing. Slowly though as the spare time passes with friends and grasping the last summer days before I go back to France next week. After that aside from the job I am fully focusing again on RGP and BGE Candy.
RGP day 6
After a few days of intensive tinkering with vector math, I finally found a perfect solution to get barycentric coordinates of the track (I explained about this coordinate concept in the previous post)
I found rayCast() function in Blender`s Python API which also fetches UV coordinates of the ray intersection point. So now all I need is to UV map the race track, shoot a ray from vehicle down to track`s vertical tangent and voila we get vehicles relative position on the track.
I also made a simple racetrack trajectory recording system that records position and speed of the car at current segment. When it is recorded it saves it to a list and AI linearly interpolates between the points.
That`s it for now.
RGP day 6
After a few days of intensive tinkering with vector math, I finally found a perfect solution to get barycentric coordinates of the track (I explained about this coordinate concept in the previous post)
I found rayCast() function in Blender`s Python API which also fetches UV coordinates of the ray intersection point. So now all I need is to UV map the race track, shoot a ray from vehicle down to track`s vertical tangent and voila we get vehicles relative position on the track.
I also made a simple racetrack trajectory recording system that records position and speed of the car at current segment. When it is recorded it saves it to a list and AI linearly interpolates between the points.
That`s it for now.
July 11, 2012
day5 - race track coordinate concept
Yesterday I had some thoughts on the toughest challenges I will have to overcome during the development. I think it is wise to reckon them before I start the work on technical aspects of the game.
Here is the first task that got me a little worried.
getting precise player positions in the race track space
This includes for AI and player to know its exact distance from start and finish and distance from both track sides. I want to avoid any ray-checks from car to do that. It is too expensive and not very accurate. One solution is to have loads of colliders (sensors) covering the track, so whenever car touches one of the sensors we know how far the car is from sides and finish then it is possible to compare it with other cars and we know which car is leader and so on. But it is just not very efficient to manually add them for a hundred kilometers long track.
What I have in mind is to convert world space position to track-relative position. So it would switch from world xyz coordinates to track uv coords. U would correspond to travelled distance and range from 0.0 to 1.0 where 0.0 is start line and 1.0 is finish line (not sure about floating point precision here) and V would be track width ranging from -1.0 to 1.0 where 0.0 is middle of the track. This idea comes from THIS blog post about AI coordinate system used for MotoGP. I think it is very elegant and simplifies a lot of tasks especially AI behavior and keeping them on track without using bunch of waypoints and ray-check system.
How would that work?
Vector power!
Race tracks will be made of segments which I will deform by curve and multiply with array till the end of the length of curve. Lets assume that 1 track segment is a quadrilateral (tetragon) made of 4 points. To switch to track-realtive coordinates we need to know world position for each track segment. This means getting each point of track into an array and sort them to form lines, so each segments start & end line act as sort of check point. Then for each car we can get on which segment the car is on and calculate the fraction of the segment covered with point-quad or point-triangle intersection function.
I already got a chance to implement an efficient ray-quadrilateral intersection test in BGE and it works really nicely, though I have to check performance compared to point-triangle intersection functions.
Here is a simple illustration:
The tracks will have sharp turns, loops, banks, tilts and variety of configurations which makes the work on AI really hard, but converting all to track-relative coordinates "flattens" and "straightens" the track which makes work with AI ridiculously simple.
some examples:
if (player.distance > otherplayer.distance):
#you are ahead of other player
difference = player.distance - otherplayer.distance
if (difference < treshold):
#start collision avoidance
#start the overtake process?
how to check on which side to overtake an opponent:
if(overtake = 1):
#overtake in progress
player_ahead.width > 0.0 ? go_left : go_right
#see on which side is more space and go
#here we can also override previous statement to check if car width is wide enough to fit in the narrowest side and so on..
this all is just a theory now how I imagine it to work in my game. I think many commercial racing games use similar approach and it works, but they have dedicated professional programmers up to the task. will see how I can handle this when I start the work. I am open for suggestions and perhaps there is even a better solution for this.
Now I take a few day rest from the project as I am moving from France to Belgium and then back to Latvia.
Edit:
I got working the basic concept of coordinate system:
https://dl.dropbox.com/u/11542084/get_track_position.blend
If this proves to be efficient enough for big tracks then I will use it in the game.
References:
1 - http://blogs.msdn.com/b/shawnhar/archive/2009/12/30/motogp-ai-coordinate-systems.aspx
2 - http://answers.unity3d.com/questions/25189/race-position-help.html
3 - http://gamedev.stackexchange.com/questions/2382/how-would-one-determine-the-position-of-a-participant-in-a-racing-game
4 - http://graphics.cs.kuleuven.be/publications/LD04ERQIT/
Here is the first task that got me a little worried.
getting precise player positions in the race track space
This includes for AI and player to know its exact distance from start and finish and distance from both track sides. I want to avoid any ray-checks from car to do that. It is too expensive and not very accurate. One solution is to have loads of colliders (sensors) covering the track, so whenever car touches one of the sensors we know how far the car is from sides and finish then it is possible to compare it with other cars and we know which car is leader and so on. But it is just not very efficient to manually add them for a hundred kilometers long track.
What I have in mind is to convert world space position to track-relative position. So it would switch from world xyz coordinates to track uv coords. U would correspond to travelled distance and range from 0.0 to 1.0 where 0.0 is start line and 1.0 is finish line (not sure about floating point precision here) and V would be track width ranging from -1.0 to 1.0 where 0.0 is middle of the track. This idea comes from THIS blog post about AI coordinate system used for MotoGP. I think it is very elegant and simplifies a lot of tasks especially AI behavior and keeping them on track without using bunch of waypoints and ray-check system.
How would that work?
Vector power!
Race tracks will be made of segments which I will deform by curve and multiply with array till the end of the length of curve. Lets assume that 1 track segment is a quadrilateral (tetragon) made of 4 points. To switch to track-realtive coordinates we need to know world position for each track segment. This means getting each point of track into an array and sort them to form lines, so each segments start & end line act as sort of check point. Then for each car we can get on which segment the car is on and calculate the fraction of the segment covered with point-quad or point-triangle intersection function.
I already got a chance to implement an efficient ray-quadrilateral intersection test in BGE and it works really nicely, though I have to check performance compared to point-triangle intersection functions.
Here is a simple illustration:
The tracks will have sharp turns, loops, banks, tilts and variety of configurations which makes the work on AI really hard, but converting all to track-relative coordinates "flattens" and "straightens" the track which makes work with AI ridiculously simple.
some examples:
if (player.distance > otherplayer.distance):
#you are ahead of other player
difference = player.distance - otherplayer.distance
if (difference < treshold):
#start collision avoidance
#start the overtake process?
how to check on which side to overtake an opponent:
if(overtake = 1):
#overtake in progress
player_ahead.width > 0.0 ? go_left : go_right
#see on which side is more space and go
#here we can also override previous statement to check if car width is wide enough to fit in the narrowest side and so on..
this all is just a theory now how I imagine it to work in my game. I think many commercial racing games use similar approach and it works, but they have dedicated professional programmers up to the task. will see how I can handle this when I start the work. I am open for suggestions and perhaps there is even a better solution for this.
Now I take a few day rest from the project as I am moving from France to Belgium and then back to Latvia.
Edit:
I got working the basic concept of coordinate system:
https://dl.dropbox.com/u/11542084/get_track_position.blend
If this proves to be efficient enough for big tracks then I will use it in the game.
References:
1 - http://blogs.msdn.com/b/shawnhar/archive/2009/12/30/motogp-ai-coordinate-systems.aspx
2 - http://answers.unity3d.com/questions/25189/race-position-help.html
3 - http://gamedev.stackexchange.com/questions/2382/how-would-one-determine-the-position-of-a-participant-in-a-racing-game
4 - http://graphics.cs.kuleuven.be/publications/LD04ERQIT/
July 7, 2012
water/undewater shader WIP
This is a water shader I am working on in my spare time. The work is based on my own observations of water characteristics and written from a scratch. It is still a work in progress.
Right now the water surface is a plane, but support for real geometry waves is on its way.
Due to my old computer I am currently on, I am almost unable to capture a video with decent framerate, but the shader uses simple calculations and runs very well on even 6 years old mid-end hardware.
thread on BlenderArtists HERE
blend HERE
known issues and bugs:
- OpenGL clipping plane is not working on some GPUs
- mouselook goes wacko on some BLender versions but works fine in others
- some are reporting that sun-grab is not working
- and for some it does not open blend at all..
Right now the water surface is a plane, but support for real geometry waves is on its way.
Due to my old computer I am currently on, I am almost unable to capture a video with decent framerate, but the shader uses simple calculations and runs very well on even 6 years old mid-end hardware.
thread on BlenderArtists HERE
blend HERE
known issues and bugs:
- OpenGL clipping plane is not working on some GPUs
- mouselook goes wacko on some BLender versions but works fine in others
- some are reporting that sun-grab is not working
- and for some it does not open blend at all..
July 4, 2012
RGP GDD (work in progress)
As I mentioned before I will post all of the development process online. Today I am making a game design document or GDD. This is the first time I am writing one on my own.
I consider GDD to be one the of most important parts of the game development process, especially if there are more than 1 developer working on the project. Well in my case this document will be a lead that will keep me on track and I do not waste time on details while there is not a solid foundation yet.
all content here is a subject to change and will form up in further development of the game. At one point I will have to make a document file. For now this is more like a verbal sketchbook of ideas and concepts not a proper GDD, so here it goes..
--------------------------------------------------------------------------------------------------------------------------------------------------------
BRIEF OVERVIEW
RGP is a fast paced single player¹ racing game where the player is a pilot of ultra fast, hovering race vehicles². Game setting takes place in a distant future or a fictional parallel universe on various distinct planets around the galaxies. The aim of the race is to test the very limits of racers skills, endurance and cutting-edge technology of vehicles in various terrain and weather conditions, much like Rally Racing and Formula One.
¹ multiplayer not planned for now
² will need a name of the vehicle
STORY
Player takes a role of a race car driver born on a fictional desert planet¹ where except for racing there is not much else to do. Player has to prove that he is the best racer on the planet in order to qualify for much more prestige races taking place in different locations. Here starts player's journey through galaxies and exotic places and extreme races. As player progresses through the game the vehicles get faster and more responsive, racetracks more dangerous and more challenging.
¹planet not yet named
Edit: darn this sounds like a plot from StarWars Ep1 taking place on Tatooine...
GAMEPLAY
Well racing games is all about being first to the finish line.
The goal of my game is for player to experience the racing itself and have fun, rather than finishing the race always first, and this might not be that easy. To do this I might make different vehicle classes or groups separated by their performance. For example player starts with a lower class race car and competes against better race cars. To qualify further, player needs just finish the race, or during the race player competes in different race groups. Player does not have to finish first, but finishing at higher position in your race group is the aim. Overtaking higher class cars might make finish more rewarding. Well of course eventually the final cup becomes a fight for the first place.
But, while the game is in the development, I will focus on primary goals - having great race mechanics and make a challenging opponents.
RACE CARS
Player has a control over a jet engine powered racing vehicles able to reach speeds that exceeds the speed of sound ( in dry air -> 1236 kph / 768 mph). Vehicles are specially designed to be agile and race at extremely high speeds. The overall design is to be aggressive yet sleek, something between jet fighter and Formula-1, the design is very distinct for each class or manufacturer. Cockpit is completely isolated from outside world as races often take place at poisonous atmospheres, very low atmosphere densities or even vacuum. Race cars are powered by a fictional power source fit in a compact capacitors that can be filled up instantaneously by being near the power source. It also powers the power-ups and onboard weapon system¹.
¹ I am not yet sure if I want add a weapons system in the game.
RACE TRACKS
As races take place in different planets the tracks vary in every possible way - track length & width, terrain, weather, hazards, even day/night cycle, etc. As the vehicles are hovering there is no need for a dedicated race track so it can take place at canyons, forests, deserts, rough surfaces and hills and even above water. Off-road racing is much more extreme and adds additional difficulty unlike on specialized racing tracks (from now on called "speedways"). Speedways offer a completely different racing experience - it is more narrow and requires more precision while overtaking and planning turns.
Length of each racetrack might be around few hundred kilometers. Most of the tracks will be cyclic, but alternate routes will add variation in each lap. Alternate routes are an important part of a race track design. Some of them might be harder to reach, but more rewarding to use, some would shorten the track if used properly, but add risk losing speed otherwise. As I mentioned there are off-road races and speedways. Speedways are powered with a force field that keeps race cars on the track. This allows speedways to be oriented at any angle, and keeps vehicles racing even upside down. When off-road, racers have full freedom. Off road races takes place at canyons, dry lakes, oceans, hills and snow filled landscapes. The only lead that shows you that you are on the course are checkpoint marks, it is up to you how you reach them.
GAME MECHANICS
I plan to keep the controls as intuitive and simple as possible, so it has a steep or almost non existent learning curve even for newcomers in the racing genre. The difficulty of game will increase as the player progresses in the story. I want to completely get rid of manual difficulty settings in game options.
I am putting high priority on the vehicle physics. Making a race game for cars without wheels makes the task much easier, but getting the right feel and believability might be a difficult task. The ground friction is non existent (as the vehicle does not have contact with ground) I get to play around more with air friction and physics laws behind it. This involves changes in vehicle control at higher speeds, changes of pressure at different atmosphere densities or behind other vehicles.
Visual feedback as vapor cone at high speeds and humid environments will add more realism in physics presence.
PRESENTATION
Having a memorable and unique visual style is one of the most important tasks in the development process.
As I have graduated in fine arts, I feel that visual aspect of the work is one of my strongest sides. I am planing to keep the game in somewhat retro futurism style, like seen in 60s - 70s futurist artworks - smooth, bright, shiny and simple, but in the same time functional and realistic.
As a professional shader designer I will focus on creating the game visually stunning and physically plausible using atmospheric effects, smooth lighting, volumetric clouds, smoke and fog, dynamic FX and sophisticated post-processing. As the hardcoded lighting engine in BGE is currently quite limited, I will make a completely custom lighting, shading and effects engine, written from ground up completely in GLSL.
(to be continued)
REALIZATION
I am making my game in Blender Game Engine (BGE). I am a long time BGE user and I know what it is capable of as well as its limits.
This is how I plan to split the realization process.
- planning & preparation
- sketching & concepting
- developing game core mechanics
- developing graphics and shaders
- developing game art
- developing sound, graphics & effects
- putting all together
- playable alpha version
- debugging
planning and preparation
Is stuff I am doing here right now - collecting my ideas and putting them on paper. Gathering inspiration - watching videos, images, reading books. Drawing sort of an initial roadmap for the development. Having a good rest before sketching and concepting. Taking a rest nicely fit in this schedule as I am moving back from France to Latvia.
sketching & concepting
Taking a look at collected ideas, then getting rid of complex and stupid ideas and keeping simple and good ones.
Making sketches and concept art of environments, vehicles, characters, menu, HUD, overall style, etc.
Alternately "sketching" the game code, making code snippets and proof of concepts. Visualizing it on paper how all pipeline interacts with idea to have easily upgradeable system. Creating a simple test vehicle. Making of a playground for testing gameplay, car handling and physics, tracks, controls etc.
Making of first track sketches with placeholders. Testing it over and over again till it plays right.
developing game core mechanics
Taking the "sketched" game code and clean, polish, and make it solid till basic gameplay works and I have something to build further features on.
developing game art
Here starts track building from track sketches, car making from concept art, texture painting, menu creation, prop modeling, etc.
developing graphics, sound & effects
Making of unified shading system as I plan to have every material for the game to be completely hand written. Making particle effects. Recording, mixing, and making of sound effects
putting it all together
as fun this sounds, it is actually a long process of separating directories, optimizing models (LoD), linking them to scenes, optimizing scenes, adding collision meshes, optimizing shaders. Then comes lighting, adding effects and testing & tweaking till it looks and plays right.
playable alpha version
fun part for everyone, game-testing, collecting bugs and stuff.
debugging
ensuring that bugs does not distract game experience.
INSPIRATION
Here is the list of games and artists which I consider my mentors for this project:
1. Wipeout series from developer Psygnosis is first title everyone mentions when seeing concept art. I am a big fan of Wipeout 2097 (1996, 2002 Mac), which I used to play on my old Mac a lot.
2. Sparth (Nicolas Bouvier) is my favorite concept artist since I started game-dev as an artist in 2006. The atmosphere and feel in his works is the main inspiration for environments of my game.
3. Star Wars Episode I: Racer by LucasArts (1999), awesome game. Love the race tracks, feel of speed, sound design, etc.
4. Syd Mead does not need an introduction :) or does it? he is awesome!
5. DethKarz by Melbourne House (1998) - an underrated futuristic racing game with beautiful visuals for the time. basically Wipeout + wheels.
6. John Wallin Liberto
7. Extreme G Racing series from Acclaim - Extreme G2 (XG2) (1998) finally a game where you can break the sound barrier and it is actually shown and heard
8. Vyle (David Levy)
9. F-ZERO series
10. Goodbrush (Craig Mullins)
--------------------------------------------------------------------------------------------------------------------------------------------------------
day3:
just posted first version of GDD. It is awesome how much things get clear while writing a game design document. I did not put even half of my initial ideas, so that is the work for tomorrow. I feel that much of the game will form up while writing more in-depth description for each of the planets, cars and the technical details.
day4:
updated some stuff. I had a 3 day holidays, but I am back now. I got prematurely a little worried about technical stuff like getting precise relative position of each race-car on the track. But I consider this as a healthy challenge and extra experience in vector math.
day8:
added stuff in "PRESENTATION"
I consider GDD to be one the of most important parts of the game development process, especially if there are more than 1 developer working on the project. Well in my case this document will be a lead that will keep me on track and I do not waste time on details while there is not a solid foundation yet.
all content here is a subject to change and will form up in further development of the game. At one point I will have to make a document file. For now this is more like a verbal sketchbook of ideas and concepts not a proper GDD, so here it goes..
--------------------------------------------------------------------------------------------------------------------------------------------------------
"Racing Game Project¹"
¹I will come up with a proper title in the processBRIEF OVERVIEW
RGP is a fast paced single player¹ racing game where the player is a pilot of ultra fast, hovering race vehicles². Game setting takes place in a distant future or a fictional parallel universe on various distinct planets around the galaxies. The aim of the race is to test the very limits of racers skills, endurance and cutting-edge technology of vehicles in various terrain and weather conditions, much like Rally Racing and Formula One.
¹ multiplayer not planned for now
² will need a name of the vehicle
STORY
Player takes a role of a race car driver born on a fictional desert planet¹ where except for racing there is not much else to do. Player has to prove that he is the best racer on the planet in order to qualify for much more prestige races taking place in different locations. Here starts player's journey through galaxies and exotic places and extreme races. As player progresses through the game the vehicles get faster and more responsive, racetracks more dangerous and more challenging.
¹planet not yet named
Edit: darn this sounds like a plot from StarWars Ep1 taking place on Tatooine...
GAMEPLAY
Well racing games is all about being first to the finish line.
The goal of my game is for player to experience the racing itself and have fun, rather than finishing the race always first, and this might not be that easy. To do this I might make different vehicle classes or groups separated by their performance. For example player starts with a lower class race car and competes against better race cars. To qualify further, player needs just finish the race, or during the race player competes in different race groups. Player does not have to finish first, but finishing at higher position in your race group is the aim. Overtaking higher class cars might make finish more rewarding. Well of course eventually the final cup becomes a fight for the first place.
But, while the game is in the development, I will focus on primary goals - having great race mechanics and make a challenging opponents.
RACE CARS
Player has a control over a jet engine powered racing vehicles able to reach speeds that exceeds the speed of sound ( in dry air -> 1236 kph / 768 mph). Vehicles are specially designed to be agile and race at extremely high speeds. The overall design is to be aggressive yet sleek, something between jet fighter and Formula-1, the design is very distinct for each class or manufacturer. Cockpit is completely isolated from outside world as races often take place at poisonous atmospheres, very low atmosphere densities or even vacuum. Race cars are powered by a fictional power source fit in a compact capacitors that can be filled up instantaneously by being near the power source. It also powers the power-ups and onboard weapon system¹.
¹ I am not yet sure if I want add a weapons system in the game.
RACE TRACKS
As races take place in different planets the tracks vary in every possible way - track length & width, terrain, weather, hazards, even day/night cycle, etc. As the vehicles are hovering there is no need for a dedicated race track so it can take place at canyons, forests, deserts, rough surfaces and hills and even above water. Off-road racing is much more extreme and adds additional difficulty unlike on specialized racing tracks (from now on called "speedways"). Speedways offer a completely different racing experience - it is more narrow and requires more precision while overtaking and planning turns.
Length of each racetrack might be around few hundred kilometers. Most of the tracks will be cyclic, but alternate routes will add variation in each lap. Alternate routes are an important part of a race track design. Some of them might be harder to reach, but more rewarding to use, some would shorten the track if used properly, but add risk losing speed otherwise. As I mentioned there are off-road races and speedways. Speedways are powered with a force field that keeps race cars on the track. This allows speedways to be oriented at any angle, and keeps vehicles racing even upside down. When off-road, racers have full freedom. Off road races takes place at canyons, dry lakes, oceans, hills and snow filled landscapes. The only lead that shows you that you are on the course are checkpoint marks, it is up to you how you reach them.
GAME MECHANICS
I plan to keep the controls as intuitive and simple as possible, so it has a steep or almost non existent learning curve even for newcomers in the racing genre. The difficulty of game will increase as the player progresses in the story. I want to completely get rid of manual difficulty settings in game options.
I am putting high priority on the vehicle physics. Making a race game for cars without wheels makes the task much easier, but getting the right feel and believability might be a difficult task. The ground friction is non existent (as the vehicle does not have contact with ground) I get to play around more with air friction and physics laws behind it. This involves changes in vehicle control at higher speeds, changes of pressure at different atmosphere densities or behind other vehicles.
Visual feedback as vapor cone at high speeds and humid environments will add more realism in physics presence.
PRESENTATION
Having a memorable and unique visual style is one of the most important tasks in the development process.
As I have graduated in fine arts, I feel that visual aspect of the work is one of my strongest sides. I am planing to keep the game in somewhat retro futurism style, like seen in 60s - 70s futurist artworks - smooth, bright, shiny and simple, but in the same time functional and realistic.
As a professional shader designer I will focus on creating the game visually stunning and physically plausible using atmospheric effects, smooth lighting, volumetric clouds, smoke and fog, dynamic FX and sophisticated post-processing. As the hardcoded lighting engine in BGE is currently quite limited, I will make a completely custom lighting, shading and effects engine, written from ground up completely in GLSL.
(to be continued)
REALIZATION
I am making my game in Blender Game Engine (BGE). I am a long time BGE user and I know what it is capable of as well as its limits.
This is how I plan to split the realization process.
- planning & preparation
- sketching & concepting
- developing game core mechanics
- developing graphics and shaders
- developing game art
- developing sound, graphics & effects
- putting all together
- playable alpha version
- debugging
planning and preparation
Is stuff I am doing here right now - collecting my ideas and putting them on paper. Gathering inspiration - watching videos, images, reading books. Drawing sort of an initial roadmap for the development. Having a good rest before sketching and concepting. Taking a rest nicely fit in this schedule as I am moving back from France to Latvia.
sketching & concepting
Taking a look at collected ideas, then getting rid of complex and stupid ideas and keeping simple and good ones.
Making sketches and concept art of environments, vehicles, characters, menu, HUD, overall style, etc.
Alternately "sketching" the game code, making code snippets and proof of concepts. Visualizing it on paper how all pipeline interacts with idea to have easily upgradeable system. Creating a simple test vehicle. Making of a playground for testing gameplay, car handling and physics, tracks, controls etc.
Making of first track sketches with placeholders. Testing it over and over again till it plays right.
developing game core mechanics
Taking the "sketched" game code and clean, polish, and make it solid till basic gameplay works and I have something to build further features on.
developing game art
Here starts track building from track sketches, car making from concept art, texture painting, menu creation, prop modeling, etc.
developing graphics, sound & effects
Making of unified shading system as I plan to have every material for the game to be completely hand written. Making particle effects. Recording, mixing, and making of sound effects
putting it all together
as fun this sounds, it is actually a long process of separating directories, optimizing models (LoD), linking them to scenes, optimizing scenes, adding collision meshes, optimizing shaders. Then comes lighting, adding effects and testing & tweaking till it looks and plays right.
playable alpha version
fun part for everyone, game-testing, collecting bugs and stuff.
debugging
ensuring that bugs does not distract game experience.
INSPIRATION
Here is the list of games and artists which I consider my mentors for this project:
1. Wipeout series from developer Psygnosis is first title everyone mentions when seeing concept art. I am a big fan of Wipeout 2097 (1996, 2002 Mac), which I used to play on my old Mac a lot.
2. Sparth (Nicolas Bouvier) is my favorite concept artist since I started game-dev as an artist in 2006. The atmosphere and feel in his works is the main inspiration for environments of my game.
3. Star Wars Episode I: Racer by LucasArts (1999), awesome game. Love the race tracks, feel of speed, sound design, etc.
4. Syd Mead does not need an introduction :) or does it? he is awesome!
5. DethKarz by Melbourne House (1998) - an underrated futuristic racing game with beautiful visuals for the time. basically Wipeout + wheels.
6. John Wallin Liberto
7. Extreme G Racing series from Acclaim - Extreme G2 (XG2) (1998) finally a game where you can break the sound barrier and it is actually shown and heard
8. Vyle (David Levy)
9. F-ZERO series
10. Goodbrush (Craig Mullins)
--------------------------------------------------------------------------------------------------------------------------------------------------------
day3:
just posted first version of GDD. It is awesome how much things get clear while writing a game design document. I did not put even half of my initial ideas, so that is the work for tomorrow. I feel that much of the game will form up while writing more in-depth description for each of the planets, cars and the technical details.
day4:
updated some stuff. I had a 3 day holidays, but I am back now. I got prematurely a little worried about technical stuff like getting precise relative position of each race-car on the track. But I consider this as a healthy challenge and extra experience in vector math.
day8:
added stuff in "PRESENTATION"
July 3, 2012
RGP day2
After a free screen-cast application roundup for Mac, I came to a conclusion that VLC is by far the best one. Still on this old and slow Mac I found it hard to work in Photoshop while screencasting even at 1fps.
So here is a vehicle concept:
This is done as an exercise and test before I start my work on the game for real. Mostly to test out sketching workflow and screen-casting.
I have not thought of the title of the game yet, but for now I will call it "RGP" - Racing Game Project
Next up - game details and putting all my thoughts and ideas on a paper (in this case - blog)
So here is a vehicle concept:
This is done as an exercise and test before I start my work on the game for real. Mostly to test out sketching workflow and screen-casting.
I have not thought of the title of the game yet, but for now I will call it "RGP" - Racing Game Project
Next up - game details and putting all my thoughts and ideas on a paper (in this case - blog)
July 2, 2012
a new game project
while working on "BGE Candy" I realized I need a game I can apply the new features on. The idea of the game has been brewing for a while in my head now and I feel it is mature enough to start developing it further. I have not been sketching for few years already, so my hand needs some training..
Here are three first drawings, you can guess the genre from these already :)
(took me few hours each)
I will try to keep the visual style of the game as clean as possible using mostly gradients, nuanced lighting, atmospheric effects, vertical shapes and simple geometry.
The art of Syd Mead, Sparth (Nicolas Bouvier), Rainart (Sebastien Larroude), Vyle (David Levy), John Wallin Liberto and other awesome concept artists will keep me inspired :)
I have already done BGE version of Simon Wallner's sky implementation originally from 2002 GDC Presentation by Naty Hoffman and Arcot J. Preetham. HERE is the link to implementation details and even a demo. It will take care of lighting and atmospheric effects:
..maybe I can finally finish a game I have started
I will screen cast the whole developing process from now on.
Here are three first drawings, you can guess the genre from these already :)
(took me few hours each)
I will try to keep the visual style of the game as clean as possible using mostly gradients, nuanced lighting, atmospheric effects, vertical shapes and simple geometry.
The art of Syd Mead, Sparth (Nicolas Bouvier), Rainart (Sebastien Larroude), Vyle (David Levy), John Wallin Liberto and other awesome concept artists will keep me inspired :)
I have already done BGE version of Simon Wallner's sky implementation originally from 2002 GDC Presentation by Naty Hoffman and Arcot J. Preetham. HERE is the link to implementation details and even a demo. It will take care of lighting and atmospheric effects:
..maybe I can finally finish a game I have started
I will screen cast the whole developing process from now on.
June 29, 2012
7DFPS
7DFPS - yeah I participated as a weapon and character 3D modeler in a group of skilled BlenderArtists. Although we did not finish the game in time, our project is still going on. I started late, I think in day 3. Here is some stuff I did for it:
SigSauer P226 (coincidentally the same gun team Wolfire made for their 7DFPS Receiver)
2570 tris
1024x1024 diffuse/spec maps
wire (red edges - UV seams)
team "swat" character w/o helmet
2720 tris
1024x1204 diffuse/spec maps
unlit
there is also an op-force character, but he is not yet done.
SigSauer P226 (coincidentally the same gun team Wolfire made for their 7DFPS Receiver)
2570 tris
1024x1024 diffuse/spec maps
wire (red edges - UV seams)
team "swat" character w/o helmet
2720 tris
1024x1204 diffuse/spec maps
unlit
there is also an op-force character, but he is not yet done.
May 8, 2012
projected grid in vertex shader
I am in the middle of making a complete water/underwater shading system in GLSL. Water surface wave displacement is now the last thing to deal with and "projected grid" concept is something I wanted to try. You can read about it in this cool article HERE. But one thing I did not found is an approach to do it completely in a vertex shader, which might speed and simplify things a lot.
As an exercise I reinvented one myself.
What it does is scales the our grid to view frustum space coordinates and projects it to specified plane in the world.
The easy thing is that frustum-space (untransformed) coordinates for our water plane is already provided as gl_Vertex. The value range is between -1.0 to 1.0 and values outside of this range correspond to points which are not in viewing frustum.
So in X axis -1.0 is left and 1.0 is right edge of the screen, Y - upper and lower edge, but for Z -1.0 is near plane and 1.0 is far plane. The tricky part is that while X and Y values are linear, Z values are exponential - more densely packed at near plane.
Next part is to create a virtual plane to project our grid to. We only need the grid Z axis to be projected as X and Y are already at needed position - at screen edges. To do so, we need to create world position. I transformed texture coordinates of grid with camera transformation matrices and then with line-plane intersection I got the coordinates of ground plane. And finally we create a depth from ground position to apply to Z coordinate of the grid. As Z is exponential, I found THIS very useful to convert linear depth to exponential.
screenshots (not an eye candy yet):
wire:
filled:
clamped size:
with a displacement map:
There is yet a lot of work ahead, but I felt I should share this. Maybe someone finds this useful.
get the vertex shader HERE
edit: I found a technique by Eric Bruneton, which is much more useful easier and faster than mine, hehe. Still it was a nice exercise and I found out bunch of new stuff while doing this.
As an exercise I reinvented one myself.
What it does is scales the our grid to view frustum space coordinates and projects it to specified plane in the world.
The easy thing is that frustum-space (untransformed) coordinates for our water plane is already provided as gl_Vertex. The value range is between -1.0 to 1.0 and values outside of this range correspond to points which are not in viewing frustum.
So in X axis -1.0 is left and 1.0 is right edge of the screen, Y - upper and lower edge, but for Z -1.0 is near plane and 1.0 is far plane. The tricky part is that while X and Y values are linear, Z values are exponential - more densely packed at near plane.
Next part is to create a virtual plane to project our grid to. We only need the grid Z axis to be projected as X and Y are already at needed position - at screen edges. To do so, we need to create world position. I transformed texture coordinates of grid with camera transformation matrices and then with line-plane intersection I got the coordinates of ground plane. And finally we create a depth from ground position to apply to Z coordinate of the grid. As Z is exponential, I found THIS very useful to convert linear depth to exponential.
screenshots (not an eye candy yet):
wire:
filled:
clamped size:
with a displacement map:
There is yet a lot of work ahead, but I felt I should share this. Maybe someone finds this useful.
get the vertex shader HERE
edit: I found a technique by Eric Bruneton, which is much more useful easier and faster than mine, hehe. Still it was a nice exercise and I found out bunch of new stuff while doing this.
April 6, 2012
BGE Candy status update 01
It has been a busy week with real life stuff, so I am not progressing very fast.
Last 2 days I have been working on environment reflection mapping coordinates. Blender currently have only view-space reflection coords reflect(viewvec,viewnormal); and of course that is not nearly enough for a proper IBL (Image Based Lighting) setup.
So first I implemented world space reflection coordinates so the environment texture is world oriented.
Then I have implemented 2 most widely used mapping algorithms - "Angular" or "Sphere" mapping and "Equirectangular" or "Spherical Panorama" mapping but sometimes also called "Blinn/Newell Latitude-Longitude" mapping.
The third and most widely used one - "Cube mapping" should be already possible as a built-in function in OpenGL, but I have to figure out how to make it work in BGE.
Same mapping techniques can be applied not only on "Reflection" coordinates, but also on "Object" and "Normal" coordinates, which means that besides doing reflection and specular reflection, the environment mapping can also be used for texturing the object or doing image-based diffuse lighting.
these are the 3 environment map textures:
"sphere" or "angular" map
"equirectangular" or "spherical panorama" or "Blinn/Newell latitude-longitude" map
"cube" map
All 3 of them does the same job, but with different results. I found a nice article about all three of env-map approaches explained in detail HERE
I'm going to vacation for 2 weeks, so no BGE Candies till then..
Last 2 days I have been working on environment reflection mapping coordinates. Blender currently have only view-space reflection coords reflect(viewvec,viewnormal); and of course that is not nearly enough for a proper IBL (Image Based Lighting) setup.
So first I implemented world space reflection coordinates so the environment texture is world oriented.
Then I have implemented 2 most widely used mapping algorithms - "Angular" or "Sphere" mapping and "Equirectangular" or "Spherical Panorama" mapping but sometimes also called "Blinn/Newell Latitude-Longitude" mapping.
The third and most widely used one - "Cube mapping" should be already possible as a built-in function in OpenGL, but I have to figure out how to make it work in BGE.
Same mapping techniques can be applied not only on "Reflection" coordinates, but also on "Object" and "Normal" coordinates, which means that besides doing reflection and specular reflection, the environment mapping can also be used for texturing the object or doing image-based diffuse lighting.
"sphere" or "angular" map
"equirectangular" or "spherical panorama" or "Blinn/Newell latitude-longitude" map
"cube" map
All 3 of them does the same job, but with different results. I found a nice article about all three of env-map approaches explained in detail HERE
I'm going to vacation for 2 weeks, so no BGE Candies till then..
March 22, 2012
BGE Candy branch
From now on I am a part of Blender developers team. Together with Matthew Dietel aka mokazon we started a new Blender development branch called "BGE Candy" with main goal to fix broken and add missing and new (mostly visual) features to Blender Game Engine.
I am quite excited about this, I even made our own logo and splash screen (with "sweet", "eye", "candy" and "Blender" in mind)
so here is the list of stuff currently done and yet to be done.
done:
• SSS (subsurface scattering) material
• rectangular area lights
• logic connector highlighting in UI
in progress:
• parallax mapping
• volumetric point & spot lights
• real-time composite nodes
planned:
• volumetric shadowing for volumetric lights
• environment cube-mapping
• scrolling texture coordinates in Blender material editor
• timer node in material node editor
• world normals in material node editor
• extra uniform inputs for 2D GLSL filters
• extra 2D GLSL filters
• Sky and Atmosphere
• fog volumes
BGE Candy branch thread in BlenderArtists HERE
I am quite excited about this, I even made our own logo and splash screen (with "sweet", "eye", "candy" and "Blender" in mind)
so here is the list of stuff currently done and yet to be done.
done:
• SSS (subsurface scattering) material
• rectangular area lights
• logic connector highlighting in UI
in progress:
• parallax mapping
• volumetric point & spot lights
• real-time composite nodes
planned:
• volumetric shadowing for volumetric lights
• environment cube-mapping
• scrolling texture coordinates in Blender material editor
• timer node in material node editor
• world normals in material node editor
• extra uniform inputs for 2D GLSL filters
• extra 2D GLSL filters
• Sky and Atmosphere
• fog volumes
BGE Candy branch thread in BlenderArtists HERE
March 20, 2012
stereo 3D for games and Inficolor triOviz
Dalai Felinto proposed a little challenge to Mike Pan and me - to add support for "Inficolor triOviz 3D" glasses for Blender Game Engine. I am quite crazy for challenges I am not sure I can handle so I started investigating the techniques behind stereo 3D.
Oh, and in return Dalai sent me a pair of glasses. Another pair I had an honor to send to Blender Foundation. It seems it has found a use there already, haha.
http://mango.blender.org/production/kickoff-workshop-day-2/
While Blender has various stereo options already, they are all based on rendering two separate images - one for each eye, from from 2 cameras - one moved a little to the right, other to the left. Then special glasses (either anaglyph, passive or active) separates the image for the correct eye. Sounds simple and reasonable, but it does not work quite well. The explanation is found HERE
implementation
Simply translating camera position will make both eye view direction parallel to each other and for closer objects will result large portion of them to be visible only for single eye and this will cause considerable eye strain.
So we need to add thing called eye convergence - both eyes are aiming at the object you are looking at, this means - for a distant object the eyes are almost parallel, but for a close object eyes must toe inward. So for our stereo 3D implementation we need to add a focal point to focus on. Now we have set both cameras to be translated by half eye-seperation-distance and oriented to look at focal object.
But we are not done yet - now both camera orientations are different and convergence is not parallel to screen plane causing vertical parallax and this adds confusion and discomfort for whole 3D experience. So we need to leave only horizontal parallax. Changes in camera projection matrix are needed to achieve non symmetric (offaxis) camera frustum.
HERE is a great article by Paul Bourke with more detailed explanation and implementation details.
too slow?
Now how about performance. While this might not be an issue for higher-end PCs, using this method for demanding console games are unimaginable. This means rendering same scene twice and cutting already shivery framerate to half is a really expensive sacrifice over an extra feature.
solution
Do it as a post-process shader. We can re-project already rendered scene for both eyes using a simple parallax shifting using magical z-buffer.
There are some shortcomings of the technique though - missing information behind foreground objects or view edges, shaders that depend on view position like reflections and specularity will look wrong and no alpha blending due lack of z-information.
These issues can be somewhat fixed - the changes between original and projected image are quite subtle, so missing information (obscured by other objects or shifted view frustum) can be filled or stretched. And view dependent shaders and alpha blended objects can be rendered separately in a FBO with 2 camera approach and composited in the final image.
GLSL implementation
Well, basically it is my depth of field shader with 2 texture samples - 1 for each eye multiplied with magenta and green, thats all.
I could not get my hands on Crytek's SSRS technique, but mine works quite well.
Shader has wide variety of tweakable user controls including autofocus and automatic parallax calculation proportional to the distance of focal plane, for the most comfortable viewing. Btw. it goes hand in hand with depth of field shader.
GLSL shader is HERE
and blend file HERE
controls:
mouse+WASD - movement
1 - enables stereo
2 - enables depth of field shader
So anyway, what is so special about this Inficolor 3D?
You don't need 3D display to view 3D content, so it is relatively cheap and it works! Sure, it can't quite compete in image quality active shutter glasses offer, but still the depth is great and loss of color is minimal. A little washed out bright parts, but otherwise I am impressed of the image anaglyph 3D can offer. Also the eye strain is minimal after longer use.
If you have magenta/green glasses, here are my results (click on them for larger size and better 3D depth):
or cross-eyed version:
Oh, and in return Dalai sent me a pair of glasses. Another pair I had an honor to send to Blender Foundation. It seems it has found a use there already, haha.
http://mango.blender.org/production/kickoff-workshop-day-2/
While Blender has various stereo options already, they are all based on rendering two separate images - one for each eye, from from 2 cameras - one moved a little to the right, other to the left. Then special glasses (either anaglyph, passive or active) separates the image for the correct eye. Sounds simple and reasonable, but it does not work quite well. The explanation is found HERE
implementation
Simply translating camera position will make both eye view direction parallel to each other and for closer objects will result large portion of them to be visible only for single eye and this will cause considerable eye strain.
So we need to add thing called eye convergence - both eyes are aiming at the object you are looking at, this means - for a distant object the eyes are almost parallel, but for a close object eyes must toe inward. So for our stereo 3D implementation we need to add a focal point to focus on. Now we have set both cameras to be translated by half eye-seperation-distance and oriented to look at focal object.
But we are not done yet - now both camera orientations are different and convergence is not parallel to screen plane causing vertical parallax and this adds confusion and discomfort for whole 3D experience. So we need to leave only horizontal parallax. Changes in camera projection matrix are needed to achieve non symmetric (offaxis) camera frustum.
HERE is a great article by Paul Bourke with more detailed explanation and implementation details.
too slow?
Now how about performance. While this might not be an issue for higher-end PCs, using this method for demanding console games are unimaginable. This means rendering same scene twice and cutting already shivery framerate to half is a really expensive sacrifice over an extra feature.
solution
Do it as a post-process shader. We can re-project already rendered scene for both eyes using a simple parallax shifting using magical z-buffer.
There are some shortcomings of the technique though - missing information behind foreground objects or view edges, shaders that depend on view position like reflections and specularity will look wrong and no alpha blending due lack of z-information.
These issues can be somewhat fixed - the changes between original and projected image are quite subtle, so missing information (obscured by other objects or shifted view frustum) can be filled or stretched. And view dependent shaders and alpha blended objects can be rendered separately in a FBO with 2 camera approach and composited in the final image.
GLSL implementation
Well, basically it is my depth of field shader with 2 texture samples - 1 for each eye multiplied with magenta and green, thats all.
I could not get my hands on Crytek's SSRS technique, but mine works quite well.
Shader has wide variety of tweakable user controls including autofocus and automatic parallax calculation proportional to the distance of focal plane, for the most comfortable viewing. Btw. it goes hand in hand with depth of field shader.
GLSL shader is HERE
and blend file HERE
controls:
mouse+WASD - movement
1 - enables stereo
2 - enables depth of field shader
So anyway, what is so special about this Inficolor 3D?
You don't need 3D display to view 3D content, so it is relatively cheap and it works! Sure, it can't quite compete in image quality active shutter glasses offer, but still the depth is great and loss of color is minimal. A little washed out bright parts, but otherwise I am impressed of the image anaglyph 3D can offer. Also the eye strain is minimal after longer use.
If you have magenta/green glasses, here are my results (click on them for larger size and better 3D depth):
or cross-eyed version:
January 4, 2012
free low-poly airplane model
I have yet another unfinished game in my portfolio (sigh)
The BGE Air Race project is dead, but from the positive side I have some nice stuff to share with you.
So I give you this nice low-poly aerobatics aircraft to play with. The model is based on Extra 300L and I used Zivko Edge 540 cockpit as the reference for the interior.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
so basically you can do anything with it.
7267 triangles
1024x1024 diffuse map
blend + textures HERE
texture pack and template for you own skins HERE
The BGE Air Race project is dead, but from the positive side I have some nice stuff to share with you.
So I give you this nice low-poly aerobatics aircraft to play with. The model is based on Extra 300L and I used Zivko Edge 540 cockpit as the reference for the interior.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
so basically you can do anything with it.
7267 triangles
1024x1024 diffuse map
blend + textures HERE
texture pack and template for you own skins HERE
January 2, 2012
//status update 02
past few months have been quite stressful, due new responsibilities. Hopefully I will resume working on my personal projects soon. Unfortunately the BGE AirRace project is dead, but I don't feel too bad about it. It has gave me new 3D models, ideas and shaders to share with. 2012 comes also with few new ideas which I have been working on past few days. Particularly interesting is a precedural volumetric planetary rendering engine. Right now it can render a planet in any size with only 12 triangles. I will write a separate topic about it.
Subscribe to:
Posts (Atom)