Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Stainless]

I have done a lot in my mod tool to help the 3d modders, but all I've done for you guys is the skin generator.

I was thinking that I could extend the tool to bake ambient occlusion maps.

It's quite a bit of work though, so I don't want to start on it and find you don't want it.

You could bake the AO into the textures if you use max, blender or maya yourself, but I don't see any skins that use this feature, so I'm not sure it's something you want.

[SAS~Malone]

i'm not an expert on the subject - could you explain a bit more about how it works in practise, and how to go about using such a feature, please?
i can bake pretty well in the kitchen, but no little about baking maps, lol

[eMeL]

Sounds like a interesting idea. Two questions though: If you intend to bring AO maps to Il-2 aircraft, their visual quality could become very different to the rest of Il-2 environment this could prove to be an undesired effect? Does these maps have any hits on gaming performance?


Couple of links to the subject:

http://en.wikipedia.org/wiki/Ambient_occlusion

http://wiki.polycount.com/AmbientOcclusionMap



eMeL

[max_thehitman]

I am not too familiarized with this, but it looks like a Bumph type of skin? or it will give the model a  more 3 dimensional look?
Or is it some type of "shadow" creator for the model?

Shadows are good to include in a model skin. I often make some layers with just highlights and another with shadows to
make a more 3D effect on the model. This has also been done by many people when painting an airplane skin (Skin-template), so its
nothing new to get into more details about,
but
when viewing the model in the game, all these highlight and shadows "painted Layers" must be tweaked to the correct shadow darkness and
highlight whites and placed properly into the model skin for them to look their best.
 
If this idea is to create "instant shadows" on a skin, leaving only the white parts to be the "highlights" on the model, then I am all for it. 
It will save all the guess work and numerous hours of painting these models and testing them over and over in the game.
The less time some of us spend on painting just one skin, we could be creaking over a dozen more. Eliminating the wasted time
schedule is a must for any game texture artist. Mass production is essential! ...but not mass producing skins with bad looking skins. No one
wants a sloppy looking skin or fly in an airplane with a bad looking skin. So mass production and painting with "style" is welcomed!

For every final and finished skin-template on every model I spend my time painting and testing about 25+ skins until I am satisfied with
the final version. So that is a lot of test skins and a lot of hours.
Once a final skin-template is created with all the needed layers with effects, the shadows, the highlight areas, the scratched and rusty areas, then all
of the skin painting can begin. All the new skin will need are the necessary stencil markings and camouflage to be painted on them.

So I say once again, if this idea is to create "instant shadows" on a skin, leaving only the white parts to be the "highlights" on the model, then I am all for it. 
It will be a time saver for any artist.

[Herra Tohtori]

Ambient occlusion doesn't really mean adding "shadows" to the model - self-shadowing baked into a texture is not really a good idea in my opinion since it looks quite odd when the light is coming from "wrong" direction. Instead, ambient occlusion is a method of shading rather than shadow casting.

Ambient occlusion means looking at a point on the surface of the model, and figuring out how much of the ambient light is occluded by the model itself. And then you do the same for all the points, within the texture resolution you're aiming for. For example, parts like wing or side of fuselage would not be occluded much at all, but parts inside engine cowling or landing gear wheel wells or other constrained spaces would receive less light from the environment, and would appear darker.

The biggest effect of AO is that it makes the models look like they "belong" to the scene more, rather than flat-coloured models. This is especially true for games which don't have very detailed or sophisticated lighting rendering, which definitely includes IL-2.

Ambient occlusion can be dynamic (Screen-space ambient occlusion, or SSAO) or static (baked into textures). Both can look very good, and it would be very nice to see skin templates with ambient occlusion layer.

Dynamic ambient occlusion is relatively expensive feature from computational perspective, and in many cases offers limited advantage. However, it does take into account how the lighting changes when the model is rotated and, for example, sun shines directly into cockpit and then rolls away from view. There's no possible way to make this work for an old OpenGL program like IL-2 at the moment.

On the other hand, static ambient occlusion DOES work for every game it's done, because it's just an effect that is pre-calculated and included into the diffuse texture (skin) of the models. It consumes no processing power when the game is running, but the process of building the AO map (which is called "baking" the map, and it basically means rendering it in a 3D program and exporting into a texture) can take some time especially with high quality settings.

If Stainless can make a tool that can export AI maps for any IL-2 model from the in-game model format, that would be excellent indeed. 

[Cloyd]

Thanks HT,

I didn't have a clue what Stainless was talking about, but your explanation makes it clear. I'm no Skinner or Modder, just a User. But it sounds like a mighty good thing. We'd better cajole Stainless into doing this before RL sends him on his way. 

Cloyd

[Yeager_1946]

This is a great idea and has the potential to be a very useful tool indeed... I say go for it!   

[Stainless]

Okay I'll start thinking about it.

The mad thing is I know how to do it in a real time environment, so the rays respect the position of the object and the light source.

Don't actually know how to do it in a none relatime environment. But I'll work it out.

[SAS~Malone]

looking forward to the results of your 'baking', mate - i'm sure it will taste real good

[Herra Tohtori]

Okay I'll start thinking about it.

The mad thing is I know how to do it in a real time environment, so the rays respect the position of the object and the light source.

