Vers un pack signalisation version 3

[jym26 434]

Bonjour à tous,

 

La nécessité d'une version améliorée qui respecterait mieux la signalisation réelle en réparant quelques erreurs de la version 2 et surtout mieux fournie en terme de possibilités est une évidence. Bernard a déjà fourni des scripts et une documentation qui répondent à, pratiquement, toutes les situations dont peut avoir besoin le créateur de ligne "standard" .

 

Il reste la création des quelques modèles 3D qui manquent et la modification de ceux existant de la version 2 qui demandent quelques aménagements (et l'écriture des 1700 et des brouettes de blueprints , j'ai bien failli les oublier ceux là).

 

Partant de cet état de fait, il m'a paru qu'il fallait en profiter pour améliorer les modèles 3D déjà existants. Donc me voilà parti pour carrément reprendre à zéro les signaux lumineux avec ce cahier des charges en terme d'amélioration par rapport aux modèles précédents :

 

- Améliorer l'aspect général en adoucissant les formes et en améliorant le respect des modèles réels.

- Améliorer le rendu des textures si possible.

- Mettre en place la gestion des ombres portées (absentes des version précédentes).

- Essayer, si possible, de trouver une technique de rendu des reflets lumineux des lampes sur les pare-soleils.

 

Le tout en sachant que le moteur 3D de RailWorks ne sait pas (ou ne veut pas ) gérer automatiquement les ombres des objets et qu'il ne sait pas reproduire une source lumineuse (ou en tout cas, moi j'ai pas trouvé ).

 

Pour les ombres elle doivent être crées en plus du modèle 3D en fabricant,en plus, un modèle 3d simplifié à base de cubes et autres structures de base uniquement. Les modèles complexes produisent des effets désastreux de redondances et d'étirements abominables .

Ceci exclue donc de faire une copie des modèles 3D des feux pour créer les ombres et demande des heures de patience et de tests pour obtenir un résultat à peu près convenable à partir de citrouilles pour obtenir des carottes (c'est une métaphore poétique, pour ceux qui prennent tout au 1er degré ).

 

Je passe sur l'aspect technique de la procédure (une spécialité KUJU) qui m'a demandé une semaine de tâtonnements et des recherche de documentation avant de comprendre le début du processus. Merci encore Monsieur KUJU.

 

Pour l'aspect des reflets lumineux c'est un vrai casse tête. Les espagnols en ont sur leurs modèles de feux, et la seule technique que j'ai trouvé, c'est une vieille ruse que j'avais déjà employé dans trainsim pour simuler les objets éclairés et qui consiste à appliquer une texture qui évoque les reflets lumineux. Une sorte de trompe l'œil. Vous constaterez l'effet sur l'image ci-dessous où sont représentés l'ancien et le nouveau modèle ( A celui qui me demande où se trouve le nouveau, je lui répond faut chercher, y a des indices dans le texte au dessus!).

 

 

 

 

 

 

Voilà, tous ceux qui ont des remarques constructives ou des idées d'amélioration voire même des techniques à me suggérer sont les bienvenues.

 

Je vous tiendrai au courant assez régulièrement des avancées du chantier, mais c'est du lourd quand même.

 

A bientôt,

 

Jean-Yves

Edited June 16, 2010 by jym26

[Spud 144]

Salut,

 

Je n'avais pas vu ce topic, Très intéressant cette chose, petite demande, serait il possible d'inclure des poteaux de grande hauteur, comme on peut en rencontrer dans certains triages ou certaines gare, juste les poteau où on pourrai y installer les feux qui sont normalement sur potence ?

 

 

Autre demande, serait-il possible de faire ces signaux :

 

Désolé je n'ai pas trouvé de meilleure photo pour ces signaux là...

 

 

 

 

Pour l'effet de lumière je dois dire que l'effet est assez bluffant, est très intéressant...

 

Impatient de voir la suite....

 

Bon courage pour cette 3ième version qui je pense sera la bonne comme on dit jamais 2 sans 3....

 

Bye

Edited June 21, 2010 by Spud

[Jules31 44]

Je me demande si la première photo représente un signal de cantonnement de BM/ (ou BAPR), ou un carré violet.

 

Comme il me semble posé à raz de terre, je pense qu'il s'agit d'un carré violet dont il manque les plaques d'identification et de repérage, dont les feux ne me semblent pas dans le bon sens (on voit mal la couleur sur la photo mais la coutume voudrait que le feu blanc se trouve en haut et le violet en bas) et qui se trouve dans une position verticale assez rare. S'il s'agit d'un signal de cantonnement de BAPR ou de BM (un feu rouge et un feu vert), ce signal que l'on voit modélisé est une grossière erreur car il ne se trouve jamais à ras de terre, il comporte des plaques d'identification et de repérage comme tout signal, et le feu rouge se trouve par coutume en bas et le vert en haut.

 

Concernant les carrés violets nains comme on en voit avec certitude cette fois sur la seconde photo, ils existent déjà dans le pack de JYM (dans leur version avec feux horizontaux comme on les retrouve dans 95% des cas). Ils se comportent dans le simulateur comme un simple signal d'arrêt à deux états et qui peuvent protéger des aiguilles. Avec les futurs scripts d'Henrion, ils risquent d'être pour l'instant sans fonction dû à la complexité de programmer fidèlement leur fonctionnement comme signal de refoulement.

 

D'ailleurs, sur un autre topic (lien ici, c'est la première remarque que je fais à JYM), j'ai fait quelques remarques sur leur aspect et en particulier concernant les plaques d'identification et de repérage.

