En août 2017, dans un Around The Verse consultable ci-dessous, CIG nous présente une technologie permettant de transposer un élément du Verse sur un écran ou un hologramme. A l'époque cette technologie semblait prometteuse en matière de réalisme, pourtant, 3 ans plus tard, elle semble avoir "disparue du jeu".
Dans une récente discussion du Spectrum, un backer soulève alors la question de savoir ce qu'il en est de cette technologie.
Ben Parry, Senior Graphics Programmer chez CIG, prend le temps d'y répondre et de clarifier de nombreux points tout en mettant le doigts sur les limites de cette technologie.
Star Citizen: Around the Verse - Secondary Viewports
Les points de vue secondaires (?)
Il y a longtemps, (3 août 2017), un épisode de Around the Verse, mettant en évidence un manque de réalisme, a été diffusé. Lorsque l'épisode est passé en direct, il semblait être sur le point d'être mis en œuvre... la technologie, appelée "secondary viewports" était censée mettre en œuvre des "réflexions" en temps réel sur les fenêtres, les miroirs, etc. elle était également un élément clé du système de communication "halographique" pour l'un des donneurs de mission.
-- ol'red sur le Spectrum
Réponses de Ben Parry
Salut, désolé d'avoir pris du temps pour revenir à ce sujet, j'ai tapé une réponse importante et ensuite, je suppose, je n'ai pas cliqué sur publier. Je vais essayer de répondre à diverses questions point par point.
Quel est l'état du système ?
Il est opérationnel ! Il est utilisé partout, dans des endroits que vous n'avez peut-être pas réalisés, comme les mini-revues et les appels comms dans le mobiglass, les hologrammes dans le monde entier, comme la grande publicité pour les boissons gazeuses dans la zone 18 et (je pense) les vues des navires ennemis dans le HUD.
Est-ce toujours le plan pour les réflexions ?
Il est important de souligner qu'il ne s'agit pas d'une solution générale pour ajouter des réflexions de haute qualité partout. Chaque fois que nous mettons en place une de ces vues, nous devons prendre des décisions sur le style de rendu qu'elle utilisera, et sur les fonctionnalités qui seront activées, en fonction du temps de rendu et de la mémoire GPU permanente dont elles auront besoin. C'est donc une bonne solution pour un miroir dans une salle de bain fermée, où nous savons qu'il n'y a qu'une poignée de lumières et que vous ne pouvez pas, par exemple, voir l'atmosphère d'une planète par la fenêtre. Le même miroir sur un objet contrôlé par un joueur serait comme une bombe en matière de performances, où le fait de le regarder dans de mauvaises circonstances réduirait de moitié votre cadence. De même, on ne peut pas se contenter de les reproduire sur toutes les surfaces brillantes.
Y a-t-il une mise à jour de la chronologie ?
Il y a quelques petits problèmes techniques qui l'empêchent actuellement d'être utilisé comme un miroir de la manière la plus simple, par exemple, en raison de la manière dont les polygones sont éliminés, le fait de refléter un objet vous montre également les faces arrière du maillage, le retournant effectivement. Aucun de ces problèmes n'est susceptible d'être énorme, mais il est probable que beaucoup de ces petits accrocs se cachent dans différents systèmes.
Des vues secondaires seront-elles disponibles sur le HUD, pour aider à l'atterrissage dans les hangars ?
Voir ma réponse à la question (2) pour savoir pourquoi nous ne souhaitons pas ajouter des vues de caméra à usage général sur des objets qui peuvent voler dans des endroits arbitraires. Cela ne veut pas dire pour autant qu'une telle vue ne pourrait pas fonctionner. L'équipe graphique a généralement plaidé pour que ce type de caractéristiques soit présenté comme une sorte de "vue scanner", ce qui signifierait qu'il pourrait avoir un aspect visuellement attrayant et non photoréaliste, et nous donnerait la liberté d'omettre les principaux puits de performance dont vous n'avez pas réellement besoin, ou qui interféreraient activement avec l'atterrissage. Par exemple, le brouillard volumétrique a des coûts de performance et de mémoire importants, mais l'atterrissage dans le brouillard est probablement plus difficile, alors pourquoi ne pas avoir un scanner qui ne voit pas du tout le brouillard ?
Encore une fois, désolé d'avoir posé une question et d'avoir ensuite disparu pendant un mois, j'espère que cela vous permettra de répondre à vos questions.
-- Ben Parry
Ben Parry répond à d'autres questions annexes
Pardonnez mon ignorance, mais comment le rendu, disons, de la vue d'une caméra tierce partie est-il plus intense que l'affichage, disons, de la vue d'une caméra externe sur un navire ?
Les deux seraient très coûteux à réaliser, si ce qui est rendu ne devait ressembler qu'à une vue de caméra. Les économies que je suggérais viendraient du fait de dire quelque chose comme "ceci est un dockmaster 3000 à balayage laser qui recherche avec précision les risques de collision dans un rayon de 300 m", et de pouvoir immédiatement ignorer les objets situés au-delà de 300 m, l'éclairage, le brouillard, etc, en le dessinant à l'intérieur comme une lecture stylisée (et, espérons-le, plus informative).
Est-ce la technologie qui sera utilisée pour les "écrans de visualisation" derrière les lits de la 890J dont on a parlé et qui pourront être des "fenêtres sur l'espace" virtuelles ? Ce serait incroyable pour les espaces intérieurs comme le Carrack Cartography Deck et si la salle de billard de la 890J avait des fenêtres virtuelles...
Comme mentionné au point 4, il serait très mauvais pour la stabilité des performances, d'avoir des caméras à usage général où nous ne pouvons pas limiter le nombre et/ou le type d'objets qui sont visibles par cette caméra.
Étant donné qu'il existe déjà de grandes fenêtres de navires (vitres du cockpit, fenêtres du mess du Carrack, salle de conférence du 890J), est-il très coûteux d'avoir un treillis dont la texture est d'une opacité variable ? Si elles se produisent dans des pièces où les autres éléments de la scène sont très limités (comme le pont de cartographie du Caraque, ou les suites d'invités du 890J).
Un "écran" qui n'est en fait qu'une fenêtre trompeuse est certainement la façon dont je suggère de faire ce genre de choses, oui. Mais cela pose un problème, si l'écran n'est pas conçu pour être très high-tech et très magique, il est difficile d'expliquer pourquoi sa vue change quand on le contourne et qu'on ne peut pas y ajouter d'effets vidéo.
Un complément intéressant
Dans le fil de la discussion, Nemo fait remarquer que dans le premier Unreal Engine de 2000, dans des jeux comme Klingon Honor Guard et Deus Ex, les miroirs, les fenêtres et les écrans étaient mis en place à l'aide de portails de zone, qui n'avaient pas besoin d'être adjacents à ce que vous vouliez voir. Ils ne faisaient que rendre une image de caméra (point de vue dynamique de l'acteur) sur une texture, en reliant un rectangle dans la zone A à un autre rectangle dans la zone B. Si vous regardiez dans le rectangle de la zone A, vous regardiez en fait en dehors du rectangle de la zone B, alors que les zones A et B pouvaient même être la même zone, juste d'un autre point de vue.
Pour les miroirs, l'image du rectangle de la zone B était simplement inversée, mais il n'y avait pas d'effort de rendu supplémentaire. En fait, l'utilisation de ces portails de zone a même augmenté les performances, car vous pouviez éliminer ce qui n'était pas visible.
Cf. Mirrors and WarpZones dans la documentation d'Unreal Engine.
Veuillez excuser que mes connaissances soient encore à ce niveau à cet égard, et j'ai donc encore besoin de savoir pourquoi il semble terriblement difficile dans Star Citizen de créer un miroir ou un écran de caméra dans une autre pièce, alors que la technologie était déjà là en 2000 ? Je comprends toujours que nous avons maintenant beaucoup plus de polygones à rendre qu'en 2000, mais le matériel GFX s'est également amélioré.
Il est malheureusement devenu beaucoup plus difficile de faire ce genre de choses dans un moteur moderne, ce qui explique probablement pourquoi nous avons vu dans les jeux la disparition des miroirs en état de marche. Le problème, c'est qu'à l'époque, tout était rendu à l'avance, de sorte que toutes les informations nécessaires pour dessiner un objet étaient fournies au moment où l'objet était dessiné, et qu'au moment où un pixel était ombré, il avait l'aspect qu'il devait avoir.
Une chose qui a changé, c'est que beaucoup de moteurs, y compris le nôtre, utilisent un moteur de rendu différé, où les polygones écrivent un ensemble de propriétés matérielles et une valeur de profondeur, et une passe ultérieure combine cela avec un ensemble de lumières. Pour que cela fonctionne, on suppose qu'il y a un calcul simple qui convertit toute coordonnée de pixel et de profondeur en une position 3D. L'ajout de miroirs ou de portails est théoriquement possible, mais il faudrait des données supplémentaires stockées dans chaque pixel pour vous dire quelle transformation appliquer, entre autres choses.
L'autre grand problème, ce sont les données qui sont définies à l'avance, avec des hypothèses similaires intégrées. Avant d'ombrager la scène, nous construisons une grille 2D des lumières qui affectent les 8x8 carreaux de l'écran, en supposant encore une fois qu'il s'agit d'un seul espace devant la caméra, ainsi qu'une texture volumétrique à faible résolution contenant des informations sur le brouillard. En théorie, je pense que nous pourrions ajouter des ID-portails à chaque lumière, pour un certain coût supplémentaire, mais le brouillard ne peut pas être masqué par la zone du miroir, car sa résolution est beaucoup plus faible.
Il y a probablement des problèmes supplémentaires que j'ai oubliés, mais ce sont ceux qui me viennent à l'esprit.
