WIP Osaka Loop (Hanshin Line)

[GizmoY]

yes, the current models in the beta are all a single model which causes traction issues. in my current beats the supports are seperate which has fixed this issue

traffic wise, they would be driving around at speed limit for that road, give or take 2-3 mph (so each lane is moving at a different pace), there would be no stop lines are intersections, so should work fairly well.

 

[Mr Whippy]

Yeah it'll be great with traffic going at various speeds and just cruising around without stops etc.

With some nice ambient sounds and also trigger lines for reverb adjustments at underpasses or whatever, it'll add a lot of realism and feel to the course as you drive around... rather than it feeling very static.

I remember Stereo perhaps mentioning scripting UV tweaks for objects, maybe. I wonder if it's also possible to have flashing lights and things by just offsetting UV, since at some points you're gonna need diversion barriers and stuff so it's obvious you need to loop back around at the boundary intersections.


I'll have to create some sky boxes for you with appropriate settings and sky maps etc.

Also do you think eventually you might add all the lines as decals, rather than having the painted lines in the main textures?

You can still get awesome results either way, I'm just curious. I've found the former is simpler to a point, then eventually it's nice to just be able to lay down decals later and forget UV mapping on the main road polygons to get them all lining up properly.

I've been working on quite a few city type tracks and decals are never easy, but having them separate does make life easier eventually

Dave

 

[Stereo]

Doing animation by switching UV coordinates is not a problem, only question is how to tell the shader the flash frequency (maybe ambient, since it usually is 1 1 1 1 anyway). I think it's helpful to have some level of control on it so it's not just "all flashing objects on the track turn on and off simultaneously". It'd be even better to have it slightly different on each instance; maybe some pseudorandom function seeded by the coordinates rounded off to the nearest metre? Though that would bug out a bit if any happen to cross the edges where it rounds.

Yeah, I've done a bit of both UV mapping and decals on track now, I would say decals are too much effort in ZMod (Blender lets you 'snap' it to a cm above the road surface automatically, so you can just draw a spline and get a line on the surface under it) Maybe at some point I'll figure out the changes to the Blender dof exporter so it can do tracks in one shot, generate a bunch of dofs and add missing objects to geometry.ini.

wrt. traffic I don't know exactly how long this loop is (seems under 10km?) but it'd probably be nice to add a script that removes cars you've passed and adds them to 'on-ramps' you're about to pass so there's not just 1 car every couple kilometers. Not really too difficult to script although the 'starting points' might need to be hardcoded with zones of highway the player should be on.

 

[Mr Whippy]

Flash frequency can be done with a 'wait' in the paint thingy.

Though paint is a bad place for such stuff as FPS from client to client change a lot. The flashing lights on the Gallardo Police car skin for example were a pain to make look nice inside the 'paint' folder vs the physics one. Mainly because from one track camera the FPS might be 60fps and it look ok, the next 120fps and they're flashing like a Benny Hill sped-up sequence

Not sure on randomising them. I suppose the big issue is draw calls and objects. Probably better to have a bunch of sequences on one texture that has enough variety to look random, and also the ability to paint some 'dimmer' than others, or slight variations in colour hue etc... that way you can get some more interesting effects perhaps?!


That traffic idea is good too. Though I'm not sure how it'd work with multiple clients playing together... I've not tried that yet but I guess the traffic is server side, so you'd just need to poll other users positions too while doing the calculations?



Gizmo, is there a list of the buildings you've done so far or some thing to help me choose? I can pick one myself but I don't want to risk picking one that you've already had a go at or something

Thanks

Dave

 

[Stereo]

That traffic idea is good too. Though I'm not sure how it'd work with multiple clients playing together... I've not tried that yet but I guess the traffic is server side, so you'd just need to poll other users positions too while doing the calculations?

I don't really know how scripting works online, I haven't tried Racer online in maybe 5 years. Probably something like that is fine though, I remember the server running AI.



