//Medium

I am moving to medium.

https://medium.com/@martinsupitis

I imported an older post and wrote a new one. It feels much easier to maintain and write stories there.

//and another year later

Not much has changed - still too lazy to post any update weekly, nor monthly.

Now when Blender Game Engine is officialy removed from Blender 2.8x and up, I amrevisiting my old BGE projects and concepts, polishing and adding comments and archiving them in a proper way. UPBGE is still actively developed and I occasionally use it for an art project or a prototype.

part 1 - volume rendering GLSL shader

part 2 - spherical penumbra shadows

part 3 - vertex shader shadows

next parts have lined up. here are some teasers:

https://www.shadertoy.com/view/tdlSRr

https://www.shadertoy.com/view/tdj3Ww

--------------

//I`m Moving to Medium, as an experiment.
I will be transferring some of my old posts there too, but my blogspot stays as a backup, if i hate it and want to come back here.

Game worlds and Flat Earth theory

OK, this is a fun one.

I have other blog posts in progress, but idea struck me unprepred and I wrote this in record speed.

So i`ve been obsessed by articles of theories that considers our world to be flat. Initially I thought they were sarcasm or jokes, but more research I did, more I realized how serious the topic is considered by some individuals.
I`m going to analyze here only my own fascination with them, not judge their ideas and reasons.

If you don`t know about them, here, have a read, it`s crazy:
https://theflatearthsociety.org/home/
https://www.tfes.org/
https://wiki.tfes.org/The_Flat_Earth_Wiki

why do I care? 

Vast majority of us don`t actually care if world is round or flat or cube or pear shaped. We are dealing with daily issues and don`t trouble ourselves wondering about how world works. I do care and think it is important to question everything. But this is not the reason why Flat Earthers caught my attention.

I make worlds every now and then. For simulators, games, personal experiments, research and so on. These game worlds mostly are crude approximations based on our own to simulate environment we experience on Earth. I place my objects in it and they are lit by Sun and the sky. I tend to specify the requirements for the game world before I start the project, mostly based on complexity of simulation I need.

Few of those are planetary scale. For these occasions I make a sphere, add an atmosphere, place a Sun and Moon in the right distance, add an orbit. Add a point based gravity to stick objects to the ground. Voila - a world like our own is ready, with working day/night cycle, stars, Moon phases. There are a lot of "hacks" and tricks involved to render planets from the distance, to be able to land and walk on them, so I tend not to complicate things too much.
Now, most of the time I don`t need a whole planet. Many of my projects are grounded and I need only a small portion of flat surface, sky and a Sun. It would be a waste of performance to render the whole globe otherwise.

spherical game world

In this case I consider our game world to be flat, which for the most part is easier to render and manipulate. This is how many 3D games have been made, and even till now game engines are only optimized for flat worlds. There are few exceptions, but in general - planetary scale is pain in the ass to maintain and operate. On the other hand flat and stationary world is more intuitive for an artist to understand, more stable for the program to predict and so naturally our games and creations use Flat Earth`s simplified physics laws. This is where I found similarities in interests of myself and those of Flat Earthers. Even more interesting - they are facing some of the same problems as I am when defining my flat worlds!

flat game world

am I a Flat Earther in my profession?!

So in a sense, Flat Earthers are too making their "game" world. What I mean is that they disregard most existing modern laws of physics because those are not required for their world to work, but still their belief is based on real world observations. This is exaclty what I do!! I have made my worlds optimized, so I need to invent shaders and functions to replicate or re-shape spherical world effects on a flat game world.

Digging through their publications and explanations of optimized flat Earth, I have found some interesting techniques in regards of skydome rendering using atmospheric lensing, they`ve gave me some ideas mapping clouds on planar surfaces to look spherical and idea of invisible ghost objects that cast only shadow is hilariously similar what digital worlds allow. I will be closely following their latest publications and approaches in non-traditional thinking and might even credit them for upcoming shaders.

2 years later

Hi, all.

So first of all - images in all of forums i`ve posted are gone - 404
I hosted all of the resources and images mostly on Dropbox, now that Dropbox has changed how their stuf works, the links are broken, so now my duty is to fix it all. Which also means I need to go back in time and re-visit most of the resources I have shared and see if they still work.

Secondly, I have promised myself to start maintaining my blog more often. And share my thoughts on stuff in weekly basis. Will see how it goes. All of my old projects are still alive and I am going to continue them. There`s a new project I`ve been working on many years and I recently published it. So next blog post is about it.

//status update 05 & a sneak peek in 2015!

