[FSX] Pétrolier Ravitailleur Durance avec Blender

Fro' · [↑]

rafalemirage a écrit :

Salut tout le monde,
je me permet de répondre à Fro', Badseb complètera éventuellement ma réponse. Le problème vient bien du modèle du Durance car on n'était pas en multiplayer mais bien en solo, chacun de son côté et on a eu la même chute de FPS, chacun de son côté avec son propre ordi. Ce qui est bizarre, c'est que le modèle ne fait que 47k poly, 100k triangles, et on a que 4 drawcalls, ce qui la même chose pour ma frégate, qui elle compte 170k poly et je tourne à 30 fps bloqué avec. Le problème m'échappe ! Il n'y a aucune animation ni aucun effet sur le modèle.
Bizarre bizarre ...
En tout cas, je trouve ce modèle magnifique et la texture envoie du fat !!!! Bon je retourne tourner autour avec mon ventilateur

OK, au temps pour moi, j'avais compris que la Durance en MP avait de meilleurs performances qu'en solo.
Si les Drawcalls sont bons (4 c'est carrément faible), c'est que le pb est ailleurs... Avez-vous fait un check des textures pour vous assurer qu'il n'en manque pas dans le dossier final placé dans SimObjects/Boats?
Un grand classique c'est un fichier Texture.cfg qui manque ou qui ne "fonctionne" pas faisant que FSX rame à chercher en vain des textures...
A+
Fro'

Dernière modification par Fro' (09-11-2014 19:16:10)

rafalemirage · [↑]

J'ai mis un texture.cfg, et je n'ai pas de message d'erreur de MCX concernant une texture manquante.

Lagaffe · [↑]

Avoir 4 textures ne signifie pas que l'objet dispose de 4 drawcalls. Vous faites une confusion entre ce que "vous ressort MCX" et la notion de drawcalls (cf FSDeveloper pour plus d'explications).

Un drawacall est le nombre de fois où un polygone va appeler une texture ... moins vous utilisez de textures avec un modèle fourni et plus le nb de drawcall va augmenter. Essayez de répartir vos textures en des textures plus petites ce qui va effectivement diminuer le nb de drawcall et le PC va moins peiner pour afficher la scène

Les textures hautes définition sont à la mode mais les utiliser efficacement n'est pas une mince affaire.

badseb93 · [↑]

Ou peu être en créer une seule par exemple en 4096 qui va regrouper tout l'ensemble?

Lagaffe · [↑]

Relit ce que j'ai écris .... une seule texture va multiplier tes drawcalls par 4

rafalemirage · [↑]

Les drawcalls je j'ai cité plus haut sont bien les paramètres que MCX appelle Drawcall qui est différent du nombre de texture. J'ai fait un essai avec une seule texture 2048x2048 et j'ai eu 6 Drawcalls.

Fro' · [↑]

Lagaffe a écrit :

Avoir 4 textures ne signifie pas que l'objet dispose de 4 drawcalls. Vous faites une confusion entre ce que "vous ressort MCX" et la notion de drawcalls (cf FSDeveloper pour plus d'explications).
Un drawacall est le nombre de fois où un polygone va appeler une texture ... moins vous utilisez de textures avec un modèle fourni et plus le nb de drawcall va augmenter. Essayez de répartir vos textures en des textures plus petites ce qui va effectivement diminuer le nb de drawcall et le PC va moins peiner pour afficher la scène
Les textures hautes définition sont à la mode mais les utiliser efficacement n'est pas une mince affaire.

Hello Didier,
Je ne suis pas vraiment d'accord avec toi. La notion de Drawcalls que l'on trouve dans MCX n'est pas un comptage de textures mais bien une notion plus complexe directement liée au fonctionnement de FSX et à sa gestion des ressources graphique. Arno l'auteur de MCX, que tu connais bien je pense, s'est appuyé sur pas mal de discussions à l'époque qui expliquaient les impacts de la modélisation sur les performances, notamment celles-ci
- Performance Art - Torgo 3000

Arno a fait ces vidéos qui restent pour moi la base d'une modélisation optimisée pour FSX:
- Performance Tutorial Video - Part1
- Performance Tutorial video - Part2

