Released SchottenRing_67, GTL Conversion...

As for the atlas UV'ing part itself, hmmm. I use 3DS Max 2010 here but I know 2011/2012 came with some better UV tools for this exact kind of job... so even for me it's harder work than otherwise.

I know in games like PGR2 for example, they just made everything like we would usually, with small textures and many small items and stuff, and then a big program would optimise/batch/atlas everything and adjust UVs as appropriate.

We don't have that luxury, but in practice it could be an automated process. Even tiled textures can be atlased because our scripts can chop in edges to give UVs something to 'adhere' to as it were.
Got me wondering how hard that kind of thing is actually. If not for texture tiling, it would be a pretty easy task to take merged objects (split based on location in the track) and compile a list of the materials+textures each one uses. Then you'd figure out a set of atlases that hits some compromise between # of texture atlases and # of materials per dof, assign the textures to locations in the atlases, and rewrite UV coordinates into the texture atlases, while merging materials. Cleaning up the edges so that mipmaps don't go bad would be another concern, either atlas similar textures (trees aren't a problem cause the edges are transparent) or inset each texture with some tiled repetition (like make the actual texture space 200x200, plus repeated around the borders) if necessary.

The trees, vehicles, etc. on this track are prob. an easy candidate for this kind of thing, since they don't use tiled textures. Could, in a first iteration, just check that the UV coordinates start on [0,1] for all polies using a particular material before allowing it to be put in an atlas.

It does add a kink having to manage different materials since that information needs to be fed in somehow. I suppose the dofs could be split to use a single shader in the first place (all solid matte, all specular, all transparencies, all decals, etc.) which from the sounds of it is not much of a performance hit compared to a single dof with multiple materials.


Before tackling the problem of cutting up too-large polygons so that tiled textures can be atlased I'd like to see more evidence that there's a meaningful performance advantage to be gained there. To some extent (maybe up to 2-3x the original texture's size) it might even make sense to, say you have a 256x256 original texture, tile that in the atlas so you have a 512x512 or larger area to work with, and map UV coordinates into that space instead of a single tile. Or if it's something like a road/sidewalk that only tiles in one axis, just run it as an entire row of the texture atlas. As long as you reassigned UV carefully, you could even use the extra space to add variation in the texture.
 
Well however you like to work is the best way to go.

For example, I see no reason why an entire track couldn't be just 1.dof 2.dof 3.dof where a whole 250m block is one massive DOF with all the materials/shaders in it.

There would be no difference vs having all those dof split up into each material for each 250m block.

Downsides might be that you can't LOD out small stuff within that 250m, say things that can be turned off at 100m.


But yes you are right, technically we may as well merge ALL alike shaders into one mega mesh, and then split it at the required intervals (manually possibly better in some places), then at the appropriate places you can split and apply a specific LOD to turn off items that won't be seen.
Say on Spa where we drive down and do an almost 180deg turn right in the middle of complex buildings. We can save loading a load of mesh data there for it to just be culled when rendering any way, by splitting appropriately and adding LOD flags to make things work optimally.


But even that might not work intuitively all the time for whatever reason, so you might have dof with many sub-materials all in one DOF and LOD'd at a certain distance, and then have another model of that thing (say the big grandstand/pit building) and then make an LOD version of it for viewing from the rest of the track. Trim out all the fancy details, bump maps, and just have a few lighter shaders that are used 90% of the time, with only the high detail one as you drive past it.


The reality is you just use a combo of techniques to get the best end result.


I'm close to release of a track I've been working on a while where the atlas is just a mixture of tiles that merge together to make a nice random but high-res surface to drive on, and the track surface is cut up into 6mx6m chunks so each part can have unique UV coords... so using that exact method you describe in the last part of your post. (4x4 = 16 texture pieces, on one 2048x2048 tile, so each 6m x 6m gets a 512x512px texture, or about 1cm per 1 pixel... but when you are driving on the large area it remains MUCH more random (well it is totally random) than a repeated 2048x2048 texture!

Obviously the polygon count is higher, but 6mx6m grid is still not that many polygons and you need some polygons for bumps/lumps any way.


Totally agree on the stacked textures for roads. An 8192x1024 texture would offer 8 sets of 1024x1024 AND you could repeat tile them without any problems... with 8 variations you could probably get something that felt almost entirely random when driving along.

I'm not sure how efficient that is though. I'm still wondering if these days we are better using a globally tiled texture of higher resolution for roads, so just planar map over the whole area, and then detail the road with decals.
Since we might want white lines, yellow lines, bumps, cracks, patches, and some of those we might want to be skiddy, bumpier, marbles on the outside of race tracks, who knows, we can also give those separate 'decal' sets different material definitions.


I'm still not sure how I'd do a road yet but I like decals right now... hitting those middle painted lines in the wet when braking is dangerous, while in most games it's one homogeneous surface. In Racer we can make that surface have a bump and lower grip etc... but we need to use the decal approach :D


There is no right or wrong way really, just different ways.
 
Hey Dave,
i understand every thing you wrote about uv mapping and remapping...thats not the problem....
My problem starts at the moment i assign the new texture to the face or object...at this second the selectet face / object disapear in the window and i can't see where i "move" the new texture....to fit it to the right place...
Sry..can't explain it better...


Hmmm, I'm not sure then with Zmodeller. I'm a novice in Zmodeller :D

Have you asked on the forums?

Might be worth looking into Blender, or 'get' 3DS Max somehow. I can guarantee it'll make life much easier when dealing with big things like tracks vs Zmodeller :D


Thanks

Dave
 
Hmmm, I'm not sure then with Zmodeller. I'm a novice in Zmodeller :D

Have you asked on the forums?

Might be worth looking into Blender, or 'get' 3DS Max somehow. I can guarantee it'll make life much easier when dealing with big things like tracks vs Zmodeller :D


Thanks

Dave
...no i've not asked anyone...maybe i should do it...;)
i was sure it's some thing with the "fog" function and i already raised it to the max....but...

I already tried blender, albatross 3d and some other i can't remember, but i can't get them handled...i have for zmod a german language file and most others are in english...there start my main problems with other prog's...
 
I'm running 964 Zmodeller 2 here, I might have a play and see if I can make my version break in this way too.

Some time next week though, busy finishing up a video these next few days!


Cheers

Dave
 
Thx Alex !

Kind of sad having most of shaders simple (1 layer), it could look a lot better I suppose, but I wouldn't love to touch the shader file too much, it hurts my mind...

I have kind of low fps ~ 17 fps...with 0.8.38 & my ATI HD 4670 1GB & with a 80K HQ car models...
 

Latest News

Are you buying car setups?

  • Yes

  • No


Results are only viewable after voting.
Back
Top