My previous post was a bit more than a year ago... well the good thing is that since then I have a collected pile of projects and other stuff to share.
None of them are finished though, maybe that`s why I felt they are not shareworthy..

Anyway, I have moved from France back to Latvia and settled down for a while. I am still working full time with Blender & also Blender Game Engine on supersecret projects of which I can`t show anything yet. So I can only share with you things I am working on my spare time.

So, here is a list of projects I am planning to work on and hopefully finish this year. For each of these projects I will write a separate article explaining the details:

RGP (racing game project):

almost all of the effects, shaders and new stuff is related to RGP. I am now building up sort of a base to build the game on. The lighting and shading system is almost done, what yet needs to be finished is the physics, handling and collision system. After that I can finally focus on the content, story and gameplay.

PBR (physically based rendering):

RGP will be rendered using new lighting system. I am now in research and prototyping stage. Basics are functional and it looks really nice already.
featuring:
- new sky model
- image based lighting (IBL) using environment map
- real time environment map based on sky model or surrounding scene.
- some advanced BRDF functions

Terrain system to render vast landscapes (also needed for RGP).

- uses adaptive LoD
- infinite procedurally generated landscapes

Continue the work on my water shader. I am still planning to implement it in Unity. 

- combined with the new terrain system

- combined with physically based rendering system

Advanced buoyancy system for water shader.

- calculate buoyancy forces for each object submerged in water

Tron lightcycle game, yep still in progress.. I am doing a full re-write of the scripts.

- port all of the code from old Blender versions to Blender 2.7

water/underwater & sky shader update #03

Yep, I haven`t been very active blogger lately.
I am very glad that company I am working for brought me to Amsterdam to Blender Conference this year. I even did a presentation there together with my colleague Michael Otto about GLSL shaders in Blender Game Engine. And for the presentation purposes I decided to demo my water/underwater shader there.
Just before the presentation I managed to tune up the shader and the scenery a bit.




so the changes since last update are:
- projected grid approach for the water surface (lousy implementation)
- per-vertex displacement mapping for waves
- basic but effective shoreline detection for water surface and ground
- added some subtle cloud layer and stars in the skies

yet to be done:
- fixes on inconsistencies
- better and procedural wave propagation model
- focus to underwater visuals
- better camera transition from water/underwater
- better coastline behaviors
- buoyancy (partly done)
- heavy optimization
- when it`s done, as many have requested - implement in Unity

trees are generated with tree[d] by frecle

blend file to be uploaded (have to clean and optimize the code a bit)

water/underwater & sky shader update #02

I published this quite a while ago, but found some time to post it here just now.



This is an update video to one of my oldest projects in the making.
nothing much has changed since the last video, I just have a better computer now and I recorded it in a higher quality and framerate.

The water shader is based on my own observations.
it features:
- reflection with accurate fresnel refectance model
- refraction with chromatic aberration
- projected caustics on geometry from the water surface based on normals
- seamless transition to underwater (no fake fog added)
- accurate water volume with light scattering
- view and light ray color extinction based on water color and sunlight
- simple coastline detection based on terrain`s height-map

does not yet feature:
- displaced water geometry
- underwater particles
- underwater light rays from caustics
- shoreline behaviors

Sky model is based on Preetham, but implementation is from Simon Wallner, with a significant (artistic) changes done by myself.

I have also included an overly exaggerated experimental glitter shader and a completely procedural "water droplets on lens" shader.

YES the underwater distortion is completely unrealistic and will be removed once I add underwater particles that will wobble similarly.

download blend:
- https://dl.dropboxusercontent.com/u/11542084/water_0.99_optimized.blend
- http://www.blendswap.com/blends/view/68857

sound files from freesounds.org

image imperfections and Film Grain post process FX

It`s been a while already since game studios try to replicate lens and film camera effects to enhance the visual fidelity for their games. Most of the time it does not make much sense to see them from the perspective of the player, but nonetheless it does look nice if done right.
I am talking about lens flares, vignetting and chromatic aberration, depth of field, bloom effects and film noise/grain. In photography or film they are considered as visual artifacts caused by imperfections and properties of film and lenses and mainly - the physics behind optics. Most of photo/cinemato-graphers do their best to avoid them by using better lenses and lens hoods to reduce vignetting, lens flares and chromatic aberration and use different sensitivity films for appropriate scenes to reduce image noisiness so in the end they get as clear image as possible that is usable for editing - tracking, compositing or whatever they do..  In the gaming industry it is pretty opposite - renderer outputs a perfectly clear image and artists do whatever they can to make it imperfect.

Few years ago these effects were done with some moving view-aligned textures, but now with clever shader tricks we can fairly accurate simulate them as an image post-process effects.

I have re-created most of these effects already and posted results in my blog. Links:
lens distortion
lens blur with bokeh v1
dof with bokeh v2.1
lens flare

And here are very nice results from other guys

