Released Roggel

[Raphael Buthmann]

I'll try today . =D

 

[Mr Whippy]

Just a note, I managed to get the Max file for just the trees, so I bunched em all into one DOF, atlased the textures, added some colour variations on the common trees (to fill the atlas), re-did the shader (trees now look nicer), and adjusted geometry.ini etc as necessary.

I went from 34fps > 41fps at the start/finish line simply by doing that change. Took about 1hr in total.

I want to fix up the graphics a bit more, and I'll combine in the cameras that have been made too, and release a patch over the weekend

I'll pester again and try get the buildings in a Max file so I can combine those and atlas etc, then we might find another 6fps or so

Cheers

Dave

 

[camsinny]

I'd rather model the buildings up a bit more, I don't mind doing this over the next week if we can get the old building data to create over the top of.
Rather than altas a whole bunch of already blurry textures I'd rather map some nice tiling textures on there and do some AO baking with vert colours and stuff.

Adding a bit more to the silhouettes of the buildings and making nicer textures would add much more immersion IMHO.
PM me if you get the buildings

 

[Raphael Buthmann]

http://www.mediafire.com/?zo48xzdbp8pvp95

Extracted Models =D .

 

[Raphael Buthmann]

Hello ? Where is everybody ? LOL

 

[Mr Whippy]

Hi,

http://www.gowhippy.com/racer/roggel_bits.zip

Well I got the 3DS Max tree files from Cruden months back.

I made them into one single DOF and also put the trees into an atlas texture.

This fixes the weird issue with the fighting of the 2 sides of the plane and also reduces the render draw count so visual quality is up (uses X tree shader) and the FPS are up about 20% on my system!


In theory all you need to do is put the tree dof, texture and shader entries in the appropriate places, along with removing the old shader entries for trees and the tree geometry, and it will work.

Alternatively just drop ALL these bits over the existing bits and it should just work.



I also added some spec maps to the paving to give it a bit extra depth/realism, and improved the TOD for that specific location.
The cloud texture still looks a bit iffy, it'd probably be a better track with harder sun lighting and a high cirrus cloud type layer but generally clear for the best looks (Racer does that look best right now)

If there is demand for a better sky I'll fix new TOD curves/sky tex/dome.


I did all this months back but had to work on other things, and also being the perfectionist I am I wasn't happy with the sky which put me off releasing. But projects are no good sat around on HDD's even if they are not perfectly perfect!


Enjoy!

Dave

 

[camsinny]

So I really wanted to detail up the buildings a little more (and thank you Raphael for the zip of the dofs) however zmodeler won't run on my pc for whatever reason (i'm thinking SLI).

If anyone would be so kind as to put them into a .3ds or .obj that'd be awesome...alternatively if Ruud wants to pass along a native max file that would also be nice!

 

[Mr Whippy]

Pester me this weekend Cam, and I'll sort them out... unless someone else does first!

The things I want to do next are a better sky dome/texture set up, then some moodier lighting.

Then probably the next weak point is the back end of the track where there isn't much going on beyond the trees. So maybe just some more detailed fields and bushes and things to make it less bare... perhaps some livestock in a field, some bales, or an old tractor?


Cheers

Dave

 

[boomer541]

Mr. Whippy,
Nice job on the trees, but as always I check the Qlog after exiting Racer and lo and behold I found a couple of Qlog problems in the special.ini (track camera) and track.shd (Cull=true) files. Took me less than 5 minutes to fix.

Always check your Qlog, it only takes a few seconds.

 

[Mr Whippy]

Hehe, oops...

I'll admit I didn't really do anything with cameras, except perhaps try those ones people were posting up.
But you are right, since my files overwrote old ones I should have checked that... just wanted to get the bits out (perhaps a longer-term reason to let these files be split, ie, camera.ini, environment.ini, waypoints.ini etc...)?

Not sure what that cull issue is, I'll take a look. I thought cull=true was a valid shader variable.


Please feel free Boomer, anyone for that matter, post up your own updates etc. Mine was mainly for the trees optimisation only!

Dave

 

[Ruud]

@MrWhippy: Strange, I get purple trees, black sky, unless I move out the 'tod' update.

 

[camsinny]

Looks like I have a bit of time on Monday perhaps if someone would be so kind as to put the .dof files Raphael posted into a .3ds or .obj

 

[boomer541]

It is always best to NOT include the TOD folder with track updates as everyones system may not like your settings and they can use thier own. When I downloaded Mr. whippys very good trees I automatically deleted his tod settings. worked fine with mine.

 

[Mr Whippy]

Hmmm weird.

I don't like my TOD for this track any way. I only included it so the curves were more correct for the geographical location of Roggel.

It'd be nice to dump TOD curves in their present form at some stage and move to a different system that used sun height for intensity instead... or Racer somehow scaled/moved the curves to fit the sunrise/sunset positions at a given geo location automatically.


My ideal would be to have the sun diffuse/ambient curves generated from the sky appearance.
The only value you might then need to tweak is sun intensity, but I think that is probably a function mainly of the sun angle in the sky and cloud cover maybe!?


Hmmm

Dave

 

[Stereo]

I can't figure out which version of Racer it was that I was happiest with the sky properties, I am fairly sure that previously, the sky rayleigh/mie values and sun position determined the ambient/diffuse, splitting them up gives more flexibility but there's currently no track that's well set up to take advantage of that, or that the sky even matches the illumination well.

