New: Parse MSTS shape format

[leezer3]

This adds a parser for the MSTS shape format in both binary and textual flavours.

Issues:

• Animations are not supported full-stop. (Quaternions / keyframe animations not currently available)
• ACE uses alpha channel transparencies. For these to work correctly, the transparency mode must be set to smooth.
• Shaders, lighting, luminosity etc. not supported.
• Route Viewer not supported, as it doesn't use the texture loader plugins.
• Error checking is rudimentary....
• ???

[leezer3]

Colored vertices probably require this PR:
#219

[leezer3]

This commit now loads most basic objects, in both binary and textual format.

See the first comment for the current issues.

[leezer3]

May also finally have a decent use for #59
Still none the wiser as to whether the code in question is covered by the original licence.
Maybe implement a non-free plugin pull after initial download? (DDS is marginally non-free in this regard, but note that the code in question appears in plenty of GPL projects....)

[leezer3]

Default MSTS Dash-9 model.

NB:
The handrail color and the white thingy on top of the engine are not bugs from this PR.
No idea where they've come from, but Shape Viewer shows them too....

[cwfitzgerald]

Wow! That's great progress! It brings back many memories.

[leezer3]

Interesting little glitch on texture loading:
Having both a daytime and nighttime texture set causes 1-bit alpha channel textures to loose the alpha, but only in objects loaded from this PR.

Must be doing something funny with the trilists somehow, although I can't see a culprit off the top of my head.
For the moment, have just nerfed the nighttime texture (MSTS does this with luminance etc. anyway), but may need to revisit this one if it's something fundamental in the blending somewhere.

[leezer3]

Cross-merged the vertex colors branch into this one.

Will try and get vertex colors for shape files implemented tomorrow, and take a better look at the broken hierarchy issues.

[leezer3]

That's better, this was a total mangled mess before (Default MSTS Class 50)!

[leezer3]

Linking back to another unfinished WIP from last year:
#167

I think we probably need to move the file reader to a separate assembly and cross-port this into that PR. File reader is now found under Data\Formats\Formats.Msts.dll
When that is OK (ish), the aim is to then parse the ENG files etc.
Looking into a basic (diesel) ENG file, all it really seems to have in the way of power variables is a simple percentage of max power per notch.

I think though, merge this PR first after the aforementioned file reader move (Ignore the animation issues???), and then work on the related stuff, else nothing will ever get done, as we're back to waiting for one or another feature to finish.....

[leezer3]

I think this might actually be mergable now.
Vertex colors aren't actually being used at the minute, but I want that option there for the future, and it saves a lot of merge fixing later on.

Waiting on the CI results, and will do a final lint pass tonight.

[OpenBveTrainSim]

Leezer,
The GE Dash9 handrail color is white near the steps, required by AAR\FRA for all locos.
The "white thingy" over the engine appears as the GE standard exhaust; it wouldn't stay white for long!
The "white thingy" over the cab is an escape hatch, required by AAR\FRA, or possibly a comms anntenna.

Good work enabling a huge MSTS legacy library for OpenBve!
OBTS

[leezer3]

That's interesting :)

That's the thing with lower-quality models sometimes though- When you don't know the prototype, you can never be quite sure if it's a glitch with your model loading.

[OpenBveTrainSim]

Leezer,
Using your program build of yesterday 18th of May & attempting to use a freeware locomotive *.S file binary object as the exterior for an existing legacy BVE train that previously had only a cab:
I've found that *.S objects are not YET as flexible in use as BVE native *.CSV or *.B3D objects.
For example, in *.Animated files, where multiple objects are often assembled to build a railcar,
the *.CSV, *.B3D, and *.Animated subassemblies can be referenced as noted below,
*.S objects can not be used in this manner and must be referenced via [Include] which limits functionality:

[Object]
State=Car0_HeadLamps.Animated
Position=0.000, +2.000, +9.100
[Object]
State=Car0_Shell.B3D
Position=0.000, 0.000, -1.500
RotateYFunction=3.142

Also, found that the ObjectViewer F7 menu is yet lacking *.S objects in its file type listing,
thus forcing the need to open ALL FILES to get an *.S object to load.
Thank you
OBTS

[leezer3]

That's expected.

Internally, a MSTS shape is (essentially anyways) an animated file, as it's got the ability to apply a quaternion matrix animation to any sub-object. I've set this up so that when the actual animation function is implemented, it works as expected. Anything else would basically require re-writing the entire parser twice.

Have fixed the Object Viewer issue though.

[OpenBveTrainSim]

Leezer:
Ok, thanks for the ObjectViewer fix.
Disappointed on not being able to use *.S objects under [OBJECT] in *.Animated files.
I was hoping to replace\supplement non~animated items (bogies, headlamps, etc) inherent to legacy *.S binary files with *.Animated subassemblies in openBVE.
Oh well, life is full of disappointments; I'll wait for what you come with on using MSTS native animation.
Thanks again.
OBTS