Using the texture to provide variation is a good idea - I was thinking maybe use an extra channel (maybe alpha of the emission map, since they probably want 'nice' emission for nighttime) where black = fastest, white = slowest flashing, so you just paint each object a constant colour for its frequency and have slight differences, eg from 0.5 to 1 second depending on the value.

 

[GizmoY]

Gizmo, is there a list of the buildings you've done so far or some thing to help me choose? I can pick one myself but I don't want to risk picking one that you've already had a go at or something

Thanks

Dave

there is no such list. Ive been watching the videos from the arcade game i posted on page 1. I noticed that the buildings in the game do not reflect real life buildings. i guess its all about just filling the area rather than accuracy.

 

[Mr Whippy]

Stereo, ah that is a nice way to introduce some randomness... even just adding r,g or b to the results to get more randomness?! I'm not sure how all that works but I suppose it's fairly trivial to test.

Gizmo, oh ok, so if I just find a cool building I like on that loop and then build it we're good to go?

Also do you want me to have a shot at making a night time sky dome/TOD settings?
I've already done something with a full moon, where really the moon is a very dim sun, so you get nice soft shadows and specular reflections, but it's still a fairly nice looking night time

Dave

 

[Stereo]

Stereo, ah that is a nice way to introduce some randomness... even just adding r,g or b to the results to get more randomness?! I'm not sure how all that works but I suppose it's fairly trivial to test.

Heh got me thinking, with a gradient you'd get marquee animations. Maybe not too useful as a continuous thing but you could have the > > > type lane closure signs.

 

[Mr Whippy]

Well those >>> signs and some cones with the little flashers on top were my main thought.

Obviously in the videos above they use the >>> type things, but in the spirit of Bay Route 9 it felt a bit more 'realistic' so perhaps something that had >>> and also flashing cone lights, like maintenance crew/roadworks type setups might be more convincing.

Either way I've often wondered how you make something that closes off lanes but looks 'right', to send you around a loop


Gizmo, what were your plans for the track? More realistic or more arcade style like the videos?


Cheers

Dave

 

[Stereo]

Got bored and wandered around Tokyo highways on Streetview for a bit.

They have a couple ways to close down lanes:

The top metal barriers are the most permanent kind - sorta like the concrete Jersey barriers used around here, I guess a forklift brings them in. They mostly seem to have those wires strung along, looks like it powers some red lights that hang every so often. Maybe the wire itself has lights in it, too? The red and white plastic ones are probably easier to move but still fairly permanent. And then the yellow barrels get used for more temporary stuff, with cones in between. Or just cones.

Kinda getting me tempted to throw together the basics for a C1 loop in Blender (elevated section, tunnel section, plus the 'stacked' elevation) so I can test 2nd UV coordinates & light map shaders. Maybe when my 'urgent' pile of work is done.

 

[Mr Whippy]

Haha, there is always an 'urgent' pile of stuff

2nd UV coords are only in the more recent versions of Racer though aren't they?
Certainly worth a test but might limit use of the track.

I'd be more tempted to up-res the mesh density and then bake lighting info in there maybe?!

And/or depending on materials/shaders, you could probably use the asphalt shader like on the small asphalt loop track, but use a unique bit of texture for anywhere you need specific lighting conditions and then add more texture data into that for light/illumination.

Say a repeating one with some AO and 'lamp' glows baked into it etc, and then for junctions and stuff make unique ones etc.

But I'd probably still think verts might work ok for this job... though baking it is gonna have to be a task done elsewhere as I'm not sure zmod has support for anything baking vert type stuff.

Is there anything in Blender for doing such jobs?



Anyway, Gizmo I'm more than happy to help where you might need it.

I've chosen this building to have a shot at for now

I'm not sure exactly how I'll go about it, but I guess that is half of the fun here trying out techniques to get great visuals at low GPU cost!

 

[Mr Whippy]

238 faces so far.

D
epending on texturing approach I might be able to save quite a few polys here. To map globally and then do a light map, and add more details, or map with repeats and have more pixel density but less 'atmosphere'

