Discussion :

[oxyde356]

Bonjour à tous, je travaille sur un gros projet de ... générateur de planète...
Je suis actuellement entrein de dévellopper un moteur permettant de se déplacer sur une planète à échelle réelle.
Explication : un planète est representé par un cube composé donc de 6 faces sur lequel est appliqué l'algorithme ROAM. Chaque point de subdivision est placé par simple normalisation du vecteur "centre de la sphere -> point" et par multiplication par le rayon puis apres j'utilise une (enfaite plusieurs mais je simplifie) fonction fractale pour calculer l'altitude du point. C'est une fonction continue donc je peux avoir une précision infinie et je devrai donc pouvoir zoomé jusqu'à l'atome et même plus (même si sa ne representerai plus rien) et n'avoir quasiment rien a stocker en mémoire !
Ce qui va me poser problème c'est la limitation des nombres flottants, hors je travail avec directx et toutes les fonctions recoivent des vecteurs aux composantes flottantes, sachant que le rayon de la terre (pour prendre un exemple) est d'environ 6400km est que j'aimerai bien avoir une precision d'au moins 1 décimètre (1 vertex tous les décimètre) je vais avoir un petit problème de précision, surtout du faite que la terre est ronde enfaite :p donc les cosinus et sinus vont vite saturés la mantisse :/
Aussi si vous aviez des idées pour contourner ce problème, je suis preneur :p changement de base, impostors, qu'est ce qui pourrait bien marcher ?
J'ai vu que l'on pouvait passer directx en double precision mais je crois que l'on peut ne l'activer qu'à l'initialisation se qui fait que même les calculs ne la nécessitant pas seront effectuer en double precision et puis sa salit gravement les performances donc si vous aviez mieux a proposer je suis preneur

Merci à vous

[Emmanuel Deloget]

Bonjour à tous, je travaille sur un gros projet de ... générateur de planète...
Je suis actuellement entrein de dévellopper un moteur permettant de se déplacer sur une planète à échelle réelle.
Explication : un planète est representé par un cube composé donc de 6 faces sur lequel est appliqué l'algorithme ROAM. Chaque point de subdivision est placé par simple normalisation du vecteur "centre de la sphere -> point" et par multiplication par le rayon puis apres j'utilise une (enfaite plusieurs mais je simplifie) fonction fractale pour calculer l'altitude du point. C'est une fonction continue donc je peux avoir une précision infinie et je devrai donc pouvoir zoomé jusqu'à l'atome et même plus (même si sa ne representerai plus rien) et n'avoir quasiment rien a stocker en mémoire !
Ce qui va me poser problème c'est la limitation des nombres flottants, hors je travail avec directx et toutes les fonctions recoivent des vecteurs aux composantes flottantes, sachant que le rayon de la terre (pour prendre un exemple) est d'environ 6400km est que j'aimerai bien avoir une precision d'au moins 1 décimètre (1 vertex tous les décimètre) je vais avoir un petit problème de précision, surtout du faite que la terre est ronde enfaite :p donc les cosinus et sinus vont vite saturés la mantisse :/
Aussi si vous aviez des idées pour contourner ce problème, je suis preneur :p changement de base, impostors, qu'est ce qui pourrait bien marcher ?
J'ai vu que l'on pouvait passer directx en double precision mais je crois que l'on peut ne l'activer qu'à l'initialisation se qui fait que même les calculs ne la nécessitant pas seront effectuer en double precision et puis sa salit gravement les performances donc si vous aviez mieux a proposer je suis preneur

Merci à vous

Les nombres flottants sont imprécis, et il est impossible de changer ça. Il existe cependant des types de données qui offrent une bonne précision ainsi que de bonnes vitesses de calcul : par exemple, les entiers de 64 bits (sais tu que tu peux encoder 594 années avec une précision de 1 nanoseconde sur un entier de 64 bits ? Ou, en ce qui concerne les distances, 18 mille milliards de kilomètres avec une précision de 1 millimètre (soit près de 2 années lumières, quand même)) ?

Mais ce n'est utilise que pour la base de donnée du monde considéré, et pas trop pour le rendu.

