Post Pictures Thread (part 4)

[KS95]

About time for a new one, this time keeping photos and videos together.

Post away folks!


Edit 19/10/12: Videos can now be added here - http://www.racedepartment.com/forum/media/category/racer.15/

 

[Mr Whippy]

It's easier if you can get the files out of the AR

Some of the older cars are really nice. OK not super high quality like other modern games but they have a really nice charm and feel to them.

I remember driving that GT40 loads back when it was released. Happy days!

I look forward to the update

Dave

 

[Mr Whippy]

Cosmo x 2. Buggy multi-player going on here hehe.

And then about to go for a spin with multi-player working ok!

I've not much time right now but with Cosmo's great pacejka and some other help this F1 car is looking, sounding and driving pretty damn nice by all accounts!

Last things to do really are just a nicer steering wheel shader and texture. Ideally I'd update the wheel model because it looks really low poly but that can come later.
For now it drives great, feels great and looks ok so why not get it out there for people to enjoy

Dave

 

[Alexander Knoll]

It's easier if you can get the files out of the AR

Some of the older cars are really nice. OK not super high quality like other modern games but they have a really nice charm and feel to them.

I remember driving that GT40 loads back when it was released. Happy days!

I look forward to the update

Dave

Hi Dave,
i know...i'm talking more about bugs and unacurate data in the car.ini...
btw...F1 looks good! Get your a... up and release him...
Alex

 

[Raphael Buthmann]

New metallic shader + New Skybox.
I miss you my friends õ/

 

[Alex Forbin]

Fantastic sky, I never released my metallic shader but yours looks very nice.
How about a picture in the bright sun?

Alex Forbin

 

[Alex Forbin]

Cosmo x 2. Buggy multi-player going on here hehe.
View attachment 59377

And then about to go for a spin with multi-player working ok!View attachment 59376

I've not much time right now but with Cosmo's great pacejka and some other help this F1 car is looking, sounding and driving pretty damn nice by all accounts!

Last things to do really are just a nicer steering wheel shader and texture. Ideally I'd update the wheel model because it looks really low poly but that can come later.
For now it drives great, feels great and looks ok so why not get it out there for people to enjoy

Dave

Hey Dave hows about sharing that track and settings, the F1 cars look really great on that concrete texture.
It would be nice to have a standard track that is more up to date than
Carlswood.

Alex Forbin

 

[Mr Whippy]

Nice screenies Raphael!

We always see games with sunny weather and things usually, so it's cool to see an overcast day that looks nice

Alex, I really do need to release it haha.

It's not finished by a long way but it's still ok for punting around and stuff.

I'll try find some time over the next 2 weeks to just do enough to make it a bit more finished and implement the latest shader stuff I've been tinkering with and then it can go out there.

Please genuinely do pester me because I do have a scatter brain when it comes to personal projects. The more you pester me the more time I'll remember that it's something worth finishing for the benefit of someone


Main problems are the latest techniques mean I spend about 1hr just making a nice working blurred TGA cube map for each TOD setting haha... and I keep adding TOD settings.
Currently got morning, evening, evening cloudy, midday sunny, midday partly cloudy, afternoon foggy with rain, night time with full moon... hehe.

Oh for proper cube-envmaps with mips in HDR... basically static $trackenvmap we have now, but just a track version in lower res... it'd make life a lot easier Ruud


Cheers

Dave

 

[Mr Whippy]

After Stereo built that PBR framework I've been using derivative shaders all over the place.

I've finally got LDR cubes to play nicely with the PBR stuff. It's still not ideal being LDR and non-mipped and static blurring, but for most track type materials it still gets about 90% of the visual quality and realism which is all that matters really.

Please forgive the weird pink on the top of the tyre wall, that is my bad over-spray from rough PS work on the textures.

So to sum up.

This is custom TOD with new sky shader and TOD inputs, with modified sky texture to get correct intensity values.
All lighting values are matched with proper PBR reference materials... basically everything matches up pretty nicely.

Then it's got a tone map to bring the colour balance back in line.

The asphalt is a PBR derivative that Stereo and I worked on on the asphalt track.

The textures on the walls and tyre wall are full PBR (albedo, spec, gloss, AO and normals)

All parts are using the same fundamental shader base. FPS seems no different here using these shaders vs the default standard_f/v types. I guess modern GPU's are just more than capable of doing the extra bit of maths PBR requires.

As you can see this material on the tyre wall is mostly all in the shade and yet it looks rich and full of texture, lighting and details.




Cam wanted to make a city track, and so did I, but neither have the time for anything huge despite having a few rough layouts of our local cities already planned, along with Exeter Roads Stereo and I began.
Nice ideas but in the end there is probably 1000hrs or even 1500hrs to make any of those fully with all the details realised just because of the sheer scale!


So we decided to do a tiny loop of Leeds city centre for Racer. It's about 500m in length. Quite a lot of buildings though but the basic ground work shouldn't take us long at all which is the main time cost.
We've already got a roughed out template in Racer to test the course feels ok to drive and to test graphics with.

