Vous n'êtes pas identifié.
Pages: 1
Bonjour,
J'avais par le passé utilisé la méthode ULE2 de William Ortis "Lionheart" pour outrepasser la limitation de FS004 en termes de polygones affichés pour un modèle donné.
Actuellement, le SDK de P3D apporte la possibilité d'utiliser 3DS Max en version 64 bits et doit permettre via les nouveaux SDK (64 bits) de gérer plus de polygones que par le passé. Néanmoins, je continue à travailler sous Gmax grâce notamment aux tutos de PatdeBarr qui permettent encore l'utilisation de Gmax avec les derniers SDK de P3D v3. Le logiciel 3DS Max est peut-être le futur mais il est trop cher et le toolkit Blender bien qu'opérationnel est encore en développement.
La dernière création que j'ai sur l'établi outrepasse allégrement la barrière imposée par le programme XtoMdl de Microsoft. Actuellement les 297392 vertices et les 455917 polygones me posaient des graves soucis lors des exports en MDL: le fameux message concernant la limite des 65535 drawcalls (très grossièrement un appel du MDL vers une texture pour habiller un polygone).
Même en dupliquant certaines textures pour limiter ces drawcalls, je n'ai pas pu compiler le modèle extérieur et intérieur.
La solution que j'ai trouvé met en pratique encore une fois une méthode qu'avait exposée par William Ortis sur FSDeveloper et qui consistait en:
0 - la création du modèle complet pour positionner TOUS les objets par rapport au centre de gravité (le point [0,0,0] sur la grille Gmax)
1 - un découpage du modèle en sous-éléments (fuselage, ailes, trains, pilote, tableau de bord, console latérale droite, console latérale gauche)
2 - une utilisation des XRefs Objects dans Gmax pour créer un projet faisant appels à d'autres fichiers Gmax, un peu comme un programme C appelant de multiples fichiers headers (*.h), tous les objets i
3 - un export en MDL pour chaque sous-élément ce qui permet de passer en dessous de "la limite des 65535"
4 - un assemblage final de tous les MDLs intermédiaires via l'outil d'Arno Gerresten : ModelConverterX
Métode d'assemblage via MCX:
a) on importe le premier fichier MDL dans l'outil MCX (version de développement)
b) on clique sur l'icone en forme de sapin qui fait apparaitre le tooltip Merge Object
c) une fenêtre intermédiaire apparait avec deux boutons: Load object et Merge
- un click sur Load object permet de sélectionner le fichier MDL à rajouter à l'ensemble
- ensuite un click sur Merge permet d'importer le fichier et de le "merger" avec le premier
- on recommence ainsi de suite jusqu'à complétude du modèle à construire
PS: on ne s'occupe pas des informations de LOD (elles devraient toutes êtres identiques, 100 en ce qui me concerne) et autres.
d) on exporte le modèle final en un objet MDL en fonction du simulateur désiré
Cette méthode a été validé pour FSX et P3D v3 mais doit l'être aussi pour FS2004 et les autres versions de P3D.
Au final mon fameux modèle qui ne passait pas est passé du premier coup sous P3D v3, d'ailleurs ce modèle compilé si je puis dire pour P3D v3 ne fonctionnait plus sous FSX qui ne savait pas l'interpréter. Le passage dans MCX et l'export de ce MDL P3D vers un MDL FSX a permis de contourner le problème et les 2 types de MDL ont été validés sur leur simulateur respectifs.
Dernière modification par Lagaffe (13-10-2015 13:17:40)
Hors ligne
Bonjour Didier,
TRES intéressant ce tuto! Merci, ça pourrait servir...
A ta connaissance, peut-on installer le SDK de P3DV3 en n'ayant que FSXACC?
Bernard.
Hors ligne
Parfaitement
Hors ligne
Lagaffe a écrit:
La dernière création que j'ai sur l'établi outrepasse allégrement la barrière imposée par le programme XtoMdl de Microsoft. Actuellement les 297392 vertices et les 455917 polygones me posaient des graves soucis lors des exports en MDL: le fameux message concernant la limite des 65535 drawcalls (très grossièrement un appel du MDL vers une texture pour habiller un polygone).
Didier, j'y vois juste un petit bémol...
La limite qui a été fixée ici et indépendante de la version du produit FSX/P3D (x32 ou x64).
La preuve, c'est qu'ils ont utilisé une variable 16 bits (65535) dans un applicatif 32 bits pour déterminer leur limite "acceptable".
Cette limite est faite afin de modérer, justement, l'ardeur des développeurs de scène dans leurs frénésies de créer toujours plus de polygone.
Les polygones sont faciles à créer, mais ensuite, il faut les traiter et les afficher à la volé...
Dans l'état actuel des moteurs (FSX/P3D) sous DX9, 10, 11, l'équation est simple... Plus tu as des polygones par objets, plus tu diminues tes FPS et éventuellement tu augmentes tes stutters!...
Avec DX12, normalement cela devrait aller beaucoup mieux.
Nota
Je n'ai volontairement pas utilisé le terme "DrawCalls" pour des raisons de facilité de lecture et de compréhension...
Hors ligne
Alain bien que sur le fond je sois d'accord, il n'empêche que l'avion sur lequel je travaille même avec 456000 poly ne consomme pas plus de FPS que mon TiBush sur la même scène à réglages identiques.
Les limites qui étaient vraies dans le temps sont en train de reculer, ce qui ne veut pas dire qu'il n'y en a pas simplement on peut pousser un peu plus qu'il y a quelques années, le matériel ayant tendance à être plus performant.
J 'essayerais de poster une image pour prouver mes dires.
Hors ligne
Lagaffe a écrit:
Les limites qui étaient vraies dans le temps sont en train de reculer, ce qui ne veut pas dire qu'il n'y en a pas simplement on peut pousser un peu plus qu'il y a quelques années, le matériel ayant tendance à être plus performant.
Oui et Non...
Pour avoir beaucoup de FPS, il y a un besoin de faire travailler ton thread principal le plus rapidement possible.
Actuellement, c'est par lui que doit passer tes appels... Les threads secondaires ne sont pas capables d'émettre ces appels DirectX.
Donc, plus tu en crées, plus tu ralentis ton thread principal... CQFD!...
Tu vas obliger certains du forum à OC à 25 Ghz!...
Il faut bien prendre en compte que ton avion peut voler en Beauce... Mais aussi à Londre!...
Dernière modification par Ptipilot (13-10-2015 19:15:39)
Hors ligne
Autant je suis d'accord avec toi sur certains points, autant là je te trouve un peu ... "obtus" si je puis dire.
La scène utilisée pour le test est LFXU - Les Mureaux avec Paris Ile de France de FVFR activée ... ce n'est pas la Beauce du côté d'Orléans tout de même et avec cela les 25 ~ 30 FPS sont tenus.
A moins que tu m’asticotes dans le secret espoir d'avoir une version de démo sous le manteau
Dernière modification par Lagaffe (13-10-2015 19:34:07)
Hors ligne
Lagaffe a écrit:
A moins que tu m’asticotes dans le secret espoir d'avoir une version de démo sous le manteau
Non, non... Merci...
Mon intérêt est juste technique sans arrière pensée!...
Lagaffe a écrit:
Autant je suis d'accord avec toi sur certains points, autant là je te trouve un peu ... "obtus" si je puis dire.
La scène utilisée pour le test est LFXU - Les Mureaux avec Paris Ile de France de FVFR activée ... ce n'est pas la Beauce du côté d'Orléans tout de même et avec cela les 25 ~ 30 FPS sont tenus.
D'une part, je ne t'asticote pas... D'autre part, j'essaie de ne pas être "obtus"...
Connaissant particulière bien le coin réel et virtuel, verticale les Mureaux n'est pas un endroit où il y a une crête d'appels DrawCalls. Par contre, à 20 nautique plus à l'Est (Verticale La Défense), là tu sollicites plus les machines si tu as mis ton autogen à fond.
Alors, cela passe peut être encore très bien sur ta machine, je ne la connais pas... Tu dois encore avoir de la réserve pour tenir tes 25/30FPS...
Mais, sur une machine un peu moins puissante, tu vas avoir les FPS en baisses. C'est t'otomatik!...
C'est, la raison pour laquelle, il est demandé/conseillé aux concepteurs de revoir l'organisation de leurs polygones (Pas uniquement dans FSX/P3D, mais dans tous les jeux...) afin de diminuer ces appels.
De plus, je pense que tu fais ta création sur P3D V3, qui doit je pense utiliser le "Deferred Context"... Ce qui n'est pas du tout le cas sur FSX (DX9 ou DX10).
Donc toi, tu te trouves dans le cas le plus favorable...
Dernière modification par Ptipilot (13-10-2015 20:07:35)
Hors ligne
Le but du "jeu", c'est quand même d'utiliser les dernières ressources mises à disposition par P3D .... non ?
La scène des Mureaux est celle de Greenhopper et donc ce n'est pas du tout la scène de base, j'avais omis de le dire, non pas quelle est mal faite mais elle est assez chargée ...
De toute façon, les avions sur lesquels j'ai travaillé non jamais été un gouffre à FPS ... donc attendez pour voir ...
Hors ligne
Bonsoir Didier,
Très intéressant ton tuto ...
Pour mes décors, je reste bien en dessous des limites de 'XtoMdl', mais on ne sait Jamais !
Mais juste un bémol pour Bernard :
Bien sûr, tu peux installer le SDK de P3D3 où tu veux, mais sa configuration ne fonctionnera pas ... 'ConfigSDK.exe' va chercher l'adresse d'installation de P3D3 dans la base de registre pour configurer certains modules !
En plus, certaines compilations avec ce SDK ne fonctionnent pas dans FS-X, alors où serait le progrès ?
Pour l'instant Gmax peut toujours être activé, mais combien de temps encore ???
Il n'est déjà plus compatible W10 et c'est vrai que dépenser 6000€ (pour nous, ce n'est pas un investissement, c'est bien une dépense) pour avoir le droit de construire, même quelque chose de très bien, c'est trop cher !
Bon courage.
Patrick
Dernière modification par PatDeBarr (13-10-2015 22:18:48)
Hors ligne
Bonjour a tous,
Pourriez vous me dire si l'on trouve dans la nouvelle version du SDK pour la version 3 de P3D, un plugin pour 3ds max 2016.
Merci d'avance pour vos réponses.
Pierre
Hors ligne
Bonjour,
PatDeBarr a écrit:
Il n'est déjà plus compatible W10 et c'est vrai que dépenser 6000€ (pour nous, ce n'est pas un investissement, c'est bien une dépense) pour avoir le droit de construire, même quelque chose de très bien, c'est trop cher !
Patrick
La plupart des amateurs qui utilisent 3DSmax l'ont par le biais de leur société et ce sont des utilisateurs professionnels ou encore ont trouvé un magasin pas cher.
JMC
Hors ligne
LAGAFFE
De toute façon, les avions sur lesquels j'ai travaillé non jamais été un gouffre à FPS ... donc attendez pour voir ...
S'est sûr quand on tape pas dans la démesure, style gros liner complexes ou beech 1900D ATR ... on garde la fluidité
Le Canadair CL 215, sera certainement un poil plus bouffeur que le C150 ..!
Hors ligne
Lagaffe a écrit:
De toute façon, les avions sur lesquels j'ai travaillé non jamais été un gouffre à FPS ... donc attendez pour voir ...
Mon propos était d'ordre général...
Non sur tes réalisations que je ne connais pas d'ailleurs et que je ne permettrais donc pas de juger!...
Hors ligne
Bonjour Didier,
Merci pour le tuto - même si j'essaye toujours d'être bien en dessous de la limite comme je fait seulement de navires AI, il y a de fois ou cette limite a géré des problèmes - et bon, je n'ai pas passé trop de temps pour trouver la solution, même si je savais que c'était possible, mais quand j'ai vu le titre de la discussion je me suis dit c'est l'heure d'apprendre quelque chose
Henrik
Hors ligne
Bonjour,
Ma question n'était pas de savoir si cette version de 3ds max est compatible avec Windows 10, ni de savoir quels sont les utilisateurs de ce soft, mais de savoir si un plugin existe dans le SDK, comme il en existe pour les précédentes versions de 3ds max.
Pierre
Hors ligne
Pierdail, les règles du forum sont de poster les questions HS sur des topics séparés.
Toutefois pour répondre à ta question le SDK de P3D v3 apporte un plugin pour 3DSM7, 3DSM9 3DSM2009, 3DSM2011, 3DSM2012 en 32 bits et un plugin 64b pour 3DSM2012, 3DSM2014 et 3DSM2015 .... pas pour la version 2016.
L'avion dont il est question n'est pas le Canadair CL215 mais un avion de chasse Français.
Dernière modification par Lagaffe (14-10-2015 19:27:32)
Hors ligne
Bonjour à tous,
Merci Lagaffe pour ta réponse, qui correspond tout à fait à ma question, que j'ai posté sur ce topic parce qu'elle ne justifie pas plus d'une réponse et que ce topic parlait d'une éventuelle utilisation de 3ds max 64 bits pour s'affranchir de la limite du nombre de polygones.
Pierre
Hors ligne
Bonjour,
Ah...mais ça peut aussi créer un modèle complexe pour programmer le déplacement d'une flotte avec AIBT. Par exemple, le Béarn avec le Strasbourg de conserve :
JMC
Dernière modification par gastonj (15-10-2015 09:54:13)
Hors ligne
Pierdail a écrit:
que ce topic parlait d'une éventuelle utilisation de 3ds max 64 bits pour s'affranchir de la limite du nombre de polygones.
Je m'étais donné comme consigne de ne plus intervenir sur ce post, mais là je vois que tu n'as pas bien compris le problème...
Aujourd'hui nous sommes dans un applicatif 32 bits et pour limiter le nombre de DrawCalls, le compteur lui est implémenté au travers d'une variable 16 bits (65535). S'ils avaient souhaité étendre ce nombre, ils pouvaient très bien le faire au travers d'une variable 32 bits qui leurs auraient donnés 4294967295 possibilités. Soit 65537 fois plus de possibilités qu'aujourd'hui...
Donc, tu vois bien qu'il n'y a pas besoin d'attendre une version 64 bits du produit pour "autoriser" plus.
Le problème réel, vient de la capacité de traitement de l'ensemble du pipeline graphique et notamment de DirectX, pour traiter ces appels DrawCalls.
D'où, ma petite intervention technique about le sujet...
Là, le post initial de Didier est d'expliquer comment lui a contourné, par un subterfuge, cette barrière.
Ensuite, comme dans toute bonne entreprise, chacun à ses positions...
Moi, je préfère que ce soit le producteur du produit (LM) qui définisse de nouvelles limites... Lui, préfère ne pas attendre...
Ce n'est pas plus compliqué que cela!...
Dernière modification par Ptipilot (15-10-2015 16:32:45)
Hors ligne
Quoique! les grands malades arrivent à tout!
Et oui, du 97 fps sur FsX avec un modèle de plus de 331 000 polygones ... et pourtant il est écrit que ...
Vous allez dire que c'est sur une zone "confortable", j'ai publié ailleurs à ce sujet.
Il n'y a que pour les médocs que je respecte la notice!
Sur Fs9 et P3D (v1, v2, v3) c'est plus de 1 000 000 de polygones qui volent ensemble et même bien.
Pour ce modèle, je n'ai utilisé aucun artifice de compilation, je suis resté dans la limite fixée par le compilateur du SDK de FsX qui est de 333 300 et quelques polygones au-delà de laquelle il refuse tout service.
Dernière modification par bede40 (15-10-2015 12:35:09)
Hors ligne
Pages: 1