# Applications > Dveloppement 2D, 3D et Jeux > Moteurs 3D >  Limitation des nombres flottants

## oxyde356

Bonjour  tous, je travaille sur un gros projet de ... gnrateur de plante...
Je suis actuellement entrein de dvellopper un moteur permettant de se dplacer sur une plante  chelle relle.
Explication : un plante 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 prcision infinie et je devrai donc pouvoir zoom jusqu' l'atome et mme plus (mme si sa ne representerai plus rien) et n'avoir quasiment rien a stocker en mmoire !
Ce qui va me poser problme 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 dcimtre (1 vertex tous les dcimtre) je vais avoir un petit problme de prcision, surtout du faite que la terre est ronde enfaite :p donc les cosinus et sinus vont vite saturs la mantisse :/
Aussi si vous aviez des ides pour contourner ce problme, 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 mme les calculs ne la ncessitant 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 ... gnrateur de plante...
> Je suis actuellement entrein de dvellopper un moteur permettant de se dplacer sur une plante  chelle relle.
> Explication : un plante 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 prcision infinie et je devrai donc pouvoir zoom jusqu' l'atome et mme plus (mme si sa ne representerai plus rien) et n'avoir quasiment rien a stocker en mmoire !
> Ce qui va me poser problme 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 dcimtre (1 vertex tous les dcimtre) je vais avoir un petit problme de prcision, surtout du faite que la terre est ronde enfaite :p donc les cosinus et sinus vont vite saturs la mantisse :/
> Aussi si vous aviez des ides pour contourner ce problme, 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 mme les calculs ne la ncessitant 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 imprcis, et il est impossible de changer a. Il existe cependant des types de donnes qui offrent une bonne prcision ainsi que de bonnes vitesses de calcul : par exemple, les entiers de 64 bits (sais tu que tu peux encoder _594 annes_ avec une prcision de _1 nanoseconde_ sur un entier de 64 bits ? Ou, en ce qui concerne les distances, _18 mille milliards de kilomtres_ avec une prcision de _1 millimtre_ (soit prs de 2 annes lumires, quand mme)) ?

Mais ce n'est utilise que pour la base de donne du monde considr, et pas trop pour le rendu. 

Pour reprsenter les univers d'une taille importante, des repres locaux (--> changements de base) sont une bonne solution. L'utilisation d'une prcision incrmentielle est une bonne chose aussi (non, lorsque tu reprsente la terre vue du ciel, tu n'as pas besoin d'une prcision de 10 cm; Si tu te contente du km, c'est dj pas mal). Rappel: il te faudrait un cran de 6400 pixels pour qu'une erreur de l'ordre du km soit visible si tu reprsente une boule de 6400 km de large...

----------


## oxyde356

> Les nombres flottants sont imprcis, et il est impossible de changer a. Il existe cependant des types de donnes qui offrent une bonne prcision ainsi que de bonnes vitesses de calcul : par exemple, les entiers de 64 bits (sais tu que tu peux encoder _594 annes_ avec une prcision de _1 nanoseconde_ sur un entier de 64 bits ? Ou, en ce qui concerne les distances, _18 mille milliards de kilomtres_ avec une prcision de _1 millimtre_ (soit prs de 2 annes lumires, quand mme)) ?
> Mais ce n'est utilise que pour la base de donne du monde considr, et pas trop pour le rendu.


Non je ne le savais pas mme si c'est facilement calculable, mais les GPU travaille qu'avec des flottants en double ou simple prcision et j'ai pas envie de faire du rendu software  ::D:  mais merci pour l'info  :;): 




> Pour reprsenter les univers d'une taille importante, des repres locaux (--> changements de base) sont une bonne solution.


