[disc]

And what are you thinking (to code)? An on the fly method, or an app that modifies the s files, and combines the textures, and saves them to files? It isn't looks to be impossible, just need to open the s files (already done in or), collect the textures, finds the best layout to combine the textures, then merge the textures, and move the UV coordinates to the new layout, and save, aiming for 1 texture on 1 shape goal. And an exclude list could be used to tell the application which shapes are don't need optimization (because of repeating textures, and outside of 0-1 uv)... however the outside of 0-1 uv can be detected by reading the shape file.
Multiple objects with many textures to one texture would be more tricky. As in msts content the shape files are not separated by theme, or type, it's hard to tell which of the shapes are appear on same tile, and which aren't... maybe by analyzing the tiles on the route and group the shapes and textures according to that data.

[James Ross]

It would depend how fast the optimisation process is, probably.

If it's only a little bit slow, we could have an option to use it automatically when loading data, and it could save the optimised version in to a temporary cache folder (obviously we're not going to modify the original). Next time OR came to load the same shape, it'd spot the cached optimised version and go directly to that.

If it's too slow for that, it would have to be a separate process (that you could run from the menu, I'd expect) which would simply scan every shape and optimise them all (also using a temporary cache folder). This approach would also allow it to do slower, better job by e.g. figuring out how frequently an object is used, or how far from the tracks it is, etc.

[Lindsayts]

Genma Saotome, on 19 August 2014 - 05:29 PM, said:

Here's one more thought: Each tile has 64 patches (subtiles). Last time I asked I was told each patch gets its own draw call. I dunno why that is given a whole lot of tiles out there are covered by just one tertex file. Seems to me in those cases that's 63 too many draw calls per tile and now that we can see far more tiles than in the past I figure if this condition is still true today there is more performance waste accumulated in rendering terrain than most models.

One method of doing detail over ones whole terrain is to have the general terrain texture as a fairly low res image, with the colours defining different terrain types (sand, grass, rock etc). One then uses a map file that specifies the different terrain types around the tile. One then has standard single colour high detail textures of all these differing terrain types. When the terrain is displayed these high detail textures are layered on the fly with the main tiles texture to generate the final tiles texture that is displayed.

This method produces fairly good looking terrain that does not require massive tile texture files. This of course increases the number of draw commands to do the terrain but it does save on the load times for all those large high detail terrain tile textures.

Just in case.......... the slight vagueness in the terms is due to the fact my 3D programming is done on Linux using the Mesa (opengl) tool kit. This uses different terms than is used in OR programming.

Lindsay

[disc]

Do OR currently support draw call batching (draw multiple objects that share the same texture and material by one call), or just instancing?

[James Ross]

disc, on 28 August 2014 - 09:34 AM, said:

Do OR currently support draw call batching (draw multiple objects that share the same texture and material by one call), or just instancing?

There's no support in XNA 3.1 for true batching AFAIK, where we would make 1 call to draw N different primitives each with different vertex buffers, etc., but we do batch shader changes in code (so each material is only set up once/frame).