Le principe que je retiens est de rationaliser l'usage de material dans sa modélisation, ce qui passe par une rationalisation des textures utilisées : regrouper autant que possible les petites textures en 1 seules, éviter l'usage de "Solid Color", de multimaterial, etc... (c'est d'ailleurs les actions que proposent les fonctions d'optimisation de MCX)
C'est donc plutôt le contraire que ce que je comprend de ton post...

Bien-sûr, il ne faut pas tomber dans un excès inverse en n'utilisant qu'1 unique texture de 4096px (ou plus) car on se heurte alors à d'autre pb comme par exemple la limitation de 64k/material lors de la compilation ou même à des pb de place mémoire pour les textures (le T45 de Dino pose parfois ce genre de pb avec son cockpit virtuel habillé à coup de textures de 4096px!!)...

Tout ça pour dire que je milite avant tout pour une réduction du nombre de textures et non, comme tu le dis, à une multiplication du nombre de petites textures. Trop de scènes héritées des usages de FS9 sont réalisées avec des wagons de petites textures (1 image pour 1 roue, 1 autre pour un panneau, 1 autre pour la façade d'1 bâtiment X, etc...) qui me flinguent mes FPS alors qu'avec quelques textures de 1024px voir 2048px on peut couvrir le même nombre d'objets à moindre coup/ressource...

Tout ceci est avant tout un principe général car les choses peuvent se compliquer énormément dans pas mal de cas particuliers ... sinon ce serait trop facile (rires)
Par contre le cas d'un navire AI devrait a priori pouvoir rentrer dans le cas général, en tout cas c'est ce que je pense d'expérience.

A+
Fro'

bede40 · [↑]

Bonsoir,

Je me base sur ce que disent les SDK de Fs9 et FsX et surtout sur ce qui a paru comme documentation sur le site de Microsoft sur le sujet.

Le nombre réel de drawcalls est donné par le compilateur (si toutefois on fait apparaître les bons fichiers). Ces drawcalls (les vrais) correspondent à l'appel d'une texture pour texturer une face d'un objet. Par principe, une texture ne peut être appliquée que sur 65 536 faces mais il est possible de passer outre. Le nombre de faces compilées ne correspond pas au nombre de faces lu dans l'outil 3D de création, il résulte du traitement réducteur de faces effectué lors de la compilation, cette différence peut être très importante dans le cas d'une compilation Fs9 (sauf pour le cas particulier de la méthode que j'ai mise au point pour obtenir une définition 3D supérieure à celle de FsX).

Pour réduire les drawcalls (vrais) il suffit de réduire le nombre de faces des objets créés.Mais ce nombre de faces et de textures dépend avant tout du modèle et de la précision que l'on veut obtenir dans le rendu 3d Fs de ce modèle.

Le type de texture à choisir dépend de la dimension de celle-ci: le BMP jusqu'à 1024x1024, le DDS de 1024x1024 à 4096x4096.

Jusqu'à 1024x1024, la compression utilisée par DDS est inutile, le type BMP (format 24bits, DXTn, etc) est lu et interprété plus rapidement, 1024x1024 est la charnière d'où le choix, au-delà le DDS est lu et interprété plus rapidement que le BMP (sources SDK et Microsoft).

D'après les tests effectués, il vaut mieux avoir 4 textures 1024x1024 qu'une seule texture de 2048x2048, idem 4 textures de 2048x2048 sont traitées et appliquées plus rapidement qu'une seule texture de 4096x4096.

Lorsque FsX se lance, il recense, entre autres, les textures à utiliser pour l'affichage demandé et valide ou non leur présence et leur conformité aux standards fixés par le SDK. Ce pré-traitement explique l'accroissement de la lenteur du simulateur proportionnel à celui du nombre d'addons ajoutés.

Pour un modèle, en fonction de cette liste de textures et des objets à représenter, FsX chargera la texture et l'appliquera aux objets ou parties d'objets qui la demandent au fur et à mesure du calcul de la visualisation de l'objet 3D. Ces textures sont gardées en mémoire (tant qu'il y a de la place!) pour permettre les changements de vue ou de points de vue. Ce n'est donc pas leur nombre qui importe mais la place qu'elles occupent réellement en mémoire une fois interprétées. FsX ne fait pas de tri entre les faces visibles ou non, tout est texturé.
Ceci explique qu'une fois un modèle chargé, la modification d'une texture à chaud n'est pas prise en compte et oblige au mieux à changer de modèle avant de recharger le modèle désiré et au pire, en cas de rajout de texture oubliée, un redémarrage de FsX.

