Les objets (les fichiers *.obj dans Home-Nostruktor 13.0 ou les fichiers *.mod3 dans EEP), assemblés sur l'axe de base (Basis) ou sur plusieurs axes de déplacement, ne doivent être constitués que d'une seule construction, c'est-à-dire d'un RGD. Idéalement, le nombre de RGD et le nombre d'objets dans un modèle sont identiques. Cet objectif optimal ne peut être atteint qu'en réglant toutes les instances de tous les objets dans un modèle identique à cent pour cent, si possible avec le réglage du Backface-culling réglé sur l'option arrière et l'option d'éclairage sur normal. Si des instances avec des réglages différents sont utilisées, cela conduit automatiquement à la création d'autres RGDs et donc inévitablement à des pertes de performances perceptibles, puisque chaque nouveau RGD représente un facteur multiplicateur supplémentaire du pipeline de rendu.

Les objets construits avec Home-Nostruktor 13.0 et ultérieurs devraient également être élaborés selon la méthode de construction pelure d'oignon. Cela signifie que l'ordre des couches des polygones va de l'intérieur vers l'extérieur. De cette façon, il est possible d'éviter d'éventuelles fausses représentations en ce qui concerne la distance entre les surfaces. Depuis EEP 7.0, le problème de la précision en virgule flottante dans le calcul de profondeur a été résolu par le fait que la caméra ne se déplace plus dans l'angle le plus éloigné du système, mais qu'elle montre, dans une certaine mesure, un panoramique du système. Dans de nombreux cas, cependant, la conception en pelure d'oignon peut vous aider à éviter qu'un décalage Z ne soit obligatoire. Ceci permet de s'assurer qu'aucune instance avec des réglages différents et donc qu'aucun autre RGD ne peut être créé. Le principe de fonctionnement de la construction en pelure d'oignon avec ses avantages et ses inconvénients est expliqué en détail dans un chapitre séparé.

Malgré les capacités toujours plus étendues des moteurs de rendu 3D, les performances graphiques restent un goulot d'étranglement dans la représentation d'une scène virtuelle complexe. C'est pourquoi il est possible d'optimiser les objets pour le matériel graphique avant de les afficher en créant jusqu'à quatre niveaux de qualité pour chaque modèle, qui sont automatiquement permutés au fur et à mesure que la distance par rapport au spectateur augmente. Fondamentalement, chaque modèle qui possède une trame filaire de plus de 300 triangles doit avoir au moins un niveau LOD, c'est-à-dire une version simplifiée du modèle principal. Le degré de simplification et la distance du spectateur à laquelle le niveau de qualité suivant est modifié peut varier d'un modèle à l'autre, mais le point principal est que pour les objets moyens et distants (> 750m), seule une petite partie de la géométrie originale (nombre de sommets et de triangles) est calculée.

Le modèle 3D complet (y compris les objets sur les axes) n'a qu'une seule texture. Cela implique que tous les sommets de l'image filaire ont un ID de texture valide. Déjà au stade de la planification, mais au plus tard lors de la création de la texture, vous devez vous assurer que :

• Tous les composants du modèle sont reproduits avec une texture unique et suffisamment petite,
• La mosaïque éventuelle (répétition d'un motif ou d'un motif géométrique) est incorporée directement dans la texture.

Si plusieurs textures sont utilisées, ce qui correspondait aux premières directives de construction, aujourd'hui obsolètes et qui ne sont plus autorisées, Home-Nostruktor 13.0 essaiera de combiner les textures individuelles existantes en une texture globale pour le modèle afin de minimiser leur nombre. Ceci est également dû au fait que le nombre de textures utilisées est un multiplicateur du pipeline de rendu.

