Projet début d'un moteur Raytracing/Raycasting de Voxel.

Bonjour à tous,
je suis Lionel et je souhaite réaliser un moteur de rendue voxel en utilisant la technique du Raytracing ou Raycasting, je me suis suis beaucoup documenter sur les techniques de raytraing basique, mais presque rien concernant le raytracing de voxel. Je n'est pas encore fait de démo ou quoi que ce soit, j'ai déjà commencer mon projet sur papier sur le fonctionnement et l'algorithme de rendue du moteur (pour vous dire que se n'est pas encore avancer). J'ai besoin de recruter une ou plusieurs personnes, qui s'intéresse à c'est technique de rendue, vous pouvez être debutant dans le sujet puisque pour moi c'est une première, mais quand même avoir quelque connaissance dont je citerait en détaille ci dessous. Pour moi c'est avant tout un projet recherche puisque de les documentions ou les moteurs concernant le raytracing/raycasting de voxel il y en a pas des masses qui sont bien détailler ou déjà finit. Mon but c'est d'abord de pouvoir intégrer l'algorithme de rendue pour le jeux vidéo , puis dans le future l'améliorer pour pouvoir l'intégrer dans des projets de rendue, simulation.

Voilà on passe aux détaille*:
-Pour commencer je ou on commencera simple pour élaboré le moteur par la suite.
-J'utilise SFML comme pour la fenêtre et j'utilise le C++ ( Avoir des connaissances sur C++ ).
-Avoir des quelque connaissance sur les méthode de rendue 3d classique avec opengl, si vous savez ce que signifie ses méthode de rendue mais que vous n'êtes jamais lancé dans ce n'est pas un gros problème mais savoir aux moins à quoi consiste le raytracing.
-Depuis le début du post je met raytracing/raycasting parce qu'on commencera par du raycasting qui est plus simple à appréhender que le Raytracing.
-C'est pas un projet professionnelle , c'est juste pour s'amuser.
-Le projet sera opensource et je ou on essayera de faire une documentation/tutorielle détailler sur notre projet.
-Votre avis contera beaucoup c'est une collaboration avant tout :) .
Pour plus de détaille sur comment fonctionnera concrètement le moteur pour l'instant contacter moi en MP ou par skype ( Thelionel626 ).

Pour en revenir au recrutement je cherche une personne qui code en C++ et d'un graphiste pour les démos et les teste du moteur aussi d'une personne qui sache créer des sites web pour la doc, mais en priorité un développeur.

Pour me présenter un peux plus j'ai 18 ans, j'ai des connaissance sur le C++ et Opengl, je sait programmer en Java, Python et HTLM5/CSS3 javascript, j'ai plus utilisé le java et le C++, comme je l'ai déjà dit j'utilise essentiellement la librairie SFML. Je suis passionnée dans le dommaine du jeux vidéo, j'aime bien les jeux avec un style "old-school".
J'ai déjà réaliser quelque projets seul mais c'était que des ébauches et contribué à des projets en équipe.


Voilà si vous voulez participez à ce projet il faut être un minimum passionné sur le sujet, avoir envie apprendre et si vous vous y connaissait déjà dans le sujet vous serez une aide tout autant cruciale.
J'aimerais avoir votre avis sur le projet, pas sur sa faisabilité, je sait c'est faisable le plus gros sera optimisation. Et au passage désolé pour certaine faute que j'ai du loupé :) .

Merci d'avance de vos réponses.

Salut :).

Alors, beaucoup de chose à dire, je vais commencer par un blog qui m'a permis de codé mon premier raytracer, il est vraiment très bien fait et permet d'appréhender les principe de bases sur des formes géométrique simple (sphère, plan, cone ...). De voir tout les petits soucis d'optimisation, les effets de rendu, et surtout: le fait que le raytracing n'est pas adapté au jeu vidéo.

Il faut bien comprendre une chose, le raytracing est hyper consommateur de CPU, les GPU ne sont pas fait pour faire tourner de tel algorithme en général.
Le seul jeu que je connaisse qui fonctionne sur ce principe est X3 terran conflict (qui nécessite déjà une bête de course pour le faire tourner).

