Model building guidelines

Validity

The requirements listed here (Model building guidelines) by Trend-Verlag came into force at the beginning of 2019.
They are constantly updated and are binding for all officially accredited designers. All previous publications of the model building guidelines lose their validity.
This also applies to other treatises such as the "Zehn Gebote für die Konstruktion", " Sieben goldene Regeln" or similar.

Name of the model file

Check of file conformity

Filenames

• The length including the dot and the file extension 3dm is limited to a maximum of 31 characters.
• All filenames assigned by the author such as 3dm, ini, wav, png etc. need to have an underscore at the end and include the author's abbreviation afterwards: Modell_XY1.3dm.
• EEP expects ANSI coding; other encodings such as UTF-8 cause display errors when using special characters and vowel mutation;

Use of special characters

Characters allowed in all files are

! + - _ 0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z

Characters that are not allowed are e.g.

" [ ] , ; \ = / @ * < > ' §

These specifications also apply when assigning folder names, e.g. when creating subdirectories.

Allowed number of characters

The model name in the external ini file of the model (Name_ENG = "..." / Name_GER = "..." / Name_FRA = "..." / Name_POL = "...") may not exceed 60 characters (including spaces).

For a user-friendly display of the model name in the model selection window, a maximum of 45 characters is recommended.

Entry in the description of the model

In the description of the model in the external ini file (Description_ENG = "..." / Description_GER = "..." / Description_FRA = "..." / Description_POL = "...") the order number of the respective shopset is prefixed, followed by a comma [,]. Example: Description_GER = "V16NXY1001, ...".

Creation of subdirectories

Starting with the second subdirectory, counting from the level of the \Resources folder, the designer can create subdirectories with his designer abbreviation as folder name. For the time being, this only applies to the \Sounds\EEXP and \Tauschtexturen folders. It is recommended for the \Tauschtexturen folder. Other folder names or combinations with the constructor abbreviation are not permitted.

Examples of permitted folder names: Resourcen\Sounds\EEXP\ 'XY1' , Resourcen\Tauschtexturen\ 'YZ3' .

Examples of not allowed folder names: Resourcen\Sounds\EEXP\ 'Whistle' , Resourcen\Sounds\EEXP\ 'Whistle_XZ1'

Note: If the designer assigns meaningful file names within the folder with his abbreviation, unsystematic folder names are unnecessary.

Model textures

General guidelines and recommendations

Requirements:

• The model is built as detailed as possible.
• A model has a single, reasonably small, main texture.
• Before building his model, the designer gets a great deal of clarity about the texture size and division.
• When the model is exported, the texture is compressed according to the nostructor, i.e. saved in DXT1 or DXT5 format.
• The color of the model is based on the RAL color scheme of the respective original.
• Models are to be completely textured; all vertices contain texture coordinates.
• Coloring or color changes on models by simply coloring vertices is not permitted. In addition to texturing, e.g. to achieve shading, coloring is permitted.
• The lower limit for texturing is 50x50 pixels per 1 square meter of model area. A good guideline is 80-90 pixels x 80-90 pixels per 1 square meter model area.
• Monotonous colored areas without any surface structure must be avoided.

Recommendations:

• The texture can be created with or without billboarding.
• When designing the texture - especially for real estate - original images should be used.

Exchange textures and inscriptions

Vorgaben:

• Exchange textures are only partially used (for certain elements or assemblies of a model), but not for the entire model in its appearance.
• Permitted file formats for exchange textures are: .dds, .bmp, .jpg, .png and .tga
• Exchange textures are installed in the folder Resourcen\Tauschtexturen. The beginning of the file name of the exchange texture corresponds to that of the associated model. This immediately signals to the user that it belongs to the desired model.
• Within the Tauschtexturen folder, it is recommended to create a subdirectory with the designer's abbreviation (e.g. "XY1"). This is used to provide a better overview and findability of the exchange texture for the user.

The installation script for exchange textures is created as follows:

[EEPInstall]
EEPVersion = 16 ; (15,14 etc.)
File001 = "Tauschtextur.bmp","Resourcen\Tauschtexturen\XY1\Tauschtextur.bmp"

Recommendations:

• If it appears plausible for a model, labels can be implemented with the inscription function or with exchange textures. Both methods serve the multiple and adapted use of the models and increase the optical variety and the individuality of the layouts.

Texture sizes

Suitable standard sizes are:

256x256px; 512x512; 1024x1024; 2048x2048; 3072x3072; 4096x4096 (maximum size)
Half formats can be used: 1024x512 is an example of a correct half format.

Wrong sizes are e.g. 1024x513, 1200x1200, 1600x1600, 1980x1024.

Model size

Requirements

• Models that consist of more than 500 triangles must contain several Levels of Details (LOD levels);
• The size of a model with all LOD levels must not exceed 500,000 triangles.
• The size of the first level LOD 0 must not exceed 300,000 triangles.

The allowed number of triangles in the last LOD level results as follows (formula):

Pixel_x * Pixel_z * 3 Width multiplied by the height of the model in pixels at a distance of 750 m multiplied by a factor of 3, based on a screen resolution of 1920 x 1080 pixels.

The last LOD level can also be reached at LOD 3 or earlier. The same calculation has to be applied.

recommendations

The following guidelines serve to reduce the number of triangles in the individual LOD levels:

LOD-Level	Reduction of the number of triangles by %	at a distance of m
LOD 0	0 %	0 m - 150 m
LOD 1	15 % - 30 %	50 m - 150 m
LOD 2	30 % - 60 %	100 m - 300 m
LOD 3	60 % - 80 %	200 m - 500 m
LOD 4	according to formula	600 m - 1000 m

Axles

When building the model, you should generally avoid unnecessary axes / axes nesting. This applies particularly to axes that are only moved once by the user (when inserting the model). Additional axes increase the rendering time significantly.

As a rule of thumb, the following can apply:

• The fewer copies of the model can reasonably be expected on a layout,
• The more complex the movements of the model are in operation,
• The more attractive the model is seen after informally obtained assessment by the publisher,

the more axes are acceptable. In case of doubt, it is advisable to contact the publisher beforehand.

EEP standardization of the models

In order to ensure a uniform standard for rolling stock, the following dimensions are binding:

Rolling stock rail

Strict compliance with the standards on buffers

• Buffer height = 100 cm above the top edge of the track
• Distance between buffers, center = 175 cm

Rolling stock road

• standard lateral offset of 2 m / 200 cm, seen from the middle of the street
• Uniform coupling height for vehicles of the same type (cars, small trucks with trailers / trucks with semitrailers). Todo: Coordination among designers is still necessary here!
• all vehicles must be equipped with a driver
• Version with driving, brake and indicator lights

Real estate

• The guideline value for textures is 80-90 pixels x 80-90 pixels per 1 square meter model area. The lower limit is 50x50 pixels per 1 sqm model area (for areas far from the field of view, etc.)
• monotonous RGB color schemes without any surface structure should be avoided
• Building plinths should reach below the zero line of the Z-axis (-x) (-50 cm), since houses that are e.g. placed on a street spline with a footpath will otherwise "hang in the air".

Private and official models

Fehler beim Erstellen des Vorschaubildes: Datei fehlt

If a model was created with the HomeNos user version, it must be compiled again with the respective DEV version of the HomeNos after a design contract has been concluded. The reason for this is that the model has already been signed to the respective serial number of the user.

Zurück zur Startseite