Lens Flare by Max Planck Institut Informatik
Lens Flare by John Chapman
DoF with bokeh by Epic Games
DoF with bokeh by Matt Pettineo (MJP)

Film Grain..
..is the reason why I am writing this post here right now.

Film grain is a texture on the photographic film caused by an emulsion containing photon sensitive silver halide salt crystals. They are sort of pixels of the photographic film. Depending of the size of the crystals varies the resolution and sensitivity of the film. Bigger the particle (higher ISO number), higher the light sensitivity, but the image is less detailed. Unlike the digital image sensor where light sensing pixels are arranged in a regular grid, film crystals are jittered randomly over the film which gives an image more pleasing for the human eye. The possible reason for that might be the fact that the film grain does resemble the pattern how the photoreceptors are arranged in the retina of the human eye. Awesome, right?

photoreceptors in human eye (source http://www.sciencecodex.com):

an extreme case of color film grain (source Wikipedia.com):

Now in the digital era of cinematography most movies are shot digitally, that`s why often the film grain effect is artificially added on digital image. Many of the Blu-ray movies have a very distinct graininess, which actually gives a nice high-def cinematic feeling.
So exactly the same should apply to computer games.

Film Grain does seem to be the least difficult to simulate compared to other lens effects, but surprisingly I have not yet seen any convincing real-time implementation that does resemble, for example, the nice granularity look of 35mm film. Well the best examples of film grain effect I found used in games are by Crytek and Valve software - Crysis Warhead/Crysis2 and L4D series to be specific. Unfortunately the effect can hardly be called "film grain", it is rather an overlay noise that makes the appearance of slight jitter. What they did right is the elusiveness of the effect. Increase the grain amount a little bit more and it gets annoying.  For many game titles film grain effect bothered me so much I disabled it completely (if there was an option at all). Mass Effect was one of them, in fact in darker scenes it looked nice, but in highlights made the image look dull and dirty. It did a good job covering up some less detailed textures and models though.

The possible reason why film grain does not seem to have advanced over the years like other effects might be that the grain filter is so subtle the developers do not bring much attention to it. And why waste time, money and precious milliseconds of computing time to create an effect most gamers would never notice. Well, here exactly lies the problem - overdone effects. Most notorious are Bloom, SSAO, DoF and yeah.. Film Grain and they are certainly very easy to overdo.
Personally I love subtle details. For me the best effects are the ones that enhances the visual quality while not bothering me with its presence during gameplay.
And there is another point - high ISO film photograph can get very grainy but the image looks nice and natural, while a bit overdone film grain effect in game ruins any viewing pleasure.. So the problem lies in the technique which generates the grain pattern and mixes it with the scene image.

Approaches

The common methods of simulating it in games are either using a real grain texture or computing a noise pattern procedurally in runtime and then mixing them with the rendered image.

Pre-computed texture approach might make the best results as you can use actual grain texture taken on real film (filming against a grey background) and then overlaying this image to game scene. the downside is that it needs to be different in every frame. You can offset it a little and tile it, but a trained eye will always notice the tiling and this can make the effect very annoying. The approach does work best for still shots.

Procedural approach will ensure the grain will never tile, but the result is actually a noise and does not resemble the granularity of film grain at all. It does look more like a digital sensor noise. One might actually misinterpret it for an interference of the video signal to the monitor.

My take on Film Grain effect

All the time I have been using the procedural noise approach which is fast and gives nice results if the noise amount is very little, but as I mentioned it looks more like an interference in video signal.
After doing some research in this matter I collected bunch of reference images taken with film camera. I extracted the noise pattern from them and compared it to the noise shader I have been using. As you see it is lacking the graininess of the real thing.

I opened the image of my noise shader in Photoshop and tried to replicate the real grain texture. Blurring a little and adding 3 passes of sharpening did actually the trick. Unfortunately doing that for full-screen texture in shader would significantly slow the process and make it unusable in real-time.

So now I had to find a procedural or semi-procedural approach to simulate the same pattern in the shader without having to blur or rendering it in multiple passes.
Few years ago I did a vertex displacement mapping experiments with a procedural Simplex noise algorithm which created a nice grainy pattern. I resurrected the shader and applied it to a grey color and here is the result:

That is a really pleasant uniform grain. It is lacking a bit of the randomness but otherwise I call this a success!

Comparison shots of noise and grain applied to a gradient.

noise:

simplex grain:

Results

There is yet long way to go for more accurate results. It could be extended to include the real science behind it like varying graininess based on camera`s relative aperture. But I am only an artist so I go by whatever looks the best :)
This whole thing is a work in process, but I feel that even at this stage it looks already better than many other real-time film grain shaders. As you see the grain is not making the image look dull. It is less visible at bright areas of the image, but more noticeable in darker shades. An option to change the grain size is yet to be done.

