• Blurring the line between real and virtual motorsports
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

TOD editing

Discussion in 'Racer' started by Ruud, Aug 11, 2010.

  1. 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.
  2. Here's a picture how it looks in SB2 :


    The half circle which represents the sun movement rotates around the whole scene/track in 2 ways like shown in those pictures.
    This way, we can set the TOD to be equatorial or polar oriented.
    I hope, it will give you some ideas...

    Nice job Ruud as always, the idea is excellent, because we can set TOD dynamically (in-game) which makes me really happy. Wow....

  3. Ruud

    RACER Developer

    Look again, use left/right to move through all curves. There are 18 of them now, including mie/rayleigh.
  4. Is that TOD per track or global?
  5. Hi Ruud,

    The normal map for the clouds sounds good.

    In theory, if you write a good material (since most clouds are cloudy and homogenous), you could just have alpha to define coverage, and the rgb channel for the normals, and let the cloud appearance be driven by the shader itself and internal values such as TOD ones (ie, we don't really need rgb diffuse definition for clouds, it's a waste of 3 channels really)
    Best to drive the clouds diffuse and ambient appearance from the sun colour, sky colour, intensities, etc etc...

    Sun x,y,z...
    Is it not best to define a lat/long, and day/month/year (month within a year would probably be plenty 1...12), and then perhaps a north direction (to spin the system if your 'up' in the map editor isn't north)?... most systems with TOD/sun position systems use these inputs and it does it all nicely that way. Should make it easy to get real life tracks sun conditions accurate, especially if you can just define the month of the year, lat/long, and get the sun taking the right path, and rising/setting at the right times etc!

    The specular, imo at least, should have a way to lock to the sun rgb output (diffuse output)

    I can't imagine I'd ever change it from that for most standard applications (ie, real life conditions)

    After all, ranging from pure reflection (envmap), through to soft reflections (specular), through to the diffuse reflections (diffuse), they are all a function of the suns intensity and colour, which ultimately are all linked.

    To unlink them is suggestive that ALL scene materials would react differently to the sun in diffuse reflections, soft reflections, and sharp/pure reflections. I'd never do that, if a specific material needed to react specially, I would set the specular properties of it specially.

    Not sure what others think with regards to that though.

  6. I'm with Dave regarding the lat/long and date and north. Theoretically, one should be able to calculate quite a lot of stuff from these given variables - maybe even correct lighting values? I don't know, I should probably ask my father, he's the rocket-scientist in these things (actually, he's an astronomer) :)
  7. Wow, just tried the TOD editor.

    Fantastic work Ruud. It's amazing to be able to use sliders in real time and see the effects.

    My big thought now is what is the best way to work with intensities and exposure. Would you prefer to normalise intensities so exposure isn't used, or should we start to use real dynamic ranges for intensities, and use exposure control to correct for it.

    One way would mean emissions would need to be scaled (so in day time headlights and flares don't appear over-bright, yet on a night time they don't appear too dull)...

    Perhaps 'exposure' might become a value to scale these effects alone (ie, headlight flare intensities, headlight beam texture intensity etc)

    Hmmmm, can test both ways I suppose :D

    Great tool though. It would be ace if we could use the same technology to adjust car.ini on the fly in-sim too (a bit like Carlab did actually, what ever happened to that :D )

  8. Anyone can explain me? TOD is automatic time curve like in gta (where you can get daytime or night, and the day keep counting automatically)?
  9. The TOD Editor should only allow a certain nb. of interpolation points perfectly "snappable/mergable" especially for the first & the last TOD curve value, for best results when looping the time. I'd say 12, 1 interpolation pt. every 2 hours.

    The first & last value (0 & 24h) should be snapped/merged together automatically.

    For the sun direction & the sun orientation, if the sun CoG is the same as the scene bounding box CoG & if by default, your sun is oriented perpendicular to the scene (top view Z axis), then sun X rotation could represent the direction of the sun & Y rotation axis would be the orientation of the sun.

    So, in the TOD Editor, we would have to set sun direction (Y value represents sun X or Y rotation axis) & the sun orientation (Y value = inverse of first axis rotation). Both sun rotation axis would be constrained to a range of : -90° to 90°, even more for security. Rotating & mixing them together, you'll get a quite realistic environment.

    Another way, maybe, using simply the skydome where we would project the curve (= direction + orientation of sun) & declare it as the sun path. Same as creating splines, but this time, just with a simple path. Alternatively, we could use A in TrackEd to build automatically the curve from one boundary vertex/point (green points in TrackEd) of our skydomes. That implicates, we tessellate the skydome correctly to project our sun curve as wished afterward in TrackEd.
  10. Cool!

    Took me a while to figure out how to remove points. (For those who are unsure you just drag the point to the bottom of the graph and it snaps away.)

    Great to see it all working :D
  11. @Dave
    I agree with you on the specular color one, non self-emissive body have a property that the radiated energy is less or equal than the energy it absorbed. Specualr is infact an approximate model of sun reflection on rough surface. In some physical based render engine, specular is coupled with envmap reflection value.

    I think the exposure should be handled automatically by adaptive exposure control, which is essential in modern HDR engine. A fixed pre-defined value can no handle situation when moving between dark/bright area, I.e. Driving out of a tunnel or looking at the sun directly.

    Edited: Finally got auto exposure working without stalling.....simply set auto_exposure.steps=1 in racer.ini
  12. Yeah, I'm more with the idea of using real dynamic ranges gtpdzbiz, and letting a good auto exposure algorithm sort things out, rather than us try make things work properly...
    The example you posted is sensible too, to get an authentic looking tunnel out into daylight glare period and look, we need automatic exposure control.

    I'll experiment with some stuff there.

    It would be nice though to remove all the sun position stuff, and have a lat/long fixed in track special.ini or something, and maybe a date (like the time input in tracks special.ini already), and then we can forget all about the sun movement/position stuff. Personally, if I had to create a curve to move the sun around the scene, I'd use a tool that used lat/long/date to help create the curve in the first place. It just seems like a level of control we don't need unless we want some kind of alien orbit simulated :D

    I think high resolution curve data will be good to keep now though, as opposed to what QuadCoreMax is thinking with a limit to 12 points or 2hrs resolution.

    If we add curves for rain, snow, clouds etc, then we might want rain to start over a minute or so, or come on and off within a few minutes, not over hours.
    Also, we might get low cloud on a mountain track and want fog to come and go faster than every two hours.
    We might want a dewy dawn, followed 30 mins later by a baking clear sunny sky... 2hr resolution (with 12 points for the 24hr cycle) is limiting ourselves before we have even started imo.

    For a 'standard' TOD setup, 12 points is probably ample, but for per-track weather or special and interesting events, we need the full unlimited point count control we have now. As a track creator I'd prefer to have a hard time editing it and getting it just how I want it, than be limited for no real reason.
    If people want to have only 12 points, then they can limit themselves with self-restraint :D

    I want 100's of points :tongue::cool:

  13. About setting dynamic weather, I got an idea of using RSX scripts. Curves are good, but you always get the same weather at the same time. So instead using millions of points to represent a curve, we can set up a probability value for rain/snow... just like in weather reports, and link up all the clouds/mie/rayleigh value. :)
  14. That's a good question !
    Maybe compile a binary TOD file which will go into the track folder for per track TOD & if global, it'll be used by the default TOD folder, in data\renderer.


    You're partially right with the max. of interpolation points....

    For some curves, we need more points in fact ! One important thing (you can test it) though, both boundary/extrem IPs (interpolation points) should be the same & that's for sure, as you test Ruud defaulft TOD, you'll see the issues from 23.59 to 0.01h. So for perfect time looping, it's necessary & it should be done automatically by Racer. The 1st & last should be always the same IPs.

    There's one thing to be careful with, if you set TOD points & accidentally, if there are 2 pts. on the same place on the TOD grid (overlapping points, one point will be hidden by the top one), then you'll understand the mess....So that's one reason, why I said the TOD pts. should snap to the grid at each second vertical line/hour. I have most of the times good reasons behind my arguments...Also, you could consider it as performant proof....

    As you know (been animating a lot since years from 2D to 3D), IP are quite resource unfriendly, so the more pts. the more Racer will have hard times interpolating those... When fast_timing Racer, by default you got a huge FPS drop, so I'd say it's quite important to keep it optimized/performance oriented.

    Still, I agree with you, rain, volumetric fog color/global density/atmospheric height, snow, hdr, sun specular multiplier etc.. should be added as new curves too.

    For the sun curve projected into the skydome, as Ruud said, the skydome normals could be used to calculate correctly the sun projection vectors into the scene.

    Easy & fair enough to handle "road splines" for roads, I'd be satisfied to see the same schema for the sun. I would always think as followed, if something in Racer is buggy & needs to be fixed somehow (multiple ways of doing it as usual), I'd help myself with the existing tools I have, like the awesome Track Editor , or in this case, the skydomes normals. It's a logical approach of handling/resolving quickly "life problems/dilemmas"...


    Yeah you're right too, if the curves are globally set, then we would have the same TOD over & over, except if we mod the default global TOD curves.
    Had the same idea yesterday night, which is great !!! In fact, with random + timer + TOD curves in Racer scripts, that should be one of the best ways, simulating an real unpredictable TOD !
  15. Was just about to bring this up actually. It'd be cool to have events that you can trigger (i.e. rain rolling in over 2 hours or something) that are triggered via a script or something. Even having random events per race would be cool. Pretty much a dynamic weather system then.
    Especially if the curves could be altered by a random seed at each racer load. I'd quite like that, then you'd never really have the same weather twice :D
  16. It's already possible with Trigger Lines in TrackEd + rsx scripts. I've tried with success, creating those at the desired position, still when entering command & then verifying the whole in special.ini file (command=...), I don't know why, but I can't make my custom commands working once my TriggerLine been activated/triggered in-game. Even compiling the rsx scripts will throw an error in console without much details about it...hmm, I hope to get it right soon...

    Maybe gtpdzbiz could create something just to show us, how great a script would do the job !
    Had some new ideas for your acceleration 0-100 script...

    If you need some help in TrackEd, open a new thread & ask, I'm finishing for now TKF cameras + collision/destroyable objects with TrackEd which is working perfectly for my first & newest track called Lil Lake.
  17. Hehe, I'm not sure what is possible with scripts, but it sounds like the way to go for weather some times.

    However, I still like the idea of doing it by curves if you wanted to, there is no reason not to have curves.

    We can then have almost 'storyline' weather for time trials for example, so it's specifically important that the weather over a 10km road stage is consistent to make it fair for example :D

    Then for longer multi-player sessions, random weather via script would be good.

    I'm not sure on the complexity, but if the curves can control weather, then would it be easy to have the script influence/modify these variables as well?

    QuadCoreMax, deffo agree on the 1st/last point being essentially the same point. How that is achieved I'm not sure though... :)

  18. Ruud

    RACER Developer

    It's currently global. Will make it per track (with a fallback to the default curves for any missing ones).
  19. Ruud

    RACER Developer

    There's a difference between rayleigh/mie curves and stuff like rain. Rain is something that is not necessarily dynamic, just like things as 'amount of people on the grandstands' or such, so it should be handled separately. Using the same curve mechanism is possible, but keeping a globally changeable rain value is useful.

    On dynamic light range, according to http://en.wikipedia.org/wiki/Lux a moonlit night is 0.27 lux, a clear day starts at 10,000 lux. That gives a range of around 40000:1. It would be a nice experiment to provide sun_diffuse_r/g/b in lux, then use exposure for now to bring things (I know, it should be automatic). You can only change ranges currently in Curved though. But it would give automatic nice values for night vs day; lots of contrast at daytime and low contrast at night.
    Don't forget to rule out bloom though, that is not adjusted for large exposures yet.
  20. Sounds like something worth trying there... what to set the sky intensity and things to will be the more difficult part.

    Using real values will be interesting at least.

    There is also the question of white balance too hehe, but I think we are best normalising for that so white always appears white?!