[jonas]

Hi,

Does anyone know exactly which sub_object of an s-file is addressed by the line ESD_SubObj ( ) in the sd-file?
It says here that it is the first sub_object of an s-file. But in the MSTS s-file "US2lamp1.s", for example, it is the second sub_object, which is then "switched on" at night.
Does "sub-object" even mean a sub_object entry in the s-files?

Greetings
Jonas


EDIT, Dec. 29, 2023: My last findings to the above questions are here.

[Jovet]

jonas, on 19 December 2023 - 11:01 AM, said:

Does anyone know exactly which sub_object of an s-file is addressed by the line ESD_SubObj ( ) in the sd-file?
It says here that it is the first sub_object of an s-file. But in the MSTS s-file "US2lamp1.s", for example, it is the second sub_object, which is then "switched on" at night.
Does "sub-object" even mean a sub_object entry in the s-files?

Hi Jonas,
It's definitely only the first sub-object. Additional sub-objects are not affected. The US2lamp1.s file only has one sub-object, named LIGHTPOOL. (The part name shouldn't matter, though.)
https://msts.jovet.net/files/images/US2LampHierarchy1.png

I just tested a shape with multiple sub-objects (e.g. the bright icon in the hierarchy list) and only the first one is affected, both in MSTS and Open Rails.

[jonas]

Ok, thanks for the answer.
So sub-objects mean the first matrix that is subordinate to the root matrix?
And sub-objects does not mean the (first) so called "sub_object" listed in the shape files?