Edited June 21, 2010 by Jules31

[Spud 144]

Salut,

 

Pour les 2 signaux nains, pour le premier, ce n'est que pour la forme du signal, que j'ai mis la photo, car c'est pour les cas ou l'entre voie ne laisserai pas la place au signal violet horizontal qui existe déjà dans les 2 précédents pack de signaux de Jym,

 

Et pour le deuxième signal il n'est là que pour montrer la plaque Nf avec le numéro, qui le numéro je pense dans la réalité est à côté du Nf et non pas en dessous.

 

Désolé je n'avais pas fait attention que tu parlais déjà dans ton message que tu parlais das plaques sur les carré violet.

 

Bye

[henrion 101]

Bonjour

 

Les photos présentées par Olivier représentent des signaux pour le modélisme ferroviaire. Ces derniers ne sont souvent pas conformes à la réalité. En ce qui concerne les carrés violets destinés aux rebroussements, ils ne sont actuellement pas prévus. Mais il est possible d'envisager d'en créer qui assurent la protection de l'aiguillage et le cantonnement sans interférer sur le reste de la signalisation. Par contre, l'intégralité des fonctions réelles de ces signaux ne peut pas être représentée actuellement.

 

Après les scripts mécaniques, je me pencherai sur les signaux de rebroussement des gares (carré et carré violet).

 

Pour les mâts, voici ce qu'il faudrait réaliser pour être conforme à la réalité:

 

[attachmentid=2280]

 

 

Cela fait dix possibilités de représentation par signal. Si cela ne fait qu'un seul script par signal, par contre il faut multiplier par dix le nombre de fichiers bin et donc le nombre de signaux dans l'éditeur. Sachant qu'à l'heure actuelle il est prévu 1700 noms de signaux cela représenterait donc 17000 noms dans l'éditeur. A partir du moment où il n'est pas possible de trier dans la présentation des noms cela me semble irréalisable ou alors il faut être très très doué avec la molette de la souris .

 

On pourrait toujours réduire le nombre de signaux puisque la moitié présente le rouge clignotant qui est quand même peu courant mais même avec cette moitié, cela représente encore 8000 signaux.

 

Faire un mât pour mettre dessus le signal pour nacelle peut être une bonne idée. Cependant, Jean-Yves fait ses signaux avec le F et NF inclus dans un même ensemble que le signal. Ces indications se trouvent normalement sur le mât.

 

Donc pour que cela soit faisable, il faudrait faire deux nacelles, une avec la lettre F et l'autre avec la lettre NF. A ce moment là il serait possible de faire un signal sans F ou NF qui pourrait se poser indifféremment sur nacelle et sur mât. Ainsi on pourrait créer tous les types de mâts possibles (haut, en drapeau) sur lesquels pourraient s'adapter tous les types de signaux. Cela permettrait de ne pas augmenter le nombre de signaux initiaux.

 

