[Goku]

SP 0-6-0, on 16 September 2017 - 05:37 PM, said:

I feel there is alot still not fully known about the capabilities of the .S file? I feel the real limitation is more likely MSTS and crude modeling programs like TSM than any limitation of the .S file format.

The limitations are MSTS limitations, not .S file limitations. S file format has everything that modern game engine needs.
Only downside of .S file is that we have only good Blender exporter (and Shetchup?), and a lot of users don't want to use Blender.

[ErickC]

captain_bazza, on 16 September 2017 - 06:50 PM, said:

Isn't the .S format a derivitive of the .X format? MSTS was the "child" of Microsoft and both formats were theirs.

CB.

I think that I read that once. It's been a while since I've poked around in an .x file, but I remember them looking pretty similar.

The only issues I've ever had with the .s format are tied to tools that read and write it, not the capability of the format itself. The GMax exporter seems to have the same 64-part limit that MSTS does (and this will become a problem when cabs get more complex), but I've considered the possibility that I could probably import models into 3DC if I had to. I suppose I could probably find a way to export multiple models and then combine them in a text editor if worse came to worse.

[Goku]

Best solution for 3d Max users now is just to convert 3d Max -> Blender -> .S
For someone that can use 3ds Max, learning basics of Blender would take half day max.

I think .S file is completely different than .X file.

[ErickC]

Yes, I wasn't sure, so I did a quick test with a simple cube. First is the cube exported with bitmap textures as an FS9 .x file:

xof 0302txt 0032

// Direct3D .x file translation of Scene_Root
// Generated by 3DSMax FSModelExp Plug-in, Version 1.00
// Sun Sep 17 11:33:12 2017


template Header {
 <3D82AB43-62DA-11cf-AB39-0020AF71E433>
 WORD major;
 WORD minor;
 DWORD flags;
}

template Vector {
 <3D82AB5E-62DA-11cf-AB39-0020AF71E433>
 FLOAT x;
 FLOAT y;
 FLOAT z;
}

template Coords2d {
 <F6F23F44-7686-11cf-8F52-0040333594A3>
 FLOAT u;
 FLOAT v;
}

template Matrix4x4 {
 <F6F23F45-7686-11cf-8F52-0040333594A3>
 array FLOAT matrix[16];
}

template ColorRGBA {
 <35FF44E0-6C7C-11cf-8F52-0040333594A3>
 FLOAT red;
 FLOAT green;
 FLOAT blue;
 FLOAT alpha;
}

template ColorRGB {
 <D3E16E81-7835-11cf-8F52-0040333594A3>
 FLOAT red;
 FLOAT green;
 FLOAT blue;
}

template TextureFilename {
 <A42790E1-7810-11cf-8F52-0040333594A3>
 STRING filename;
}

template Material {
 <3D82AB4D-62DA-11cf-AB39-0020AF71E433>
 ColorRGBA faceColor;
 FLOAT power;
 ColorRGB specularColor;
 ColorRGB emissiveColor;
 [...]
}

template MeshFace {
 <3D82AB5F-62DA-11cf-AB39-0020AF71E433>
 DWORD nFaceVertexIndices;
 array DWORD faceVertexIndices[nFaceVertexIndices];
}

template MeshTextureCoords {
 <F6F23F40-7686-11cf-8F52-0040333594A3>
 DWORD nTextureCoords;
 array Coords2d textureCoords[nTextureCoords];
}

template MeshMaterialList {
 <F6F23F42-7686-11cf-8F52-0040333594A3>
 DWORD nMaterials;
 DWORD nFaceIndexes;
 array DWORD faceIndexes[nFaceIndexes];
 [Material]
}

template MeshNormals {
 <F6F23F43-7686-11cf-8F52-0040333594A3>
 DWORD nNormals;
 array Vector normals[nNormals];
 DWORD nFaceNormals;
 array MeshFace faceNormals[nFaceNormals];
}

template Mesh {
 <3D82AB44-62DA-11cf-AB39-0020AF71E433>
 DWORD nVertices;
 array Vector vertices[nVertices];
 DWORD nFaces;
 array MeshFace faces[nFaces];
 [...]
}

template FrameTransformMatrix {
 <F6F23F41-7686-11cf-8F52-0040333594A3>
 Matrix4x4 frameMatrix;
}

