[caldrail]

Open Rails for me is a frustrating experience. It's clearly got great potential but there's always niggling bugs, mainly graphical.

Perhaps my graphic drivers aren't the worlds greatest, but nonetheless these maybe bugs are still persistent...

1 - Transfers are darkened compared to MSTS
2 - A few shapes do not display textures. I can't see any reason for this - the texture files are no different to others in format, but seeing off-white rectangles instead of foliage by the trackside is annoying (specifically the RF trackside vegetation suffers from this.
3 - Black mip mapping. Some textures also bleed black in the distance. the MM vegetation grasses suffer from this. Again tere's no obvious reason why these textures behave like that.

[James Ross]

Firstly, sorry you're seeing issues. Would it be possible to provide screenshots highlighting them? If you could grab the same picture in both MSTS and OR that would be fantastic. That said, here are some thoughts...

 caldrail, on 03 September 2014 - 04:27 AM, said:

1 - Transfers are darkened compared to MSTS

Quite possibly an OR bug. We have reverse-engineered the whole graphical display so things often don't match up quite right. If things are only slightly off, we might not worry too much, but if it is a glaring difference we'd like to know more (route, location, screenshots, etc.) so it can be fixed.

 caldrail, on 03 September 2014 - 04:27 AM, said:

2 - A few shapes do not display textures. I can't see any reason for this - the texture files are no different to others in format, but seeing off-white rectangles instead of foliage by the trackside is annoying (specifically the RF trackside vegetation suffers from this.

Could be a number of things - low virtual address space, weird texture formats and odd data in the shape. Most of the possible problems will produce a warning in the Open Rails log (on your desktop) so if you could reproduce this issue and then attach the log, it might help us identify what's breaking.

 caldrail, on 03 September 2014 - 04:27 AM, said:

3 - Black mip mapping. Some textures also bleed black in the distance. the MM vegetation grasses suffer from this. Again tere's no obvious reason why these textures behave like that.

The mipmap textures come from the ACE file, if it provides them; otherwise they're generated by the graphics drivers. There shouldn't be any weirdness here, but we don't support the mipmap bias setting in shape files which might be being used to 'fix' things in MSTS. Similar to the other issues, if you could provide pictures and/or directions to download a route with this problem we can investigate.

[engmod]

Could you post your computer specs please.

cheers

[Genma Saotome]

 James Ross, on 03 September 2014 - 06:38 AM, said:

The mipmap textures come from the ACE file, if it provides them; otherwise they're generated by the graphics drivers. There shouldn't be any weirdness here, but we don't support the mipmap bias setting in shape files which might be being used to 'fix' things in MSTS. Similar to the other issues, if you could provide pictures and/or directions to download a route with this problem we can investigate.

I'll guess this is highly likely to be the texture (but of course showing us the image will settle the issue right away).

A whole lot of textures for vegetation are exported with a black background. You'd think with a 1 bit maek that the background would also be masked away but that is not what happens with mip mapping. Mip Mapping is going to grab whatever pixels there are when it kicks in and that includes anything from the background that's behind the mask.

IMO the correct thing to do in such circumstances is to use 3 layers in the art. There is the art for your object on one layer. Set up a second layer in one just color that will be totally unlike anything in your art (I use red). That allows you to select just that color and create the 1 bit mask. A third layer is painted to a reasonable match of the foreground object image (e.g., green where the leaves are, brown/gray/black where the trunk is). When you export you send layers 1 and 3 to the file -- the object image layer and the similar background layer. The mask you created on layer 2 should export automatically. Make the .ace as you would normally. When the mip mapping kicks in the extra pixels will be reasonably similar to the object pixels allowing the colors to stay the same as one would expect.

IMO the reason this appears to be an OR problem is the clarity of OR allows you to see things that were probably too blurry to notice in MSTS.

[caldrail]

I'll see to some of these requests shortly.

However, the issue of black mip mapping. This is something I encountered early on in MSTS, but solved by avoiding black surround in the texture, so that the dilated masking in mips wasn't going to pick up glaring colour differences. However, that tactic doesn't seem to work 100% in OR.

[eric from trainsim]

Sounds like what's happening on the mip mapping issue is that

1) MSTS was flawed
2) Someone came up with a workaround that many people adopted
3) ORTS isn't replicating the flaw from MSTS
4) Everyone now things the problems caused by the workaround are a bug

[Hack]

 caldrail, on 05 September 2014 - 05:13 AM, said:

However, the issue of black mip mapping. This is something I encountered early on in MSTS, but solved by avoiding black surround in the texture, so that the dilated masking in mips wasn't going to pick up glaring colour differences. However, that tactic doesn't seem to work 100% in OR.

The effect (MSTS and OR) is most prevalent with textures containing alpha that have DXT-1 compression. The compression eliminates areas where a solid black mask meets a section of the texture. As the texture mips, the contrast between texture and black become blurred to the point that a "black edge" will appear at distance. To reduce the effect, do not use DXT compression on alpha textures, leave plenty of space between contrasting colors on the texture, and do not map to the absolute edges of contrasting colors.

[disc]

 Hack, on 05 September 2014 - 04:54 PM, said:

To reduce the effect, do not use DXT compression on alpha textures, leave plenty of space between contrasting colors on the texture, and do not map to the absolute edges of contrasting colors.

DON'T!
MSTS already has a lot of unoptimized resource wasting assets, and uncompressed textures are memory hogs... When using OR, it's better to just use DXT3 or DXT5 compressed DDS files in such situations.

[Hack]

 disc, on 06 September 2014 - 02:41 AM, said:

MSTS already has a lot of unoptimized resource wasting assets, and uncompressed textures are memory hogs... When using OR, it's better to just use DXT3 or DXT5 compressed DDS files in such situations.

I meant for texture containing alpha or those of high contrast, not for all textures. Besides, MSTS doesn't support DDS (note the "and" between MSTS/OR above). The benefits of a few k of memory are outweighed by the benefits of a cleaner scene. As I said, not all textures need to be uncompressed, just those that would be otherwise problematic. Also note that since DXT is lossy, and depending on which is used, that some degradation (or a lot) will always be present. For items very close to or always in your face, such as track or locomotives, one should be mindful how a compressed texture looks up close. Freight cars, buildings and other items further from view will obviously benefit from compression for a more efficient scene, however.

[disc]

 Hack, on 06 September 2014 - 08:31 AM, said:

I meant for texture containing alpha or those of high contrast, not for all textures. Besides, MSTS doesn't support DDS (note the "and" between MSTS/OR above). The benefits of a few k of memory are outweighed by the benefits of a cleaner scene. As I said, not all textures need to be uncompressed, just those that would be otherwise problematic. Also note that since DXT is lossy, and depending on which is used, that some degradation (or a lot) will always be present. For items very close to or always in your face, such as track or locomotives, one should be mindful how a compressed texture looks up close. Freight cars, buildings and other items further from view will obviously benefit from compression for a more efficient scene, however.

I didn't said either that i mean all textures. None of the textures should be uncompressed. There is a real rarity in current games that have even a few uncompressed textures, the 99.99% of the textures of the best looking games are DXT compressed.
I see too many of "exeptions" in MSTS contents. A compressed texture means 1/4 or 1/2 size in memory, which is a lot especially in MSTS contents where the 1bit transparency is overused because of the low polygon misinformations. DXT compression makes barely cause visible loss in quality if photo textures used, however it depends which tool is used for compression.
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. MSTS can still read the old ace.
See some rolling stock for TS2014, do those look bad? I don't think so, but every texture there is compressed.