8:30pm near sunset and 7:15am, near-dawn. (Carlswood got rotated at some point) 0.8.13 on the left, 0.9.0RC3 on the right. It's just missing out on the colour I'd expect in the golden hour, with the sky going a deep blue and the sun going red/orange.

Somewhere on my list of things to do is to take a series of photographs, and then produce accurate TOD curves for one day. Can't really generalize but it would at least give one nice setting. Simpler than that, I have a nice photoset around dawn that I could use to get one time ok (although the latitude-longitude play a part, I would just set it up at the time the sun's the same height over the horizon)

Can't vouch for the white balance on this, but the photo info - ISO80, 1/1000sec, f/4.9 - taken at 8:28am on Jan 8th, around 20-30 degrees north - doesn't suggest it would be anything out of the ordinary. You can definitely see where specular being 1-Kd makes sense - the ocean's a lot yellower in specular than the clouds are in diffuse.

 

[Mr Whippy]

Yep, for anything non-metal 1-kd seems to make sense.

I've done quite a few tests at my end now using my polariser out on wet roads, dry roads, and general materials and 1-kd seems to give the right result!


In Racer specular == diffuse curve values. I believe I asked that specifically of Ruud at the time because specular are borne from the diffuse intensity.

However on reflection it's perhaps not ideal because as we get more diffused specular (softer reflections), we reflect not just the sun itself (which is white), but also the large orange bloom around it from the suns scattering with the atmosphere especially at dusk/dawn!

I'm not sure what the best solution is. If you take photos at dawn/dusk when the sky is orange, the main 'diffuse' still looks white on a white object, but reflections that are diffused (glancing reflection on brick walls or asphalt for example) are clearly influenced by the orange in the sky as much as the white sun spot.


Perhaps 1-kd will fix that a little bit without many other changes, but there is probably some strong maths underneath this that is important and without understanding the shaders Ruud has programmed I don't think it's my place to tinker too much here as I might get the right result for the wrong reasons or vice versa!



As per the curves, the ones I hosted a long time back for sunny/overcast were specifically set for the given Lat/Long and date/time, and they used IES values directly from the architectural lighting analysis part of 3DS Max, so I expect they are quite 'ok'

They seem to work nicely in Racer.

But that is the issue, they are tied to a specific date/time/lat/long. As soon as we move a tiny bit then sunrise/sunset change in the time axis, and then the sun height may change and get too intense at midday etc.
Obviously the extreme example is a polar location where it can stay daytime, but only just, for many months... obviously a set of TOD curves wouldn't work there at all!


So really TOD curves are useless unless you adhere to the authors lag/long/date/time etc... deviate and it breaks in a cascade effect through all your other settings. Trying to set up shaders/effects on 'bad' tracks is just a nightmare as you don't know what is reacting right or not.


What I think is a really valuable exercise and one I need to undertake, is to take actual photos and generate HDR's, and then work out how to get the KLux values read off them. I assume a properly calibrated camera/hdr build in photoshop is accurately metered so perhaps there is a way to do it there.

Then in theory you can 'copy' the scene as you see it into Racer, and then check kLux intensities till they match!


But you also raise an interesting question about white balance. IRL colour balance is amazingly wide, but we obviously flatten this with our TOD curves somewhat.

The mie/ray sky on the other hand doesn't white balance itself and can appear as a very strong blue colour without the sun, yet with our balanced TOD curves the impact of the deep blue sky isn't apparent in the ambient impact on materials.

Ie, set sunny=0 and the sky is a deep blue, but then check a matte white object and it looks light grey, not deep blue.



Another argument imo for coherency between the values. Imo that should be done by having the live envmap, or a version of it, poll the scene every 50 frames or so and determine the appropriate diffuse/ambient/specular values to use to light the scene. That way as the TOD changes and the sun sets, then the diffuse/ambient values 'auto' set themselves through to black as the sun finally goes below the horizon.

If the day is cloudy then the diffuse is automatically lower and the ambient setting higher.

You could even detect dynamic range (look for the maximum contrast?) and use the shadow filtering to soften or sharpen the shadows on hazy or very clear days.

This works and we use it all the time in arch vis and other renderings, even for VFX, by using environment probes to create the appropriate scene lighting. We generate our own scene environment in HDR with the mie/ray sky so it seems crazy not to use the values it generates, they will surely then create diff/amb values that match accurately the sky



The only one factor I can't think how we would set is the sun intensity value which seems to scale the overall sky brightness. I guess this is one case where just getting data at certain lat/long/dates and conditions is essential and then build up a table, and match it in Racer...
I'm guessing it's just proportional to sun elevation.

It's also easy to check intensity with an SLR. Iirc they meter for grey point at 2 stops down from white.
So you meter into the blue of the sky and add exposure comp to + 2, and then use those camera settings to calculate out the Klux.
Ooor, you can just adjust after doing the calc.

There was a nice little app on the iPhone that did this, you could even take a photo with the stats and add the compensation on too, so it had a picture showing what it looked like and also the kLux value!!!
Stupid thing was people were using it to measure incident light kLux rather than reflected, so they REMOVED the functionality. Duhhh... some people actually wanted to use it for reflected light intensity! (probably graphics people )

So I'm back to SLR and taking notes and doing calculations but it's good as I have a really high quality reference picture too (and if you do the old polariser trick too a nice reference of the spec map or 1-kd map you want to have!)


Thanks

Dave