Vous n'êtes pas identifié.
Pages: 1
Bonsoir,
En écoutant un podcast sur pcflight.net, portant sur une discussion avec le chef de projet Prepar3D chez Lockheed Martin. Adam Breed annonce une nouvelle qui avait déjà fuité il y a quelques mois et qui semble donc se confirmer: les textures PBR devraient apparaître dans la prochaine release majeure c'est-à-dire la v5.0.
PS: Les textures PBR sont déjà présentes dans XPlane 11 et pour rassurer ceux que cela effraient, disposer de ce type de texture au sein du moteur de rendu n'impliquerait pas obligatoirement de renouveler tout ses add-ons, plus exactement le moteur analyserait l'addon et s'il y trouve des textures PBR, il serait capable de les utiliser. XPlane n'est pas le seul simulateur a avoir utiliser ces textures FSW l'a aussi fait dernièrement et tous les avions utilisables dans ce simulateur n'étaient pas obligatoirement développé en ce sens.
Dans cet entretien, il a aussi mentionné d'autres points qui risquent de faire pas mal couler d'encre à la sortie de cet opus.
Le lien pour suivre cet entretien : https://pcflight.net/episode-13-lockhee … adam-breed
On trouve aussi des amorces de discussion concernant cette technique sur AVSIM: https://www.avsim.com/forums/topic/5047 … es/?page=2 avec là aussi des personnes qui crient à la non-compatibilité sans savoir de quoi il retourne (lire la dernière intervention du post).
Pour ceux qui seraient intéressés par ce nouveau rendu, voici la page d'un développeur pour XPlane qui utilise cette technique pour ces avions avec beaucoup de réussite: http://blog.khamsin.org/page/8
Dernière modification par Lagaffe (13-08-2018 20:51:55)
Hors ligne
En anglais masi assez clair : https://www.youtube.com/watch?v=PjGCtnEDDeU
Hors ligne
Bobonhom a écrit:
Et qu'est-ce que ça donne de plus???
Un realisme visuel a un niveau jamais atteint par P3D.
C'est esthetique.
Hors ligne
Le PBR n'a pratiquement aucun impact lorsqu'il est implementé correctemenet.
Le dynamic lighting dans P3D est implementé avec les pieds (et des chaussettes tres epaisses). Il en resulte un impact catastrophique sur les FPS.
En comparaison, dans XPlane 11 on a le dynamic lighting et le PBR et c'est parfaitement fluide.
Hors ligne
oups, doublon, désolé
Dernière modification par Daube (14-08-2018 10:17:22)
Hors ligne
D'où mon inquiétude, si LM implante le PBR de la même façon dont ils ont implantés le Dynamic Lighting c'est pas très rassurant.
Ne parlons même pas de l'issue avec l'autogen quand TFR est sur Unlimited...
D'après le post de Lagaffe on ne perdrait pas la compatibilité avec les addons qui ne le supporte pas ce qui en soit est déjà une bonne chose.
Hors ligne
Les problemes d'autogen dependent grandement du materiel.
Chez moi sur P3Dv4.3 je vole uniquement en FPS illimites et je n'ai pas de soucis d'autogen, meme lors de nos sessions de vol en ligne en jet militaire (on reste en dessous de Mach1 cependant, parce qu'on est trop mauvais pour tenir une formation serrée ).
A noter que je vole avec l'autogen au maximum de densité, sur les scenes photoHD de FranceVFR, avec l'autogen de Vogel.
Hors ligne
Je fais surtout du liner. Je ne perds pas l'autogen (sauf avec le FSL où des fois ça a du mal à suivre xD) mais souvent à l'arrivée le sim a cette vieille tendance à popup l'autogen surtout dans les zones aéroportuaires avec des grosses villes à proximité, ça casse l'immersion.
Tout ça pour dire que implanter de nouvelles technos c'est bien à condition que ça ne se fasse pas aux détriments du reste.
Dernière modification par Pilote95 (14-08-2018 11:55:38)
Hors ligne
Pas affolement sur le PBR, si il existe c'est surtout pour les moyens combinés de créer les textures, ces textures sont livrées telles qu'on les connait (y compris dans FSW), c'est à dire: une texture pour le fond, une texture pour la brillance, un texture pour le relief, etc. Nous n'aurons pas une texture unique qui fait tout, c'est d'ailleurs pourquoi LM assure que les anciens formats fonctionneront.
Par contre, comme LM change de moteur graphique, il serait bien mieux qu'ils intègrent le calcul de l'occlusion ambiante comme dans FSW (pour tous les objets visibles, autogen, avion, etc). Basé sur des shaders, ce calcul n'impacte en rien les fps mais facilite grandement le travail de ceux qui créent les textures et fait travailler la CG.
Dommage que FSW soit passé à la trappe, partant comme LM de FsX, les développeurs avaient d'excellentes idées qui auraient pu aiguillonner LM.
Hors ligne
Bernard, c'est d'ailleurs sans doute ce qui s'est passé
Maintenant leur faire des critiques avant même que la version ne soit sorti ... sans doute faut-il attendre
Oui, j'ai entendu le murmure : ce n'est pas une critique mais une crainte. A cela je réponds attendons et nous verrons.
Dernière modification par Lagaffe (14-08-2018 21:16:22)
Hors ligne
Serait-il dans le domaine de l'imaginable que DG puisse céder la technologie utilisée pour le PBR dans FSW (notamment au niveau du traitement de l'occlusion ambiante) à LM pour limiter de cout de leur investissement après l'arrêt de FSW et donc que cette annonce d'un nouveau moteur graphique ne soit pas complètement indépendante de l'annonce de la fin de FSW.
En tout cas cela aurait beaucoup de sens
Quoi qu'il en soit, LM a bien compris que P3D malgré son leadership sur le segment des plate-formes de simulation, a perdu des parts de marché face à XPlane et aussi FS2 notamment à cause de son moteur de rendu vieillissant et donc il est vital pour eux d'investir dans ce domaine pour maintenir leur avance dans les autres domaines (notamment la richesse de l'offre d'addons)
Dernière modification par ydelta (14-08-2018 22:41:31)
Hors ligne
Le rendu graphique n'est que l'utilisation de Shaders fournis par le fabricant de la carte graphique pour le moteur de rendu (Vulkan en l'espèce) rien d'insurmontable.
Vulkan (ex OpenGL Next) est un standard développé en commun par AMD, Intel et Nvidia et est fourni avec les pilotes graphiques de la carte. Quiconque peut l'utiliser librement, donc, actuellement, X-Plane 11 l'utilise, comme FSW l'avait fait, quelle que soit la marque de la carte graphique équipant le Pc ou le Mac.
Le fait que Vulkan soit développé en commun par les trois principaux fabricants de processeurs graphiques pour leurs matériels et le fait que Vulkan fonctionne quel que soit l'OS devraient favoriser le choix de LM pour ce moteur de rendu puisque LM tient à rester indépendant de tout fabricant de GPU.
Mais bon, ceci n'est que le moteur de rendu, la gestion du 3D c'est autre chose et c'est bien là que ça coince actuellement, d'où l'annonce par LM du changement de moteur graphique pour la v5 et, là, c'est sûr, c'est le gros du boulot et ce qui devrait nous apporter plus de performances.
Des améliorations nettes en performances (et rendu ?), certes, mais tout dépendra, comme toujours, de la puissance de la carte graphique utilisée.
Hors ligne
Vulkan est une api graphique mais je ne pense pas que l'on puisse la qualifier de moteur de rendu, vulkan est la couche en dessous, comme directx. Un moteur de rendu utilise Vulkan ou directX par exemple
Hors ligne
Qu’est-ce qu’une API graphique
Une API graphique est une interface de programmation spécifique, qui permet de créer des rendus 2D et 3D simplement et rapidement, en utilisant des fonctions prêtes à l’emploi qui seront traitées par la puce graphique, en passant par le pilote graphique qui traduira les fonctions en commandes à exécuter. En utilisant une API graphique (Open GL, Vulkan, DirectX, etc.), il est alors possible de créer des moteurs 3D. Ces moteurs 3D (Unreal Engine, Unity 3D, etc.) seront ensuite utilisés par les développeurs de jeux vidéo pour créer leurs titres.
Hiérarchie:
1. GPU
2. Pilote
3. API (moteur de rendu)
4. Moteur 3D
Hors ligne
Je préfère cette définition :
There are two major categories for 3D rendering tools: API and engines. In one hand it’s possible to work with 3D Graphics API, such as OpenGL, Direct3D, Vulkan and VTK and on the other hand with engines as Unreal and Unity.
LE moteur est, si c'est bien fait, indépendant de l'API et constitue une couche d'abstraction supplémentaire (l'API permettant elle de s'abtraire du matériel, donc une couche en dessous).
Le moteur peut fonctionner en vulkan ou directx. et directx ou vulkan, les API, peuvent fonctionner avec du nvidia ou du amd, chacun cache ce qui se passe juste en dessous.
je parle de moteur et api "tout court" car les uns comme les autres font plus que le rendering qui n'est qu'une partie de leurs fonctionnalités
Bon, c'est pas le sujet de toute façon
Dernière modification par Nirgal76 (19-08-2018 22:13:32)
Hors ligne
Heu, pour autant que je me souvienne, "si c'est bien fait", le moteur n'est pas du tout independant de l'API.
Au contraire même: si c'est bien fait, le moteur doit être concu autour de l'API que l'on compte utiliser, histoire d'optimiser les choses le plus possible, en fonction de la facon dont l'API fonctionne....
Hors ligne
Je ne pense pas que l'on parle de la meme chose. Pour le developpeur du moteur, oui, effectivement,il aura a faire du spécifique PAR api qu'il décide de supporter (comme unity, qui est un moteur "bien fait" et qui supporte, directx, opengl et vulkan sur tout un tas de plateformes).
Mais pour le developpeur de jeu, "simple utilisateur" du moteur, le but est d'avoir le moins de chose spécifique à faire quelque soit la plateforme (et donc l'API), ça fait gagner du temps et de l'argent. Bon, les shaders resteront forcément spécifiques par exemple, c'est certain. Entre les versions consoles et pc, peu de moteur sont réécrits pour être optimisés, on a souvent à faire a des portages plus ou moins malheureux, par soucis d'économie uniquement.
C'est d'ailleurs l'essence de l'informatique normalement, rendre la vie facile à l'utilisateur, même si cela rends les choses plus compliquées pour le développeur . L'argent venant tout gâcher comme toujours...
Hors ligne
Ah ok, tu parlais du moteur de jeu. Je pensais que tu parlais du moteur graphique :)
Hors ligne
Pages: 1