It's still early days but the plan was to make everything PBR, have AO maps everywhere we could, and really bring out the nice lighting and depth of lighting that is possible with PBR and AO in these kinds of city environments where shadows and bright highlights rule.
Ideally we might have say 6 shaders for the entire city, with splitting done manually only to optimise draw count/view distance. The aim is for more FPS than any other Racer track, while also having more detail and visual quality than any other track too.

If that won't get Ruud interested in the idea of proper full PBR support and stuff I don't know what will


The aim is to get something looking as good as Grid Autosport if not better.

I think Cam is still busy adding splines everywhere, and we've probably got about 20 buildings or so roughed out too.

My next task after all the props for the track-elements are done is possibly to take a look at making a 3D spectator that can wave their hands etc



It'd be extra cool to have a streaker who would run across the track as you drove along hehe

Maybe the Tour de France is still strong in my mind after it departed here just a few weeks ago


Sorry for babbling in post yer screenies. The forums are so quiet it seems we may as well just have one thread where we're all seeing what each other are up to

Dave

 

[Alex Forbin]

It looks like all of the study on polycounts site is paying off. The pink just makes it look a little less sanitary, so it helps the realism as far as I'm concerned. PBR certainly looks like the way to go especially if a library is
available for material reference. I know Ruud was considering moving to opencl at one time, will PBR port well?
A city track is a good idea, it will certainly show off Racer at it's best and
it looks like it can be extended later.
About the lowres cubemaps, didn't Ruud give us the ability to capture envmaps from the console a while back?

Alex Forbin

 

[Mr Whippy]

PBR really is kinda extending out along the lines Ruud was going with the energy conserve stuff.

That early interpretation was only really impacting diffuse/specular though but left the ambient element the same as before... and it didn't use fresnel on reflections (specular ones), so 'realism' was still way off... but it was at least a sign Ruud was thinking along the path towards PBR eventually probably.

The framework Stereo wrote is really just an extension of what Racer currently does. It's mainly just balancing diffuse, spec, ambient and ambient spec properly within any shader. So the actual code should move around to any system you want. I can't see OpenCL would cause any issues at all.



Yep it's a small city track but scope to move out from there with different layouts. We wanted to use that approach so if things were successful we can then make it bigger. Even a small track seems like a lot of work though hehe.

It'd be ideal to have the latests DOF format with 2nd UV channel, then we could just bake a load of AO/radiosity maps like Forza 4/5 do.
A building that is about 20x texture repeat would be silly to make one huge texture just so we can do AO maps. So we may try use vert colour baking too... it might work ok.




Right now we have the $trackenvmap which is really the '$carenvmap' because it follows the car around.

This envmap can be mipped down (kinda blurred), is HDR, and is live... so it's kinda almost perfect for all the car related PBR needs!

For tracks we're then stuck with LDR TGA cube maps that can't use mips.

So I just shoot out a cube map from the track, then rebuild into a DDS cube map, then blur it up appropriately, while also adjusting the levels so the output on a test sphere closely matches the results on a sphere using the HDR live envmap alongside.

That way I can basically get everything balanced so it looks the same.

Blurring is the hardest task as the TGA are huge (512px), but they could probably be 256px for mirror type surfaces and be using a 32px mip for most blurry stuff.

It's all pretty trivial stuff to be honest... someone like Ruud would storm through this in a week or so if he had the I bet!




Hehe yep, Polycount is a good place to double check things. PBR still seems quite new and not fully understood by many so it's good to ask those who are really familiar with it what optimisations and stuff they are making.
The reference materials by Seb Lagarde for instance were a great start to get it working, but the optimisations and stuff that we read about right now from current games are well worth considering.


All exciting stuff!

Dave

 

[radome]

Please forgive, but the search tool will not search on such a small term as PBR. I know you're not referring to Pabst Blue Ribbon or Professional Bull Riding but beyond that.....

Ah... Physically Based Rendering (I searched on the Polycount wiki)

 

[Mr Whippy]

No no, I do mean professional bull riding

Yep, Polycount covers all the stuff quite well, along with the documents Seb Lagarde has posted up and around which is what Stereo and I used as a basis for everything.

I was nattering with Stereo earlier in an email and thinking that AO >> radiosity vert lighting would be nice.

0-128 doing multiplication from 0-1 on the ambient data for AO, and then 129-255 doing addition for radiosity.

With vert rgb info you could do some really nice baked lighting.

If I get chance I'll have a go one evening this week.

Better to really use light/radiosity maps but with only 1 uv channel in current DOF we're stuck.

I think Ruud mentioned he's got a new DOF format with 2nd UV working but we've yet to get that version... so for now we can just build with vert lighting and upgrade to image lighting later if we get the features.

Really excited to get some shaded areas between buildings filled with reflected light where the sun manages to streak through gaps etc! It'll look pretty nice I think

 