template Frame {
 <3D82AB46-62DA-11cf-AB39-0020AF71E433>
 [...]
}
template FloatKeys {
 <10DD46A9-775B-11cf-8F52-0040333594A3>
 DWORD nValues;
 array FLOAT values[nValues];
}

template TimedFloatKeys {
 <F406B180-7B3B-11cf-8F52-0040333594A3>
 DWORD time;
 FloatKeys tfkeys;
}

template AnimationKey {
 <10DD46A8-775B-11cf-8F52-0040333594A3>
 DWORD keyType;
 DWORD nKeys;
 array TimedFloatKeys keys[nKeys];
}

template AnimationOptions {
 <E2BF56C0-840F-11cf-8F52-0040333594A3>
 DWORD openclosed;
 DWORD positionquality;
}

template Animation {
 <3D82AB4F-62DA-11cf-AB39-0020AF71E433>
 [...]
}

template AnimationSet {
 <3D82AB50-62DA-11cf-AB39-0020AF71E433>
 [Animation]
}

template DiffuseTextureFileName {
 <E00200E2-D4AB-481a-9B85-E20F9AE07401>
 STRING filename;
}

template AmbientTextureFileName {
 <E00200E2-D4AB-481a-9B85-E20F9AE07402>
 STRING filename;
}

template EmissiveTextureFileName {
 <E00200E2-D4AB-481a-9B85-E20F9AE07403>
 STRING filename;
}

template ReflectionTextureFileName {
 <E00200E2-D4AB-481a-9B85-E20F9AE07404>
 STRING filename;
}

template ShininessTextureFileName {
 <E00200E2-D4AB-481a-9B85-E20F9AE07405>
 STRING filename;
}

template BumpTextureFileName {
 <E00200E2-D4AB-481a-9B85-E20F9AE07406>
 STRING filename;
}

template DisplacementTextureFileName {
 <E00200E2-D4AB-481a-9B85-E20F9AE07407>
 STRING filename;
}

template PartData {
 <79B183BA-7E70-44d1-914A-23B304CA91E5>
 DWORD nByteCount;
 array BYTE XMLData[ nByteCount ];
}

Header {
	1;
	0;
	1;
	}

//=====================
// FILE NODE HEIRARCHY
//=====================
// Scene_Root (1 Children)
//   Box01 (0 Children)