Don't actually know how to do it in a none relatime environment. But I'll work it out.

Maybe you could just use a completely white environment to produce a perfectly even, ambient lighting condition, without any point light sources? That way, only the model should affect the AO calculations (since the environment is the same everywhere) and that should create a "generic" AO map for that particular model.


Some more stuff about what static ambient occlusion does, and how it is created, for those who are interested:

As far as I've understood, static AO mapping works by checking how the surface pixels are exposed to ambient light. Since ambient light comes from every direction evenly, you can use a form of raytracing to check the relative area of sky visible from any given point of the surface.

For example, if you have a spherical object, all the points on the surface would have direct line of sight to 50% of the "sky", or ambient light that comes from every direction. So a sphere would have a perfectly even ambient map. In fact, every concave polyhedron shape has a perfectly even ambient map, because there are no protrusions from the surface that would cause some objects to have less exposure to ambient lighting. For example, a tetrahedron, cube, icosahedron and dodecahedron each consist of flat polygons that have nothing blocking their view to 50% of the sky - which means the surface receives ambient light from

Things get different with convex and more complicated meshes. For example, a torus would have similar AO properties as a sphere on the outside part of the donut ring - each point receives light from 50% of the sky - but on the inside of the torus (the hole of the donut), the torus itself blocks large parts of the sky, which means ambient light can only illuminate the surface from a limited amount of directions. Hence, the inside of the torus becomes darker even in an environment that is perfectly light and featureless.

When this is combined with diffuse and specular lighting from point light sources, it adds a significant amount of depth to the render.


Dynamic AO works technically the same way except instead of using true ambient light (perfectly even light coming from every direction) it creates an ambient light map for the scene, which updates every frame. For example, if you fly an aircraft into a deep valley between mountains, that would make the ambient light environment darker and light would mainly come from above. Or, if you fly an aircraft above a bright cloud layer, you would get blue ambient light from above (the scattered light from the sky) and white ambient light from below (reflected sunlight from the clouds).

[Stainless]

The way I am going to do it is.....

Code: [Select]

Foreach vertex in the mesh
   count = 0;
   for int i = 0 to some user supplied limit
        Generate a random ray within 22.5 degrees of the normal
              foreach triangle in the mesh
                     if the ray intersects the triangle
                          increment count and stop testing
   repeat
   convert count into a light value
   store as vertex colour                         

Then I can draw the object using the UV coordinates of each point as the X and Y coordinates and a fixed Z using a orthorgraphic projection into a render buffer

This will produce a similar view to the skin creation tool output I have already written but with the triangles shaded based on the calculated vertex colour

So you will get a grey scale inamge of the skin with just the ambient occlusion values in it.

Then I can mix this with the input texture to create a baked texture

Save this to disc and Bob's your father's brother.

[Herra Tohtori]

Mmh, that creates a per-vertex (or per-face?) AO map. Considering the low polycount of most IL-2 models I suspect it will not have very good accuracy, and worse yet it will not take into account things like smoothing.

Also the method seems highly sensitive to the amount of iterations per vertex (ie. how many random rays you generate and check for collisions).

A much more accurate (and, of course, much more performance-intensive) way would be to do per-pixel occlusion checks, but I don't know if you have the resources for that. It would also be much more resource-intensive when you're creating the maps, but the advantage is that you get an AO map for every pixel on the surface of the aircraft.

I would do it something like this (in pseudocode):


define uvLocation(0,0)
       if uvLocation = mapped
       then
             get normalVector  ;; normal of the face plus any adjustment made by smoothing
             pixelValue = 255  ;; fully white by default
             start casting rays to cover a full hemisphere around normalVector ;; random rays in 90 degree arc around the normalVector
                   cast exactly 256 rays
                   if intersect(pixelValue = pixelValue - 1)  ;; if all rays are intersected by the model you would get a fully black pixelValue
        end

Code: [Select]


Do this for every uvLocation (ie. pixel in the UV mapped texture). Since you do 256 checks for occlusion, you would directly get an 8-bit greyscale map as a result.

If you do random rays, you can improve the precision by doing several iterations and then averaging the results. In this case I would recommend adding a control that allows user to set number of iterations from 1 to 4, for example. With setting "1" the program would do 256 rays per pixel. Setting "2" would double the rays to 512 and calculate the pixelValue accordingly, settings 3 and 4 would increase rays per pixel to 1024 and 2048 respectively. The effect of this would basically reduce the variation caused by random rays between adjacent pixels, which can result in noise-like aliasing artefacts in the baked occlusion map. The more iterations, the more smoother the resulting map is.


For a 2048² texture, you would have to cast a maximum of 2048x2048x256 rays per single pass, which comes up to 1,073,741,824 rays total (about 1 billion). But that's a maximum assuming an impossible UV map with 100% utilization; most UV maps utilize something like 75% of the surface, a 90% utilization UV map is a fairly good one.

Since this is about making a pre-rendered AO map which could be used for skinning, I would recommend optimizing the program for quality rather than speed. Even if it takes like an hour to render a good AO map, it would still be worth it since you only need to do it once for any given model.


If the vertex-based solution is very fast it could be useful for creating a preview, test map, or just for WIP experimentation.