Ainsi, plus tard, il pourrait être possible de créer également les signaux pour implantation à droite et cela ne ferait donc que 1700 signaux x2 soit 3400 ce qui est encore acceptable dans l'éditeur.

 

Bonne journée

 

Bernard

Edited June 22, 2010 by henrion

[Spud 144]

Oups,

 

Faites comme si je n'avais rien dit, car à chaque fois j'ai l'art de poser des questions qui demande des rpéonses pas possible.

 

Pour les carrés violet Il existe donc des signaux avec et sans Nf ? ou pas.

 

Encore désolé d'avoir émis cette idée. Mais c'est parce que parfois sur ma ligne et je pense ce ne sera pas la seule ligne dans ce cas, c'est que certains signaux sont en courbe ou après un bâtiment et sont difficilement visible...

 

Bye

[henrion 101]

Pour les carrés violets, il sont tous avec la plaque Nf.

 

Ton idée n'est au contraire pas mauvaise du tout mais il faut avoir le temps de la réaliser et cela ne dépend pas de moi car les modèles 3D ce n'est pas du tout ma chose. Sinon je m'y serai déjà attelé depuis longtemps . Peut être que l'on y viendra avec le temps.

 

Bernard

[pml3 303]

...

Ainsi, plus tard, il pourrait être possible de créer également les signaux pour implantation à droite et cela ne ferait donc que 1700 signaux x2 soit 3400 ce qui est encore acceptable dans l'éditeur.

 

Bonne journée

 

Bernard

 

J'ai peur quand je vois le nombre de combinaisons possible !

Si jamais un concepteur à le courage de créer le meccano qui permette de tout faire, il sera le seul à savoir s'en servir...........

Sur un simulateur, il faut savoir aller à l'essentiel, et ne pas se perdre dans tout ce que la réalité a mis 50ans ou plus à créer.

 

Bravo pour la conception des scripts des signaux. Le LUA dans Kuju, c'est un sport à haut risque !

Une texture judicieuse pour simuler les effets de lumière : c'est parfait.

 

Patrick

[henrion 101]

J'ai peur quand je vois le nombre de combinaisons possible !

Si jamais un concepteur à le courage de créer le meccano qui permette de tout faire, il sera le seul à savoir s'en servir...........

Sur un simulateur, il faut savoir aller à l'essentiel, et ne pas se perdre dans tout ce que la réalité a mis 50ans ou plus à créer.

 

Bravo pour la conception des scripts des signaux. Le LUA dans Kuju, c'est un sport à haut risque !

Une texture judicieuse pour simuler les effets de lumière : c'est parfait.

 

Patrick

Le nombre de combinaisons ne doit pas faire peur . En fait, cela me semble moins difficile que de construire et programmer une loco.

 

Pour arriver , en terme de signalisation, à faire face au plus grand nombre de possibilités qui permettront de rendre RailWorks très proche de la réalité, et c'est je pense, ce que beaucoup attendent, il faut pouvoir répondre à 3 éléments:

 

1°) La construction des modèles 3D. Jean-Yves nous prépare une version sur pied à hauteur normale et pour implantation à gauche de la voie. Si l'on veut étendre les possibilités pour répondre à la question d'Olivier ci-dessus ou pour permettre à Geluc d'avoir des signaux conformes pour sa ligne d'Alsace, il faut créer en plus, comme je l'ai dit dans un de mes messages précédents, les 9 modèles de mâts ou nacelles supplémentaires et un modèle de chaque signal de type A, B, E, G soit 7 signaux en tenant compte des oeilletons inversés, ces derniers pouvant être créés à partir des signaux déjà existants. A partir de là on peut décliner toutes les possibilités.

 

2°) Le script. L'essentiel du travail est fait. Le plus dur a été de réaliser un script de base à partir duquel tous les autres scripts dérivent par ajout ou suppression de modules. Quand j'aurai fini les scripts, je ferai un document qui explique comment procéder car il faut bien transmettre le savoir. En fait, dans les scripts, le plus dur est la bonne écriture de la fonction ReactToSignalMessage qui permet à notre signal de présenter le bon état en fonction des messages envoyés par le signal suivant. Il ne faut surtout rien oublier dans cette fonction sinon les signaux ne marcheront pas correctement entre eux. Il y a donc un travail de préparation important pour réaliser cela mais ce n'est pas insurmontable . Le tableau ci-dessous montre le plus compliqué que j'ai eu à réaliser pour rédiger cette fonction. C'est juste à titre d'exemple car je ne vais pas me lancer dans une explication. Cela sera détaillé dans le document à venir. Il manque des états qui sont communs à tous les signaux de ce type et qui font l'objet d'un autre tableau.

 