Donc d'un premier abord, je dirais que c'est irréalisable.
Ensuite concernant l'intérêt du rendu par voxel, pourquoi utiliser des voxels alors que le but du raytracing est justement de coller le plus possible à la réalité? Si la pluparts des moteurs se base sur des formes géométriques complexes, c'est justement parceque le monde qui nous entoure est composé de forme géométriques complexes.

Donc utilisé des voxel viendrait "pixéliser" le rendu et prendrait plus de temps à calculé que les rendu par voxel étant déjà existant.
Ensuite on peut très bien utilisé un système de voxel tree pour accélérer le rendu mais bon, ça restera pas top.

Je ne comprends pas trop pourquoi tu cite openGL, car justement, celui-ci ne sera d'aucune utilité pour le raytracing, l'utilisation de la SFML est quand à lui bien pensé.

Je conclurais donc par ceci: Es-tu sur que l'ambition de vouloir tourner ton projet pour le jeu vidéo est réalisable (et utile)?
Si c'est pour te lancer un défi (ce qui est très bien) essaye plutôt de faire un raytracer qui donnera un rendu le plus réaliste possible (bon nombre de développeur ont effectué ce type de projet car il est très formateur).
Ce type de projet est excellent pour aborder des notions tel que:
_ Le calcul parallélisé
_ Les formule mathématique d'intersection
_ L'optimisation processeur
_ Les formule mathématiques définissant un phénomène physique (refraction/diffraction/transparence).
_ Des concept d'imagerie (bump mapping, shadow map ...).

Voili voilou, si tu as des questions sur la manière de réaliser un tel projet, je serais ravi de t'aider sur mon temps libre :).

Merci pour ta réponse rapide, j'ai déjà fait un tour sur ce blog il y a quelque temps.
Pour le moteur d'abord j’intégrerai tout l'algorithme en un seul rendue c'est à dire pas en temps réelle, en pur C++ puis je passerait sois à opengl en utilisant les shaders ou opencl, je n'ai pas encore fais mon choix. J'ai décider de choisir le voxel pour stocker les données parce que c'est très "Maniable" comme donné, qu'on peut aussi en afficher une énorme quantités et j'aime bien le rendue sa donne, il y a aussi le coté volumétrique, mais on pourra utilisé la géométrie dans mon moteur pour l'instant c'est que théorique, mais pour la géométrie je calcule la collision de la géomètrie avec une AABB cette collision sera le voxel en gros ( je sait pas si je me suis bien fait comprendre ). Pour les projets simillaires qui se rapproche le plus de mon projet il y a voxelnauts( https://www.youtube.com/watch?v=NMvD...?v=NMvDvPH0nTA) ou voxelquest ( http://www.voxelquest.com/ ) et avec moin l'aspect bloc il y a Atomontage engine, mais il utilise la plupart du temps la SVO (Sparse Voxel Octree) pour les données moi je ne compte peut être pas utilisé sa et pour commencer je ferait du raycasting. Mais je testerais de faire un raytracer, j'avais déjà hésité sur le faite de commencer sur un raytracer puis aller vers le voxel raytracing. Mais les deux technique sont intéressent mais je me suis orienter vers le voxel juste par préférence.
Et pour si c'est utile dans le jeux vidéo, je pense que avec l'évolution de la puissance de calcul et des API comme réçament vulkan, se genre de chose en temps réelle dans le jeux vidéo sera possible mais après c'est une question goût et de besoin.
Merci quand même de ta réponse.

On peut justement afficher un grand nombre de voxel car les moteurs 3D actuels ne se base pas sur du raycasting :).
Il faut bien comprendre que pour chaque rayon, il faudra tester l'intersection entre ce rayon et chaque voxel, donc plus tu en rajoute plus ça sera lourd. Ensuite des optimisations existe comme le quad-tree qui permet de ne pas effectuer de calcul pour les voxel dont on sait qu'il ne seront pas dans la région recherchée. De la à rendre le calcul temps réel, c'est un peu compliqué.

