[Goku]

Eldorado.Railroad, on 09 April 2017 - 08:15 AM, said:

I have wished for OpenRails to have its own shapeviewer, that understands, non square textures, DDS textures, etc. Other things like random consist creation are also very handy to have.

Do you know about TSRE?

[Genma Saotome]

James Ross, on 11 April 2017 - 09:42 AM, said:

Thanks, that does make things very clear.

It's a logical model, not aphysical model.

Physically you could combine most of those entities if you wanted to. Logically presented tells you about the data in its native state.

As an example of how many degrees of freedom you have from this model, you mentioned the physical model entity was the .eng file... yes, but in my mind this .eng is about 16 lines long. The other 400-600 lines are found in the parameter files -- the .inc files, because that way you write them just once and reference them by writing Include(foo) in about 9-10 of those .eng file lines. Or, as perhaps you were thinking, they're all in one file, just like KUJU's .eng. For myself, it's a no-brainer to use the .inc files because they make updating your fleet with any new knowledge a trivial step -- you change a line or two in an .inc file and you are done. None of this tracking down those two lines in 839 different files in 467 folders -- the way it is done with the Kuju design.

The second question you had was which entity would be referenced by the Activity files... yes, it would be right to aim that read statement at the skin file. That's the file that is 1:1 to a single unit of rolling stock. And yeah, it really coul dbe just a few lines, pretty much a list of "Mesh ABC, texture 1, is replaced by texture B" statements. The first half is necessary because most mesh files will have texture files listed and since in this logical model a rolling stock unit can be made up from multiple meshes you would have to protect against the odd chance two different meshes use the same texture name... where there really are two different textures out there somewhere.

Last question, yes, your understanding is correct. The archive for those skin files (perhaps texture assignment file is a better name), when distributed, do not need to include the actual mesh files, so long as the mesh package is available elsewhere. Of course both types of data could be included as a courtesy but that wouldn't occur with payware and for freeware it would raise the question of whether the mesh related files were really the same as what you already have in hand. On that matter James I have to say the experience of writing a whole lot of Include() statements has shown me how great a percentage of identical values are present across our hundred (or thousands) of .eng and .wag files. Once you start using standard values from .inc files the willingness to accept yet another traditional Kuju .eng or .wag intended for a mesh you have in hand is HUGELY reduced. What the logical model suggests is you download one zip for all of the mesh related files -- as defined by its creator and/or updated by yourself after installation, and separately download n number of skin files that point to that extant mesh definition.

[James Ross]

Genma Saotome, on 11 April 2017 - 01:56 PM, said:

As an example of how many degrees of freedom you have from this model, you mentioned the physical model entity was the .eng file... yes, but in my mind this .eng is about 16 lines long. The other 400-600 lines are found in the parameter files -- the .inc files, because that way you write them just once and reference them by writing Include(foo) in about 9-10 of those .eng file lines. Or, as perhaps you were thinking, they're all in one file, just like KUJU's .eng. For myself, it's a no-brainer to use the .inc files because they make updating your fleet with any new knowledge a trivial step -- you change a line or two in an .inc file and you are done. None of this tracking down those two lines in 839 different files in 467 folders -- the way it is done with the Kuju design.

I was thinking very much of your short (~10 line) .eng with everything else in include files - this certainly seems like the way forward, whether through us explicitly separating items (e.g. forcing coupling to be a separate file) or simply by allowing and recommending an include mechanism. I'm leaning towards the latter.

Genma Saotome, on 11 April 2017 - 01:56 PM, said:

The first half is necessary because most mesh files will have texture files listed and since in this logical model a rolling stock unit can be made up from multiple meshes you would have to protect against the odd chance two different meshes use the same texture name... where there really are two different textures out there somewhere.

Good point, we should design for multiple meshes from the start. :)

Genma Saotome, on 11 April 2017 - 01:56 PM, said:

What the logical model suggests is you download one zip for all of the mesh related files -- as defined by its creator and/or updated by yourself after installation, and separately download n number of skin files that point to that extant mesh definition.

Yeah, that seems about right. I wouldn't be surprised if many mesh packages had a single skin with them, as you would have to have made the model with some kind of textures to get UV coordinates and texture assignments/materials right, but it wouldn't be required.

Actually, I wonder if it makes sense to have the material properties (optionally) defined in the skin too? E.g. reflectiveness, etc.

[Genma Saotome]

James Ross, on 19 April 2017 - 12:14 PM, said:

Actually, I wonder if it makes sense to have the material properties (optionally) defined in the skin too? E.g. reflectiveness, etc.

I proposed that some years ago. Using the skin file idea probably would be one of the easier ways to implement it.

[roeter]

Hello all,

there's something I have had in mind for a long time that may not be relevant for a consist editor, but I think it is relevant for the data model.
What I would like to do is to enable a single model (engine, coach etc.) to have a set of alternatives for one or more textures, with the active selection defined per train as defined in a timetable. The usage would be to change destination boards, headcodes and such as applicable for that particular working. It could also be used to set appropriate USA-style 'flags' on an engine, again as appropriate for that working.
One rather important consequence of such an option would be that multiple instances of the same model which are visible at the same time, could be using different textures and therefor are no longer exact 'clones' as they are now.
Admittedly I'm not very good with data models, and I do not have the time to sort things out right now, but if this model is going to be the 'base' of how to handle models and textures, perhaps this idea can be worked into this model such that it can be taken into account right from the start rather that having to redefine things later on.

