TOD editing

Ruud

RACER Developer
Racer v0.8.16 has a time-of-day editor, currently including 18 variables to track. The release is at http://www.racer.nl/download/racer0.8.16.zip .

The editor starts up immediately (data/scripts/oncar.rex). You can add new points and move them vertically. Dragging them out the graph vertically will remove them.

I'll need help with getting a nice base. Specific problems:
- sun x/y/z
- specular rgb - leave it just as diffuse rgb or really define it separately?

Known issues:
- adding a point seems to be a little difficult at the extreme left & right

Also it would some day be cool to use the sun direction for the clouds; for that you'd need to have clouds rendered and have a normal map that describes the cloud direction. This could generate nice sunsets.
 
Wow this thread is turning into the "Things I've wanted to happen for 5 years all happening at once" thread :D

SFX triggerlines would be great.

Dynamic Range ace.
Changing the range in Curved sounds ok though, since once we get a standard it shouldn't really change much. I don't see much point in having ANOTHER variable/command in the console for something so easily changable.

Dave's point about white-balance has been on my mind for a while now...though I'm pretty sure that's basically changable with mie/rayleigh settings(?) Since you can change the tint of blue/red with them.
Brings up the question of content creation and best procedures then. Still best practice is probably to photograph textures on an overcast day.

This coming week I should be able to get some photos of the area around my house at every hour through the day and model the area up. No doubt it'll be overcast at some point.


Really excited about all the progress right now. This is such a big leap.
Congrats Ruud. You should be proud of your little baby :)
 
This coming week I should be able to get some photos of the area around my house at every hour through the day and model the area up. No doubt it'll be overcast at some point.

I've been thinking about doing something like this, but I'd like to figure out the best practice for choosing the scene and setting a usable baseline - maybe set a couple sheets of white paper in the sun and shade. Otherwise not only do you have the lighting to worry about, but finding a good texture brightness. Then there's the camera settings... if Racer is going to implement auto-exposure, is it better to take one set of photos on auto, one set with fixed exposure?
 
I was planning on taping some paper to the ground - one in shade, one in the sun (maybe a couple just in case) then photographing at fixed shutter and stop. That way with autoexposure turned off in racer I should be able to match the scene. Though it'd be nice to have a light-meter to measure how many lux I'm matching to

Hmmm...
 
Glad to see Ruud making the TOD folder available in track folder so that the curves can be adjusted for the track as well as global.

I'm having trouble setting the points when the car wants to move as I don't see the "sliders" that were mentioned in an earlier post. So how do I get the slders to see the changes interactively?

The curves are adustable with curved and I'm working on them as they need working over to get the sky to look right on a track other than carlswood. Backed up the TOD folder first!

Something wrong with the forum as it won't let me save the pages in this thread, damned oragutangs in the back room!
 
Using 'edit tod' you should just get a curve editor - editing there is far easier than using Curved, although for tiny details Curved has some advantages.

I'm trying the full lux range now - 1 lux at night to 100,000 lux at midday. As this is bad for float precision, I'm using kilolux as a unit, so 0.001 lux - 100 lux. Should be interesting.

As for performance, don't worry about the number of points. Everything is converted into a lookup table (lut), just like the engine torque curve for example. So O(1) performance hit for every variable, and only when time changes the lookups are done.
 
I've been thinking about doing something like this, but I'd like to figure out the best practice for choosing the scene and setting a usable baseline - maybe set a couple sheets of white paper in the sun and shade. Otherwise not only do you have the lighting to worry about, but finding a good texture brightness. Then there's the camera settings... if Racer is going to implement auto-exposure, is it better to take one set of photos on auto, one set with fixed exposure?

Do everything with known camera settings, and have the sky in the background.

Ie, f-stop, iso, shutter speed, and if possible, the colour temp, and do a few bracketed shots, or shoot in raw for more dynamic range.

In theory, the colour dis-balance we get (is that a word?) at dawn/dusk is a function of the different sky/sun colours. However, even at dusk, exposing for white balance on a matte object pointing right up, will result in a sphere appearing with an orange tint on one side, and a bluey tint the other, just the vertical will tend towards being neutral (which is just what we want I guess :D )

So, in theory, if you white balance at any TOD with a vertical matte object (several sheets of white paper is better so it stops acting with sub-surface scattering/transmission etc), you should still get a good idea of the colours from the sky/sun independently of each other.
You would need to capture these off a matte sphere though.

This is why I have my white/grey/black and chrome balls setup, so I can just white balance on the base (white matte now), and just use my balls as a guide for the colour tint. I can also capture the whole sky in the chrome ball, so we can get an idea of what the sky 'white out' level is like relative to a nicely exposed matte bright white object (ball) in the scene.


Once we start getting an idea of realistic ish values, others will start to drop into place. It's a bit like the pacejka issues 8 years ago before Alpine provided lots of data, it was just shooting in the dark until some real data came along to help us out :D


I guess the alternative is to try gather absolute colouring info too, and have Racer do the white balance, but I can't see it serving much purpose because we would always want to 'auto' colour balance to white anyway (same with exposure), but I'm not sure what the benefits would be with white balance being done. Ie, it's not as significant as bloom driving out of a dark tunnel. Maybe a cloud uncovering the sun might look a bit more authentic as the colour balance changed with auto-colour balancing?! Hmmmm :D


The light meter would be really handy as Camsinny mentioned, to get real lux values along side this too. I'm pretty sure a modern DSLR has a meter in it, but how you can see the 'raw' data from it is another thing :)
Maybe really top-end models have a meter readout (ie, Nikon 1D etc etc)