Les jeux utilisant le raycasting se présente souvent dans l'espace car il y a moins de rendu à faire (pas d'environnement, des objets géométriquement simple composé de sphère principalement ....). Ensuite je ne comprends pas trop l'intérêt d'utiliser openGL si c'est pour faire du raycasting, pourrais-tu éclairer ce point?

Concernant OpenCL, pareil, je ne vois pas trop l'intérêt, cette lib étant faite pour la manipulation d'image complexe et non pour du rendu de moteur.

Je ne comprend pas non plus l'intérêt de faire un jeu "cubique" en raycasting, le rendu étant très éloigné de la réalité, on perd tout l'intérêt du raycasting non?

Les moteurs actuels utilisent un système de projection (ce qui est l'inverse du raycasting, on vient projeter notre volume sur un plan 2D et non balancer un rayon sur un volume), c'est pourquoi ils sont performant, mais nécessite d'avoir des formes géométriques simple (afin d'optimiser les projection car les transformation de repère sont simple sur des formes comme des triangles ou des carrés).

Donc le raycasting ne sera pas efficace à partir de voxels, car le nombre de calculs sera très important et la qualité de rendu sera la même qu'une projection.

Par analogie, on pourrait dire que le rendu par projection via des formes simple correspond à un signal étalonné (possédant des valeurs déjà connu et niveller, donc niveau de détail faible) et le rendu par raycasting correspond à un signal analogique (possédant une plage de valeur infini pour un niveau de détail infini). Le niveau de détail est toujours définis par ta source (les formes primitive ou forme géomtriques complexes) donc si tu utilise des voxel, tu viendra "voxéliser" ta source et aura donc un rendu moins précis que si tu prends la source à l'état pur (donc avec une résolution spaciale infiniment petite).

J'espère avoir été clair dans mes propos ^^. Tout ceci pour t'expliqué pourquoi un moteur de rendu en raycasting par voxel n'éxiste pas :).

Je pense qu'il n'y a aucun problème à faire ce genre de projet pour s'amuser, sans compter que l'on apprend des choses en le faisant.

C'est marrant Skeud, parce que le tutorial en lien plus haut je l'avais aussi écrit pour m'amuser (oui je sais j'ai des drôles de hobbies) sans que ça ne débouche sur quoi que ce soit un niveau professionnel. J'avais aussi écrit un moteur de rendu de terrain en (pseudo) voxels type Outcast/Commanche : http://www.massal.net/article/voxel/ pour m'occuper quand j'étais étudiant.

Après pour les avantages du raycasting par rapport à d'autres méthodes. Dans le cas du moteur ci-dessus, je crois que l'avantage était à la rasterisation (tout comme elle l'était pour Doom, c'est une erreur que l'on voit souvent de dire que Doom était en Raycasting). Tout dépend des structures de données à traverser pour de vrais voxels 3D, où ça peut être un peu plus compliqué et le raycasting est sans doute plus envisageable.

Le tracé à partir de voxels (ou représentation 3D d'une scène) est utilisée aujourd'hui pour l'illumination globale (voxel cone tracing global illumination) http://www.icare3d.org/research/publ...sponzanew1.png mais c'est un exemple particulier où de nombreuses optimisations sont possibles.

Après pour la représentation explicite tu as les modèles stockés dans des sparse voxel octrees : https://i.ytimg.com/vi/VpEpAFGplnI/hqdefault.jpg cette représentation est un peu dans un cul de sac technique à l'heure actuelle mais les idées peuvent être réutilisées ailleurs. On notera que Minecraft s'il a une représentation à base de voxels, ces voxels sont rasterisés sous forme de triangles à l'affichage (donc pas de raycasting/raytracing).

Un peu plus éloigné (toujours explicite mais pas techniquement des voxels) tu as les représentations à base de nuages de points à la Euclideon : http://techreport.com/r.x/2014_9_24_...ames/altar.jpg

Citation:

---

Envoyé par skeud

On peut justement afficher un grand nombre de voxel car les moteurs 3D actuels ne se base pas sur du raycasting :).
Il faut bien comprendre que pour chaque rayon, il faudra tester l'intersection entre ce rayon et chaque voxel, donc plus tu en rajoute plus ça sera lourd. Ensuite des optimisations existe comme le quad-tree qui permet de ne pas effectuer de calcul pour les voxel dont on sait qu'il ne seront pas dans la région recherchée. De la à rendre le calcul temps réel, c'est un peu compliqué.

Les jeux utilisant le raycasting se présente souvent dans l'espace car il y a moins de rendu à faire (pas d'environnement, des objets géométriquement simple composé de sphère principalement ....). Ensuite je ne comprends pas trop l'intérêt d'utiliser openGL si c'est pour faire du raycasting, pourrais-tu éclairer ce point?