Frame frm-MasterScale {
FrameTransformMatrix {
   0.000977, 0.0, 0.0, 0.0,
   0.0, 0.000977, 0.0, 0.0,
   0.0, 0.0, 0.000977, 0.0,
   0.0, 0.0, 0.0, 1.0;;
}		// End frm-MasterScale FrameTransformMatrix
Frame frm-MasterUnitConversion {
FrameTransformMatrix {
   1024.000000, 0.0, 0.0, 0.0,
   0.0, 1024.000000, 0.0, 0.0,
   0.0, 0.0, 1024.000000, 0.0,
   0.0, 0.0, 0.0, 1.0;;
}		// End frm-MasterUnitConversion FrameTransformMatrix
Frame RotateAroundX {
FrameTransformMatrix {
   1.0, 0.0, 0.0, 0.0,
   0.0, 0.0, 1.0, 0.0,
   0.0, -1.0, 0.0, 0.0,
   0.0, 0.0, 0.0, 1.0;;
}		// End Frame RotateAroundX FrameTransformMatrix
Frame frm-Box01 {
FrameTransformMatrix {
  1.000000, 0.000000, 0.000000, 0.0,
  0.000000, 1.000000, 0.000000, 0.0,
  0.000000, 0.000000, 1.000000, 0.0,
  0.000000, 0.000000, 0.000000, 1.0;;
}		// End FrameTransformMatrix

Mesh Box01 {
26;		// Mesh 'Box01' contains 26 vertices
  -0.304800; -0.304800; 0.000000;,
  0.304800; -0.304800; 0.000000;,
  -0.304800; 0.304800; 0.000000;,
  0.304800; 0.304800; 0.000000;,
  -0.304800; -0.304800; -0.609600;,
  0.304800; -0.304800; -0.609600;,
  -0.304800; 0.304800; -0.609600;,
  0.304800; 0.304800; -0.609600;,
  -0.304800; -0.304800; 0.000000;,
  0.304800; -0.304800; 0.000000;,
  0.304800; -0.304800; -0.609600;,
  0.304800; -0.304800; -0.609600;,
  -0.304800; -0.304800; -0.609600;,
  -0.304800; -0.304800; 0.000000;,
  0.304800; 0.304800; 0.000000;,
  0.304800; -0.304800; -0.609600;,
  0.304800; 0.304800; 0.000000;,
  -0.304800; 0.304800; 0.000000;,
  -0.304800; 0.304800; -0.609600;,
  -0.304800; 0.304800; -0.609600;,
  0.304800; 0.304800; -0.609600;,
  0.304800; 0.304800; 0.000000;,
  -0.304800; 0.304800; 0.000000;,
  -0.304800; -0.304800; -0.609600;,
  -0.304800; -0.304800; -0.609600;,
  -0.304800; 0.304800; 0.000000;;

12;		// Mesh 'Box01' contains 12 Faces
  3; 3, 2, 0;,
  3; 0, 1, 3;,
  3; 7, 5, 4;,
  3; 4, 6, 7;,
  3; 10, 9, 8;,
  3; 13, 12, 11;,
  3; 7, 14, 1;,
  3; 1, 15, 7;,
  3; 18, 17, 16;,
  3; 21, 20, 19;,
  3; 23, 0, 22;,
  3; 25, 6, 24;;
MeshMaterialList {
  1; // 1 Materials
  12; // 12 Faces have materials specified
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  0,
  0;
  Material gork0 {
  0.588000; 0.588000; 0.588000; 1.000000;;
  0.000000;
  0.900000; 0.900000; 0.900000;;
  0.000000; 0.000000; 0.000000;;
  TextureFileName {
     "diffuse map.bmp";
  }
  DiffuseTextureFileName  {
    "diffuse map.bmp";
  }
}		// End Material 'gork0'
}		// End MaterialList for 'Box01'
MeshNormals {		// Mesh normals for Box01
6;		// 6 vertex normals
  0.000000; 0.000000; 1.000000;,
  0.000000; 0.000000; -1.000000;,
  0.000000; -1.000000; 0.000000;,
  1.000000; 0.000000; 0.000000;,
  0.000000; 1.000000; 0.000000;,
  -1.000000; 0.000000; 0.000000;;
12;		// 12 faces with normals
  3; 0, 0, 0;,
  3; 0, 0, 0;,
  3; 1, 1, 1;,
  3; 1, 1, 1;,
  3; 2, 2, 2;,
  3; 2, 2, 2;,
  3; 3, 3, 3;,
  3; 3, 3, 3;,
  3; 4, 4, 4;,
  3; 4, 4, 4;,
  3; 5, 5, 5;,
  3; 5, 5, 5;;
}		// End Mesh normals for Box01
  MeshTextureCoords {
  26;		// 26 uv pairs
  1.000000; 1.000000;,
  0.000000; 1.000000;,
  1.000000; 0.000000;,
  0.000000; 0.000000;,
  0.000000; 1.000000;,
  1.000000; 1.000000;,
  0.000000; 0.000000;,
  1.000000; 0.000000;,
  0.000000; 1.000000;,
  1.000000; 1.000000;,
  1.000000; 0.000000;,
  1.000000; 0.000000;,
  0.000000; 0.000000;,
  0.000000; 1.000000;,
  1.000000; 1.000000;,
  0.000000; 0.000000;,
  0.000000; 1.000000;,
  1.000000; 1.000000;,
  1.000000; 0.000000;,
  1.000000; 0.000000;,
  0.000000; 0.000000;,
  0.000000; 1.000000;,
  0.000000; 1.000000;,
  1.000000; 0.000000;,
  1.000000; 0.000000;,
  0.000000; 1.000000;;
  }		// End MeshTexture Coords for 'Box01'
}		// End of Mesh 'Box01'
}		 // End of frame frm-Box01

}		 // End of RotateAroundX frame

}		 // End of frm-MasterUnitConversion frame

}		 // End of frm-MasterScale frame


AnimationSet {		// Collection of Animations
}		// End of AnimationSet.

Then I opened the same project in the MSTS gamepack, substituted the diffuse map for one in .ace format, and exported:

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

