VDrift Graphical Upgrades

[NaN]

What sort of other light types and sources do you think we need?

Night time driving is the motivation here. As soon as the dynamic sky is working.
Another thing about my sky implementation. I am calculating the correct sun position, light color(intensity) based on input data.
So the sky is the light emitter. How do I pass this data to the renderer? The scene graph has no support for light emitters.

but it uses a very simple tonemapping that's local to the pixel

You mean: 1-exp(-light*exposure)? I am using the same in the scattering shader.
Have been thinking about replacing it with one based on average luminance.

I think a better material system is needed too.

I have been playing with a modified phong model lately:
I = Ia*ra + Il*(rd*Lambert + CookTorr)
Il: light intensity
rd: diffuse map
Ia: ambient light intensity(reflection environment map scaled by the ambient map)
ra: surface reflectivity
A surface map contains roughness, fresnel term(cooktorr) + reflectivity(ra).

This should allow a greater range of materials. I think it should also be possible to setup/test the materials in blender(not sure if they are using the same equation):

[joevenzon]

i thought a normal map was a synonym for a bump map. normal maps look pretty hard to create by hand.

There are normal map generators that will take a bump map (where brightness = height) and generate a normal map. The results usually look fine for flat surfaces.

[joevenzon]

Dynamic reflections are back in R2634 and data R484. Still a couple of bugs (I need to turn off car drawing when drawing the reflected scene, for one) but so far so good. :-)

[portets]

There are normal map generators that will take a bump map (where brightness = height) and generate a normal map. The results usually look fine for flat surfaces.

i could do that if need ever arises. like asphalt bumpiness, fences, curbs, just basic stuff like that. nothing on cars though. at least not yet.

oh, and by the way, thanks for reimplementing the reflections!
it looks good, and no noticeable performance loss. i was never here before the rewrite so i never got to see it before, other than some screen shots.

[joevenzon]

Night time driving is the motivation here. As soon as the dynamic sky is working.
Another thing about my sky implementation. I am calculating the correct sun position, light color(intensity) based on input data.
So the sky is the light emitter. How do I pass this data to the renderer? The scene graph has no support for light emitters.

Yeah, right now everything is set up for a single directional light. You can pass in the directional light location with GRAPHICS::SetSunDirection. It takes a quaternion but you can build that from eulers.

In the future the scenegraph will need to support emitters.

I have been playing with a modified phong model lately:
I = Ia*ra + Il*(rd*Lambert + CookTorr)
Il: light intensity
rd: diffuse map
Ia: ambient light intensity(reflection environment map scaled by the ambient map)
ra: surface reflectivity
A surface map contains roughness, fresnel term(cooktorr) + reflectivity(ra).

I'll look at this more later, but I have Cook-Torrance and Lambert BRDFs implemented already, so a change like this should be pretty easy. It's just a matter of replacing the way the game gets values to feed those. One note, though, car surfaces tend to contain a couple of layers that are typically modeled with two (edit: specular lobed) BRDFs added together -- something to think about.

[joevenzon]

no noticeable performance loss

You must have a faster machine than me! :-) On my computer it's a hefty FPS hit, but it's still very playable. I haven't optimized it at all yet, though, so I'll see what I can do.

[joevenzon]

Real-Time Rendering (third edition) by Akenine-Moller, Haines, Hoffman recommends this BRDF:

Code:

cdiff/pi + [(m+8)/(8*pi)]*Rf(alpha_h)*(cos_clamped(omega_h))^m
where:
Rf(alpha_h) = fresnel reflectance equation =
Rf(alpha_h) = Rf0 + (1-Rf0)*(1-cos_clamped(alpha_h))^5
alpha_h = angle between incoming light direction and surface normal
omega_h = half vector between incoming light direction and view vector
cos_clamped = cosine function clamped to range 0..1

material parameters:

Code:

cdiff = diffuse reflectance
m = micro-scale roughness
Rf0 = fresnel reflectance value at zero degrees

The whole thing then gets multiplied (piecewise for each RGB component) by the usual lambertian stuff:

Code:

E_l*cos_clamped(omega_i)
where:
E_l = incoming light intensity/color
omega_i = angle between incoming light direction and surface normal

This all gets computed for each light and summed.

Since cdiff is just the diffuse reflectance, it is defined with the usual diffuse texture. The fresnel reflectance value at zero degrees is the specular color of the material and can be defined by an additional RGB texture. The micro-scale roughness parameter m is the blinn-phong specular exponent and can be defined as a scalar value using an additional texture channel. Ideally, I'd like to also be able to define how m will change as the distance between the viewpoint and the pixel increases, because as you get further away from an object with a rough normal map, that mid-scale roughness (defined by the normal map) should at a distance be transferred over to the micro-scale roughness that's defined by the BRDF. Now that I think about it more, this could easily be precomputed from the normal map and stored in another texture channel.