...

				distance_level (
					distance_level_header (
						dlevel_selection ( 1500 )
						hierarchy ( 2 -1 0 )
					)
					sub_objects ( 4
						sub_object (
							sub_object_header ( 00000400 -1 -1 000001d2 000001c4
...

[jonas]

Jovet, on 20 December 2023 - 11:45 PM, said:

...It's definitely only the first sub-object. ...

I have created this shape and have this ESD_SubObj ( ) problem in OR:

The reception building shape consists of 2 matrices: "Main" and "Night". "Night" is the first and only child matrix and consists of 1 primitive which is textured with "BlendATex". The root matrix "Main" consists of 3 primitives, which are all textured with "TexDiff".
OR apparently considers the first primitive (80 polys, texture "BfTrglw_Jm.ace") of the root matrix to be the first sub-object and therefore does not draw it on the day.
In the shape's code, the first "sub_object" in the "sub_objects" section is the 8 poly primitive of the "Night" matrix. The second "sub_object" is the 80-poly-"sub_object" of the root marix "Main".
I come to the conclusion that OR is incorrectly using the second "sub_object" listed in the shape as being switched day/night by "ESD_SubObj ( )".
OR does not seem to evaluate the matices but the primitives - more precisely: the 2nd "sub_object" in the shapes code with its primitive.

Since it works correctly in MSTS, I think it should be treated as an OR bug.
Do I see this correctly or what is wrong with my shape? ->  BfTrglw_Jm.zip (158.04K)
Number of downloads: 124

[Jovet]

jonas, on 21 December 2023 - 11:01 AM, said:

So sub-objects mean the first matrix that is subordinate to the root matrix?
And sub-objects does not mean the (first) so called "sub_object" listed in the shape files?

Yes, and yes. The terminology gets confusing because a lot of it is used inappropriately. That's one reason I like the nice, generic term part.

jonas, on 22 December 2023 - 10:51 AM, said:

I have created this shape and have this ESD_SubObj ( ) problem in OR:
OR apparently considers the first primitive (80 polys, texture "BfTrglw_Jm.ace") of the root matrix to be the first sub-object and therefore does not draw it on the day.

That is correct. The part labeled as "1" in the hierarchy icon is the part affected by ESD_SubObj().
It may help to know which software you used to create this building shape?

jonas, on 22 December 2023 - 10:51 AM, said:

In the shape's code, the first "sub_object" in the "sub_objects" section is the 8 poly primitive of the "Night" matrix. The second "sub_object" is the 80-poly-"sub_object" of the root marix "Main".

I have never really paid much attention as to how "sub_objects" in shape files relate to their matrices. It could be the order in which they're created or attached to one another in your modeling software but it doesn't matter because the Matrix entries are what matter. The only time I've noticed the order matters is when polygons at a distance don't get culled properly if they're not in the "right" order.

I don't really understand why your part Night shows 8 "static" polygons and none of the other parts seem related to or peers of that. I don't believe your shape is structured or exported correctly. When you click on the "1" node in the hierarchy list, the part you show that disappears highlights.

Additionally, you say things work in MSTS, but in MSTS shape textures must be sized to a square power of two. Maybe you've lucked out somehow, but that's definitely not a supported design.

[jonas]

Jovet, on 23 December 2023 - 07:26 AM, said:

...
Additionally, you say things work in MSTS, but in MSTS shape textures must be sized to a square power of two. Maybe you've lucked out somehow, but that's definitely not a supported design.

Sorry, I reduced the size of the texture files of the shape in order to let the download here not become too big. Here again the shape with the original sized texture files:  BfTrglw_Jm.zip (1.3MB)
Number of downloads: 128

[jonas]

The shape is exported from 3dsmax as a 3DS file and then converted into an s-file with Conv3DS.exe (just like I have been creating the most of my shapes for my AddOn for years).

About the terms: Because "sub_object" is used by Kuju in the shape code, I assumed that "ESD_SubObj ( )" might refer to ... might refer to.
In fact, however, it seems to refer to the first sub-matrix, at least in MSTS.

What does the "1" in an orange primitiv cube shown in the Model Hierarchy window actually mean? Is that known?
I can't read anything about the meaning of the numbers in the Shape Viewer help. It only says about the orange cubes: "Orange indicates a primitive in the higher sub-objects - these are usually alpha textured (translucent) parts."

[jonas]

I have varied 5 times the material hierarchy in 3dsmax and learned that the order of the materials directly determines the order of the sub_objects in the shape.
This order can be recognized by the numbers in the orange cubes of the primitive (the orange parts ;-). The brown cube is part of the order stands for the number 0, i.e. the first sub_object in the shape, the number 1 for the second and so on.
It is now interesting that MSTS hides the first sub_object/primitive, OR the second sub_object/primitive because of ESD_subObj () on the day:

The matrices and their hierarchy seem to play no role at all for the ESD_subObj () parameter!

OR differ and does not correctly simulate the MSTS-ESD_subObj functionality in my eyes.

[Jovet]

jonas, on 23 December 2023 - 01:38 PM, said:

The shape is exported from 3dsmax as a 3DS file and then converted into an s-file with Conv3DS.exe (just like I have been creating the most of my shapes for my AddOn for years).

Okay, that makes sense. I suspected something like that, as I have never gone that route and have not known how much control one has in the shape hierarchy creation. Obviously this method works, since it's what Kuju used to make the original game. Do you have the Conversion of Shapes and Textures 1.01.doc that came with MSTS? It outlines the specifics of what you need in your scene to get a smooth conversion. This seems to be a resource you need to clear up this confusion.

jonas, on 23 December 2023 - 01:38 PM, said:

What does the "1" in an orange primitiv cube shown in the Model Hierarchy window actually mean? Is that known?
I can't read anything about the meaning of the numbers in the Shape Viewer help. It only says about the orange cubes: "Orange indicates a primitive in the higher sub-objects - these are usually alpha textured (translucent) parts."

A shape file has a main part, and then can have up to 32 subordinate parts (e.g. "sub objects") which have their own pivot point, rotation, animation, etc. In certain situations, such as this topic or as signals or locomotives or such, the parts will be specifically animated or hidden/shown by the game. I believe that more than 33 total parts are supported, but only 32 first-level child parts are supported.

The Shape Viewer Hierarchy window will show special numbered icons for the first four subordinate parts, which the MSTS documentation does call "subobjects". The rest of the subordinate parts have generic icons, as I suspect the program's creator did not want to take the time to make and manage all 32 custom icons.

jonas, on 23 December 2023 - 04:57 PM, said:

I have varied 5 times the material hierarchy in 3dsmax and learned that the order of the materials directly determines the order of the sub_objects in the shape.
This order can be recognized by the numbers in the orange cubes of the primitive (the orange parts ;-). The brown cube is part of the order stands for the number 0, i.e. the first sub_object in the shape, the number 1 for the second and so on.
It is now interesting that MSTS hides the first sub_object/primitive, OR the second sub_object/primitive because of ESD_subObj () on the day:
The matrices and their hierarchy seem to play no role at all for the ESD_subObj () parameter!
OR differ and does not correctly simulate the MSTS-ESD_subObj functionality in my eyes.

My modeling avenue of choice has been Gmax. When I export to shape files from Gmax, I can explicitly control which parts are which "subobjects" in the final shape. For example, to test functionality for this thread, I made this test shape:
https://msts.jovet.net/files/images/TestEsdSubObject1.png

With this shape, I can confirm that MSTS and Open Rails behave identically, and only the first "sub-object" SUB1 is hidden during the day for ESD_SubObj.

Please notice that the bright, numbered icon polygons are all listed subordinate to the part names. This is how it should look, as those polygons belong to those parts. The same is true of the US2Lamp1.s shape I posted above. Your shape's hierarchy does not look like this, which is what I believe is causing you problems. If you don't have the Conversion of Shapes and Textures 1.01.doc file to review, I will be happy to send it to you.

[Jovet]

If you should want to examine the shape I made for testing, here it is.

[jonas]

Jovet, on 24 December 2023 - 01:40 AM, said:

...

If you should want to examine the shape I made for testing, here it is.

Thank you Joseph for your detailed work on this topic so far and even for creating your extra shape - especially on a day like today!

You encouraged me to read the "Conversion of Shapes and Textures 1.01.doc" again and I have translated part of it for myself. Thanks for the offer to send me the file, but I had easily found it on my computer. In principle I still knew the contents, it had been some time since I had read it, but now it is well refreshed.

I also work with Gmax sometimes, especially when 3dsmax messes up when exporting animations to 3ds format, which can be very annoying with steam locomotive rods, for example. So I also know that Gmax works enviably "cleaner" when it comes to creating s-files.They seem to be more clearly structured and work for MSTS/OR without much rework. However, I am very accustomed to the handling of 3dsmax and also to the possibility of making detailed manipulations, e.g. via material designations. Something that often seems like an advantage to me, but has become a problem here.

On this occasion of the thread here, I tried to understand the structure of the s-file in relation to the ESD_SubObj ( ) parameter in more detail. The categories "matrices", "hierarchy", "sub_objects" and "primitives" were my approach. For the most part, it is still a mystery to me how exactly this works in relation to the ESD_SubObj ( ) parameter, because of course I can clearly see that the US2lamp1.s or your shape work well, but what is so "wrongly sorted" in my reception building that some sub_objects are always hidden that are not desired still remains hidden from me.

I don't want to bore anyone here with these details, which perhaps only concern me. I'll stay on the ball a little longer and if I have any further insights, I'll be happy to post them here.

Until then, Merry Christmas to everyone!
Jonas

[Jovet]

Quote

There is a strict naming convention for shapes:MaterialName[sub object id][_user defined].

Myself never having put shapes together as you are doing, I can only guess how exactly this "strict naming convention" works in practice. Are you currently assigning a "sub object id" of 1 to the lighted part?
As far as the shape files, I can't claim to be an expert, even after all these years, but it's been my understanding that the sub_objects() groups under each LOD distance_levels() group represent each part in the shape. The first sub_object() is part #0 which is the main shape (or the root of the hierarchy). Additional sub_object() groups continue as needed for each part. The matricies() group earlier in the file enumerates the later sub_object() groups, gives them their part names, pivot point coordinates, etc. Looking over my example shape from my last post in Archibald, many of the shape file's fields are given interesting or helpful titles as to their purpose, but not all of them are.

Merry Christmas back at you! Even if it's a day late.

[jonas]

Jovet, on 26 December 2023 - 07:05 AM, said:

Quote

There is a strict naming convention for shapes:MaterialName[sub object id][_user defined].

Myself never having put shapes together as you are doing, I can only guess how exactly this "strict naming convention" works in practice. Are you currently assigning a "sub object id" of 1 to the lighted part?

Thanks to your advice, Joseph, I did exactly that. And after many hours, I have now gained some insights. In addition to your quoted part, the following is then written in the "Conversion of Shapes and Textures 1.01.doc":

"•Sub object id is an optional number between 0 and 31 so that other sub objects can be assigned, ..."

I didn't understand this exactly for years, because for me it should have read better:
"•Sub object id is an optional number between 0 and 31 using it one can define sub objects IDs, ..."

Finally, I then understood/discovered for the first time that a SubObjID exists in every sub_object_header, which uniquely indexes the sub_object:

SIMISA@@@@@@@@@@JINX0s1t______

shape (
	...

	lod_controls ( 1
				...
					sub_objects ( 3
						sub_object (
							sub_object_header ( 00000400 -1 -1 000001d2 000001c4
								...
								subobject_light_cfgs ( 1 0 ) 0               <-- SubObjID = 0
							)
							...
						)
						sub_object (
							sub_object_header ( 00000400 -1 -1 000001d2 000001c4
								...
								subobject_light_cfgs ( 1 0 ) 2               <-- SubObjID = 2
							)
							...
						)
						sub_object (
							sub_object_header ( 00000400 -1 -1 000001d2 000001c4
								...
								subobject_light_cfgs ( 1 0 ) 1               <-- SubObjID = 1
							...
							)
						)
					)
				)
			)
		)
	)<div>)

The last digit at the end of the "subobject_light_cfgs" lines is always the SubObjID.
(Admittedly, the connection between this number in the last "subobject_light_cfgs"-lines at each blockends and the "sub_object_header" wasn't easy to realize for me)

---

Now back to the actual topic, the ESD_subobj () entry in the sd file:

In MSTS, the sub_object for which this SubObjID = 1 is always hidden during the day!
(In the example shapefile above, the lowest sub_object would be hidden during the day because it has SubObjID = 1)

OR, on the other hand, indexes by itselfe the sub_objects according to their appearance from top to bottom in the shape file and ignores the SubObjID!
(In the example shapefile above, the middle sub_object with SubObjID = 2 (!) would be hidden during the day)

I looked up the OR code and identified the variable i in the corresponding for-loop-i++ as the "wrong" indexer (Shapes.cs, approx. line 2121).

The SubObject that appears second in the shape file is often the one with the SubObjID = 1, but even not always.

All the effects here and here are now easy for me to explain.

[Genma Saotome]

jonas, on 27 December 2023 - 08:31 AM, said:

In MSTS, the sub_object for which this SubObjID = 1 is always hidden during the day!
(In the example shapefile above, the lowest sub_object would be hidden during the day because it has SubObjID = 1)

That explains this shape:

Quote

SIMISA@@@@@@@@@@JINX0t1t______

shape ( Vampire.s

ESD_SubObj ( 1 )
ESD_Detail_Level ( 5 )
ESD_Alternative_Texture ( 0 )

)

jk.

I see many ESD_SubObj ( 1 ) values assigned to automobile shapes in both the Raton, WP3, and Tehacchippi routes, some i n carspawners, most static.

[jonas]

Genma Saotome, on 27 December 2023 - 12:49 PM, said:

...
I see many ESD_SubObj ( 1 ) values assigned to automobile shapes in both the Raton, WP3, and Tehacchippi routes, some i n carspawners, most static.

Hi Dave,

For MSTS it does not matter how you write it, it is always the sub_object with the SubObjID = 1 that disappears during the day.

I've tested:

ESD_SubObj ( )
ESD_SubObj ( 0 )
ESD_SubObj ( 1 )
ESD_SubObj ( 2 )
ESD_SubObj ( 3 )
ESD_SubObj ( Rabbit )
and even ESD_SubObj without any brackets works...but always only for sub_object with SubObjID = 1.

For me, this means that the letter sequence ESD_SubObj alone is already effective. Only when I entered ESD_SubOb (e.g. without the j) does it become ineffective in MSTS.

Here are the only MSTS sd files in which ESD_SubObj occurs at all:
carlisle.sd
c_van.sd
JP1SagumionoSt.sd
JP1ShinjukuSt.sd
JP1streetlight1.sd
Jp1Truck1.sd
OEHauptInnsbruckSt.sd
OEKematonSt.sd
OELamppost.sd
OEOzthalSt.sd
OEStamsSt.sd
US2BeltonSt.sd
us2cutbank.sd
US2lamp1.sd
US2Shelby.sd
US2SpottedRobeSt.sd
US2WhitefishSt.sd
US2YardLts.sd

There are some dubious ones, such as carlisle.s, a truck shape which only has 1 sub_object with the SubObjID = 0 anyway.
But at least the lamps like JP1streetlight1.s, OELamppost.s and US2lamp1.s seem to have the same good working structure and always a sub_object with SubObjID = 1, which represents the light.

I have not explicitly tested whether OR differentiates between ESD_SubObj ( ), ESD_SubObj ( 1 ) or ESD_SubObj ( 2 ), but I think it is unlikely. The code always tests for "1", regardless of which ESD_SubObj entry was read, whereby in OR it is not the SubObjID = 1 that is meant, but the rank in the order of the sub_objects.
Excerpt from the If query in the code: "... (i == 1 && HasNightSubObj ..." (Shapes.cs, approx. line 2127)