Perlin noise grain applied in CryEngine (big images):
screenshot 1
screenshot 2
screenshot 3

100% crops from the shots above:

Continuing

today during further grain shader development I tried to replicate the grain in the image with the rally car. I had to de-noise the original image with resulted in some loss of detail. Then I applied the new grain shader on it. Here is the result:

original:


de-noised and artificially added film grain shader:

real film grain compared to new film grain shader:

There are some significant changes from the original shader:

- user variable grain size
- added varying coordinate orientation for noise pass to eliminate any directional artifacts
- option to reduce grain based on luminance value
- added more tweakables for color noise

downloads

v1.0 (old one):
HERE you can find the GLSL shader file.

v1.1:
HERE


References:
- noise algorithm I copied from HERE by toneburst, but original implementation comes from Stefan Gustavson found HERE

RGP day 15 - AI and a download link

So, as promised, I am finally giving you something to play with.

AI
I have added a very basic AI steering system and obstacle avoidance behaviors. I will write a more detailed article about it soon.

physics and handling
I completely rewrote handling and physics system using real world laws of aerodynamics. It was a really nice exercise and gave me the basic understanding of movement, drag, acceleration, etc.
The movement is now much smoother and the vehicle is very stable.
all math came from here: http://physics.info/drag/ & HERE
I will write a more artist-friendly overview of the physics behind the game.

UI
added subtle motion to the UI while steering

camera movement
The camera is now more dynamic. FOV, height and distance from vehicle increases with the velocity.

post-process filters
added a simple lens filter that distorts, blurs, creates vignette and adds some chromatic aberration near the edges of the viewport. I might make it react to the velocity as well.

a video:



and a download link to blend: https://dl.dropbox.com/u/11542084/RGPv01.zip

Now I have to finish few projects, so this is probably last (RGP related) blog post in next few months.

RGP day 10 - a bit of everything

First post in 2013, and I feel it is going to be a great year :]
I know it`s been a while, but I am working on the game again!

It is actually day 10 - 14 of the RGP. I worked on the project quite a lot, mostly tweaking the code to make it work just right. And finally here is also some visual stuff, while only sketchy, but something! So here is the stuff I`ve been busy these last 5 days.

physics and handling

I`ve been collecting some useful resources regarding physics, acceleration & springs`n`dampers aswell as browsing through YouTube videos of Wipeout, F-Zero and other futuristic racing games. I believe now that a nice vehicle handling system will be actually much bigger challenge than I initially thought. I hoped I could stay with Blender`s built in Bullet physics & material properties in UI, but I just could not get the feel and handling right as well as it caused stability issues at high speeds. So I created my own system. Basically it consists of spring-damper system for vehicle suspension, engine system for thrust and turning and a very basic inertia and gravity system.

race track & vehicle

I made a race track to push my physics system to the limits. Basically it is an oval loop with a twist - literally :).  I created a race track based on Möbius strip - "A model can easily be created by taking a paper strip and giving it a half-twist, and then joining the ends of the strip together to form a loop". So you are actually racing on the both sides of the race track. Also the oval in the middle is bent around 90degrees up which at high velocity, will create very high negative or positive centrifugal forces, so that the race car will be either pressed against racetrack surface or pulled off it. In the game speedways will have a gravitational force field which will keep the race cars from falling off the track either at high centrifugal forces or regardless if the track is upside down, so I think that this kind of racetrack configuration is perfect for testing and tweaking purposes.

overview of the "Möbius race circuit"



clearer view of the configuration



This is a generic racecar you would find in similar racing games. As the rest of the game this is only a placeholder. More race car concept-art is on the way :)



UI

This is the first time I am working with Moguri`s BGUI - a graphical user interface (GUI) library for BGE. I have just started to mess around with it, so nothing much to see yet, but I intend to keep it simple and minimal, close to what you can see in the screenshots below.

Camera movement

I worked also on the camera movement a little. A good setup can add a great amount of immersion into the game. Just parenting it to the race car`s chassis does not look good. I will do a deeper look at it sometime later.

Graphics & FX

Nothing fancy yet - a simple skylight setup like THIS, completely texture baked terrain, simple fogging that gives an atmospheric feel. Exhaust trails are cross shaped , textured planes spawned each frame - I should find some more efficient way of doing them.


screenshots showing all of this together which starts to form up the feel of an actual game:













(I am having some difficulties with screen capture software working on Windows 8 so perhaps I will switch back to win7 to be able to make some videos)

Back to Win7 and video is here.



blend file is on the way.

BGE Candy - Area lights

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

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

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 :)

//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

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.