---

Le raytracing me semble être ce qui à le plus de potentiel pour l'avenir, juste à regarder Euclideon et leur quantité gigantesque de data qui tourne en real time sur CPU. Et encore mieux voxelquest qui reprend ce principe à la Minecraft, mais utilisant le GPU. La méthode semble être performante, pas si complexe d'implémentation avec un résultat superbe, même avec de grande quantité de données.

Le principe étant une détection de collision par rayon provenant de chaque pixel de l'écran donc du pixel final avec un parcours inverse.
Pour Voxelquest la méthode est très intéressante :

Citation:

---

At a high level it is based on ray tracing, specifically a method known as Signed Distance Field ray marching (SDF ray marching). But that is only part of what is going on.

Vanilla ray marching simply steps along a ray at fixed intervals until it hits something. This is costly with a small step size, and erroneous with a large step size. SDF ray marching computes the distance from the nearest objects, and moves along the ray no more than the smallest distance from any of these objects.

---

Pièce jointe 204021

Citation:

---

This is very fast when the ray actually hits the object, but considerably slower if the ray "just misses" the object as shown above. The interesting thing about SDF marching is that it works hand in hand with boolean geometry or solid modeling. Inigo Quilez has a great primer on distance functions and operations located here. You can also find many great live examples of SDF ray marching at shadertoy.com.

The problem with naive SDF is that every ray at every pixel is considering every object in the scene to be rendered. This becomes insanely expensive if you have many objects in the scene. For example, imagine I have 1920x1080 pixels to render, which amounts to about 2 million rays to cast. Each ray is calculating the distance from 1000 objects, 60 times per second. Lets imagine each ray travels 100 steps on average, and requires 100 instructions to make its calculations. You are looking at 1.2 quadrillion instructions per second, if I did my math right.

The trick I use is aggressively reducing the number of objects each ray considers, using very straightforward, naive cell hashing.

---

Pièce jointe 204022

Citation:

---

Here we have a ray (purple) intersecting 3 objects. The ray gradually marches through each cell, from position B3 to N13. If the cell is empty, it does nothing. If any objects are within the cell, it adds them to the list of objects which it should compute. It does not store duplicate object references. Using math, it determines exactly whether or not it hit a given object - but this is not a final result. If an object has a bumpy surface, or has holes in its surface, its possible a ray can hit the object but miss it when it renders the surface in detail. All of these objects are gathered up and then a traditional SDF pass is used to determine the details and exact hits. For some further clarity, cells can contain multiple references. Cell H8 contains references to both the green rectangle and red circle, but cell M11 only contains 1 reference (the orange pentagon). The way in which you implement the cell data is up to you, but I use OpenGL's samplerBuffer (which is like a texture but functions more like an array).