Additionally, we need to model some area light sources. For these, we'd use environment cubemaps. One environment cubemap with its mip chain will look progressively blurrier, these could be blended between based on the object's micro-scale roughness parameter. One of the lower resolution cubemaps could also be used as an irradience environment map -- or we could precompute a more accurate irradience environment map instead.

[zimluura]

I think some the most obvious improvements to graphics would require a lot of artist work on new assets: high poly car models with normal maps, higher res track textures, baking ambient maps for the tracks, normal maps and specular maps for tracks, and so on.

i'm mostly in favor of shared meshes and textures that can be tweaked and re-used in many different tracks. should help download sizes as well.
things we see allot of are tire-walls, chain-fences, trees, grass (add tufts maybe), and perhaps track-scenery vehicles. but it could require some lod meshes to be fast. otherwise we'd be rendering far-off tire-walls in way to many polys.

so we can model the race-team tractor-trailers, and then go about removing the instances in the .jpk (which is where i guess they reside) and replacing them with mesh and location. so the freshly imported track would look very bleak. and then you'd go about busying it with prefabs.

with the central shared track objects; if a single pine-tree on the ring sticks out as looking bad you could fix it and the results would automatically propagate to any other track that referenced that object.

grass textures could maybe be done in gray-scale once, and then use that texture and a glcolor (or equivalent, my knowledge ogl after 1.1 is limited), for every track. grass tufts make things look nice but i think racetracks keep their lawns short usually, maybe for weekend_drive type tracks.

i'd guess with cars, the next steps would be to build them piecemeal (so we can modify them and damage them) and the dreaded normal map, which i understand, but i suck when it comes to subsurf modeling so normal maps kinda scare me.

roads could be a great place to start, asphalt_texture + specular_map + bump_map + propagate universally = roads that look dreamy in the soon-to-be-setting sun.

[NaN]

@joevenzon

these could be blended between based on the object's micro-scale roughness parameter

Yeah, I am biasing the environment map lod based on roughness to blur the reflection.
What is your pixel color equation(E_l * Lambert * BRDF + ambient)?

Edit:

i'm mostly in favor of shared meshes and textures that can be tweaked and re-used in many different tracks

I've been dreaming of an objects/textures library(trees, buildings, ....) since my exporter/importer rewrite. What is the license status of our tracks? I could extract the objects and set up a library. If we assign some mass to the objects, we would have dynamic collisions with track geometry(tire barriers).

[joevenzon]

@zim

That's all really excellent stuff. I totally agree with moving in that direction! Some thoughts: 1) a better track editor/format would make this easier, 2) some code work will be needed to optimize for the case of a bunch of instances of meshes -- but I needed to touch up the scene graph system anyway.

What is the license status of our tracks? I could extract the objects and set up a library. If we assign some mass to the objects, we would have dynamic collisions with track geometry(tire barriers).

There's some license information in the about.txt files in the track folders. Most are used with permission without any copyleft licensing, Rouen is public domain so that'd be the best place to pull out some objects and textures. The TORCS project is another good source.

What is your pixel color equation(E_l * Lambert * BRDF + ambient)?

I propose this:

Code:

sum_over_lights(E_l * Lambert * BRDF) + ambient_reflection + ambient_irradience

[joevenzon]

NaN, do you have a google account? Send me your username and I'll add you to the issue tracker. Some of the issues on there relate to what you're doing. For example:

It's a Nishita style atmospheric scattering sky box(quad).
I've got the code since February. Just haven't had the time to integrate it properly into the game.

http://code.google.com/p/vdrift/issues/detail?id=60

[zimluura]

hey joe, a while back i mentioned making a tire mesh that could be shared between all cars in blender. it had vertex groups, so they could potentially be resized in code to accommodate nearly any tire geometry. they'd be just the tire, so the rim mesh could still be on a per car basis.

you asked "why not generate them in code?"

i've just been fiddling around in codeblocks and gotten vertexes together for it. next up is faces with uv coords. do you think this would be good to add add to vdrift?

[joevenzon]

Yeah, sure. Would it just be the tires, and then the wheel would be separate?

[zimluura]

yeah, just builds tire meshes. might be useful to have some code to build the outer rim as well. that way it could always have the same amount of segments as the tire. but that part will need a different texture so it's shiny-ness can match the unique rim designs. also could be good to generate brake-rotors dynamically as well (then they can be easily customized in-game when you buy mods for your car).

i just got it to a good point. there's an image here
http://sites.google.com/site/zimluuraprojects/vdrift

should i try to get vdrift using this code or would you like to take a look at it first? or would you like to integrate it into the game yourself?

if its something i should try on my own - be forewarned: i've never committed code to svn, and i don't know the codebase so any advise would be appreciated.

[joevenzon]

@zim: The pic looks good. I assume the mesh's resolution/polycount is adjustable?

Hmm, if it's just building the tire, how would we integrate it with the wheel? Are you thinking someone would build (by hand) several wheel designs, and then they would be scaled to fit the tire?