Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

pierreg

Membre
  • Content count

    1,509
  • Donations

    0.00 EUR 
  • Joined

  • Last visited

  • Days Won

    124

Posts posted by pierreg


  1. Bonsoir,

     

    Voilà une trés bonne nouvelle ! Elle est belle, complète et dans le jeu donc :rolleyes: un très grand pas est fait. Ce qui t'arrive ne vient pas forcément du modèle :unsure:

    C'est un problème déjà rencontré et qui peut venir des "blueprints" si la déclaration des Axes de bogies et d'essieux n'est pas strictement faite dans l'ordre "de l'avant vers l'arrière" dans les blueprints Engine (rubriques Bogey) et Bogies (rubriques Axle).

    Néanmoins il faut aussi vérifier l'orientation du repère du corps du modèle dans le modeleur 3D.

     

    Bravo en tout cas et bon courage pour la suite de ton superbe projet !

     

    A+

     

    PierreG

     


  2. Bonjour Julien,

     

    :) Mais le but de ce "fil" est surtout d'être enrichi par les expériences des autres avant de devenir une référence !

    J'avais remarqué que sur plus de 80 sujets dans cette rubrique, je n'en ai vu que 2 qui traitaient du sujet :( .

     

    Voici les autres points "à pièges" que je prépare concernant le matériel moteur (ce n'est pas dans un ordre pédagogique) :

    - hiérarchie du dossier "Source" et création de blueprints,

    - intégration d'une loco diesel,

    - quelques trucs 3DCanvas vers RS

    Les contributions sont les bienvenues :)

     

    A+

     

    PierreG

     

     


  3. Bonjour à tous,

    Première rubrique d'aide à l'import de matériel roulant dans RS

    On suppose que le modèle 3D a été réalisé, que sa hiérarchie est correcte avec les noms de noeud adaptés au moins pour les essieux (1_1000_bo01wh01, etc...), que tout est texturé et que les noms des shaders sont corrects. En principe le modèle ne doit pas comporter d'attelage mais uniquement le crochet lié au chassis.

    Comme il n'existe pour l'instant pas de procédure automatisée pour intégrer les caractéristiques géométriques du modèle dans les fichiers XML nécessaires à la simulation, il faut avant tout noter un certain nombre de paramètres sur le modèle qu'il faudra entrer avec le BluePrintEditor. Les voici dans le schéma ci-dessous avec les libellés que vous trouverez dans l'éditeur.

    On remarque tout de suite une certaine incohérence : certaines valeurs sont des longueurs et d'autres sont des coordonnées avec l'origine à la surface de roulement des rails et à l'aplomb du centre de la "Collision box" (en grisé ci-dessous). L'axe oY est vertical. On remarque que le volume appelé "Collision box" n'est pas la "bounding box" bien connue en 3D et englobant tous les éléments du modèle. Cette "box" ne comporte ni les organes de choc, ni les essieux et leurs équipements.

    wagon_data.jpg

    Le premier exemple est celui d'un simple wagon à deux essieux : il comportera au moins deux "blueprints" . Celui du wagon " wagon blueprint " et celui des essieux " Bogey blueprint ".

    La documentation et les tutoriels existants ne me paraissant pas très clairs sur le sujet, voilà mon interprétation :

    Dans le "wagon blueprint", c'est d'abord la rubrique " Rear coupling receiving point " qu'il faut renseigner :

    - Front Pivot x et Back Pivot x : il s'agit des coordonnées du point de jonction des attelages du wagon attelé : si les tampons sont collés, c'est donc la position horizontale de la surface extérieure du tampon. Les valeurs de "Front Pivot y" et "Back Pivot y" devraient être la position verticale du centre du tampon (1.06 à 1.075m) mais en général elles restent à 0. ou -0.5 (??) et personne n'a vraiment trouvé si elles étaient utiles...

    - dimensions de la " Collision box " comme ci-dessus : si la "Collision box" définie empiète sur le rail (1/2 hauteur supérieure au "center y") votre wagon explosera littéralement en l'air dès que vous tenterez de le mettre sur une voie... De même si sa longueur est supérieure à la somme des distances des "pivots", il sera impossible de l'atteler à quoi que ce soit et même résultat.

    La longueur de la "Collision Box" définit implicitement les points d'appui sur les tampons lors d'un accostage (sans doute une erreur dansRW) : pour que les tampons se touchent et ne "se rentrent pas dedans" il faut que le paramètre "Collision Length" soit égal à [(longueur entre Front et Back Pivot) - 0,60] comme ci-dessous :

     

    tampon_colle.jpg

    Il faut ensuite, même pour un 2 essieux, remplir la rubrique " Bogey " avec uniquement la référence au "Bogey blueprint" utilisé.

    Après avoir fait "Save", ouvrir le " Bogey blueprint " et informer les rubriques " Axles "

    - On donne dans l'ordre de l'avant vers l'arrière, la coordonnée horizontale de l'axe de l'essieu avant, le nom de son noeud dans le modèle 3D puis la même chose pour l'essieu arrière. On laisse les paramètres de "Pivot offset" à 0. Ils ne sont utiles que pour les bissels paraît-il.

    Faire "Save" et "Export" .

    - On réouvre le "Wagon blueprint" et on informe les rubriques obligatoires : " Train Brake assembly " avec des valeurs par défaut, " Secondary named texture set - Blueprint set ID " avec les références au fichier 3D .IGS du modèle (attention à votre hiérarchie) et " Cargo component - cargo def " avec "Bulk cargo def" par défaut.

    Faire "Save" et "Preview" .

    - Si vous avez des messages d'erreur de l'éditeur, c'est le moment de les lire. Si des textures ne sont pas trouvées, elles sont signalées.

    - Si en "Preview", seul un petit élément gris est affiché , il manque au moins une référence quelque part : soit au fichier IGS, soit au "Bogey blueprint" nécessaire.

    - Si l'AssetEditor se plante dès qu'on le lance, vérifiez votre modèle 3D :
    - tous les éléments doivent être texturés,
    - il ne doit pas y avoir d'arêtes ou de sommets non rattachés à des faces .

    - Si le modèle est affiché dans la fenêtre de l'AssetEditor, nous sommes sur la bonne voie ! Il faut maintenant positionner les attaches des attelages :

    blped4.jpg

    Les 4 positions à définir correspondent aux 4 rubriques en bas à gauche. La flèche verte du "bilboquet" doit toujours être dirigée vers l'avant du wagon.

    " Coupling " et " Coupling receiver " correspondent à la position en 3D du crochet receveur de l'attelage (positions marquées A et B dans le schéma ci-dessus). C'est une bonne idée de le faire interactivement en 3D mais le fait que le "bilboquet" de positionnement n'est jamais caché par le modèle ne facilite pas les choses !!

     

    Depuis TS2014, les matrices de positionnement sont accessibles dans le Blueprint Editor, ce qui permet d'être précis compte tenu des définitions des points selon ci-dessous pour l'attelage avant :

    post-1028-0-23442600-1393172507.jpg


    Faire "Save" et "Export" .... puis lancer RS etc...


    Le cas d'un matériel à bogies est assez semblable. Il faudra simplement fournir les positions relatives des axes sur chacun des bogies en respectant toujours l'ordre de l'avant vers l'arrière. Ci-dessous le schéma : l'avant est à droite de la figure.

    bogies_data.jpg




    On suppose connu la création des blueprints et la hiérarchie nécessaire (plus de détails sur mon site en cours de construction http://ajrailsim.free.fr/, rubrique "Modélisation")


    A+

    PierreG


  4. Bonjour à tous,

     

    Jules31, à propos de ton post sur le langage LUA : merci. :) Je l'ai lu, je me suis dit : "on verra plus tard, on ne va pas se disperser". Et puis, comme je l'ai lu sur UKTrainsim, à quoi bon développer une signalisation spécifique si la moindre rame AI n'arrive pas à la respecter ?...

     

    Au risque de ne plus rester dans la bonne rubrique (PN automatique : Julien, tu peux déplacer :rolleyes: ), je veux quand même répondre au reste de tes propos en donnant mon impression :

    Bien sûr les développements pourraient se faire de façon plus coordonnée mais depuis six mois que je me suis vraiment mis à RS et parcouru les forums un peu partout, l'impression est la même : RailSimulator a promis beaucoup mais il est totalement démotivant pour les développeurs.

     

    Que ce soit aux US, en Angleterre, en Allemagne, en Italie ou en Espagne, au bout de 18 mois, il y a très peu de choses nouvelles opérationnelles et terminées. Pour ce qui est du matériel roulant freeware, il me semble qu'il y a moins d'une vingtaine de modèles publiés dont la moitié sont des transpositions de modèles MSTS et beaucoup sont incomplets (ombres, cabine, sons, etc...).

    Chez les anglo-saxons donc, je ne vois pas en quoi ça se passe mieux : ça cause plus (avec un tout petit nombre de compétences pointues) car ils sont plus nombreux, c'est tout...

     

    À mon avis cela n'est pas une question d'organisation mais tient à deux raisons : le marché du simulateur ferroviaire "ouvert" est étroit et TrainZ et MSTS l'ont épuisé dans tous les sens du terme : on a vu, on a joué et seuls les très mordus sont restés fidèles. Les fidèles ont vieilli, leur motivation a changé de domaine et la nouvelle génération prête à retrousser les manches pour mettre le nez dans le cambouis est encore moins nombreuse que la précédente.

     

    Quelques développeurs passionnés se sont mis à RS, d'autres ont attendu MSTS2 mais le marché semble bien terminé. De plus RS, à part un rendu graphique amélioré mais mal finalisé, se révèle totalement défaillant sur le réalisme de l'exploitation ferroviaire qui pourrait faire l'intérêt d'un tel logiciel (TrainZ avait pris initialement le parti "ludique" avec un peu plus de réussite).

     

    RS est un jeu et le développement pour RS est en général un loisir (certains font de la programmation pendant leurs loisirs) mais ce développement doit aboutir sinon, ce n'est plus un loisir, c'est une "galère". Je n'ai aucune compétence sur la programmation de la signalisation (je n'ai pas lu la doc) mais à lire les forums j'ai compris que le problème était le même que pour le matériel roulant : un paquetage très prometteur mais une foule de points de détail non résolus. La mise au point et la finalisation d'un matériel roulant dans RS consomme énormément de temps et de patience (alors que la modélisation 3D est souvent gratifiante en elle-même). Je vous ai d'ailleurs promis une petite FAQ évolutive sur le sujet... Ce sera ma façon de faire avancer les choses.

     

    RailSimulator 2 risque de n'être rien de plus qu'un réétiquetage "a minima" du même logiciel avec quelques addons mais avec les mêmes bugs : sinon ça se saurait et l'équipe compétente n'aurait pas le temps de blogger comme elle le fait...

     

    A+

    PierreG

     


  5. Bonjour Loïc,

     

    Non, les fichiers ACE ne sont pas les mêmes que ceux de MSTS mais ce n'est pas vraiment un problème. On peut passer de l'un à l'autre :

    MSTS ace -> TGA avec TGATool et TGA -> RS ACE avec ToAce

     

    Tu trouveras la nomenclature dans la doc 4.07 Train Guidelines page 8 et un bon exemple d'utilisation dans la doc 9.01 How to create an Engine.

    Il y a par ailleurs un bel exemple d'incohérence dans la doc 4.07 :angry: je crois. Les bogies et les essieux sont présentés comme des modèles à part (à la TrainZ) alors que dans les faits, il faut les intégrer au modèle avec leurs repères locaux bien positionnés.

    Bon courage....

     

    A+

     

    PierreG


  6. Bonjour à tous,

     

    Un peu de trafic SNCF dans la gare de Béziers. D'abord un grand merci à l'auteur de la ligne. :)

    Image IPB

     

    Les matériels que vous voyez sont fonctionnels mais nécessitent encore pas mal de boulot au niveau aspect (ombres et shaders en particulier). J'ai d'abord voulu tester l'intégration d'un matériel dans le jeu en utilisant mes modèles MSTS. C'est plutôt le b...azar, comme dans MSTS à ses débuts, car c'est à coups d'essais-plantages qu'on y arrive.

    Comme tous ceux qui ont intégré un matériel dans le jeu, j'ai rencontré de multiples pièges mais qui peuvent être en partie dépendants du modeleur utilisé. J'utilise 3DCanvas et je vais préparer une première liste des "pièges" que j'ai rencontrés et plus ou moins résolus pour l'intégration du MATÉRIEL (pour les objets, il y en a sûrement mais peut-être pas les mêmes).

     

    Même après avoir lu les 400 pages de doc développeur, parcouru des dizaines de forums et suivi des tutos, je n'ai pas vraiment trouvé ce genre de liste. :(

    Par exemple :

    -checklist à faire si le modèle apparaît comme objet mais n'apparaît pas comme matériel dans la vue de l'Asset Editor

    -checklist à faire si le wagon explose en l'air lors du lancement du scénario qui le concerne

    -checklist à faire si RailSimulator plante lorsqu'on veut démarrer une loco

    etc...

    plus des bugs RS manifestes.

    Comme je suis débutant sur RS, je pense que d'autres plus aguerris auront des informations à apporter.

     

    A+

     

    PierreG

     

     


  7. Bonjour à tous,

     

    Je pense qu'il est nécessaire de rappeler un certain nombre d'informations sur Rail Simulator : depuis octobre 2007, Electronics Arts et Kuju ne sont plus concernés par Rail Simulator. Compte tenu du marché, ils n'ont pas vu la nécessité de continuer à soutenir et à développer le produit. Alors que l'équipe de développement comportait chez Kuju plus de 40 personnes, celle-ci a été dissoute et seul un tout petit nombre (moins d'une dizaine il me semble) de développeurs ont eu le courage de se lancer dans le support de RS et le développement d'ajouts : pour cela, ils ont fondé une petite société de droit britannique appelée "Rail Simulator Developments Ltd" (alias RSDL).

     

    Pour continuer le support de RS, des accords ont bien sûr été passés avec Kuju et EA et, à ma connaissance, leur contenu n'a pas été rendu public. En tout cas, voilà des courageux qui ne doivent pas avoir des fins de mois très faciles s'ils n'ont que cela pour subsister (d'ailleurs si vous jugez bon de les encourager, n'hésitez pas acheter sur le site RailSimulator les ajouts de belle facture comme "Ile de Wight" !).

     

    Donc, à mon sens, l'annonce de Tim Gatland, directeur général de RSDL, doit être lue en regard de ces informations : peut-être bien que les accords de licence étaient limités dans le temps et que l'annonce d'un "nouveau" simulateur était légalement nécessaire. Ou bien, pour subsister, il faut proposer une "suite", peut-être sur "le business model" de la saga des TrainZ pour soutenir l'intérêt et l'attente.

     

    Indépendamment des informations officielles du premier paragraphe que vous pouvez retrouver là : http://forums.flightsim.com/vbts/showthread.php?t=273201, le reste n'est que conjecture. RailSimulator nous donne du plaisir à jouer mais les temps sont durs pour les développeurs. :(

    A+

     

    PierreG

     

     

     


  8. Bonjour à tous,

     

    Désolé Richard :o , mais je ne connais pas de méthode automatique. De toute façon, la qualité doit primer la quantité : à mon avis comme l'atout principal (si ce n'est le seul) de RS est la qualité du rendu graphique (de jour), il faut que l'aspect graphique des objets soit à ce niveau.

     

    Si un objet de décor est un modèle relativement simple comme peut l'être un bâtiment, le travail le plus long sera celui sur les textures. Si l'on possède déjà les dimensions et les détails de la forme, quelque soit le modeleur 3D utilisé, la géométrie sera très rapidement refaite. Comme sous RS l'aspect de l'objet nécessitera au moins le volume d'ombre et éventuellement les textures nuit et de saisons (différentes de celles sous MSTS) et autres (réflexion, bump mapping...), la conclusion me semble toute trouvée :

     

    1) Si les objets existants sous Gmax ont des textures de très bonne qualité, refaire simplement la géométrie sous 3DSMax, 3DCanvas ou Blender et appliquer les textures. Pour RS, les textures .bmp ou .tga sont converties sans problème avec ToAce (DEvTools de RS).

    2) Si les textures sont médiocres, donc à refaire : eh bien, ça vaut la peine de tout refaire. Pour un objet, je pense qu'il y a 1/4 du travail sur la géométrie et 3/4 sur les textures (sans compter le temps de rassembler la doc).

    Ceci valant pour les objets statiques.

     

    A+

    Pierre


  9. Bonjour à tous,

     

    L'ami Richard va à la vitesse de l'éclair... :rolleyes: Moi, je m'y mets lentement sans pour autant abandonner la modélisation sous MSTS. Finalement ni MSTS, ni RS ne sont des simulateurs aboutis mais avec l'un ou l'autre il y a de quoi se faire plaisir ! Sans oublier OpenBVE qui promet.

    Voici donc une conversion sur RS d'un de mes modèles MSTS présenté en Objet statique :

    Image IPB

     

    Tout reste à faire : les ombres, l'utilisation de tous les shaders possibles, le paramétrage, la cabine. Pour moi, c'est quelques mois de "jeu de modélisation" avant la publication. Merci à tous ceux qui ont pris la peine de rédiger des tutos bien utiles mais j'aurai sûrement besoin des "lumières" de certains...

    Outils 3D utilisés pour le modèle : TSM + 3DCanvas 7.1.2 et en plus pour RS en général : Blender 2.48a

    A+

    PierreG

×