In order to step through cells efficiently, I recommend using a supercover line algorithm, such that each cell is only considered once as the ray travels through it (image credit: http://lifc.univ-fcomte.fr/home/~ede...cts/bresenham/).

---

Pièce jointe 204023

Citation:

---

You will want to toy with cell sizes to hit the sweet spot: big enough so that one cell usually fits an entire object, but small enough such that there are not too many objects within a given cell.

Because VQ uses only one type of uber geometry (rounded boxes with super-ellipsoid-like corners), it can compute exact hits for every single type of primitive only using one set of instructions (from cones to cylinders to spheres to rounded boxes to you name it), eliminating the need for branching in that area. So it narrows it down to geometry that the ray hits exactly.

But it goes further than that. How many objects is a ray likely to miss? As it turns out, you can usually get away with only considering the first 4 to 8 objects and you will rarely get errors. In the illustration above I have just shown 3 objects, but imagine if that box is filled with hundreds of objects. Now, for each ray, I only need to consider the first couple of objects that get hit instead of hundreds of objects for every ray. As I have shown in the past, you can render millions of objects using this method and there is not really any slow down - it tends to run at a pretty constant speed. You can optionally improve performance further through use of the flyweight pattern or templates. If I am using an object that will be repeated many times (for example, a hallway) - I need only store the specifications for this object once, and then instance of it is just a reference with a bit of data like position and orientation.

---

Pièce jointe 204024

Citation:

---

Not every object is traditional geometry though. The terrain is composed of smooth chunks of earth, which is produced by sampling a volume texture with bilinear filtering. As it turns out, vanilla SDF won't work that great trying to compute distances based on textures. The trick I have found is to allow the SDF algorithm to overstep into a solid area, and then step backwards along the ray (correcting itself), back and forth a few times until it gets close to the surface. There are probably better ways of analytically computing distance from a bilinear filtered point, but this works for now.

---

Ceci serait un bon point de départ ;)

Merci pour vos réponses et de vos conseille, sa m'aidera peut être :) . Et quand je cite OpenGl par rapport à ses technique de rendue, je veut dire par là l'implémenter au GPU grâce aux shaders ( même si c'est pas fait pour sa, sa accélère beaucoup les calculs ). Et aussi mon but n'est pas forcément de créer un rendue cubique ou de faire l'hyper réalisme, c'est de s'adapter aux rendue voulue par l'utilisateur, j'aurais pu le faire en utilisant les techniques de rendus classiques mais le Raytracing offre beaucoup possibilités, juste les performances qui est un inconvénient quand on veut faire du temps réelle. Aussi, est-ce que le PBR ( Physically Based Rendering ) s’implémente facilement au raytracing ? Et aussi le Recrutement tient toujours :) .

Citation:

---

Envoyé par lionel626

Aussi, est-ce que le PBR ( Physically Based Rendering ) s’implémente facilement au raytracing ? .

---

J’aurais tendance à dire que tout est plus facile à implémenter en Raytracing. La gestion des ombres, la lumière, on peut implémenter le tout à la perfection, avec le même algorithme, c'est à dire le parcours du rayon qui va rebondir et ainsi détecter sur quoi il est réfléchie. Les méthodes standard sont plus ou moins des approximations, qui demandes des sous-rendu, comme pour faire des ombres, ce qui devient vite très complexe et lourd.

La base du Raytracing est peut-être plus difficile à réaliser, surtout pour avoir de bonne performances, mais si ça marche les possibilité sont infinies.
Le PBR c'est l'information du matériau qui va déterminer comment le rayon est réfléchie, encore une fois je crois que c'est plus simple, il suffit de calculer un angle.

Je me demande comment l'auteur de Voxelquest procède pour son tableau? D'après moi, il utilise un énorme tableau de texture 2D, donc un tableau 3D d'une résolution X (le sweet spot) pour ses objets pour ainsi calculer les collisions des rayons.

Bonjour,

Pour l'histoire des SDF (Signed Distance Function), nous avons deux articles dessus sur Developpez.com :

• http://jeux.developpez.com/tutoriels...istancefields/
• http://geeks3d.developpez.com/GLSL/raymarching/

(Enfin, toutes les ressources raytracing de Developpez.com sont là.)

Maintenant, les SDF, pour les jeux, bah, c'est pas vraiment ça. En effet, c'est cool, ça produit des images temps réels, mais elles sont très mathématiques (générées à partir de fonction). La demoscene adore cette technique, mais à part pour les démos, je ne crois pas qu'il y ai de vrais applications.

Merci LittleWhite, ça ma donné le goût de me lancer dans le Raytracing/Raymarching. Ces articles mon bien aidé.

Voici donc un petit Raymarching que j'ai fais sous Windows et WebGL :

Raymarching DataBlock

Pièce jointe 206848

Sympa :)
Après, on peut faire des effets originaux avec l'opérateur mod(). On peut récupérer un index pour repérer sur quel bloc on se situe et donc, modifier le bloc selon (ça casse la répétitivité). :)