[attachmentid=2281]

 

Chaque signal donne bien évidemment lieu à un tableau différent.

 

Contrairement à ce que l'on peut croire, il ne faut pas forcément connaître le langage LUA pour écrire des scripts. Personnellement je n'ai aucune connaissance de ce langage. Je marche uniquement avec mes souvenirs de la programmation en langage BASIC des années 80 dont sont dérivés le langage C, C++, LUA. Mais une fois que l'on sait qu'un if doit être suivi d'un then, qu'une autre possibilité se traduit par un elseif et qu'en final le tout doit se conclure par un end, après ce n'est qu'une question de logique entre les modules ou fonctions. Les scripts de Kuju, même s'ils sont particulièrement confus permettent cependant d'aider à comprendre le fonctionnement.

 

3°) Après il y a enfin à modifier les fichiers bin pour dériver les signaux dans leurs nombreuses possibilités et le nombre de liens différents. Dans chaque fichier bin il n'y a que cinq noms et chiffres à modifier. Quand j'ai fait les 1700 fichiers bin initiaux je pensais mettre au moins quinze jours mais j'ai adopté une technique qui m'a permis de mettre moins d'une semaine. Par contre cela est parfaitement soporifique à faire .

 

Après reste le problème de l'installation par le créateur sur les lignes. Et c'est là la difficulté majeure par manque des connaissances de base. J'ai fait un document qui débroussaille la façon de bien choisir les signaux et la façon de les installer, mais cela ne résoud pas tout si le créateur n'a aucune connaissance dans ce domaine. Mais il y a des personnes compétentes en la matière sur ce forum qui peuvent donner tous les conseils voulus.

 

Enfin, le conducteur du train doit aussi connaître parfaitement la signification des signaux et là aussi c'est un autre problème.

 

Il ya quelques sites comme celui-ci: http://pagesperso-orange.fr/geillon/trains/signaux/ qui expliquent la signalisation.

 

Mais je crois, qu'au niveau de la signalisation, nous allons arriver à faire quelque chose de très correct et se rapprochant au mieux de la réalité.

 

Bonne soirée

 

Bernard

Edited June 22, 2010 by henrion

[Jules31 44]

Je doute dans l'idée de leur concepteurs que le C soit l'héritier du Basic. Le BASIC a juste été crée pour créer un langage de haut niveau bien plus accessible que le langage de programmation de référence dans les années 60 : Le Fortran. D'ailleurs, l'acronyme BASIC suffit à lui même pour comprendre : Beginner's All-purpose Symbolic Instruction Code". De plus, ne pas oublier que ce qui a fait presque exclusivement son succès et la fourniture d'interpréteurs BASIC avec les premiers PC et son intégration dans nombre de calculatrices programmables.

 