Partons du principe que je n'ai qu'une seule plante. Quand je suis a 40000km je vois ma plante bien ronde, pas de problme, quand je zoom au metre prs les points formants les triangles partent en sucette  ::P:  d au fait que le cosinus d'un angle permettant de calculer les coordonnes cartsiennes d'un point de la plante sont surement gale  9.99999998 (par exemple) calcul en flottant me rend une approximation moisie et que de toute faon 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 prcision incrmentielle est une bonne chose aussi (non, lorsque tu reprsente la terre vue du ciel, tu n'as pas besoin d'une prcision de 10 cm; Si tu te contente du km, c'est dj pas mal). Rappel: il te faudrait un cran de 6400 pixels pour qu'une erreur de l'ordre du km soit visible si tu reprsente une boule de 6400 km de large...


Ihih non mais la c'est plus vraiment le mme problme ^^ biensur que je n'essaye pas de calculer au centimtre pres quand je suis a 6400km sinon j'aurai  calculer des milliards de milliards de points ^^ la prcision au sens du nombre de points a rendre a c'est pas un problme je sais faire, ce qui me pose problme c'est que je veux pouvoir all d'un infiniment grand a un infiniment petit  ::P:  bon enfaite ce n'est pas un infiniment biensur ^^ enfaite la prcision du flottant me convient presque il me faudrait juste 2 fois plus de chiffres dcimaux (rien que sa  ::):  ).

Je me suis peut tre mal exprim sur mon problme : mon problme se sont les compantes flottantes X, Y et Z du vecteur position d'un point de ma plante, qui doivent avoir des valeurs du genre : 5000000000000,000000000005 en somme quelque chose de pas vraiment grable 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 sphriques sa m'embrouille beaucoup :/

Merci beaucoup d'avoir rpondu  ::): 

Si quelqu'un a une ide qu'il n'hsite 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 sphre de rayon 1 (par exemple).

L'ide est de calculer la taille de ta plante  l'cran et d'adapter ta camra afin que ta sphre 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 plantes les plus loignes vers les plus proches.

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

----------


## 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 transforms en GL_FLOAT par les drivers de la carte graphique, donc cela ne change rien au problme.

Dans  le lien que j'ai mis tu as un journal de dveloppement et il y parle de sa solution pour rsoudre ce problme.

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 annes (environ 2002-2003, fin de mes tudes) sur un article dans Gamasutra que j'ai russi  retrouver.

Un article trs intressant sur ce problme prcis, de plus, la personne traite beaucoup d'lments sur ce sujet fort intressant de la gnration dunivers  ::): 

*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 annes (environ 2002-2003, fin de mes tudes) sur un article dans Gamasutra que j'ai russi  retrouver.
> 
> Un article trs intressant sur ce problme prcis, de plus, la personne traite beaucoup d'lments sur ce sujet fort intressant de la gnration dunivers 
> 
> *A Real-Time Procedural Universe*
> 
> Le tout en 4 parties:
> - Partie 1: Generating Planetary Bodies
> - Partie 2: Rendering Planetary Bodies
> ...


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

----------


## Ti-R

Sans trop driver vers un autre sujet, il y a peut tre moyen pour toi de t'associer/renseigner auprs 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 mme 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 trs interressant et je l'avais dja vu mais ce n'est pas exactement le mme problme que moi qui est rsolu, enfin dans l'absolu si c'est le mme problme mais les solutions apportes ne sont pas vraiment applicables dans mon contexte. Affich des objets complexes qui sont archi loin c'est pas vraiment mon problme, la je sais comment faire en thorie, 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 ides je veux bien le max de docs possible  ::): 
Merci pour votre prcieuse aide :p

----------


## oxyde356

J'ai rien dit  ::D: 
Effectivement dans cet article : http://www.gamasutra.com/features/20...oneil_01.htm##
Il explique tout (mais je comprend pas tout par contre  ::D: ) !
Effectivement il faut trait la camra comme l'origine, sa m'a l'air d'tre la meilleur solution pour traiter avec meilleur precision les "objets" de prs. Par contre je comprend toujours pas comment il fait pour calculer les coordonnes des vertices. Moi mes vertex ne sont pas calculer a chaque frame. Ils sont stocks, et j'en rajoute/enlve selon que je me rapproche ou m'loigne. Donc si la camra bouge je peux pas mettre a jour la position de mes vertices. A un moment il dit de rduire 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 camras 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.
Aprs tu peux faire un montage vidos 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 mmes principes et les "float" sont donc largement suffisants.

----------