Les délais d'affichage et flous souvent constatés sont dus essentiellement aux calculs par le CPU des luminosités, flous (et oui) agrémentés de quelques broyages savants de pixels des textures à appliquer pour la vue désirée. Plus les dimensions en pixels de la texture sont grandes et plus sa structure est complexe, plus son traitement sera long. Il faut garder à l'esprit que FsX traite une sphère qui a pour centre situé dans l'espace géographique, par exemple, le point de vue (œil) fixé dans l'aircraft.cfg du modèle, et pour rayon le rayon fixé pour l'affichage des objets du décor. Cela fait beaucoup d'objets et de textures.

Pour revenir sur le nombre et les dimensions des textures: par exemple le C172 ou le Cherokee de A2A ne semblent pas poser de problèmes particuliers avec leur quarantaine de textures par version chacun (plus de 2048x2048 que de 4096x4096).

Quelques exemples payants réputés pour écrouler FsX:

New-York: 41 blocs d'objets et plus 12 100 textures
Toulouse: 26 blocs d'objets et plus de 870 textures
CDG: 292 blocs d'objets et environ 500 textures
Orly: 27 blocs d'objets et environ 500 textures

Le raisonnement est également valable pour P3D qui a toutefois un traitement par calculs différent de celui de FsX. En effet, FsX coince à 350 000 drawcalls (les vrais) environ pour un modèle, P3D et Fs9 (l'ancêtre bien sympathique) vont jusqu'à près de 3000 000 sans faiblir.

L'essentiel de l'histoire est d'avoir des textures de structures les plus simples possibles et absolument conformes à ce que précise le SDK. Toute entourloupe ou innovation dans le genre est pénalisante puisqu'elle demandera un temps de traitement supplémentaire si toute fois cette structure est acceptée.

Un petit rappel au passage: être indulgent pour les produits créés par des amateurs plus ou moins éclairés, sinon ces personnes cesseront de produire ou passeront dans le payant ce qui finirait par nuire au système convenez-en.
Le temps investi dans l'apprentissage, la recherche de documentations, la modélisation et l'acquisition des matériels nécessaires a un coût certain en monnaie et vie familiale.

Amicalement.

rafalemirage · [↑]

Merci Bede pour ces explications bienvenues ! Effectivement, personnellement, je n'ai que quelques mois de modélisation sous le coude et comme la plupart d'entre vous on du le vivre, on commence par modéliser puis arrivant à un certain point, on commence à se soucier de l'optimisation du modèle. Personnellement, pour les frégates je me demande après avoir vu les vidéos que Fro' a mis en lien, s'il ne serait pas opportun de faire des LODs ?

Lagaffe · [↑]

Les explications de Fro' sont très intéressantes et ces liens aussi. On notera quand même qu'ils datent de 2007 et que depuis 7 ans se sont écoulés et que le matériel a aussi bien évolué.

Le LOD était à mon sens valable en 2007 mais actuellement, en rajouter :
- va rajouter de la complexité à l'objet .... quitte à rajouter des LOD, il faut encore que les LODs sont moins fouillés que le premier!
- le simu va travailler encore un peu plus pour savoir à une distance donnée quel LOD afficher pour satisfaire les critères

Bref, ma philosophie est de détailler mes objets et de les optimiser au mieux sans plus:
- pas de LODs,
- texture < 1024 en BMP dxt1 ou dxt3 sans mipmaps sinon cela provoque des scintillements
- texture > 1024 en DDS
- vérifier avec le log de Gmax le nombre de "drawcalls à la compilation" pour rester dans des valeurs données par Bede40

Je suis sans doute en désaccord avec Arno et Fro' mais je pense qu'il n'y a que le résultat qui compte: ça marche ou ça boite

rafalemirage · [↑]

Tous les conseils sont bon à prendre et il ne doit y avoir qu'une méthode/philosophie qui fonctionne mais plusieurs, plus ou moins adaptées aux objets que l'on souhaite réaliser. Il serait peut être intéressant de faire un sujet épinglé sous forme de FAQ ou autre concernant l'optimisation de la modélisation car actuellement, il faut aller piocher dans différents posts des infos qui se répètent surement. En tout cas, tout ça est très instructif

Fro' · [↑]

Hello,
Les discussions datent un peu, c’est vrai, mais FSX n’a pas vraiment évolué entre temps non plus… (rires)
Les machines elles ont sensiblement évoluées depuis, ce qui pousse les créateurs à utiliser de plus en plus de grosses textures, mais les principes restent toujours les mêmes…

A lecture des post de Didier et Bede40, j’ai l’impression qu’on ne se focalise pas forcément sur la même chose.
Je ne parle pas de l’impact de la taille ou du format des textures sur le chargement de FSX ou le lancement d’un vol, d’ailleurs sur ce sujet je suis d’accord avec vous et ne milite pas du tout en faveur des textures de 4096 ou plus.
Je parle de l’impact d’un mdl au cours d’un vol : comment faire pour qu’il réduise au maximum sa consommation de ressource graphique lors d’un vol.

Pour cela, la première règle que je me fixe est l’équivalent de ta philosophie Didier : « détailler mes objets et de les optimiser au mieux sans plus ». En fonction de ce qui sera visible et à quelle distance on sera de l’objet dans FSX , j’ajuste le maillage (nombre de vertex) utilisé. Cela ne mange pas de pain et cela marche toujours : la chasse à la « sur-qualité » (rires)

Comme à maillage équivalent les performances sont loin d’être toujours équivalentes, j’ai ajouté une deuxième règle qui est de rationnaliser la consommation de « material » et ce, quelle que soit la taille de la texture qui lui sera associée (je travaille toujours en 1024px par défaut sauf besoin spécifique de définition comme un pont de porte-avions). C’est le principe que décrit Arno dans ses vidéos qui peut s’apparenter parfois à du Tétris qui fonctionne.

La troisième règle, que je trouve quasiment aussi importante, est d’optimiser le mapping de mes objets sur mes textures : moins le mapping de mon objet est éclaté sur ma texture mieux c’est ! Par exemple, un même objet peut voir la taille de son mdl exploser selon la façon dont le mapping est réalisé. Au-delà du poids du mdl, cette notion de « Textured vertices » impacte aussi pas mal les ressources graphiques utilisées tout en étant moins visibles par le créateur.

Ensuite viennent des règles plus secondaires comme éviter (autant que possible) l’usage de propriétés « sophistiquées » comme la transparence, effets miroir, etc… Et si je les utilise, je le fais sur de material dédiés afin d’impacter le moins d’objets possible.

Encore une fois je ne suis pas sûr que tout ceci soit orthogonal à ce que Didier ou Bede40 disiez…
A+
Fro’

PS j'ai testé les LOD sur une version du Clem, c'est assez pénible à manipuler pour des effets pas vraiment sensible... je ne recommanderais pas non plus mêm pour un navire AI...

rafalemirage · [↑]

Ok, merci du retour, je commençais également à me poser la question quand aux animations et ça ma paru assez compliqué à mettre en oeuvre
On écarte alors l'option du LOD

Lagaffe · [↑]

Tu as raison Fro' nos positions ne sont pas si éloignées les unes des autres sauf pour ce qui est de la notion de "drawcalls" à savoir :
- la notion relative à la phase de compilation via le SDK ou
- plus généralement l'appel des textures par FSX dans le simu ...

Le principal étant de tirer des règles de "programmation/modélisation" de manière à faire passer le plus de détails avec le moins de charge CPU/GPU au niveau du simulateur.

Là je rebondis sur ce ue tu disais à savoir FSX n'a pas évolué tant que ça ... FSX, oui mais P3Dv2 pour lequel je dirige tous mes efforts est sensiblement différent et devrait nous apporter des surprises voire des modifications dans nos schémas de pensée ... car d'expérience, ce moteur semble se rapprocher plus de FS9 dans son comportement vis à vis des modèles 3D que de FSX ... avis personnel

Fro' · [↑]

Lagaffe a écrit :

... FSX, oui mais P3Dv2 pour lequel je dirige tous mes efforts est sensiblement différent et devrait nous apporter des surprises voire des modifications dans nos schémas de pensée ... car d'expérience, ce moteur semble se rapprocher plus de FS9 dans son comportement vis à vis des modèles 3D que de FSX ... avis personnel

Hello,
Autant j'ai lu pas mal de chose sur comment arriver à utiliser les outils du SDK de P3D, autant je n'ai pas encore lu grand chose sur une modélisation spécifique pour P3D... Mais je ne creuse pas plus que ça les forum P3D car, pour l'instant pour moi, la cible reste FSX(*), et je pars du principe que ce qui tourne sous FSX tourne aussi sous P3D sans régression/précaution particulière avérée.

Quelque part cela m'arrange car j'ai déjà assez de mal avec mes projets mono version, alors je n'imagine pas la galère si en plus je devais gérer plusieurs version avec plusieurs sources et plusieurs compilateurs...

A+
Fro'

(*) Lockheed Martin ne semble pas très intéressé par l'aéronavale, non seulement ils n'y a pas d'amélioration dans les fonctions aéronavales du SDK mais en plus il en avait enlevé (disparition du miroir d'appontage de FSX Acceleration): rédhibitoire pour nos projets RFN....

