J'aimerais dessiner de très grands graphiques (~ 500 px) de planètes en rotation lente. Ces graphiques sont destinés à impressionner. Quelle est la meilleure façon de procéder? Je n'ai aucune expérience avec un moteur 3D particulier, et je ne suis même pas sûr de la plate-forme sur laquelle ce jeu fonctionnerait, donc:
- Je pouvais pré-rendre chaque image, mais à 500 pixels et une période de rotation de 10 secondes, c'est une quantité ridicule de données par planète.
- Je pourrais utiliser un moteur 3D et cartographier la texture de la planète sur un maillage approchant d'une sphère, mais à 500 pixels, je crains que le nombre de polygones ne soit énorme pour qu'il soit beau.
- Je pourrais écrire une sorte de moteur 3D personnalisé qui ne fait que rendre efficacement une sphère texturée, en convertissant les coordonnées x / y de chaque pixel de vue en l'espace de coordonnées de la texture de la sphère - mais cela est impliqué et ne pouvait pas bénéficier de accélération graphique.
- Quelque chose d'autre auquel je n'ai pas pensé?
Voici un exemple de GIF animé de ce que je veux dire. (À 100x100 px et 60 images, c'est déjà assez énorme, désolé.) Imaginez ceci, beaucoup plus grand, tournant beaucoup plus lentement et animé plus facilement:
Mais si c'était 500x500 px et 10 x 25 = 250 images, nous parlerions de centaines de Mo de données, donc cette approche directe ne fonctionne pas.
2d
3d
graphics
graphics-programming
Zarkonnen
la source
la source
Réponses:
Le nombre de polygones pour rendre une sphère 500x500px "belle" avec un seul appel de dessin est trivial pour les GPU à gérer sur la plupart des plates-formes, surtout s'il n'y a pas grand-chose d'autre dans la scène. Il y a aussi quelques notes sur la texturation des sphères pour éviter la distorsion du texel; assurez-vous d'utiliser une carte de cube.
la source
Puisque vous regardez la sphère avec une caméra constante, vous pouvez effectuer un rendu de haute qualité extrêmement rapidement avec une simple table de recherche précalculée.
En tant qu'étape précalculée, avec n'importe quelle méthode que vous aimez (généralement avec des polygones ou un lancer de rayons), vous rendez une sphère mappée de texture dans un tampon offsceen, mais au lieu de calculer les couleurs en fonction de la texture, vous ne stockez que les coordonnées u / v de la texture.
Ensuite, lors du rendu de la planète réelle, vous rendez un carré simple et pour chaque pixel, vous récupérez les coordonnées u / v réelles de la table de recherche et les couleurs des pixels de la texture de la planète en utilisant ces coordonnées u / v. Pour faire pivoter la sphère, il suffit de décaler la coordonnée u avec l'angle de rotation.
Cette technique était très populaire dans la demi-scène par exemple avec des effets de tunnel à texture mappée, mais malheureusement je n'ai trouvé aucun bon tutoriel à ce sujet.
la source
Si vous faites cela dans un cadre 2D, consultez cette question précédente ...
Illusion 3D d'une texture de planète 2D
Le même concept fonctionnerait bien avec une grande image et en déplaçant dynamiquement la texture du terrain sur une couche sous le "trou" dans l'espace.
Lisez le lien ci-dessus pour savoir ce que je veux dire par là.
la source
Si vous compressiez l'animation résultante avec un codec vidéo moderne, ce ne serait pas particulièrement gros du tout et loin de "plusieurs centaines de Mo de données" ni ridicule ...
Mais comme déjà indiqué, tout dépend de votre plate-forme cible et comme tout le monde l'a dit; le simple rendu d'une sphère 3D lisse impliquerait en fait une quantité insignifiante de polygones et très peu de stockage de données (la texture étant tout ce qu'il y a et même à des résolutions très élevées, la compression JPEG standard la ramènerait à rien).
Tout dépend aussi un peu de la façon dont vous êtes pointilleux - si vous recherchez le style de défilement quart de pixel et les détails de la texture à égalité avec les démos de pointe et pas seulement les jeux contemporains avec toute leur interpolation et leur aliasing même à 8x FSAA - alors cela pourrait être impliqué presque sans fin (et nécessiter aussi un peu de ruse artistique) ^^
la source
Si vous rencontrez des problèmes avec les performances, procédez de la manière traditionnelle (texture et mappage normal sur une sphère à polygones élevés), ce qui, comme beaucoup l'ont mentionné, ne devrait pas être un problème à cette résolution:
"Raytrace" avec un fragment shader. Si votre caméra est fixe, tout ce dont vous avez besoin est une entrée flottante uniforme dans votre fragment shader (pour l'angle de rotation) et le shader peut prendre en charge le calcul des coordonnées de texture. Les vecteurs d'éclairage peuvent même être identiques à chaque image. Quant à l'anticrénelage, vous pouvez également obtenir une silhouette sphérique parfaite avec peu d'ingéniosité (si le pixel est sur la frontière de la sphère, calculez sa couverture)
Cela vous permet d'envoyer seulement 4 sommets à travers le pipeline, et ne vous oblige pas à allouer un gigantesque framebuffer multisampled pour combattre les jaggies.
Au prix d'avoir à proposer plusieurs algorithmes sur mesure.
la source