[Dariuszek]

Is there a possibility to make these boards on the second picture show the laptime? If so, how to do this?

 

[camsinny]

It'd be ideal to have the latests DOF format with 2nd UV channel, then we could just bake a load of AO/radiosity maps like Forza 4/5 do.
A building that is about 20x texture repeat would be silly to make one huge texture just so we can do AO maps. So we may try use vert colour baking too... it might work ok.

I'm sure we (read:stereo) could write a shader to dig a second UV set out of the vertex colour channel. Essentially they're just packing the vert colour data into a channel, I don't believe it's actually any different to a UV channel data-wise.
I could be wrong though.

Once my head is a little more settled (a few recent life changes) I should be working more and more on Leeds, as well as hopefully releasing some (very much) overdue car projects, it's been a while but this whole PBR revolution has gotten me all excited about games again.

 

[Stereo]

I could, I just didn't suggest it cause I don't know how to tell max or any other software "ok put these UV coordinates in the vertex colours on export"

 

[camsinny]

I'm pretty sure you can do it (albeit manually) through the channel info dialog.
Otherwise I think when you're unwrapping there's an option to unwrap to the vert colour channel.
This is all in Max though, not sure how to do it in other software.

 

[Mr Whippy]

Is vert colour data stored spatially though? I thought it was just a list and an rgb value.

I never knew to look of course.

The other issue I doubt is supported in Max is you'd need to split the meshes where texture boundaries would be (ala like like mesh smooth boundaries are at export to DOF), so you could let the same apparent vert share different texture coords.

In Max the vert list you see is different to the UV vert list you access for obvious reasons.


Probably best to wait for Ruud, or just do quick/dirty vert bakes for now... then when the 2nd UV stuff does arrive we can just plug another UV channel on, do a quick auto-unwrap and then use the same baking setup to bung AO/radiosity data into that LUT.

On that thought, I guess lightmaps and dynamic TOD don't mix. So you're stuck to AO only unless you want to generate light maps on the fly or other exotic things.

But for our needs we can do the AO approach, or do AO/radiosity combo, with 128rgb values being neutral?!

I'm not even sure what conventional light maps do, I assume they multiply against the ambient pass or something. Hmmmm. In the olden days of Q1 and Q2 I remember it just used a vert channel to multiply against the texture colour

Rendering the lighting took ages sometimes hehe.

Dave

 

[Stereo]

I might say use emission = light map 100% intensity, not sure what sources you plan to bake though. For streetlights, neon signs, etc. then emissive is proper, for the skybox I think it's more correct to call it an AO map and multiply that with ambient light.

So you have
sun - diffuse light + blocked by shadow map
sky - ambient light + blocked by AO map (note: could be rgb AO if you can get max to figure that out, and you want a dramatic sky colour)
scene lights - emissive light + blocked by radiosity map


The TOD curves set diffuse/ambient, the track.shd sets emissive properties, then.

 

[Mr Whippy]

Yeah I guess throwing the bounced light into emission makes sense, like a backwards AO.

But given the cost of VRAM etc, having a combined AO/emission map would be cool.

Three channels with coloured emission/AO.

I guess the dynamic range might be an issue though, especially for emission.

I'm mainly thinking situations in cities where light can pass between buildings and light an area up quite a lot despite it being quite deep shadow, and you get a lot of bounced light in these areas re-illuminating things around the light hit area.

Maybe if the area hit is say a red building, then things all around that area will be tinted red.


We have plenty of options in the end hehe... I'm excited to get to play with the 2nd UV stuff when it arrives in Racer for us!


Cheers

Dave

 

[Stereo]

Yeah, I'm just saying that way to have a solid basis - everything that's driven by (bounced) ambient light will tint to match the sky without having to bake 10 different settings. Of course the option's still open to have time-specific textures if you want to take the time.

imo if VRAM is a problem, halving texture resolution of separate ao+illumination maps (which ends up 1/4 as large each so 1/2 the texture space vs. just removing one of them) is better than having them in one compromise texture. But I don't know how many textures you have planned for the whole track.

You mentioned that 'local AO' crease texture - I think that's more likely to suffer from being half-resolution than a regular AO map (the only time AO looks bad is if it's so low-res that the unwrap is blurred over neighboring islands of UV)



Spintires focuses a lot on nighttime lighting and has an interesting strategy - there's a couple textures set to global coordinates, one color and one normals, that says what direction the light hits the ground plane and how bright it is. It's obviously only an approximation of how light would hit objects in motion (ie. vehicles) since it's 2d, but it looks good for only needing an extra low res texture over the whole map. I didn't really follow how they use it to cast shadows or if that's just done based on 'hero' light sources getting shadowmaps.

I don't think Racer can use it as-is because car and track textures are loaded separately, but it's an interesting idea... eg. replace a fixed ambient with a texture lookup based on the car's current coordinates.