Pour représenter les univers d'une taille importante, des repères locaux (--> changements de base) sont une bonne solution. L'utilisation d'une précision incrémentielle est une bonne chose aussi (non, lorsque tu représente la terre vue du ciel, tu n'as pas besoin d'une précision de 10 cm; Si tu te contente du km, c'est déjà pas mal). Rappel: il te faudrait un écran de 6400 pixels pour qu'une erreur de l'ordre du km soit visible si tu représente une boule de 6400 km de large...

[oxyde356]

Les nombres flottants sont imprécis, et il est impossible de changer ça. Il existe cependant des types de données qui offrent une bonne précision ainsi que de bonnes vitesses de calcul : par exemple, les entiers de 64 bits (sais tu que tu peux encoder 594 années avec une précision de 1 nanoseconde sur un entier de 64 bits ? Ou, en ce qui concerne les distances, 18 mille milliards de kilomètres avec une précision de 1 millimètre (soit près de 2 années lumières, quand même)) ?
Mais ce n'est utilise que pour la base de donnée du monde considéré, et pas trop pour le rendu.

Non je ne le savais pas même si c'est facilement calculable, mais les GPU travaille qu'avec des flottants en double ou simple précision et j'ai pas envie de faire du rendu software mais merci pour l'info

Pour représenter les univers d'une taille importante, des repères locaux (--> changements de base) sont une bonne solution.

Partons du principe que je n'ai qu'une seule planète. Quand je suis a 40000km je vois ma planète bien ronde, pas de problème, quand je zoom au metre près les points formants les triangles partent en sucette dû au fait que le cosinus d'un angle permettant de calculer les coordonnées cartésiennes d'un point de la planète sont surement égale à 9.99999998 (par exemple) calculé en flottant me rend une approximation moisie et que de toute façon je dois me contenter de ça pour positionner mes points ^^
Mais en partant du principe de changement de base qui me permettrait de simplifier mes valeurs et d'éviter des arrondis trop stricte... comment je peux faire je vois pas du tout :o

