[mOved] [F] news » info & high-tech » 3D, voxels et nuages de points - Page 1

Ce sujet est issu d'une discussion ayant dérivé sur deux thèmes distincts. Pour vous rendre sur le sujet d'origine, merci de cliquer sur ce lien

une nouvelle technique pour faire des moteurs 3D qui, selon eux, exploserait littéralement tout ce qui a été fait jusqu'ici... aucune idée si c'est crédible ou non :



momotte ?

Ça ne vaut pas le turboencabulator qui, en tant que moteur ultime, fait aussi moteur 3D, si`si`.

Leur technologie (si elle est réelle) n'est qu'un générateur "RT" de polygones a partir d'une vue "haute def" d'une scene, enfin c'est ce que j'en comprends perso.

Non, d'après ce que j'ai lu (parce qu'il ne faut pas trop compter sur le commentaire du gars pour avoir des infos précises) il utilise un nuage de points pour afficher ses scènes
Et pour le moment ça tourne à 20-30fps pour une petite résolution genre 1024*600 en software. pas de support hardware pour le moment.

ça ne me parait pas des masses crédible car on n'a pour le moment aucun détail sur comment animer tout ça, comment éclairer tout ça, comment gérer des objets transparents, quelle empreinte mémoire, etc. Sans parler du sérieux du gars qui transparait de son discours très bullshit

ceci dit, c'est quand même impressionnant

Nuage de point, cad ?

Il parle de représenter l'univers 3D comme des atomes, perso je vois mal comment c'est possible et surtout comment ça pourrait être efficace mais bon.

Peut-être qu'on pourrait imaginer trouver, pour chaque pixel de l'écran, quel atome est le plus visible compte tenu de la caméra (ou quels sont les N atomes les plus visibles et faire une moyenne de la couleur). Ça permettrait de conserver un temps linéaire qu'on soit très près d'un objet (on verrait donc beaucoup d'atomes, voire tous ses atomes) ou très loin (on ne verrait que peu d'atome de chaque objet), mais je vois difficilement comment on peut sélectionner efficacement un nombre borné (et faible) d'atomes à projeter quel que soit le champ de vue parmi tous ceux de la scène, surtout si elle permet un niveau de détail "unlimited".

Mais c'est pas simplement du voxel, ça ?

Peut-être bien, je n'y connais pas grand chose. En tout cas, ça a l'air de ressembler pas mal à ça par exemple (cf. gallerie).

C'que j'allais dire, cherchez "Ken Silverman Engine"...

Kochise

Zerosquare (./14297) :
Mais c'est pas simplement du voxel, ça ?

C'est du voxel

(un truc amusant : http://www.youtube.com/watch?v=eQMBGLMtdFE fait par Chris Delay (le dev principal d'Introversion (le studio derrière Defcon, Darwinia...)))

avec des voxels, la scène est organisée sous forme de grille 3d régulière et est rendue avec des bouts de cubes
dans un nuage de points, il n'y a pas de grille mais des points en vrac et ils sont rendus avec des quads ou juste des pixels
genre ça : http://www.youtube.com/watch?v=Sho5LV7Udhc

j'avais pas l'impression que la techno du gars était à base de voxel mais vu qu'on a zéro détail c'est dur de savoir

Si vous avez des connaissances dans ces différentes technos, vous seriez d'accord pour les expliquer (même brièvement) dans un fork ? ^^

Je peux essayer
(tu peux forker un post vers un autre forum, genre imagerie ? )

(oui ^^)

du coup, un voxel engine et un nuage de points, ça marche grosso modo comment et ça diffère en quoi ? (j'ai du mal à voir comment ça partitionne l'espace pour restreindre à un nombre raisonnable de voxels/points à afficher, compte tenu des quantités astronomiques qu'il semble y avoir au total dans les démos postées plus haut)

c'est pas simplement une matrice 3 dimension par objets, ou il aurais dégagé les pixel intérieurs pour laisser seul ceux des bordures (car sinon niveau place on fait pas ça avant 20 ans) ? quant je vois le gundam du début ca me fait pas de doute ^^

en tout cas ça permettrais des déformation d'objets bien plus réaliste que maintenant (tu met une balle dans le gars, ici tu creuse vraiment le trou et ajoute vraiment la matière du sang)

et pareil pour passer des objets en 3d, un scanner laser et c'est réglé, pas besoin de transformation en facettes et polygones

si on c'est pris la tête à découper par des polygones (c'est vraiment pas naturel les polygones il faut l'avouer) c'est que cette solution doit vraiment bouffer de la place et du cpu, il est peu être temps de revenir à la simplicité car maintenant on la possède cette place et ce temps cpu

Avec des voxels, ta scène est représentée par une grille régulière de cases qui peuvent être ou vides ou d'une certaine couleur. La grille n'a pas besoin d'avoir une densité constante quand il n'y a pas de petits détails à représenter. Dans ce cas on utilise un octree pour limiter le poids en mémoire de la grille.
Pour afficher les voxels soit on affiche chaque case de la grille sous forme d'un cube mais c'est pas optimisé soit on extrait la surface entre ce qui est plein et de qui est vide et on l'affiche.

Avec un nuage de points, la scène est représentée par un tas de points en vrac qui sont d'une certaine couleur, qui peuvent avoir une certaine taille et une certaine orientation (et donc ce sont plus vraiment des points ). Chaque point est affiché en utilisant une un quad ou la primitive point d'OGL/DX. Avec une densité suffisante, et une taille adaptative des points on voit une surface. c'est utile pour afficher des points en vrac et ça n'a pas le rendu cubique (même s'il peut être lissé) du voxel.

Il parle bien de point cloud quand il affiche le gundam (merci r043v) donc je suppose que c'est de ça dont il s'agit
Comment le gars peut faire pour faire tenir ses zillions d''atomes" en mémoire, aucune idée Mais ça a l'air d'être la clé de sa techno

du coup la principale différence c'est que dans le cas du voxel on a une structure pleine (une matrice 3D) contenant éventuellement en chaque case un voxel (je n'ose pas imagine la taille de la matrice), alors que dans l'autre on a des points arbitrairement placés ?

si c'est ça, ok, mais je ne comprends toujours pas comment on peut arriver à gérer une quantité aussi énorme de points en conservant un framerate acceptable ^^ (le mec qui fait le moteur de ./10 dit qu'il a pris les vidéos sur un laptop, et son truc est monstrueusement impressionant...)

[edit] sur certains screenshots (celui-ci par exemple) on voit bien les voxels de son terrain ; pour avoir un rendu avec une résolution acceptable, cad ne plus voir ces voxels, il doit en falloir des millions ?!

Oui, mais des millions des voxels ça ne pèse pas si lourd que ça.
Et pour les zones entièrement pleines tu n'as pas besoin d'avoir des voxels aussi fins que pour la frontière entre le plein et le vide. Il suffit de subdiviser autant qu'on veut cette frontière, comme pour ce cercle en 2D
plutôt que

OK pour la densité non-constante, mais je reste étonné d'avoir des trucs qui tournent avec autant de points affichés par cette technique (d'autant que pour le screenshot on les voit clairement, mais pour la vidéo d'Euclideon ça devient carrément monstrueux ^^).

Merci pour les explications

je vais pas dire des conneries (en fait bien sur que si, vous inquiétez pas :- D)

je conçois bien qu'il doit utiliser les capacités de la carte graphique et donc les voxels et choses similaires que tu cites

après perso je pense en 100% soft (gp32 rulezz) mais une technique style raycasting avec un jolie lancé de rayon en dégageant de grosse branches via des math basiques pour les collisions (pré calcul de la hauteur des objets en utilisant également leur positions) ça permettrais d’accélérer les calculs

pour la place utilisée par les matrices, c'est évident qu'il ne sauve pas l’intérieur des objets, on utilise pas encore des cristaux 3d pour le stockage donc il à du bien se faire chier pour compresser au max les contours de son objets, sans surtout sacrifier la lecture rapide de son stockage vers un x,y,z rempli ou non

après c'est sur que pouvoir afficher en temps réel le tout et surtout l'animer est un gros défis

iwannabeamaki (./21) :
pour la vidéo d'Euclideon ça devient carrément monstrueux

Meme avec 6 octets par pixel (coordonnées, couleur), ses milliards de points sur une scène vont prendre une place démentielle, non ? Et le calcul du rendu un temps de fou ? Qu'existe-t-il qui sache faire ça en hardware à l'heure actuelle ?

Le raytracing en temps réel existe déjà, mais c'est assez récent et pas sur des scènes de cette complexité. Quand tu regarde sa scène, tu as une distance de visibilité énorme et surtout des objets avec plein de trous et de petits détails, donc des calculs d’intersection des rayons assez complexes. Donc des maths basiques ça ne sera pas suffisant

Sinon sa techno n'est pas encore accélérée sur GPU, c'est que du CPU

Folco (./23) :

iwannabeamaki (./21) :
pour la vidéo d'Euclideon ça devient carrément monstrueux

Meme avec 6 octets par pixel (coordonnées, couleur), ses milliards de points sur une scène vont prendre une place démentielle, non ? Et le calcul du rendu un temps de fou ? Qu'existe-t-il qui sache faire ça en hardware à l'heure actuelle ?

Rien, c'est pour ça qu'il dit que sa techno est révolutionnaire et tout et tout

(pareil, j'avoue mon inculture en matière de 3D, mais je vais essayer quand même ^^)

Ben les perfs qu'ils annoncent en rendu software pur seraient déjà très impressionnantes s'ils utilisaient des polys et un niveau de détail équivalents aux jeux actuels. Vu qu'en plus leur niveau de détail est carrément plus élevé, ça me paraît difficilement croyable, honnêtement.

De plus, utiliser des points à la place des triangles n'explique rien en soi : si les triangles sont suffisamment petits, on peut les assimiler à des points, et à nombre de points égal une modélisation polygonale sera plus jolie que la même en voxel (puisque grosso modo, un maillage en triangles, c'est comme un maillage de points avec de l'interpolation linéaire). Et ils ne donnent strictement aucune info technique sur ce qui différencie leur rendering des approches classiques, alors que c'est là qu'est toute la difficulté.

D'ailleurs je regrette que pas grand-chose n'ait été fait pour avoir de l'accélération matérielle d'autres types de surfaces que les polygones (enfin à ma connaissance, en tout cas dans les cartes "grand public"). Quand on regarde le dessin vectoriel 2D, on arrive à faire des trucs très propres avec des courbes qui sont finalement assez peu complexes, alors qu'il faudrait un grand nombre de segments pour arriver au même résultat. Imaginez si on pouvait faire la même chose en 3D...

dans un autre domaine, je reviens de chez le dentiste chez qui j'ai passé un scanner. Il faut transmettre le scan au spécialiste, je l'ai reçu sur CD, tout simplement.

sans trop d'espoir je pensais avoir un fichier raw uniquement lisible par la machine de scanner en question.

Au lieu de ça le CD contenait un autorun avec une visionneuse. La visionneuse est écrite en java, donc niveau perf c'est pas très optimal, eh bien je me retrouve avec une interface à la 3dsmax, avec le scan en 3d voxelisée manipulable en temps réel, résolution: 200 microns sur la machoire complète.
et pas d'histoire de matrice creuse, tous les voxels sont remplis, je pouvais choisir la densité minimale affichée, donc passer sans interruption entre os et muscles. Vraiment très beau truc.

le fichier de données faisait 200 mégas.

bref: en optimisant un peu et en virant les parties cachées, avec un bon truc de sélection des pixels lointains, ça me semble pas inconcevable un truc comme présenté, qui est très beau d'ailleurs, vraiment bluffant!

cross et edit: les polygones finissent tous rasterisés, alors pourquoi on pourrait pas faire une accélération matérielle pour un nuage de points 3d? a mon avis c'est l'étape suivante logique.

la texture pourrait aussi être ajoutée "traditionnellement"

Ok ok. Mais entre la matrice de donnée d'une map entière sur un jeu, et son rendu en tant que frame envoyée à mon moniteur, il y a combien de milliards de milliards de cycles à exécuter ? ^^

squalyl, balance le scan de ta machoire

Sinon pour rasteriser des points, il y a déjà tout ce qu'il faut dans nos cartes 3d. les points peuvent être transformés en triangles par la carte 3d et puis affiché de manière conventionnelle. Ce qui manque, c'est comment manipuler une scène formée de milliards de points, ou plutôt comment réduire le nombre de points à afficher pour pouvoir rendre la même chose avec seulement un million de points.

c/c IRC, ça détaille un peu plus les questions que je posais au début du topic, sachant que ça ne reste que des suppositions naïves et que je suis probablement complètement à côté de la plaque

[23:11] <Zerosquare> bon Zeph, t'as déterré un troll 3D, c'est pas possible
[23:12] <@Zeph> un troll ?
[23:12] <Zerosquare> ben si ça marche vraiment, nVidia et AMD achèteraient ça une fortune
[23:12] <Zerosquare> sinon c'est du beau troll
[23:13] <Zerosquare> (ou alors c'est du vent pour attirer des investisseurs)
[23:14] <@Zeph> nVidia et AMD ça les ferait bien chier surtout oui
[23:15] <@Zeph> ça veut dire qu'il faudrait reprendre toute l'architecture actuelle, adapter les shaders, etc
[23:15] <@Zeph> c'est pas pour rien que le renderer du mec est en software, pour l'instant le hardware semble pas adapté à son truc, et si c'est une vraie révolution il va falloir réviser quelques années de pratique ^^
[23:16] <Zerosquare> c'est même pire que ça
[23:17] <Zerosquare> en fait d'après sa description, il se base sur des polys au départ parce que les softs de 3D génèrent ça, mais sa technique marche pour tout
[23:17] <Zerosquare> donc même si tu reste dans l'optique "poly", il a gagné un facteur 1000 ou plus sur ce qui se fait actuellement
[23:18] <Zerosquare> moi je veux bien, mais soit il a découvert une astuce mathématique absolument monstrueuse, soit y'a de l'embrouille
[23:18] <Zerosquare> parce que pour qu'un simple CPU puisse le faire à 30 fps, imagine ce qui serait possible sur un GPU
[23:19] <@Zeph> [23:17] <Zerosquare> en fait d'après sa description, il se base sur des polys au départ parce que les softs de 3D génèrent ça, mais sa technique marche pour tout
[23:19] <@Zeph> si j'ai bien compris, il a juste converti des meshes en polygones vers des meshes en "atomes"
[23:19] <Zerosquare> ouais
[23:19] <@Zeph> pas en temps réel quoi, c'est juste un pré-requis pour ses scènes
[23:20] <Zerosquare> mais ces atomes, si tu y réfléchis, ce ne sont que les sommets des triangles
[23:20] <@Zeph> je pense pas
[23:20] <Zerosquare> donc ça revient à faire un truc en polys en regardant de loin
[23:21] <Zerosquare> ben étant donné que tu ne modélises pas l'intérieur (ça n'aurait aucun intérêt, sauf pour des décors destructibles), je ne vois pas où est la différence
[23:21] <@Zeph> a priori y'a presque toujours > 3 atomes par triangle (il n'y a que les très très petits triangles qui peuvent être simplifiés en 1 à 3 atomes)
[23:21] <@Zeph> faut bien rendre toute la surface
[23:21] <Zerosquare> oui, mais tu pourrais avoir le même rendu en triangles pur, si tu augmentais le nombre de triangles
[23:22] <Zerosquare> finalement, les triangles, c'est une interpolation des atomes
[23:22] <Zerosquare> un triangle 3D c'est une interpolation linéaire entre 3 points
[23:22] <@Zeph> oui ?
[23:22] <Zerosquare> donc il a résolu un problème encore plus dur que les polys
[23:23] <Zerosquare> déjà sur des polys une amélioration aussi importante c'est monstrueux
[23:23] <Zerosquare> mais là c'est encore plus fou
[23:23] <@Zeph> sauf que les techniques derrière n'ont a priori plus rien à voir
[23:23] <Zerosquare> ouais... mais justement, ça m'étonnerait beaucoup.
[23:23] <@Zeph> on utilise des polygones parceque c'est la seule façon qu'on sache utiliser, mais c'est plus une contrainte qu'autre chose
[23:23] <Zerosquare> non
[23:23] <Zerosquare> au contraire !
[23:24] <Zerosquare> y'a plein de techniques de 3D qui utilisent autre chose que les polys
[23:24] <@Zeph> de 3D temps réel ?
[23:24] <Zerosquare> seulement, les polys, on sait les accélérer
[23:24] <Zerosquare> le reste c'est plus chiant
[23:24] <@Zeph> oui voilà
[23:24] <Zerosquare> donc tout le monde est parti à la course à la puissance sur les polys
[23:25] <Zerosquare> disons que s'il avait fait par exemple un truc qui accélère les courbes, là j'y aurais davantage cru
[23:25] <Zerosquare> parce qu'une seule courbe peut remplacer énormément de polys d'un coup, donc si tu accélères ça, tu gagnes immédiatement
[23:25] <Zerosquare> mais là c'est l'inverse, il résoud un cas plus général
[23:25] <Zerosquare> donc c'est d'autant plus impressionnant
[23:26] <Zerosquare> or dans sa vidéo il insiste énormément sur les atomes, alors que c'est pas là qu'est la révolution
[23:26] <Zerosquare> enfin, je me trompe peut-être. mais dans ce cas, ce type va être milliardaire
[23:27] <@Zeph> bah la révolution c'est qu'il a trouvé une façon de les afficher qui ne devait pas être possible il y a quelques années (avant que tout le monde se focalise sur les polygones), ou bien à laquelle personne n'a pensé
[23:27] <@Zeph> ça parait peu probable, mais y'a pas tellement d'explications pour l'instant
[23:27] <Zerosquare> c'est théoriquement possible
[23:27] <Zerosquare> mais (à ma connaissance) y'a jamais eu de révolution fondamentale en 3D
[23:28] <Zerosquare> juste des raffinements progressifs, surtout parce qu'avant le hardware ne suivait pas
[23:28] <Zerosquare> quand tu regardes les grands principes, c'est en fait assez vieux
[23:28] <@Zeph> pour moi y'a deux problèmes à résoudre :
[23:28] <@Zeph> - optimiser l'affichage des primitives (poly, atome, autre)
[23:29] <@Zeph> - optimiser les moteurs de rendu pour minimiser le nombre d'éléments à rendre
[23:29] <@Zeph> c'est sur le 2eme point qu'on gagne énormément, et c'est sur le 2eme point que toutes les optimisations conséquentes sont trouvées
[23:29] <@Zeph> donc il utilise des atomes, c'est plus complexe à afficher, ok
[23:29] <@Zeph> ptet qu'il a suffisement contrebalancé l'autre point pour se le permettre
[23:30] <Zerosquare> c'est à mon avis infaisable sans une évolution mathématique majeure
[23:31] <Zerosquare> or les principes de la 3D de base sont assez simples, finalement
[23:31] <@Zeph> sauf que comme je le postais dans le topic, même si c'est théoriquement possible de sélectionner un nombre très (vraiment très) limité d'atomes à afficher étant donné la caméra et la résolution de l'écran, je vois difficilement comment on fait en un temps raisonnable
[23:31] <Zerosquare> surtout que ça existe déjà pour les polys ce genre d'optims.
[23:31] <@Zeph> poly ou pas on s'en fout un peu
[23:31] <Zerosquare> (plusieurs modèles avec un niveau de détail décroissant, et sélection avec la distance)
[23:32] <@Zeph> y'a ptet juste des optims qui sont plus intéressantes avec des atomes qu'avec des polys
[23:32] <Zerosquare> ben...
[23:32] <@Zeph> (parceque les atomes permettent cet espèce de lod automatique qu'il montre dans la vidéo, alors qu'avec des poly c'est hyper chiant à faire)
[23:32] <Zerosquare> c'est ça que je ne pige pas.
[23:33] <@Zeph> le coup de "plusieurs modèles", c'est un hack
[23:33] <Zerosquare> parce que pour que ce soit vrai, il faudrait que les atomes soient grands par rapport à la taille d'un poly
[23:33] <Zerosquare> là tu ne vois aucun crénelage, donc ces atomes sont tous petits
[23:33] <@Zeph> tu précalcules des modèles dégradés à partir du modèle initial, pour gagner quelques polys quand l'objet est loin
[23:34] <Zerosquare> ce qui veut aussi dire que tu pourrais les remplacer par des polys, des sphères ou n'importe quoi
[23:34] <@Zeph> avec des atomes il n'a pas besoin de faire ça, si seulement une fraction des atomes sont choisis pour être rendus quand l'objet est loin, ça te fait automatiquement ta dégradation
[23:34] <Zerosquare> donc s'il y a une astuce, elle marcherait aussi pour les polys
[23:34] <@Zeph> tu peux pas supprimer arbitrairement des polys
[23:34] <@Zeph> alors que des atomes, si
[23:34] <Zerosquare> oui et non
[23:34] <Zerosquare> ça te fait des trous quand même
[23:35] <@Zeph> bah pas si chaque atome est rendu avec un quad suffisement gros pour recouvrir ses voisins
[23:35] <@Zeph> tu supprimes les atomes en t'assurant de conserver une densité apparente suffisante
[23:35] <Zerosquare> mais tu imagines le nombre de quad qu'il faut pour avoir une résolution pareille ?
[23:35] <@Zeph> d'où mes remarques dans le topic
[23:35] <Zerosquare> le simple fait de modéliser avec des atomes c'est qu'un tout petit bout du problème
[23:35] <Zerosquare> faut bien les dessiner après
[23:36] <@Zeph> ben oui ^^
[23:36] <Zerosquare> en tout cas je suis curieux de savoir ce que momotte va en penser
[23:36] <@Zeph> aze semble dire qu'afficher des millions de voxels ça ne pose pas de pb [23:36] <@Zeph> et avec des millions de quad, on peut quand même afficher pas mal de détails

oui mais pour des détails, des quads ça sert a rien en fait, vu qu'ils seront rastérisés en 2-3 pixels max