shape (
	shape_header ( 00000000 00000000 )
	volumes ( 2
		vol_sphere (
			vector ( 0 0.3048 0 ) 0.554326
		)
		vol_sphere (
			vector ( 0 0.3048 0 ) 0.527929
		)
	)
	shader_names ( 1
		named_shader ( TexDiff )
	)
	texture_filter_names ( 1
		named_filter_mode ( MipLinear )
	)
	points ( 8
		point ( -0.3048 0 -0.3048 )
		point ( -0.3048 0 0.3048 )
		point ( 0.3048 0 0.3048 )
		point ( 0.3048 0 -0.3048 )
		point ( -0.3048 0.6096 -0.3048 )
		point ( 0.3048 0.6096 -0.3048 )
		point ( 0.3048 0.6096 0.3048 )
		point ( -0.3048 0.6096 0.3048 )
	)
	uv_points ( 4
		uv_point ( 1 1 )
		uv_point ( 1 0 )
		uv_point ( 0 0 )
		uv_point ( 0 1 )
	)
	normals ( 6
		vector ( -1 0 0 )
		vector ( 0 0 1 )
		vector ( 1 0 0 )
		vector ( 0 0 -1 )
		vector ( 0 1 0 )
		vector ( 0 -1 0 )
	)
	sort_vectors ( 1
		vector ( 0 0.3048 0 )
	)
	colours ( 0 )
	matrices ( 1
		matrix BOX01 ( 1 0 0 0 1 0 0 0 1 0 0 0 )
	)
	images ( 1
		image ( "diffuse map.ace" )
	)
	textures ( 1
		texture ( 0 0 0 ff000000 )
	)
	light_materials ( 0 )
	light_model_cfgs ( 1
		light_model_cfg ( 00000000
			uv_ops ( 1
				uv_op_copy ( 1 0 )
			)
		)
	)
	vtx_states ( 1
		vtx_state ( 00000000 0 -5 0 00000002 )
	)
	prim_states ( 1
		prim_state gork ( 00000000 0
			tex_idxs ( 1 0 ) 0 0 0 0 1
		)
	)
	lod_controls ( 1
		lod_control (
			distance_levels_header ( 0 )
			distance_levels ( 1
				distance_level (
					distance_level_header (
						dlevel_selection ( 0 )
						hierarchy ( 1 -1 )
					)
					sub_objects ( 1
						sub_object (
							sub_object_header ( 00000400 -1 -1 000001d2 000001c4
								geometry_info ( 12 1 0 36 0 0 1 0 0 0
									geometry_nodes ( 1
										geometry_node ( 1 0 0 0 0
											cullable_prims ( 1 12 36 )
										)
									)
									geometry_node_map ( 1 0 )
								)
								subobject_shaders ( 1 0 )
								subobject_light_cfgs ( 1 0 ) 0
							)
							vertices ( 24
								vertex ( 00000000 0 5 ff969696 ff808080
									vertex_uvs ( 1 0 )
								)
								vertex ( 00000000 1 5 ff969696 ff808080
									vertex_uvs ( 1 1 )
								)
								vertex ( 00000000 2 5 ff969696 ff808080
									vertex_uvs ( 1 2 )
								)
								vertex ( 00000000 3 5 ff969696 ff808080
									vertex_uvs ( 1 3 )
								)
								vertex ( 00000000 4 4 ff969696 ff808080
									vertex_uvs ( 1 3 )
								)
								vertex ( 00000000 5 4 ff969696 ff808080
									vertex_uvs ( 1 0 )
								)
								vertex ( 00000000 6 4 ff969696 ff808080
									vertex_uvs ( 1 1 )
								)
								vertex ( 00000000 7 4 ff969696 ff808080
									vertex_uvs ( 1 2 )
								)
								vertex ( 00000000 0 3 ff969696 ff808080
									vertex_uvs ( 1 3 )
								)
								vertex ( 00000000 3 3 ff969696 ff808080
									vertex_uvs ( 1 0 )
								)
								vertex ( 00000000 5 3 ff969696 ff808080
									vertex_uvs ( 1 1 )
								)
								vertex ( 00000000 4 3 ff969696 ff808080
									vertex_uvs ( 1 2 )
								)
								vertex ( 00000000 3 2 ff969696 ff808080
									vertex_uvs ( 1 3 )
								)
								vertex ( 00000000 2 2 ff969696 ff808080
									vertex_uvs ( 1 0 )
								)
								vertex ( 00000000 6 2 ff969696 ff808080
									vertex_uvs ( 1 1 )
								)
								vertex ( 00000000 5 2 ff969696 ff808080
									vertex_uvs ( 1 2 )
								)
								vertex ( 00000000 2 1 ff969696 ff808080
									vertex_uvs ( 1 3 )
								)
								vertex ( 00000000 1 1 ff969696 ff808080
									vertex_uvs ( 1 0 )
								)
								vertex ( 00000000 7 1 ff969696 ff808080
									vertex_uvs ( 1 1 )
								)
								vertex ( 00000000 6 1 ff969696 ff808080
									vertex_uvs ( 1 2 )
								)
								vertex ( 00000000 1 0 ff969696 ff808080
									vertex_uvs ( 1 3 )
								)
								vertex ( 00000000 0 0 ff969696 ff808080
									vertex_uvs ( 1 0 )
								)
								vertex ( 00000000 4 0 ff969696 ff808080
									vertex_uvs ( 1 1 )
								)
								vertex ( 00000000 7 0 ff969696 ff808080
									vertex_uvs ( 1 2 )
								)
							)
							vertex_sets ( 1
								vertex_set ( 0 0 24 )
							)
							primitives ( 2
								prim_state_idx ( 0 )
								indexed_trilist (
									vertex_idxs ( 36 0 2 1 2 0 3 4 6 5 6 4 7 8 10 9 10 8 11 12 14 13 14 12 15 16 18 17 18 16 19 20 22 21 22 20 23 )
									normal_idxs ( 12 5 3 5 3 4 3 4 3 3 3 3 3 2 3 2 3 1 3 1 3 0 3 0 3 )
									flags ( 12 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 )
								)
							)
						)
					)
				)
			)
		)
	)
)