L'utilisation d'une précision incrémentielle est une bonne chose aussi (non, lorsque tu représente la terre vue du ciel, tu n'as pas besoin d'une précision de 10 cm; Si tu te contente du km, c'est déjà pas mal). Rappel: il te faudrait un écran de 6400 pixels pour qu'une erreur de l'ordre du km soit visible si tu représente une boule de 6400 km de large...

Ihih non mais la c'est plus vraiment le même problème ^^ biensur que je n'essaye pas de calculer au centimètre pres quand je suis a 6400km sinon j'aurai à calculer des milliards de milliards de points ^^ la précision au sens du nombre de points a rendre ça c'est pas un problème je sais faire, ce qui me pose problème c'est que je veux pouvoir allé d'un infiniment grand a un infiniment petit bon enfaite ce n'est pas un infiniment biensur ^^ enfaite la précision du flottant me convient presque il me faudrait juste 2 fois plus de chiffres décimaux (rien que sa ).

Je me suis peut être mal exprimé sur mon problème : mon problème se sont les compantes flottantes X, Y et Z du vecteur position d'un point de ma planète, qui doivent avoir des valeurs du genre : 5000000000000,000000000005 en somme quelque chose de pas vraiment gérable avec du float !
Je pense que je dois faire un changement de base pour les positionner mais je ne vois pas trop comment je dois faire surtout vu que je travaille sur des objets sphériques sa m'embrouille beaucoup :/

Merci beaucoup d'avoir répondu

Si quelqu'un a une idée qu'il n'hésite pas !

[hougoul]

Bonjour,

Va voir le projet suivant :
http://www.gamedev.net/community/for...opic_id=345363

Sinon tu peux jouer sur la matrice de transformation 3D vers 2D (lookAt, fov, clipping plane ...) afin d'utiliser une sphère de rayon 1 (par exemple).

L'idée est de calculer la taille de ta planète à l'écran et d'adapter ta caméra afin que ta sphère de rayon X remplisse la totalité de l'espace écran voulu.

Bien entendu cela t'oblige à ne pas utiliser le depth test pour tout ton rendu et de commencer par les planètes les plus éloignées vers les plus proches.

Sur le site que je t'ai donné, tu devrais trouver les infos nécessaires.

[epsilon68]

avec opengl tu peux utiliser les doubles...
mais je pense quand meme qu'un petit changement de repere s'impose.

[hougoul]

En fait les GL_DOUBLE sont transformés en GL_FLOAT par les drivers de la carte graphique, donc cela ne change rien au problème.

Dans le lien que j'ai mis tu as un journal de développement et il y parle de sa solution pour résoudre ce problème.

Mets nous au courant de tes évolutions, pour que l'on puisse t'aider un peu plus.

[Ti-R]

Je suis tombé il y a quelques années (environ 2002-2003, fin de mes études) sur un article dans Gamasutra que j'ai réussi à retrouver.

Un article très intéressant sur ce problème précis, de plus, la personne traite beaucoup d'éléments sur ce sujet fort intéressant de la génération d’univers

A Real-Time Procedural Universe

Le tout en 4 parties:
- Partie 1: Generating Planetary Bodies
- Partie 2: Rendering Planetary Bodies
- Partie 3: Matters of Scale <- les questions que tu te poses actuellement
- Partie 4: Dynamic Ground Textures and Objects

ps: J'ai pris le temps de placer tous les liens car ce n'est pas directement lié sous gamasutra...

[Emmanuel Deloget]

Je suis tombé il y a quelques années (environ 2002-2003, fin de mes études) sur un article dans Gamasutra que j'ai réussi à retrouver.

Un article très intéressant sur ce problème précis, de plus, la personne traite beaucoup d'éléments sur ce sujet fort intéressant de la génération d’univers

A Real-Time Procedural Universe

Le tout en 4 parties:
- Partie 1: Generating Planetary Bodies
- Partie 2: Rendering Planetary Bodies
- Partie 3: Matters of Scale <- les questions que tu te poses actuellement
- Partie 4: Dynamic Ground Textures and Objects

ps: J'ai pris le temps de placer tous les liens car ce n'est pas directement lié sous gamasutra...

Le site web de l'auteur (si ça aide)

[Ti-R]

Sans trop dériver vers un autre sujet, il y a peut être moyen pour toi de t'associer/renseigner auprès du projet vieWTerra

[oxyde356]

loul c'est un grand malade le gars de viewTerra :o:o:o
Quel travail monstrueux...
Mon projet se rapproche plus de celui de Infinity, j'ai même envie de dire c'est exactement ce que je cherche, je vais éplucher tout son journal de dev :p
Quand à l'article sur gamasutra il est très interressant et je l'avais déja vu mais ce n'est pas exactement le même problème que moi qui est résolu, enfin dans l'absolu si c'est le même problème mais les solutions apportées ne sont pas vraiment applicables dans mon contexte. Affiché des objets complexes qui sont archi loin c'est pas vraiment mon problème, la je sais comment faire en théorie, mais vu que la c'est pour calculer un cosinus avec un angle tout petit c'est plus chaud. Je vais voir le carnet de dev mais si quelqu'un a encore des idées je veux bien le max de docs possible
Merci pour votre précieuse aide :p

[oxyde356]

J'ai rien dit
Effectivement dans cet article : http://www.gamasutra.com/features/20...oneil_01.htm##
Il explique tout (mais je comprend pas tout par contre ) !
Effectivement il faut traité la caméra comme l'origine, sa m'a l'air d'être la meilleur solution pour traiter avec meilleur precision les "objets" de près. Par contre je comprend toujours pas comment il fait pour calculer les coordonnées des vertices. Moi mes vertex ne sont pas calculer a chaque frame. Ils sont stockés, et j'en rajoute/enlève selon que je me rapproche ou m'éloigne. Donc si la caméra bouge je peux pas mettre a jour la position de mes vertices. A un moment il dit de réduire la taille proportionnellement à la distance, je vois pas vraiment ce que sa apporte une mantisse pleine de 1 restera une mantisse pleine de 1, il n'y aura que l'exposant qui changera dans ce cas la. Que comprenez-vous sur le paragraphe juste avant le titre : Problems of Scale: A Star System ?

Je crois qu'avant toute chose je vais étudier le code source du gars qu'y a poster les articles surtout ^^
merci

[hougoul]

Ce qui est vachement bien avec les caméras c'est que l'on peut filmer des choses toute petite et faire en sorte qu'elles paraissent grandes.

Imagine :
tu filmes en gros plan une bal de golf.
Puis tu te filmes normalement.
Après tu peux faire un montage vidéos de tel sorte que tu apparaisses avec la balle de golf.
On aura l'impression que la balle de golf est plus grande que toi.

Ici tu appliques les mêmes principes et les "float" sont donc largement suffisants.