BERJU83 · [↑]

Bonjour à tous,

Ho, les gars, vous vous décidez? Beaucoup de petites textures ou bien peu de grandes? C'est que j'ai du mapping à faire moi!

Quoi?...Que je me démerde? Bon d'accord, j'y retourne...je vais faire de moyennes textures avec mes moyens!

A+
Bernard.

rafalemirage · [↑]

excellent Berju ! Tu m'as devancé !

Fro' · [↑]

BERJU83 a écrit :

Bonjour à tous,
Ho, les gars, vous vous décidez? Beaucoup de petites textures ou bien peu de grandes? C'est que j'ai du mapping à faire moi!
Quoi?...Que je me démerde? Bon d'accord, j'y retourne...je vais faire de moyennes textures avec mes moyens!
A+
Bernard.

Ben, si tu prends quelques textures moyennes (1024px) tu devrais tomber sur un compromis qui satisfait tout le monde!

Sinon est-ce que quelqu'un a déjà vu le phénomène d'ombre bizarre qu'il y a avec la Durance (post d'hier à 1h02)? Une idée de ce qui pourrait le causer?

A+
Fro'

rafalemirage · [↑]

On a remarqué ca également avec Badseb et on se demandait d'où ca pouvait venir car il n'y a aucun objet plat transparent à cet endroit la. Ce modèle doit être hanté, je vais appeler les Gost Busters ou Van Helsing