[ErickC]

I have a bit of an idea. If accessibility is a concern, and people are using a variety of modelling programs, then why not create a dedicated model compiler that accepts a universally-exportable format (like an x file), allows us to set z-bias, and creates LODs (export one x-file per LOD) in a way similar to the GMax LOD editor, then does some drawcall batching and, finally, compiles a native model (how about .ors for an extension)? This basic idea has worked wonders in ESP, where you can export a model from basically any modelling program you like.

If you're more of a visual thinker, the process would look like this:



CONS:

-More than one step in the export process
-Requires the creation of the compiler
-Universal philosophy means LODs must be exported separately and loaded together into the compiler

PROS:

-Use of universal input format means most modelling programs can build a model
-Drawcall batching eliminates tedious task of combining parts before export (a real pain if you have a lot of similar models using interchangeable parts because you have to basically redo the export setup process every time you finish a model)
-No need to update export modules for multiple modelling programs. Simply update the compiler and re-export.
-End to 64-part maximum for GMax users
-We could someday implement custom coding - perhaps in XML - and the compiler could read from a list of custom codes like it does in ESP for limitless animation and control possibilities

I had an idea, when I drew the image, that there could be a material settings panel to set material properties, but I think it might make more sense to treat all materials equally, with specular properties, transparency, reflection mapping, and bump mapping handled in maps specified by the settings in the .sd file. That would be a lot less work. All you need, then, is the ability to set z-bias for transparent parts, something GMax users already do in the Gmax compiler (so it's reasonable for a compiler to perform this function). Settings for z-bias could be saved and loaded by part name so that the builder doesn't have to repeat this step unless the part names change. You would simply save a file the first time you do it, then load that file every time you export a new iteration of the same model. Then multiple models with the same hierarchy but modified shapes (think of variations in a single class) could use one file. It would be more steps than one presently has to take, but it would be kind of necessary for a universal system.

[sergio]

Any news, still planned for version 1.3?

[Genma Saotome]

Goku, on 17 September 2017 - 12:20 AM, said:

The limitations are MSTS limitations, not .S file limitations. S file format has everything that modern game engine needs.
Only downside of .S file is that we have only good Blender exporter (and Shetchup?), and a lot of users don't want to use Blender.

There some issues w/ Sketchup:

Trimble has stopped development on the free version (2017 is the last one released, 2016 is what I recommend).
Anything you do in SU has to make it thru the SU to .s exporter (written in Ruby). If it ain't in the exporter it won't bne in the .s file.
SU doesn't do animations., It's excellent for architectural models and anything static, problematic (but do-able) for anything w/ complex combinations of cylinders, can be difficult (but do-able) to texture anything based on complex 2d curves and/or cylinders.

[Guille592]

ErickC, on 19 September 2017 - 05:26 PM, said:

If you're more of a visual thinker, the process would look like this:

ORTS exporter idea.JPG

I would sign with my eyes blinded for this, a compiler in the final export process would be a great deal and a great opportunity for some of us to get rid off some big headaches that the reverse engineering is giving us. This sure would be a big step for the ORTS community! :D

[ErickC]

It's worked very well for MSFS. You can get a model into MSFS from just about any 3D platform because the compiler's input format ( DirectX ) is almost universally-available for export. The compiler does a lot of the heavy lifting, you just make sure the right materials are in the right slots. For a rapidly-evolving platform, this provides the special benefit of the compiler handling version-to-version output differences.

[Genma Saotome]

> -Drawcall batching eliminates tedious task of combining parts before export (a real pain if you have a lot of similar models using interchangeable parts because you have to basically redo the export setup process every time you finish a model).

Do you mean dynamically creating a texture atlas or something else?

WRT interchangeable parts, AFAIK there is no reason why 1 game object (e.g., a freight car) must be 1 mesh. We should be able to change the OR loader so when handed a set of assembly instructions the loader combines multiple meshes into one game object. Or is that what you were trying to describe?

We should also be able to change the OR loader so when handed a list of replacement texture files (e.g., mesh texture.ace replaced by newtexture.ace) it understands what to feed the main program. This one change would allow car and locomotive creators to make one mesh and as many .eng or .wag files as wanted and leave them all in one \trainset folder so long as there is some text to tell the loader what to do for substitution. Aside from reducing the folder count in \trainset AND letting all those /wags or .engs load just one instance of commonly shared textures (instead of one per folder), I figure it would make reskins easier to do as well.

[ErickC]

No, the process of drawcall batching is combining all non-animated parts that share the same material into a single node, which reduces the drawcall count, which is an important performance factor (though I find that it's secondary to the number of vertices). Let's say I have a model, and this model uses a single material, and has ten parts: a cab, two hoods, a frame, two trucks, and two wheels on each truck. If I leave it as-is and export it, this is ten drawcalls. But the only parts that really need to be separate are the trucks and wheels, because those are animated. So I can join all of the non-animated parts together, and now we are left with seven drawcalls. This assumes a fairly basic material. If you start adding more maps (bump, reflection, et c), that single material now multiplies the drawcall count by the number of additional maps. So let's say I added a specular map to this model, now it's the difference between 20 and 14 drawcalls. So a model that has been optimized into the fewest possible drawcalls is optimal, because things will get out of hand very quickly once you start dealing with modern materials (which might have a reflection map, specular map, normal map, and Fresnel map).

The glory of the MSFS compilers is that they do the drawcall batching automatically, so you can keep your parts separate in the source files, which makes building and editing models easier. With the TS exporters, we have to do this manually, and the only way to go back is to have a separate set of source files for export - which means joining parts over and over again whwne you modify something and create a new export version. This is tedious and time-consuming. If we had a compiler that did this automatically... no problem.

Note that joining parts doesn't necessarily create a single drawcall. Let's say, for example, I used a pair of small textures, one for the hoods, and one for everything else. Well, I join the hoods, cab, and frame together, and the entire assembly is still two drawcalls - again multiplied by the number of maps in the material (so it becomes four if each material has a diffuse map and a specular map). This is why I cringe when I see a model that uses a bunch of tiny images instead of a few or one big image.

Having couplers and trucks and whatnot as separate meshes probably wouldn't affect drawcall counts in that each is an animated part that will always be an additional drawcall anyway. If you're putting handrails and exhaust stacks and other static parts in a separate mesh, though, you're screwing the user out of some degree of performance. This becomes very important when there are a lot of objects on-screen.

As far as I know, a texture atlas really only helps you when everything that uses it can somehow be combined into a single drawcall (such as with shrubbery and buildings, that is, static scenery). If the objects can't, then it can actually be even worse if the platform treats each instance of the same file as a separate file. Let's say you have four boxcars, and you decide to combine the four 2048 x 2048 pixel textures (it's 2018) into a single 4096 x 4096 pixel texture. Well, those four boxcars are always going to be four sets of n drawcalls, so you didn't gain anything performance-wise. Let's say the program treats the same texture as a separate file for each car, though. Now you're still loading four images into memory... but they're significantly larger and taking up much more memory. I think that this is rare, however. I'd hope that OR only loads one instance of each particular file into memory... does it? The answer could very well determine how I build models in the future (combining several models into one texture may not save on drawcalls, but it can mean a more efficient use of space within the textures themselves, especially with flatcars).

"Interchangeable parts" was a poor word choice. I'm referring to building a fleet of similar pieces of rolling stock with parts that might be the same, but might need to be moved from model to model. As an example, I am presently building the Soo Line's entire 7-locomotive GP7 fleet (MNTX 559 belonged to the CRIPs and doesn't count). I can't use the same model for all of them, because each locomotive is different. The final step in the export process is joining together all of the static parts (I am using a single material for the entire locomotive). Thus each final GP7 model should only be 7 drawcalls. Having to do this 7 times is really annoying, especially when LODs enter the equation.

I could build a basic model and add secondary freight shapes - but, again, I'd be adding additional drawcalls. This will become very significant when more advanced shaders and more complex materials enter the equation (that said, I have considered this process as a possibility for "build your own locomotive" packages where I'd provide a generic basic model and one particular railroad's detail parts as a freight shape, allowing the user to create their own detail parts for a particular road and repaint).

[Hamza97]

Quote

decide to combine the four 2048 x 2048 pixel textures (it's 2018) into a single 4096 x 4096 pixel texture.

I am thinking of using the same technique above in my project, 4 2K textures in a single 4K one, solely from performance point of view, should i use it or try something else....?? :mellow: :search:

[wacampbell]

ErickC, on 26 January 2018 - 02:37 PM, said:

The glory of the MSFS compilers is that they do the drawcall batching automatically, so you can keep your parts separate in the source files. With the TS exporters, we have to do this manually,

Just an FYI, the Blender to MSTS exporter does this drawcall batching automatically on export. It combines meshes everywhere possible to use the minimum number of drawcalls in the .s shape file it creates.

I still support the idea of using compilers as suggested. The concept of compiling geometry to an internal format has many advantages:

- this internal format can be optimized for fast loading

- it can support whatever source formats are convenient for the artist

- drawcall batching can be done according to the capabilities of the player's hardware. For example if we introduce texture arrays into Open Rails, these require a different strategy for drawcall batching than the current graphic algorithm. Adopting the Vulkan graphics API would use different batching and formats again. All of this can be made transparent to the end user by using compilers.

- We don't have to have artists trying to second guess what works best on the hardware. Artists build their content in the way that makes sense to them, and let the compiler figure out what optimizations make sense for the graphics code.

- having a compiler makes batching across a full scene possible. ie the compile operation isn't done model by model, its done tile by tile, merging multiple models that share the same material settings across a tile or section of a tile. And it can choose to use instancing, or mesh consolidation which ever is best for the end users hardware and software.


Wayne

[James Ross]

ErickC, on 26 January 2018 - 02:37 PM, said:

I'd hope that OR only loads one instance of each particular file into memory... does it?

You are correct; Open Rails will load only one copy of each texture, shape (mesh), tile, etc. into memory no matter who is referring to it. It will even deduplicate materials (textures + render options) across all loaded shapes, so if multiple shapes use the same texture with the same options (e.g. TexBlendA), there will only be one material for it - and the draw calls for the whole scene get batched by material.

wacampbell, on 27 January 2018 - 06:55 AM, said:

- having a compiler makes batching across a full scene possible. ie the compile operation isn't done model by model, its done tile by tile, merging multiple models that share the same material settings across a tile or section of a tile. And it can choose to use instancing, or mesh consolidation which ever is best for the end users hardware and software.

I've toyed with the idea of merging non-animated parts of tiles and auto-generating texture atlases, which I know isn't going to be perfect but ought to work in our favour in many cases.

The only thing about a compiler is where does it run: on the content-creators computer, or the end-user? Maybe it's both. I ask because some of the items listed mention the player's hardware but most commonly the compilation only happens at the content-creator end AIUI.

[Genma Saotome]

James Ross, on 29 January 2018 - 01:51 PM, said:

You are correct; Open Rails will load only one copy of each texture, shape (mesh), tile, etc. into memory no matter who is referring to it.

James, does the above include identical textures loaded from multiple folders in \trainsets?

Quote

It will even deduplicate materials (textures + render options) across all loaded shapes, so if multiple shapes use the same texture with the same options (e.g. TexBlendA), there will only be one material for it - and the draw calls for the whole scene get batched by material.

Ohhh, I did not know this...interesting... it sounds sort of like instancing by texture. What happens if the texture is applied to faces with different LOD's? I'm curious because I do A LOT of texture sharing across many different models (e.g., brick, concrete, windows, door textures are commonly shared in all of my models).