La recommandation logiquement n'appelle pas une mesure, mais fait appel à la volonté de compromis et à la raison du constructeur. La limite supérieure de résolution de 512 x 512 pixels a été supprimée, ce qui permet d'utiliser des tailles de 800 x 800 et/ou 1024 x 1024 pixels. Cependant, il faut garder à l'esprit qu'une taille de texture de 256 x 256 pixels permet d'obtenir le meilleur résultat en termes de vitesse de calcul, d'adressage de fichiers et de qualité d'affichage grâce au matériel et au logiciel. Tant qu'un système 32 bits est utilisé, cela ne changera pas.
Lors de l'exportation de modèles, il est essentiel de s'assurer que les dimensions de la texture globale du modèle généré ne dépassent pas 2048 pixels, afin d'optimiser au mieux les performances graphiques.
Les dimensions (largeur x hauteur) de la texture du modèle générées sont affichées dans la fenêtre de dialogue de la fonction d'exportation et sont également sauvegardées dans le fichier info log dans le dossier de réalisation, par exemple, sous une entrée telle que Création d'un texture globale : Sys_262.dds[DXT5].(1088x544). Si une ou même deux dimensions de la texture du modèle dépassent la limite de 2048 pixels, vous devez obligatoirement choisir une autre option de mise à l'échelle. La mise à l'échelle par défaut est de 100%, ce qui correspond aux dimensions d'origine, mais vous pouvez également sélectionner une mise à l'échelle de 75% ou 50%.

Même si la compression de texture S3 est une compression à perte et produit des artefacts, elle reste la méthode la plus largement utilisée que Microsoft a incluse dans DirectX ainsi qu'implémentée comme algorithme de décompression par tous les fabricants de cartes graphiques et de puces graphiques. Ce qui distingue cette méthode est le taux de compression constant, le faible besoin en mémoire et surtout la faible bande passante, ce qui est avantageux pour la taille physique du fichier et son adressage à l'opposé des textures non compressées qui produisent généralement un goulot d'étranglement dans le calcul 3D.
Dans Home-Nostruktor 13.0, la compression de la ou des textures pendant l'exportation est le réglage par défaut, qui doit être utilisé. Les textures opaques avec mélange alpha sont stockées au format DXT5 et non opaques au format DXT1. Si vous décidez de publier un modèle sans compression de texture, cela doit être mis en évidence et indiqué lors de l'installation du modèle. Vous pouvez également proposer un tel modèle sous le même nom, mais avec compression de texture, de sorte que le choix est laissé à l'utilisateur.

Le nombre d'axes est aussi un multiplicateur du pipeline de rendu. Par conséquent, un modèle ne doit contenir que le nombre d'axes nécessaires et le moins élevé possible. La construction des modèles dans lesquels les objets ont été placés sur des axes immobiles, pour des raisons de commodité ou d'ignorance, appartient au passé et devrait être évitée dans tous les cas. Les composants immobiles peuvent être importés rapidement et facilement dans d'autres objets ou dans l'axe de base (Basis). Lors de la configuration des signaux lumineux pour EEP à partir de la version 7.0, vous devez utiliser des ID de signaux lumineux qui, contrairement aux versions précédentes du programme (jusqu'à EEP 6.0), ne sont pas commandés par des axes mobiles. Ceci contribue de manière décisive à une vitesse de calcul plus élevée et améliore la lisibilité des images du signal.

Lors du nommage des axes, il faut respecter les noms réservés tels que Wasser (eau), qui ne peuvent être utilisés que pour des effets ou des fonctions très spécifiques. La convention d'écriture informatique habituelle, qui ne permet pas les trémas, les espaces ou les caractères spéciaux allemands, doit également être respectée. Les noms pour les axes mobiles devant être contrôlés par l'utilisateur doivent être stockés dans le fichier INI externe du modèle. Cependant, des trémas et des caractères spéciaux peuvent être utilisés dans ce fichier, qui est utilisé pour décrire les noms traduits dans la langue locale.

Lors de l'éclairage des modèles et des ID de signaux communs (par exemple pour l'éclairage supérieur d'une locomotive ou l'éclairage intérieur d'une maison), il est recommandé d'attribuer une couleur uniforme à tous les sommets des polygones éclairés afin de maintenir les niveaux de couleurs internes aussi cohérents que possible. Si tous les sommets d'une surface polygonale illuminée sont de la même couleur, le rendu filaire est beaucoup plus rapide. Les nuances de couleur ou de luminosité possibles à l'intérieur d'un polygone doivent donc être réalisées dans la texture et non par l'ombrage lisse (Smooth-Shading) ou Ombrage de Gouraud habituel, ce qui crée un gradient de couleur entre les sommets. La longueur et surtout le nombre de registres de couleurs, stockés comme adresses distinctes pour chacune d'entre-elle est déterminant. Si trois sommets d'un polygone sont de la même couleur, trois registres de couleur sont suffisants ; sinon, toutes les valeurs intermédiaires doivent être calculées et enregistrées comme adresses supplémentaires.