Hmmmm.

On Google Street view parked on the road side looking right at it on wide FOV it's gonna be about 1024px high.
So assuming you normally fly past on a slightly narrower FOV, but it's at the side, then 1024px high seems fairly ok for a building like this.

Then again I think split glass makes some sense (since we have to make our own cube maps in LDR), so glass for glossy shiny stuff with a sharp cube map, and then a blurry cube for the rest of the building.

Hmmm, decisions decisions

Cheers

Dave

 

[Stereo]

2nd UV coords are only in the more recent versions of Racer though aren't they?
Certainly worth a test but might limit use of the track.

Say a repeating one with some AO and 'lamp' glows baked into it etc, and then for junctions and stuff make unique ones etc.

But I'd probably still think verts might work ok for this job... though baking it is gonna have to be a task done elsewhere as I'm not sure zmod has support for anything baking vert type stuff.

Is there anything in Blender for doing such jobs?

Yeah, Blender can bake the scene to vertex colours. Though I haven't tried yet so don't know how well it works (also haven't tried exporting to Racer or writing a shader that uses them). Rigging up the lights might be the most inconvenient part, emissive materials apparently don't work all that well.

I thought 2nd UV coords were there for a bit longer but I looked and it's only RC8 that they got added, according to the docs. Maybe a bit too recent then, since RC5d still seems to be my goto version for general Racer use.

 

[Mr Whippy]

Yeah I'm on RC5c here, I can't remember what d changed but I went back to c.

Things seem to work nicely there.

Vert shaders, I've made a few and they work ok, mainly I was just tinting xtree/xhedge stuff to give some variety to the colours and subtle shading in these items.

I'll have a shot at using a few techniques on this building and then Gizmo can see which he likes the look of the most.
For buildings maybe an rgb texture would be best for emission and light mapping purposes... but obviously you get stuck needing a full unwrap and can't really re-use repeating texture parts without careful planning.

Hmmm

Dave

 

[Mr Whippy]

Uhh, well I've realised again after some hair pulling, that Some1's vert colour export in the dof exporter doesn't appear to work.
But that is no big issue for now as ASE > modeller > dof does work.

But a bigger problem is that in the vert shader for the PBL shaders we're using, the COLOR v2p is used up by extinction (huge waste for a float)

But just scrubbing out extinction for a test, and I can pass the vert colour into the Ke input in the PBL shader and get nice 'emission' from vert colours and stuff... so in this example the street lights and lit evening ambience casts nicely onto my building model.

Obviously without the streets (which we wouldn't see as we're on the raised road here), or street lamps, or other buildings around, it looks weird, but it looks smooth enough on the building model.

This looks just as nice for daytime use, using repeated textures and split off window geometry/shader, the vert lighting just for AO looks pretty smooth for this quality of asset... yet ties the object into the scene much nicer with surrounding elements and the PBL shaders general realism as well.


But to get AO and vert lighting in the vert data would seem a bit impossible for now as it's just one channel and no way to differentiate between AO or light influence.

But with smart value setting at least for the night time, we can probably dump the ambient TOD input for lighting and just light purely with the vert data (or a bit of both), that way the AO is baked in with the emission data at a given 'emission' value.


So you could probably have a day-time model set with AO only in the vert bake, or night time model set with a full ao/emission combined bake, and an appropriate shader swap.


Hmmmm

Dave

 

[Mr Whippy]

Well I've been having a fiddle with some bits and pieces on this track.

So panorama, just an image with some emission, put into a custom panorama shader (mainly just so you can scale the fog intuitively, also adds emission for glowing stuff)
It's badly cut out, but hey, just testing.

Road is just the asphalt shader Stereo and I were messing with last year or so.

Sky dome is new, just using a panoramic type sky vs the top down one. So slightly customised night sky grabbed off cg skies for testing.
Sky shader is just the rgb raster multiplied up so the kLux outputs are about right for a night sky (multiplied using 'clouds' variable)
Time is actually a day time, but with a very low sunny setting, so the sun is actually casting a soft shadow and very low intensity to be the moon (edited shadow params in constants.cg and racer.ini via batches/ini.exe for easier tweaking in tracks, so it's lower res and softer)

Erm, the lamps are using the billboard type shader Stereo wrote for Bay Route 9. Probably could look better here with a better texture etc. Banding seems a bit of an issue. Needs a really bright spot but a more subtle falloff element. Oh for 16 or 32bpc for these types of jobs.


Not sure if the intensities are realistic or not. I still need to figure out some calibration scenes in Racer so I can figure out what 'exposure' settings in Racer equate to real camera settings... then we can simply take real images with real settings, colour pick, and check in equivalent Racer screenies to get intensities about right.
It's probably all fairly ball park apart from the glows around the lights which seem too intense still... dropping emission looks better for the falloff glow, but then the middle is too dim... high bpc alpha needed... hmmm, maybe could maybe take rgba as a monotone and stack to get an equivalent 32bpc single channel alpha mask? Colour with a fixed emission value? Stereo does that sound feasible to make the tweak in the 'glow' shader?


Cheers

Dave

 

[Stereo]

If you can get a texture formatted that way, a shader should be doable, only trick would be handling gamma values correctly.

I might have just left the lamp glows up to bloom here and used a dot of a single brightness, idk. Mine kinda sparkle a bit but don't have the banding.

 

[Mr Whippy]

Yeah I think the bloom can achieve an ok effect on it's own.

It was just interesting on the flarey/glarey blooms done manually.

I think it's doable too. I'm just trying to figure out if alpha is managed in 32bit float or is always an 8bit affair.
Using baseCol.a + r + g + b for example, will get you ~ 1000 levels of intensity in theory, but I'm not sure it's being passed like that, and isn't instead just clamping the alpha output once it hits 255.

So the next check is to divide each channel then sum them, or divide and multiply, and do things with gamma too no doubt. Some maths is required here to figure out the logic to then be able to author a HDR image and split the channels down into rgba 8pbc

A job for another day I think

Dave

 

[Stereo]

I think the main concern from my end is the bilinear filtering, ideally all 4 channels need to be continuous from 0 = darkest to 255 = brightest output, if you had some scheme like 'rgb + 256*alpha' then you could have 0-255 from 0 alpha, 256-511 from 1 alpha etc, but the filtering would mean you're actually getting alpha = 0.5 sometimes. You'd ideally want to implement your own texture filter that handles that, but I have no idea how to add those to Cg. It may be the case that they're done in hardware and you get major slowdowns by ignoring them.

One option I can think of is converting to HSV and splitting up the value into 2 ranges - in the lower range alpha is 0 and rgb is used as-is, in the higher range alpha is the value and you assign max value & convert back to rgb. Would need to do something fancy with gamma so that the range of values is smooth but that's just math.

If you want greyscale you can do similar over all 4 channels - first red goes 0-255 and sticks at 255, then green goes 0-255 and sticks at 255, etc.

Which is all just adding up the values, so you only double the number of intensities.

Maybe you could do like a float where one channel is the exponent and the other is the details - I'm pretty sure that goes weird at the bilinear filtering again though.


Easiest might be like you said, light falls off at a square of distance (and glare does even higher) ... use a corresponding gamma value to linearize the texture. It'd be relatively easy to set a texture to linear, and pass a gamma from the shader (eg. in the 'scale' parameter)

 

[Mr Whippy]

I'm not sure I meant that, I think what I was suggesting was inferior and your idea is better hehe

So yeah, some kinda texture with as smooth linear values as possible (255-0 over a 512px wide 'glare' texture for instance, seems about perfect )
Then use an exponent value (scale) to adjust the ramp in actual values in a HDR sense, since that is really what is going on... some kinda exponential falloff of light in some shape or form.

I just realised I was saying cube falloff too, instead of square

Dave