badseb93 · [↑]

Laisse tomber, c'est ma faute, je suis un vrai chat noir...

dutrla · [↑]

Superbe nouvelle,

heureux de voir que le projet se poursuit !

"Sans logistique Rien ! "

badseb93 · [↑]

Juste ce petit message pour vous avertir que suite à une étude de Fro' sur mon projet, il s'avère que j'ai de gros soucis de dépliage UV avec Blender, ce qui cause la chute de FPS.

Donc :

Je vais revoir une partie du modèle 3D pour alléger certaines choses et mettre du low-poly, refaire un nouveau dépliage UV en catégorie bien défini, refaire mes textures et y mettre les moyens, donc elles seront plus belles, je le promets. Ajouter ensuite le reste comme prévu, hommes, lumières et animations.

Je passe ensuite je pense à mon deuxième projet, le TCD Ouragan.

Mes excuses pour le retard déjà abusif, mais ceci sera à mettre sur mon inexpérience

dutrla · [↑]

Bonjour,

je profite de l'annonce de rafalemirage concerant sa frégate Surcouf, pour remonter le post.

Quelles sont les nouvelles ?

Merci.

rafalemirage · [↑]

Salut tout le monde,

La première version du modèle est disponible sur le site de la RFN.

Grâce à Badseb et à Micpni, on a maintenant de quoi ravitailler nos bâtiments de la royale par la royale !

Seb

Dernière modification par rafalemirage (09-05-2015 21:59:06)

#76 [↑][↓] 09-11-2014 19:15:34

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#77 [↑][↓] 09-11-2014 21:32:11

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#78 [↑][↓] 09-11-2014 21:36:17

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#79 [↑][↓] 09-11-2014 22:04:40

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#80 [↑][↓] 09-11-2014 22:21:07

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#81 [↑][↓] 09-11-2014 23:33:37

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#82 [↑][↓] 10-11-2014 00:07:36

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#83 [↑][↓] 10-11-2014 04:25:56

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#84 [↑][↓] 10-11-2014 10:38:01

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#85 [↑][↓] 10-11-2014 10:50:58

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#86 [↑][↓] 10-11-2014 11:01:24

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#87 [↑][↓] 10-11-2014 12:09:13

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#88 [↑][↓] 10-11-2014 12:40:05

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#89 [↑][↓] 10-11-2014 13:09:08

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#90 [↑][↓] 10-11-2014 13:54:36

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#91 [↑][↓] 10-11-2014 14:29:30

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#92 [↑][↓] 10-11-2014 15:03:41

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#93 [↑][↓] 10-11-2014 15:05:48

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#94 [↑][↓] 10-11-2014 15:19:48

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#95 [↑][↓] 10-11-2014 15:43:35

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#96 [↑][↓] 11-11-2014 10:59:50

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#97 [↑][↓] 11-11-2014 20:57:47

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#98 [↑][↓] 28-03-2015 14:40:23

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

#99 [↑][↓] 09-05-2015 21:58:53

Re : [FSX] Pétrolier Ravitailleur Durance avec Blender

Pied de page des forums