Dave
 
We have a light meter here, but it only goes upto 20,000 lux. Outside (sunny) it was 15000 lux in the shade, in the sun it got an overflow. Inside it was 400-500 lux, which seemed ok.
Racer 0.8.17 (out now) uses kilolux, so night lighting around 0.001 kilolux upto 100 kilolux at 12:00. Quite harsh shadows you get, but I guess that's the way it is.

On white balance, our eyes tend to correct for that, so I guess on the screen you want to avoid any colour balancing and just make it visually pleasing. The real measurement is now: how much lux is there each hour in the day; does it go up quickly or is it very low in the evening/morning. Hm.
 
Well I plan to log intensities of my 'balls' through the day (assuming the sky stays clear), and generate HDR's from them, so at least we can check the relative intensity through the day, which is just as usefull if you know the absolute intensity at one point that day :D
Ie, if we get 25,000 lux at dawn, and at that point the HDR is 20% intense, we know at midday that 5x intensity in the HDR ~ 125,000 lux, for example.


Just waiting for that day now haha. Since I finished my balls and rig off, it's been cloudy and rainy! Bah!

Dave
 
The light meter would be really handy as Camsinny mentioned, to get real lux values along side this too. I'm pretty sure a modern DSLR has a meter in it, but how you can see the 'raw' data from it is another thing :)
Maybe really top-end models have a meter readout (ie, Nikon 1D etc etc)

This won't work as accurately as a light meter since the camera's picking up the reflected light, but you can translate from the camera's exposure settings for a white card (I'd think every DSLR provides these numbers as well as an exposure meter)
Lux = 50 x fnumber^2/ (exposure time in seconds x ISO film speed)

At the least this kind of thing will provide decent relative values if you can expose the card consistently.
eg. I took a photo at about 1140, in direct sunlight. With f/7.1, 1/200s shutter, ISO 100. Formula works out to about 5000. It is kinda overexposed though so the shutter could have probably been shorter, which would increase this number.
A couple days later it was cloudy, so at 1813 I took a similar photo. f/4.5, 1/80s shutter, ISO 200. Formula works out to 400.
Just continuing to take photos like this over a single day would probably give reasonable relative values.


I guess I need to learn more about the manual settings on my camera :p and wake up before the sun rises.

Racer 0.8.17 (out now) uses kilolux, so night lighting around 0.001 kilolux upto 100 kilolux at 12:00.
Quite harsh shadows you get, but I guess that's the way it is.

Seems to be correct behaviour, I went through the photos I 've got lying around for one taken a little before noon in sunlight and attached it. The shadows do look completely black, you have to adjust about +120 brightness/contrast to even see the colour of the grass there (and at that point the rest of the image blows out to white) This has the same settings as the pic I mentioned earlier - f/7.1, 1/200s shutter, ISO100.
 

Attachments

  • DSC_0111a.JPG
    DSC_0111a.JPG
    116.3 KB · Views: 250
Ruud, have you tried adding atmosphere CPU simulation? So we can get the sky/sun color at an given direction.

P.S. at the moment racer calculates auto exposure by: exposure=offset-sceneLuminance*gradient, this has some problem as it does not give enough feed back when the scene is very bright, try exposure=scale/sceneLuminance(I use scale =10 and the result is good) instead~ the result is very convincing~ tested at the tunnel @ carlswood:

in the tunnel,
screenshot007.jpg


near the exit:
screenshot005.jpg


and out~
screenshot004-1.jpg


Edited: @ boommer: sorry for the inconvenience, but pb is a good photo hosting site at least for me, uploading jpgs directly to racedepartment will cost rd more storage and bandwidth, and it won't show up in full size in the post.
 
I knew I'd get a bunch of crap for the way I posted the comment about the pictures but they did not appear when the page opened and other pictures posted on other threads don't fully appear. The little thumbnails always show up and work very nicely when I click them. They are generally made compressed a bit and are only on average under 100kb, not the monsters that take several seconds to appear on the post pictures thread that don't fully work! Doesn't the RD server have to get the pictures from another website in order to display them, that eats bandwidth.

It could be the crappy MS IE 8 that I have that causes the problem, but today they appeared.

Sorry if I have offended anyone, after trying to see the pictures I got a bit _issed!
 
I hadn't realised I had a light meter for my camera around (a Kenko KFM-1100). That gives EV values.
On http://racer.nl/tech/lighting.htm I've noted some of my measurements. Going from EV to lux is just LUX=2.5*2^EV.

As for exposure, I noticed a '0.1' constant in common/hdr.cg for exposure. Took that out so the exposure gradient is now 1.0 instead of 10.0. It all fits like the SI system! exposure=1/sceneLuminance. All in 0.8.18.
 
Nice work Ruud.

Those numbers stack up and scale pretty nicely from the ones on Wikipedia, considering your lat/long and the intensity change because of it etc.

I guess intensity of the sun/sky can be done pre-atmosphere, and again controlled automatically, since we have no control over these.

What we do change, or see change, is the atmosphere, so cloud cover impacting the intensities, and the mie/rayleigh of the atmosphere.


I can see eventually that we might only need curves for a few parameters mainly relating to the random nature of the atmosphere, with the main background driving forces being automatic.

Dave
 

Latest News

Are you buying car setups?

  • Yes

  • No


Results are only viewable after voting.
Back
Top