WIP Exeter Road

[Stereo]

Dave and I have been discussing this for a bit and I think it's ready to have a thread.

Exeter Road is the southernmost major road in the city I live in, London, Ontario. It's quite flat around here, and Exeter Road in particular is pretty much flat and straight for about 5 kilometres. It's also where the City of London's driving test centre is located.

This project is an attempt to fairly quickly produce and release some new content for Racer, taking advantage of the new shader features, time of day, and so on. As a consequence we're focusing on a relatively small area which is the minimum amount necessary to run an Ontario G2 license test. You can see the approximate area in this image, marked in red.

Within this area, there will be:
- reasonable topography
- accurate pavement with lane markers, curbs, etc.
- traffic behaving normally
- the full complement of street signs, traffic lights, street lights, as appropriate
- a scripted driving instructor to guide you
- parked cars
Around it, there will be
- reasonable scenery (vegetation, buildings, fences): not photorealistic but visibly present
- side streets and driveways with a basic level of detail
- traffic sometimes being warped around to help feed it back onto the main streets of interest
- right of way signs
- no invisible barriers
When most of the items on this list are complete there should be a beta release to get feedback on the traffic and stuff.

Once this is complete, if interest remains high, the area covered will expand out to the ends of Exeter Rd., then south on Wonderland and Wellington to meet Hwy. 402 & 401, forming a loop.

If anyone's interested in contributing, there are plenty of opportunities to pick a property along the route and bring it up to a higher level of detail. The traffic and parked cars would also benefit from some medium quality models - we were thinking a budget of ~7000 polygons at the highest level of detail, with exterior, wheels, and shadow interior.

 

[Mr Whippy]

Glad to see a WIP thread up here Stereo

It would be really good to get community involvement... more than anything it'll just be more fun and obviously it'll get finished more quickly, or finished to a higher standard!


I'm more than happy to get the thing rolling and all the basic materials laid out, but then it'll be cool to run through buildings with ID's and then upload the building files, then if people want to grab one and just build nice textures or LOD's for it then they can.

Then when it's done we know it fits exactly where it needs to in the bigger picture.

Given certain limits on texture/shader structure we can then batch/atlas it all together efficiently too.


I'm certainly excited about doing a track we can all play and enjoy together, together.


No it's not a Wangan Highway, but I think this could be equally cool, especially for those wanting to do some US muscle car type racing down this main road


Just for reference, I can hit 260mph in the Veyron SS and stop again along this road, although I've not added in the bumps yet hehe

Dave

 

[Sneer]

Sounds promising.
I might be able to help out with some hardsurface model(s), basicly the "around it" related meshs and textures, depending of course on how much spare time I have ...
It's summer and currently I got a lot of impressions from racer. I like to test several track-related ideas one after the other, too. Anyway a community-track sounds great!

 

[The Wolf]

Wow, didn't realize you were so close Stereo -- I'm in Strathroy. My daughter has her G1 and will likely do her G2 test at the Exeter Rd location. And she has actually asked me if any of my racing games would be suitable for her to practice on! Wish I had some skills to contribute to the project...

 

[Stereo]

Not a very exciting update I've started compiling a list of track objects, with size reference from the Ontario Traffic Manual, first of all to get an idea of what needs to be done, and second to track the progress.
https://docs.google.com/spreadsheet/ccc?key=0Ai9FAdHwmZ6kdHhwQUVSc1lVUWVMbjhaeGhPTHBRR1E#gid=0
First pass I'm just adding everything I can think of. Once that's done I'll go back and stick priorities on (I'm thinking 1. basic necessities 2. necessary for completion 3. nice to have 4. misc. scenery)

I also wrote down the road line info, I'm hoping Dave will find it helpful.

 

[Harey]

