[Hack]

 disc, on 06 September 2014 - 09:21 AM, said:

Since the topic is about problem with textures in OR, and as or supports DDS too, so the fix is to use dds texture with dxt3 or dxt5.

The OP was making a comparison between his experiences with MSTS vs OR, thus my reasoning for mentioning both in my post.

 disc, on 06 September 2014 - 09:21 AM, said:

See some rolling stock for TS2014, do those look bad? I don't think so, but every texture there is compressed.

Not true, as not all textures will benefit from, or can even use compression (glass, normal maps, etc.). Besides, the backend of Railworks is different than that of MSTS or OR and therefore off-topic. However, regardless of the game platform used, it's all a matter of budgeting an efficient model and knowing when to use (or not use) compression to achieve the desired results.

[Eldorado.Railroad]

 From 06 September 2014 - 09:43 AM:

The OP was making a comparison between his experiences with MSTS vs OR, thus my reasoning for mentioning both in my post.


Not true, as not all textures will benefit from, or can even use compression (glass, normal maps, etc.). Besides, the backend of Railworks is different than that of MSTS or OR and therefore off-topic. However, regardless of the game platform used, it's all a matter of budgeting an efficient model and knowing when to use (or not use) compression to achieve the desired results.

+1 on that!

[Genma Saotome]

I think this is a DXT-1 issue rather than compression in general. IIRC DXT-1 and multi-bit alpha are indeed a bad combination... very lossy. But other versions of DXT compression, esp when paired with .dds are, I beleive, nowhere near as lossy and in many situations would probably do well enough.

When I have a texture that has a small portion of an alpha I almost always try to find a way to put it off on it's own. It's going to use its own draw call anyway so I see no need to keep it with the other colors and use just one texture.

[caldrail]

Quote

A compressed texture means 1/4 or 1/2 size in memory

No it doesn't. A compressed texture is smaller in storage only. For the graphics card to use it the system must uncompress it on loading to display the pixels, therefore in memory the size is exactly the same.

[James Ross]

 caldrail, on 12 September 2014 - 03:17 AM, said:

A compressed texture is smaller in storage only. For the graphics card to use it the system must uncompress it on loading to display the pixels, therefore in memory the size is exactly the same.

Not true; DXT compression is directly supported by the GPUs and is never completely uncompressed - the GPU calculates the individual samples straight from the compressed data when it needs them during rendering (with a very small buffer of uncompressed values for performance, IIRC). They certainly do not use the uncompressed amount of GPU RAM.

[disc]

 caldrail, on 12 September 2014 - 03:17 AM, said:

No it doesn't. A compressed texture is smaller in storage only. For the graphics card to use it the system must uncompress it on loading to display the pixels, therefore in memory the size is exactly the same.

Only those that are not compressed wth DXT. As DXT is supported by hardware, don't need to be uncompressed, and it's supported by all GPU-s since early 2000s.

 Hack, on 06 September 2014 - 09:43 AM, said:

Not true, as not all textures will benefit from, or can even use compression (glass, normal maps, etc.). Besides, the backend of Railworks is different than that of MSTS or OR and therefore off-topic. However, regardless of the game platform used, it's all a matter of budgeting an efficient model and knowing when to use (or not use) compression to achieve the desired results.

Normal maps are usually very small (if used correctly) (however there is also normal map compression supported by directx10(?)+ hardware called 3Dc based on DXT5 but avoids the normal map artifacts created by the original compression).
For glass, in the beginning i used no compression in railworks/TS2014 as the tutorials said so, but then i tried the compression, and saw no difference, nor with trainglass.fx or TrainWeatherGlass.fx.

[caldrail]

Sorry this comparison is a bit late (RYI and so on...)

http://s30.postimg.org/r55aw6svl/Mip_Comparison.jpg

The left side shows foliage fading to green, as intended. The right shows foliage fading to carbonised black. It looks pretty awful :D

[James Ross]

 caldrail, on 15 September 2014 - 04:23 AM, said:

Sorry this comparison is a bit late (RYI and so on...)

http://s30.postimg.org/r55aw6svl/Mip_Comparison.jpg

The left side shows foliage fading to green, as intended. The right shows foliage fading to carbonised black. It looks pretty awful :D

Is there an example I could load up on my machine, either an in-box or freely available route & location? I have at least one change locally which might help this but either way I need to run it in the game to debug the colour.

[disc]

Isn't this caused by the instancing shading problem that is fixed already yesterday?