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

pierreg

Membre
 View Profile  See their activity

  • Content count

    1,489

  • Donations

    0.00 EUR 

  • Joined

  • Last visited

  • Days Won

    122

Posts posted by pierreg

  1. Posted

    Bonjour,

     

    Non, un matériel MSTS ne peut pas être installé tel quel ni dans RailSimulator ni dans TrainZ. :P

    Pour tous les simulateurs, il faut avoir créé avec un modeleur 3D le modèle représentant ce matériel aussi bien vu de l'extérieur que de la cabine intérieure, puis ensuite il faut l'adapter, le compléter par des sons et enfin paramétrer toutes les caractéristiques de son fonctionnement dans le simulateur.

     

    Si l'on dispose du modèle 3D, des logiciels, de la compétence et du temps nécessaires, l'adaptation est toujours possible mais plus ou moins complexe : il faut de toute façon le modifier et créer des textures adaptées au moteur graphique du simulateur. Je passe sur le problème des formats de fichiers 3D incompatibles.

     

    Mais il se trouve que certaines formes 3D créées pour MSTS avec le modeleur TrainSimModeler peuvent être relues correctement par le logiciel 3DCanvas Pro qui lui même est capable de créer des modèles pour RailSimulator.

    Ce qui explique que parmi les matériels déjà créés pour RailSimulator beaucoup sont des anciens modèles de MSTS et c'est ce que je fais moi-même avec les modèles que j'ai prévu de publier.

    Par exemple ce modèle que j'ai publié en 2003 pour MSTS et qui est en cours d'adaptation sous 3DCanvas :

    Image IPB

     

    A+

     

    PierreG

     

  2. Posted

    Bonsoir à tous,

     

    Orangina75, tu as dû entendre un message subliminal de Railsimulator.com car je n'ai rien lu de ce genre ! :D

    Et, de plus, j'ai l'impression qu'il y a des mots qu'il ne faut pas prononcer ici !!! J'attendais des compléments plus constructifs à mes informations. :rolleyes:

    Enfin, c'est pas tout les gars, il faut se secouer un peu pour aider dede34 (et les autres développeurs de matos) : je trouve que la sono dans RS est un sacré bon sujet d'investigation à défricher : qui s'y colle ??

    Je reste à l'écoute pour mes prochains matériels ;) .

     

    A+

     

    PierreG

     

     

  3. Posted

    Bonjour dede34,

     

    :unsure: Voilà encore un point où RS a peut-être des fonctionnalités très avancées mais où le développeur est dans le brouillard le plus complet. La doc officielle n'est pas suffisante et ce serait très surprenant que RailWorks paraisse avec une doc développeur plus complète. :rolleyes:

    Seul moyen de s'en sortir : fouiller les dossiers de matériel d'origine car même les exemples "sources" sont "muets" sur le sujet :P .

    Les forums anglo-saxons sont pleins de gens comme nous : on tâtonne, on cherche...

     

    Quelques indications quand même :

    - les fichiers .wav et les fichiers xml qui les activent semblent être dans les sous-dossiers du dossier Audio : il y a des sous-dossiers par type d'Asset : bruit des joints de rail dans RailNetwork, bruit des matériels dans RailVehicules\etc...

    - les sons permanents (roulement, aéro...) semblent référencés dans des rubriques "Child" du chapître "Container component" de l'Engine Blueprint.

    - les sons liés à une action dans la cabine sont plutôt dans la rubrique Cab évidemment : fouille dans les dossiers Kuju\Audio\RailVehicules\..... J'ai réussi un peu au hasard à avoir un klaxon deux tons SNCF sur les locos électriques en modifiant dans le Cab de la Class 101 le fichier Class101_Horn.proxyxml la référence Horn Loop vers un fichier .wav de MSTS et ça marche bien.

    Allez, bon courage, moi je retourne développer sous MSTS :P : là au moins, il y a tout ce qu'il faut pour les sons et même un debugger sonore temps réel.

    A+

    PierreG

     

     

  4. Posted

    Bonjour à tous,

     

    Ah, pml3, tu sais, j'avais intitulé un post "le cauchemar des blueprints"... Il y a eu des moments où j'ai failli faire tout passer par la fenêtre :lol:

    Ma loco parait sur les rails mais quand je mets un conducteur : déraillement instantané car en fait je suis "presque sur les rails" (décalage de qq cm) Je crains que la cause soit le bazar dans le centre de gravité des bogies.

    Je crois que le déraillement instantané peut avoir deux causes :

    - la "Collision box" mal centrée avec une hauteur qui déborde sur les rails : elle doit être au-dessus des roues;

    - une rubrique obligatoire manquante dans le Blueprint Engine. Malheureusement il n'est dit nulle part celles qui sont obligatoires. Par exemple "Driver Position" que tu dois placer en 3D dans l'Asset Editor, "Control Container component" avec toutes les "cab" et autres manettes, etc...

     

    Si tu ne vois rien en Preview, cela peut venir d'erreurs de références vers les différents Bogey blueprints : attention aux champs Provider et Product à partir desquels RS reconstitue le chemin !

     

    Une solution pour t'en sortir est bien de prendre le source du Sample Engine Electric de Kuju en le recopiant dans ta structure source et en modifiant les références vers ton modèle, ses paramètres et le reste restant par défaut.

     

    Effectivement le décalage du repère modèle par rapport aux rails doit se régler dans le modeleur 3D. Moi je sais faire dans 3DCanvas mais pour 3DS Max ça ne devrait pas être très difficile. RS a l'air de se moquer totalement de ce genre d'erreur et des valeurs de Y dans les Bogey blueprints... C'est le repère modèle qui compte.

     

    Bon courage,

     

    PierreG

     

  5. Posted

    Bonsoir Pml3,

     

    Je ne comprends pas bien ce que tu décris puisque tu as montré la loc sur ses rails :blink:. En principe quand l'Asset editor recherche les textures demandées par un fichier IGS, il cherche d'abord dans un sous-dossier "Textures" soit, au pire, dans le même dossier que celui de la géométrie .IGS.

    Crée d'abord un répertoire "Textures" dans le répertoire "Engine" et place les textures en question dedans. D'ailleurs j'ai remarqué que tes objets "Scenery" avaient parfois des textures placées bizarrement (et pourtant ça marche!! :) ) : par exemple des sous-dossiers dans le dossier "Textures" placé au même niveau que "Scenery", etc...

    Pour une hiérarchie dans les règles, regardes les blueprints du Sample_engine fournis en exemple.

     

    Si tu suis les règles de hiérarchie, tu devrais avoir au moins le chemin :

    Source\pml3\Addon\RailVehicles\pml3_2D2_9100\...

    ce qui dans les blueprints imposera les libellés Provider : pml3 et Product : Addon

    Je ne suis pas sûr que tes problèmes viennent de là mais autant respecter les règles RS. De plus je te signale que dans l'"Object Filter" la présentation des noms de développeurs se fait dans l'ordre alphabétique mais Majuscules d'abord, puis minuscules. Donc avec "pml3" tu devras aller chercher tout au fond de la liste... :rolleyes:

    Tu es sur la bonne voie. Bon courage et A+

    PierreG

     

  6. Posted

    Bonjour pml3,

     

    Eh bien, chapeau si c'est le premier modèle pour RS que tu réalises :rolleyes: ! Il y a encore du boulot mais ça fait vraiment plaisir de voir ça.

     

    Pour répondre à tes interrogations :

    Oublies le principe de l'instanciation des bogies : c'est une erreur de la doc (elle en a pas mal) qui n'est pas à jour. Ils pensaient faire "à la Trainz" mais ont abandonné. Le modèle doit comporter tous ses bogies et ses essieux avec évidemment les bons noeuds de hiérarchie dans un seul fichier IGS.

     

    Je me suis fait une 2D2 (pas aussi belle que la tienne :( !!) pour vérifier tout ça :

     

    Image IPB

     

     

    Comme tu le vois, il y a 3 blueprints "Bogie" car 3 groupes d'essieux (respecter l'ordre de référence "avant d'abord" dans le paragraphe "Bogey" de l' Engine blueprint) mais il n'y a de géométrie (dans l'IGS donc) que pour le premier et le troisième qui sont des vrais bogies.

    Dans leurs blueprints tu devras déclarer le nom du noeud de la géométrie les représentant. Pour le deuxième (qui sont les 4 roues motrices) tu laisses la ligne "Geometry" vide mais les 4 paragraphes "Axles" comporteront les références, dans l'ordre, des noeuds des 4 essieux (sinon les roues ne tourneront pas).

     

    J'ai vérifié : ça marche bien sauf que ça manque un peu de jeu latéral dans les courbes serrées :D !!

     

    Encore bravo et bonne continuation pour ce beau projet !

     

    A+

     

    PierreG

     

  7. Posted

    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

     

  8. Posted

    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

     

     

  9. Posted · Edited by pierreg

    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

  10. Posted

    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

     

  11. Posted · Edited by pierreg

    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

  12. Posted

    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

     

     

  13. Posted

    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

     

     

     

  15. Posted · Edited by pierreg

    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

  16. Posted · Edited by pierreg

    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

×