Regards,
Rob Roeterdink

[Genma Saotome]

Rob, a questions: My interpretation of your post is you are asking for skins to be, at a minimum, assigned by what we now refer to as the consist file... or perhaps by the consist file and timetable specification combination thereby allowing the same consist to vary its appearance by virtue of where the instances appear in the timetable. Is that about right? If yes, which of the two is what you want.


Am I also correct in guessing this is intended to address appearance matters when a fixed consist of passenger cars reaches one destination and then heads off in another direction, perhaps the reverse direction, now identified as a different train which requires different skins for identification?

[roeter]

Genma Saotome, on 21 April 2017 - 09:06 AM, said:

Rob, a questions: My interpretation of your post is you are asking for skins to be, at a minimum, assigned by what we now refer to as the consist file... or perhaps by the consist file and timetable specification combination thereby allowing the same consist to vary its appearance by virtue of where the instances appear in the timetable. Is that about right? If yes, which of the two is what you want.

The latter - consist and definition in timetable would define the actual set of textures which is to be used.
Default textures would be defined which are to be used in case no specific set is required.

Quote

Am I also correct in guessing this is intended to address appearance matters when a fixed consist of passenger cars reaches one destination and then heads off in another direction, perhaps the reverse direction, now identified as a different train which requires different skins for identification?

Yes, that's exactly what I had in mind.
For modern trains with computer-controlled destination blinds this is ofcourse exactly as it happens in real life.
As for older days - well, I think it's a little too much to assume that we will be able to simulate that someone actually comes along and turns over all the boards to show the new destination .... :D
But at least, if you meet the train somewhere along the way it will show the correct destination.

This is mainly a timetable issue as trains in timetables do indeed form into the reverse (or indeed a completely different) working. Such things generally do not happen in activities - for activities it would be sufficient if such details just could be defined in the consist.

By the way - a bit of a complication which just comes to mind is how to handle portioned trains. In such cases, different parts of the train would obviously show different destinations, even if they are the same (type of) coaches.
Hmm, this is actually more complicated than I thought. Will need to do a lot more thinking on this.

Regards,
Rob Roeterdink

[James Ross]

roeter, on 21 April 2017 - 02:51 AM, said:

there's something I have had in mind for a long time that may not be relevant for a consist editor, but I think it is relevant for the data model.
What I would like to do is to enable a single model (engine, coach etc.) to have a set of alternatives for one or more textures, with the active selection defined per train as defined in a timetable. The usage would be to change destination boards, headcodes and such as applicable for that particular working. It could also be used to set appropriate USA-style 'flags' on an engine, again as appropriate for that working.
One rather important consequence of such an option would be that multiple instances of the same model which are visible at the same time, could be using different textures and therefor are no longer exact 'clones' as they are now.

Interesting! I don't think it's clearly supported in the data model as it stands, but I can see a way to do it:

• Each skin file specifies texture overrides but doesn't need to specify all of them, as they'll all have defaults in the mesh file (all per data model)
  
• The consist file can include a list of skin files for each car
  
• The skins must all point to the same mesh
  
• Each skin file will override earlier skin files

Now what you'd need is:

• The model set up such that each "changeable" component is assigned a separate texture (*)
  
• Skin files for each component's possible state (e.g. one for each destination, one for each headcode, etc.)
  
• Consist files for each combination of cars and skins that is needed

(*) We probably want to look at this more generally, and see if we can come up with a good way to have different bits of a mesh share a texture but still be replaceable separately.

[James Ross]

roeter, on 21 April 2017 - 09:41 AM, said:

This is mainly a timetable issue as trains in timetables do indeed form into the reverse (or indeed a completely different) working. Such things generally do not happen in activities - for activities it would be sufficient if such details just could be defined in the consist.

By the way - a bit of a complication which just comes to mind is how to handle portioned trains. In such cases, different parts of the train would obviously show different destinations, even if they are the same (type of) coaches.
Hmm, this is actually more complicated than I thought. Will need to do a lot more thinking on this.

If we can live with the consist file approach I mentioned above, I believe you just need the following functionality (which I have a feeling already exists in timetables):

• A single train formed from multiple consist files
  
• A train split operation which can specify another train in the timetable (with its own consist list) as each part of the split

You then define Train A to be Consist 1 + Consist 2, Train B to be Consist 1, Train C to be Consist 2, and Train A splits into Train B and Train C. It might also be possible with only two trains, if the split allows one potion to continue as the same train.

What I am unsure about here is whether the combinations for consists will be a problem or not; you will not need more consist files than today for the same results, but you'll probably want more as there's much more flexibility available.

[Genma Saotome]

I agree w/ James. It's not a hard problem to solve but the proper solution will require changes in many places.