Wow, useful things there, one thing I would add to it (obviously I don't have this information myself) would be lane sizes and maybe road sizes, as they can vary depending on traffic, and area. I think that would find the best use on most residential streets that don't have any lines, though even then some can be wide enough to have 2 lanes (1 on either side) of parked cars as well as 2 lanes of traffic, while others can fit about half that.

Also another thing I noticed, you have sign sizes, but no post size as well, I mean if you're going to get specifics for the sign size, might want it at the right height as well.

 

[Stereo]

Hmm, if I see those I'll make a note. The Traffic Manual has 13 sections of 150 pages each published so far, so aside from things I know how to look up it's taking a bit to find information.

The standard is 2m to the bottom of the main sign for most signs. 1.5 to 2.5m above the curb in general, though I think the variation is just so they can hammer in signs without using a measuring stick

 

[Mr Whippy]

Looking good so far Stereo.

With this we can choose an appropriate size for the texture sheet to hold all the decals we will want to use...

Having nice normal maps and transparency maps, along with a nice specular response (gloss map using ambCol as a cheap envAmb, and fixed IOR?)
diffuse rgb, transp alpha (so compatible in a basic shader state with one texture)
normal rgb, gloss alpha (for extra effects and stuff)

It should be plenty for nice decals for white/yellow lines and stuff like that.

Best bit is we can assign a material for these too so we get a bit less grip too, so watch out in the wet or overtaking in a powerful rwd car



I've been playing recently with the sky.

I hate to say it but the current one in Racer is a bit wrong. Perpetuated by me making bad TOD curves years back I will admit (though it looked/felt ok at the time)... mainly sun intensity values up near 6 or so.
The sky tint thus looks more correct (lighter blues at the horizon), but the klux intensity is maybe 5x too high! That then starts causing problems with the shaders Stereo and I have been working with!

Sun intensity should really be = 1 all the time...

Mie sun is now a normal size, but the Rayleigh blue looks too dark too most of the day. Also sunrise/sunset looks wrong.



I'm not sure what is wrong but it's not correct. It probably could be correct but I can't seem to balance the values of mie/ray to get the right look, so I think it's something in the atmosphere code!

I've been tone mapping HDR images of skies set up to match the Racer ones in 3DS Max using mental ray physical sky and they do look MUCH better. Naturally I've set up some TOD (fixed) for specific skies and the difference in Racer is quite stunning.

Almost all the values match what Max is throwing out and in Racer it looks very nicely balanced.


There is just something a bit wrong with the Racer sky system. I'm not sure what it is. It's not massively broken.
The tinting seems correct, ie, at the horizon my sky images from mental ray seem to blend nicely into the horizon mie/ray extinction, so generally things seem ok.

It just seems that the Racer sky is heavily blurred or something meaning that the subtle tint changes that occur in quite small distances in 3DS Max are just not present in Racer.


I'll post some compare shots.

For now doing the sky via image is a nice fix, but it would be REALLY nice to get Racer skies matching 3DS Max more closely in this regard.


I also experimented with using an alpha map to control mie so that clouds were present in a correct nature (large particle scattering)
Technically this could look VERY nice at sunsets with the clouds going the correct colours near the sun...
So with clouds as rgb normals and alpha as mie, you could in theory render a very nice looking sky indeed!

But until the sky gradient itself is rendering properly I can't really see how good that effect might look.

It would be very nice though to just render the sky (base sky with baseline mie/ray etc, perfect day, no clouds), then the user picks the cloud map (from hazy to foggy to cloudy or whatever they want), and that automatically makes things look right at any TOD, with stunning sunsets etc appropriate to the clouds.



So if anyone is an expert on the maths of the atmosphere.cg implement Ruud has gone with (it's not the first function, it starts about 2/3rd the way down and seems to have very few tunable params which makes it hard for me to tinker with) and can try see any obvious flaws then that would be cool


I'll post some pics on the Exeter Road later to show the side by side compare of what technically should look the same (I know Racer is real-time and 3DS Max is pre-rendered but these systems are pretty basic and can be rendered in real time on a GPU, more so if you render them once and simply 'look it up' until the TOD changes again!!!)



Thanks for reading this far if you have got here

Dave

 

[Stereo]

Have you tried using a very high-poly skybox? I'm not sure what the defaults use but you could probably crank it up to 100,000 or more to see if the visuals are right, and then figure out middle ground where it looks good enough.
Might also be good to tesselate more detail near the horizon, since it changes more quickly there and is also visible to the player more often.

Racer only calculates the sky at the vertices of the skybox, I'd guess 3dsmax knows the value at every pixel, or at least more than enough to get details.


Had a thought while I was in the park today... I've been pondering the best way to animate track objects for a bit and I finally remembered that the waving flags (and trees) just used a custom shader. From there it was easy to figure out ways to animate the traffic lights using a special shader. The way I've figured it, take one of the unused parameters (Kdiffuse likely - as it's not used if you author textures with kd=1 1 1 in mind) and use that to swap out the textures. 4 floats is enough if you encode something like this:
Kd.x = length of cycle
Kd.y = time in cycle light turns green
Kd.z = time in cycle light turns yellow
Kd.w = time in cycle light turns red
So for two sets of opposing lights with 40/20 second greens, you'd have
Exeter@Wonderland: diffuse = 60 0 18 20 -> red for 20 to 60, green for 0 to 18, yellow for 18 to 20
Wonderland@Exeter: diffuse = 60 20 58 60 -> red for 0 to 20, green for 20 to 58, yellow for 58 to 60
The math to do this is easy, it's just a question of whether the lights should have on/off textures and emission, or use a glow-overlay like car taillights, which determines the style of texture sheet to use. Pedestrian signals could be stuck in too, they're just 'walk' during green, 'don't walk' otherwise. - or 'don't cross' for the last 10 seconds of the green light if you want to get fancy.
If it's using on/off textures they can be laid out on a texture sheet one above the other and modify UV coordinates so it's only one texture, if it's a glow-overlay they can just be not-drawn when off. Either way you need a separate material per direction at an intersection with lights, and I guess either an extra material for advanced left turns, or take Kambient to signify that.

 

[Mr Whippy]

OK not 100% comparative because of various factors but the sky from mental ray is clearly quite different to Racer's sky.

Racer sky:

Mental Ray sky:

Note how the road is reacting to the sky colour (reflecting and ambient colour)...

This is the main reason I wasn't happy with the Racer sky really, since it was appearing with non correct colouring all over thus materials just looked wrong because they were reacting to lighting conditions that are just not present at certain times of day (sunrise/sunset in this case)

Note in the Racer image how the road behind the car is still shining yellowy, but in the bottom image the road is now shining bluey again which is more correct as the sky is blue at sunset, except at the horizon line under and around the sun!
In Racer it is just orange everywhere, towards and away from the sun, only going feint blue directly upwards.

As per my last post, the Racer sky is almost right, it just feels like this falloff in colouring because of the sun isn't occuring either enough, or at all... or the mie is over-powering rayleigh or something!?


Please note the issue with the road reflection taking both the envmap and specular, thus not being so energy conserving.

Ideally we should use a texture without the sun spot, and then put that over as a flare with no influence anywhere, or some combination where by we have the the suns energy only ever passed into items via the diffuse/spec methods, leaving ambient/ambient spec to the envmap (sans sun spot too!)


Hmm

Dave

 

[Mr Whippy]

Hmm, I'll have a play with a super high density sky dome... but it's pushing a load of polygons every frame for no benefit I think.

Best to render the sky per-pixel to a texture, then update when the TOD changes?

That way you can get per-pixel accuracy on a low-density sky dome.

Even just updating say 1% of the sky dome per-frame, and over 100 frames it's got a new texture to put to the buffer for the sky rendering... or even do 0.1% of the sky dome pixels per frame... every 10s or so you'd get a full update which is probably ample for a real-time passage of time!


Dave

 

[Stereo]

Hmm, yeah, that does bear a much stronger resemblance to what the actual sky looks like in photos I've taken around that time. I wonder what tweaks are necessary to get them to match up. I can take a look at atmosphere.cg but I don't presently know a lot about the formulas used.

 

[Mr Whippy]

I'll try a super dense mesh and see what happens.

Though IMO that isn't ideal vs pre rendering at runtime to a texture perhaps.

Extinction could just be done like that too, no need to calculate just look up.

Main trouble with using texture skies is matching at the horizon, but it's doable as you can see.


I like the whole TOD concept but to me that means it needs to look right too. If you can't transition through a sunrise or sunset and it look great you may as well fix TOD and use a texture that looks amazing, and is probably cheaper on the gpu (my shader just multiplies rgb from texture, nothing more)


I hope the dense mesh works then we know the code is right at least!

Once that is known we can pester Ruud to have the sky render per pixel and then save to a LUT... possibly even with the mie sun as an overlay for the screen shader rather than used in envmap etc


Hmmm


As per atmosphere.cg, may as well ignore tweaking till I test out a super dense mesh.

Worth looking at trying to turn on the 1st function though, it looks very good in the demo of that code... But it looks like it was written into Racer pre HDR right back when we just got CSM so its not working without some work. I got it working but not very well hehe


Excited though if we can get skies looking as per the 2nd image automagically in Racer

Dave

 

[Mr Whippy]

Hmmm ok, 10meg DOF mesh (150,000 triangles or more), and the sky looks the same as the 100kb DOF sky with about 1000 triangles hehe.


So not sure what to say at this stage except that you are best running a texture sky if you want a good sky currently... that includes doing the clouds, sky colouring and intensity all inside the image...

Only problem is getting the sun spot energy super high due to the LDR images... but I have a feeling you could run the mie sun spot *only* in a special function in atmosphere.cg and overlay that over your texture in the right place.



I'm not 100% certain but although the sun might only be outputting 80klux into the scene for illumination purposes for example, it's still reading way over 150klux in the mental ray sky, and in real life it seems!

So to get a horizon outputting say 5klux intensity and a sun over 150klux in one 0-255 texture you are gonna get banding!

Thus it seems best to strip out the sun, then the sky is in the range 0-25klux usually (giving much less dynamic range to cover with the texture), leaving the sun spot done procedurally...






I'm wondering more actually. I wonder if it's possible then to use a texture sky, sans the sun spot itself.
Render everything like that.

Then in the full screen shader add the sun spot just before bloom/tone mapping. That way it's not in any shaders getting duplicate energy etc etc, and only becomes visible to the viewer via the screen shader?

That would solve a lot of problems actually...


I guess if/when the dynamic sky is improved then the same process could apply wherby the sun and sky rendering are split and applied at appropriate stages (ie, the sun right at the end only for the viewer, not the envmap/cube map rendering etc)


Hmmmm...


Stereo, do you think it's possible to somehow pass the mie sun:

float miePhase=sunny*0.000079577471636878192976419142055225*atmosMie*((1-g)*(1-g))/pow((1+g2-2*g*cos),1.5);

And just drop it in the full screen shader instead?

Ie, it's not in anything until the last minute?

What might be even cooler is if it can be added elegantly after the auto-exposure step too, since we usually don't expose with the sun in mind when driving any way... it might result in more realistic exposures when the sun is in view (ie, whited out skies at sunset).


Hmmm

Dave

 

[Mr Whippy]

I like the idea on the traffic light shader using colour value to determine timing... the textures can be pretty small, and it nicely ties the shading data in with the timing data so hopefully it's cheap vs alternative methods.


The UV vert moving methods are very nice. I still had trouble with the atlas trees and UV mapping, I need to do more testing but they were kinda working having trees waving around. It's also very cheap... with 25,000 trees I couldn't see any difference in FPS with or without the trees using the wavy vert shader!

It'd be cool perhaps to have the electric wires use the 'banner' technique too, so they can dance around in the wind a bit.

Iirc, TDU 1 used these techniques and trees/wires would fly around a lot in windy conditions. It'd be nice to tie the Racer wind params together so on a windy day you could feel the car moving around with the visual cues of wavy trees etc!


Getting a course like this to feel alive will be really important I guess, so lots of ambient sounds and movement will be nice to add in eventually

Dave

 

[Harey]

Dave your posts got me thinking, is it possible to make clouds on a separate kind of layer for the sky box (maybe even just make the clouds individual models). And have them either moving varying by the TOD, or if possible, using the wind already in Racer.

I do agree with getting a course to feel more alive is important, too bad we can't animate animals trying to cross the road at random lol (ok maybe that's actually a good thing).

 

[Mr Whippy]

In theory you can do clouds like that.

I've already done some tests but authoring nice normal maps and opacity maps is difficult. Also since the sky values are a bit wrong to begin with then overlaying clouds becomes tough because they react with the atmosphere too.
It's just throwing wrong on top of wrong and right now I'm not prepared to invest the time making clouds that look average hehe.


I'd rather invest time now in getting stacked images (for HDR), or a hybrid of mie sun and LDR image to create a very nice characterful realistic looking sky for now that we know is giving us accurate values and we can author relatively easily too.


Hehe, we can have animals run out I think. We just need to make an animal model and skeleton, make a run animation, and iirc Racer can support rag-doll so once the Elk runs out and is hit we can trigger rag-doll behaviour (I think*)
Iirc there was that video of the person waving on Carlswood, maybe I'm thinking back to Carmageddon too much but I'm sure they were run over and rag-doll physics took over




As for sounds, yeah it'd be nice to just record a load of sounds and have them playing. Part of me really wants the sound system to go HDR too so we can balance off sounds nicely from interior/exterior/replay track cameras etc.

From what I can tell it's as simple as sum sounds in scene, then scale in the 0...1 range with a filter that changes slowly vs time (just like the auto exposure for graphics), but with audio it's obviously much cheaper and simpler.

Hmmm

Dave

 

[boomer541]

In the Factory test track the sky texture doesn't have a sun. The sun spot is behind the sky texture and it would be nice if when the sun was behind a cloud the intensity would deminish.

But otherwise it's quite realistic. I am having problems with TOD as my waterfall is way to bright and I've been unable to correct it. It was ok in ver 0845 but bad in the 090's.

 

[Mr Whippy]

My quick tips:

http://www.nrel.gov/midc/solpos/solpos.html

Use that and the global tilted irrandance value. Convert to klux by dividing by 10 iirc.

Set to your exact position/time requirements.


Then set sun_intensity curve to a constant 1.

Set sun ambient curves using the klux colour picker around the horizon area (usually about 5-15klux with a blue or bluey yellow tint) for the given mie/ray settings at any given TOD.


Really the only curves you need creative freedom over are mie and extinction, since ray is more a constant I think (changes a bit due to high/low pressure iirc)

Mie is basically air water vapour and large particulates. Extinction I guess is just scaling the effect but I'm not sure if that is also a fixed constant in practice.


So yes, very little to have to tune in theory... but while the sky rendering looks a bit flat vs the more contrasty colourful ones we see from physically based systems using similar principles then I really wouldn't use the Racer sky as a base to set the ambient colours because overall you just get unrealistic feeling skies doing that.



I agree having clouds over the top via a method that lets the sun get blocked is nice, and the current sky system does that iirc.

Though that would be better imo if we used the alpha to control mie scaling (which I've tried and it works ok, at least as good as the current clouds overlay), and then use the rgb for normals so the clouds light up nicely.

All the colour tinting for clouds going red at sunset is then automatic. High mie clouds = more red shift, but only in the clouds, just like real life... the sky still stays more yellowy orange.
With the normals the sky can be spun around or rotated constantly and you'll get a really nice dynamic sky.

In theory when the sun spot goes behind a cloud the mie value will be high and it'll simply diffuse away so you can't see it!


Technically it'll work and work well. It's probably a 30min shader to write.

The lengthy task is authoring good textures hehe... that might take a day or two just to take a nice sky panorama and paint a nice alpha for the mie, and then a long time painting a normal map over that too (probably best in a normal painting app like nd02 for example)


Also the underlying sky needs to be correct looking otherwise the whole illusion breaks down... so when I tested it I had to use my imagination a bit because the Racer sky just goes yellow all over at sunset hehe... also I spent about 2 mins on my textures so they looked very ropey.


Cheers

Dave