Le C a été crée plus tard par Bell sans aucune référence ou parenté directe avec BASIC (hormis le fait qu'il soit aussi un langage impératif) pour offrir un langage bas niveau et leur permettre de rendre alors leur premières version du système d'exploitation UNIX plus portable.

 

Henrion, tu as appris forcément le langage LUA, en particulier sa syntaxe, sinon tu n'arriverais pas à exécuter sans erreur le moindre script La connaissance dont tu parles est celle que tu disposes en algorithmie et qui te permet de concevoir des traitements en programmation dite impérative (comme avec le langage LUA dans RW,comme avec le langage C, Pascal, Fortran, Basic, etc). Comme tout langage impératif, LUA te permet d'écrire des séquences d'instructions à exécuter (et la séquence logique que tu écris est un algorithme, cqfd). Il existe d'autres formes de programmation (d'autres paradigmes pour utiliser le bon terme...) qui ne font pas appel à des algorithmes, comme la programmation fonctionnelle (exemple le langage Caml) ou la programmation logique (comme le langage PROLOG).

 

Bref, refermons la parenthèse historique et informatique et revenons aux signaux.

 

Pour la simplicité souhaitée dans la signalisation dont parle pml3, je ne pense pas que cela soit la solution pour un simulateur si cela réduit les fonctionnalités offertes, même si je comprends le désarroi de certains face à la complexité de la chose. Par contre, de la rationalisation, oui !

 

Je ne pense pas que la difficulté, si difficulté il y a, réside dans l'utilisation de la signalisation et la connaissance de ses principes. En effet, Elle ne tient pas selon moi dans les principes de tel ou tel type de signalisation modélisé mais plutôt dans l'implémentation qui en est faite par les concepteurs et par le fonctionnement des liens qui en découle. Pour les liens et du point de vue de l'utilisateur, si tu as le manuel d'utilisation associé qui explique comment les utiliser facilement pour chaque signal, je ne vois pas où est le problème d'avoir un peu de complexité.

 

Pour en revenir à la complexité de la signalisation, c'est un problème inhérent au système ferroviaire que l'on veut simuler. Il n'y a pas en général en matière de sécurité de choses essentielles et d'autres qui ne le sont pas. C'est un tout qui doit être indissociable. De plus, l'histoire de la signalisation ferroviaire à laquelle tu fais référence PML3 ne va pas comme tu le laisses supposer vers une plus grande complexité, du moins pour le conducteur qui doit la respecter.

 

Regarde la liste chronologique suivante qui va te montrer l'évolution, avec chaque fois une progression en terme de sécurité (les administrations chargées de la sécurité ferroviaire n'homologuent d'ailleurs depuis toujours que des nouveaux systèmes qui sont au moins autant sécuritaires que les anciens, c'est la loi) :

 

- l'époque des anciennes compagnies avec chacune leur code et règlement,

 

- le code verlant de 1930 qui a introduit une grande harmonisation (et qui n'a pas touché que le ferroviaire, ne pas l'oublier, car c'est lui qui a introduit le code rouge/jaune/vert que l'on utilise partout),

 

- l'introduction de la règle de combinaison des feux lumineux et des signaux lumineux (dont on a parlé dans un autre topic), règle qui simplifie grandement la signalisation car elle ne présente avec cette nouvelle règle que l'information la plus restrictive (avant, quand tu voyais un avertissement fermé combiné à un carré ouvert, tu avais un feu au moins allumé pour chacune des deux informations (pas sympa pour un mécano dans sa machine à vapeur),

 

- l'introduction de la TVM qui permet d'afficher directement en cabine des signaux, et encore mieux, on affiche dorénavant des vitesses de consigne à appliquer au prochain repère (c'est encore bien plus parlant qu'un ensemble de lampes de couleur allumées). Encore mieux, originaire d'Allemagne où il équipe toutes les lignes à VL > 160 Km/h, un système de signalisation à transmission continue également, nommé LZB, permet le pilotage automatique des rames équipées à partir des vitesses de consigne et des distances but,

 

- le nouveau système de signalisation européen ETCS offre (et offrira) dans toutes ses variances un système harmonisé, avec présentation des informations directement en cabine (style TBL2/3 pour les connaisseurs des systèmes belges avec vitesse cible et distance but) et un contrôle complet à bord du respect des indications données.

 

Pour nous, c'est bien la fidélité de la conduite qui nous intéresse dans la simulation (hormis ceux qui jugeront que non car un simulateur ne sert qu'à s'offrir une simple ballade dans de beaux décors). De plus, veux-tu qu'en plein milieu de ton voyage sur RW tu te fasse déglinguer dans un tête à tête avec un autre train à 160 Km/h ? Je ne pense pas car tu veux rouler avec une signalisation la plus simple, souple et fidèle à la réalité que possible, et tu veux rouler avec la plus grande sécurité que tu pourrais avoir (sauf si tu veux faire un simulateur de crash-test). Chemin de fer réel ou simulateur, c'est pareil. Tout cela a forcément un coût à supporter, et actuellement sur les simulateurs, ce n'est pas trop celui qui fait les modèles 3D qui la subit mais plutôt celui qui comme Henrion se cogne la logique de fonctionnement de la chose avec des tonnes de paramètres. A remarquer néanmoins que plus le système simulé est et de conception ancienne, plus la complexité se déplace vers le modèle (entre un signal mécanique et un repère TVM, il n'y a pas photo pour savoir où se trouve la complexité).

 

Pour moi, ce travail qui est fait sur le BAL est un moindre mal. Je ne vois pas ce qui est moins essentiel qu'autre chose parmi tous les signaux de BAL qui sont traités. On a en plus les compétences en 3D, on a les compétences en programmation, faisons le plus de choses possibles, même les feux rouges clignotants, même les bandes jaunes. Faisons le bien et de manière rationnelle pour l'utilisateur, le tout pour son bonheur car il pourra conduire fidèlement un train et faire apparaître une signalisation la moins bridée que possible sur ses lignes. De plus, on essaie de concevoir des systèmes évolutifs (futur BAPR, liens avec des futurs signaux mécaniques, carré violets de refoulement, etc). Donc même s'il manque des choses, on prévoit ce qui manque (du moins on essaie d'oublier le moins de chose possible, et vous pouvez également nous y aider !!!!!!!!!). Que du bonheur non ?

 

Concernant les connaissances nécessaires en signalisation, voila ce que je pense. Pour le créateur d'une ligne, s'il veut équiper sa ligne d'une signalisation, il me semble qu'il vaut mieux qu'il s'y connaisse dans le domaine comme le fait si bien remarquer Henrion. Si ce n'est pas le cas et qu'il veut apprendre, dans ce cas, il trouvera ici même des personnes qui sauront l'aiguiller et lui transmettre le savoir. S'il bloque sur l'utilisation qui en est faite dans RW, c'est que les concepteurs des signaux n'ont pas fait leur boulot de fournir un vrai manuel d'utilisateur (ce qui ne semble pas être être la volonté des intéressés), et si cela arrivait, je pense que je serais l'un des premiers à les engueuler gentiment

 

Tout va bien dans le meilleur des mondes donc Don't panic buddy ! Si on est dans l'erreur caractérisée, tirez tout de même le signal d'alarme et accrochez vous, car le freinage d'urgence, ca peut être violent :lol:

 

Et pour finir, n'oublions pas une règle de base : si vous voulez conduire un train sur une ligne, même sur un simulateur, il vaut mieux que vous connaissiez les règles de la signalisation, sinon abstenez vous

 

Bonne nuit les petits et les grands !

Edited June 23, 2010 by Jules31

[henrion 101]

Bonjour

 

@Jules31

 

Désolé mais je confirme que je n'ai pas appris la programmation LUA. Je n'ai programmé que sous BASIC (années 80) et sur la base de données DBase 3+ (années 90). Je n'ai appris aucun langage de programmation depuis. D'ailleurs j'ai découvert qu'il existait une programmation LUA avec RailWorks car je n'en avais jamais entendu parler auparavant. C'est en traduisant le document sur la signalisation que j'ai découvert la syntaxe de la programmation LUA. J'ai ensuite regardé les scripts de Kuju et j'ai passé beaucoup de temps à les décortiquer et à voir comment les choses s'enchaînent logiquement et quelle était la syntaxe utilisée. D'ailleurs, je suis conscient que j'ai encore beaucoup de choses à apprendre et surtout à comprendre sur ce type de programmation.

 

Bonne journée

 

Bernard

Edited June 23, 2010 by henrion

[Jules31 44]

Bah tu apprends le langage par sa pratique et tu assimiles petit à petit sa grammaire. Tu n'es pas à un niveau confirmé mais tu possèdes les notions.

 

Pour moi tu connais quasiment le langage Et puis, ce n'est qu'un langage de script, et ce type de langage est super basique par rapport à un langage type C. Tu ne gères rien de bas niveau et l'utilisation est énormément simplifiée. Tu l'assimilerais bien vite je pense avec tes connaissances (quand tu vois la tronche de la doc de l'API...).

Edited June 23, 2010 by Jules31

[jym26 434]

Bonjour à tous,

 

Je constate avec bonheur que le sujet passionne à juste titre. Même si je ne réponds pas à tous les messages, je prends bonne note des remarques qui sont apportées et qui me semblent judicieuses. Je retiens l'idée d'Olivier pour les mats de plus grande hauteur, puisque je refait touts mes supports ce sera assez facile à réaliser. Mes mats ont déjà été modifiés depuis la version 2. Le pied à subi une cure d'amaigrissement plus conforme avec la réalité, du coup les plaques Nf et F se retrouvent donc à dépasser des mats comme dans la réalité. c'est rien mais j'ai du leur faire une face arrière qui n'était pas nécessaire avant, (pas un gros boulot quand même, faut pas pousser ).

 

La gestion des ombres demande un temps considérable pour obtenir un rendu correct. Le moteur 3D étant particulièrement capricieux dans ce domaine, il faut tester en réel chaque modification .

 

La gestion des reflets des lumière des lampes va demander un travail conséquent pour un bon rendu de jour comme de nuit. L'effet n'étant qu'une illusion d'optique et non un calcul fait par le moteur 3D, il faut trouver un compromis.

Et puis tout se paie, un travail soigneux demande plus de temps. Il va falloir être patient. De plus la période estivale n'est pas le plus propice au travail sur l'écran, faut bien profiter un peu du grand air .

 

Par exemple, entre les déplacements professionnels en semaine et les weekends au bon air, j'ai pas avancé beaucoup. Mais j'y pense qu'en même.....

 

A bientôt à tous,

 

Jean-Yves

[jym26 434]

Bonjour à tous,

 

Un petit mot pour vos donner des nouvelles. Je me suis remis au travail sur la version 3 de la signalisation.

 

Je tenais à obtenir un rendu assez réaliste au niveau de l'éclairage des feux. Le problème restant entier au niveau l'absence de gestion d'une émission de lumière dans RailWorks et donc obligatoirement des reflets qui vont avec, j'ai donc contourné le problème en appliquant une texture qui simule le rayonnement de la lampe lorsqu'elle est allumée. C'est pas ce qui est le plus dur à réaliser sur un objet quelconque, mais ici il s'agit de simuler le reflet d'une lampe de signal qui s'allume ou s'éteint au gré du fonctionnement normal des signaux commandés par les scripts selon les évènements du simulateur. L'application des textures des reflets lumineux doit donc être directement liée avec le script qui commande le signal. De plus ces textures doivent avoir un rendu acceptable de jour comme de nuit .

 

Il m'a fallu quelques mois de travail pour trouver, à force de tâtonnements, des solutions qui marchent pas trop mal.

 

Voilà ci-dessous la dernière version du Signal Cible A sur pied.

 

 

Il me reste à travailler sur les lods des feux pour améliorer la distance de visibilité, quelques retouches sur la structure et les ombres.

 

Puis créer les blueprints de toutes les variantes du signal en utilisant les scripts de Bernard, qui donnent toute satisfaction aux premiers essais ( ce sont les les scripts qui donnent toute satisfaction, pas Bernard...quoique.... il nous fait un sacré boulot, merci encore Bernard )

 

Enfin créer les versions sur mats surélevé puis sur nacelle et après cela........ passer aux signaux sur cible B etc.... C'est pas dis que ça sorte pour Noël..... .

 

Voilà,

 

A bientôt,

 

Jean-Yves

[thebogie 4]

bonjour

la signalisation sur ma ligne ne sera pas réaliste , pas d'expérience et difficile a comprendre , malgré tout je souhaite apporter une protection basic comme on pourrait le faire sur un réseau HO je pense , avec un seul signal sa doit être réalisable , si oui le quel me conseillé vous .

ou je fait un appel d'offre , a celui d'entre vous , pour réalisé la signalisation une fois ma ligne terminé bien sur son pseudo figureras a coté du mien , ( il y aura un premier pack gratuit d'une trentaine de kms a voie unique juste des petites portions a double voies .

[henrion 101]

Bonjour

 

Je pense que dans le cas de cette ligne, une signalisation mécanique sera plus appropriée. Geluc va sortir prochainement sa signalisation mécanique. Le sémaphore pourra faire l'affaire.

 

Bernard

[thebogie 4]

Bonjour

 

Je pense que dans le cas de cette ligne, une signalisation mécanique sera plus appropriée. Geluc va sortir prochainement sa signalisation mécanique. Le sémaphore pourra faire l'affaire.

 

Bernard

OK , bon déjà je sais que je ne vais pas être lâcher en pleine nature , donc j'attends le sémaphore de Geluc et puis il n'y a as le feu .

merci a toi henrion pour ton aide

[nicolas 1,030]

Salut.

Je n'ai pas vu trop de changement enfin, y en a mais dont je ne me souciais pas du tout et en plus je ne l'avais remarquer. L'effet de lumiere qui se réflechis m'a par contre beaucoup étonner, on dirais un vrai. La qualité semble aussi meilleur. Personnellement pour moi la version 2 étais trés bien. La version 3 sera encore mieux ,avec des changements.

 

Bravo!!

 

[Spud 144]

Salut,

 

Bravo et surtout bon courage pour le travail que tu fais sur la signalisation Jym, c'est en partie grâce ou a cause d'Henrion s'il y a une version 3 des signaux Et il y aura beaucoup de changement au niveau des scripts ce qui apportera une touche de réalisme supplémentaire au simulateur.

...mais ce qui ne facilitera pas la vie aux créateurs de routes car là il ne sera plus possible de dire je mets un feu rouge à l'aiguillage et s'est bon vu la quantité de signaux qu'il a scripté...

Mais bon on ne peut que saluer l'acharnement qu'Henrion a eu avec les PN mais le résultat est là un PN on ne peut plus réaliste et simplifié. Le bonheur pour le créateur de route...

 

alors avec les signaux... en ayant Jean Yves et Henrion aux commandes ça va donner quelque chose de très réussi.

 

 

Donc impatient d'avoir des nouvelles même si on espère une sortie avant noël ... 20.. bah il y a 88 possibilités je ne suis pas trop pressant comme ça :lol:

 

Aller bon courage pour la suite...

 

Bye

[jym26 434]

Bonjour à tous,

 

Dans la famille Panneau A, je voudrais le grand frère de droite :lol: .

 

 

Voilà, la famille s'agrandit. Désormais chaque type de signal sera disponible en 5 versions. Sur mât normal implantation à gauche ou à droite, sur mât haut implantation à gauche ou à droite et sur nacelle (j'entends d'ici les alsaciens sauter de joie ). Ce qui fait déjà pour les 8 scripts disponibles en panneau A ....40 modèles (ils ne possèdent qu'un seul lien) .

 

Le panneau B en cours de réalisation possèdera 480 modèles avec les liens classiques (1, 2, 3 ,4 ,5 ,6 ,7 ,8 ,9 ,10, 12, 15 liens) . Ceux qui n'ont pas encore de molette sur leur souris vont pouvoir s'équiper pour faire défiler tout ce monde dans la fenêtre de l'éditeur.

 

Les possibilités d'équipement en matière de signalisation lumineuse vont atteindre des proportions qui devraient rassurer les plus exigeants des créateurs .

 

Voilà, allez! J'y retourne....

 

A bientôt.

[GerardS 539]

Bonjour

jym26

Formidable tes signaux de plus, une signalisation à implanter à droite, je n'osai pas l'espérer.

Cordialement

Geluc

[Spud 144]

Salut,

 

Ca avance... intéressant les signaux sur mât haut.... et en plus il y a des signaux a droite.... ce sera bien pour les signaux dont l'implantation ne peux se faire qu'à droite, et je pense qu'il yBye en a un parmi nous qui en rêver sans oser le voir se réaliser.

 

Bonne continuation et bon courage pour les signaux de type B....

 

Bye

[jym26 434]

Recoucou,

 

Bernard me susurre à l'oreille que ce n'est pas 5 modèles par signal mais bien 6 qu'il faut créer. En effet le modèle sur nacelle a également sa version à gauche et à droite, l'œilleton et la plaque F ou Nf ne sont pas du même coté selon l'implantation.

 

Donc, les calculs étant refait cela nous donne 48 modèles pour les 8 scripts des signaux à 1 seul lien et 576 modèles au minimum pour les autres .

 

Bon...Ben au boulot donc...

 

Jean-Yves

[jym26 434]

Bonjour,

 

Le travail avance.... :

 

Voici les familles Cible A et Cible B au complet.

 

 

 

Voilà, je continue la suite....

 

A bientôt,

 

Jean-Yves

[henrion 101]

Excellent travail!

 

Je suis prêt à t'envoyer les scripts des panneaux E dont j'ai déjà modifié le nom des mods pour être conforme avec ta dénomination.

 

Bernard