Salut !
Il y a quelques jours j'ai eu une petite idée : créer mon propre moteur de 3D en C-Basic.
Après... c'est parti en cacahuètes.
RUB3R est l'acronyme de Really Ugly and Bad 3D Render (ou "rendu 3d vraiment moche et mauvais" pour ceux qui ont pas fait anglais LV2), simplement car il a été réalisé sans aucune théorie de la trois dimension.
En gros, j'ai dessiné un truc qui ressemblait à de la 3D en F-Line et j'ai bidouillé quelque chose à partir de cela.
Il s’exécute sous C-Basic.
RUB3R est divisé en (beaucoup) de sous-programmes, qui commencent tous par un "R" pour s'y retrouver :
-RTEXTURE, le moteur de rendu de textures qui prend en argument la matrice A (les 3 ou 4 points de la figure à texturer dans un ordre précis) et la liste 1 (qui contient 3 éléments, les niveaux respectifs de rouge, vert et bleus qui composent le code RGB de la couleur de la texture). Il dessine la texture, c'est son seul job.
-RUB3R, le programme principal, qui affiche le modèle du programme mis entre guillemet au milieu de ce programme principal ("Prog "VOTREPROGRAMME") et qui gère les entrées clavier. Par défaut ce programme c'est "RMODEL"
-RMODEL, un exemple de modèle. Les points sont définis par rapport à des repères.
-RRECT, le programme "repère" qui vous permettra de comprendre la logique des positions des points et de faire moult tests.
Voilà, en gros pour créer un modèle on l'écrit dans RMODEL et on peut appeler RTEXTURE après avoir défini la matrice A et la liste 1 pour dessiner les textures.
Le programme de textures marche avec tous les quadrilatères (enfin je crois, faites moi remonter des bugs si il y en a) mais les triangles n'ont été testés qu'avec des triangles rectangles donc je ne suis pas sûr du résultat.
Je pense faire un tuto là dessus dans pas longtemps, pour expliquer comment ça marche en détails.
D'ici là, voici quelques images ! Ne vous fiez pas au compteur de FPS, j'ai fait n'importe quoi.
J'ai aussi fait une vidéo en vrai, l'émulateur sous VM c'est bizarre parfois...
Merci beaucoup ! Il reste encore quelques bugs (quand je descend en dessous du modèle à 0:04 de la vidéo sous émulateur, la texture violette passe au dessus de la rouge) mais globalement je suis assez content du résultat. C'est cool de voir que tu apprécie !
pour ton problème de texture, logiquement ceci est géré par 2/3 approches dans un moteur 3D classique :
- la normale à la face à afficher est calculée et ensuite on regarde si le produit scalaire entre le vecteur de caméra et cette normale est positif ou pas, si positif c'est que la face est orientée de manière visible (et sera donc à afficher), sinon est est vue par l'arrière et est donc invisible (et donc pas à afficher). Cette opération s'appelle le "Back-Face Culling".
Note: ceci impose d'avoir un vecteur normal, de bien l'orienter à la définition initiale de la facette, puis de lui appliquer les mêmes transformations que la face pour savoir son évolution au cours des transformations (rotations, translations).
- ensuite il faut faire un rendu de l’arrière vers l'avant, c'est à dire commencer par les faces les plus éloignées et finir par les faces les plus proches, ce qui impose un tri sur un critère (coordonnée Z ???). En théorie c'est censé fonctionner, sauf que dans les faits si on a des faces de tailles très différentes, on obtient le même genre d'overlapping non maîtrisé de faces. Il vaut donc mieux utiliser la méthode suivante qui est par contre hyper lourde en calculs : le Z-Buffering.
- Le Z-Buffering consiste à tracer dans une zone tampon toutes les faces visibles (pas forcément triées je précise) en gardant une trace de la coordonnées Z (profondeur) du pixel correspondant. Ensuite avant de tracer un nouveau pixel sur une autre face, on vérifie dans le Z-buffer si le pixel est devant ou derrière celui déjà tracé. Si il est derrière, on fait rien, si il est devant, on le trace et on fait un update de la coordonnée Z correspondant dans le Z-Buffer. Comme tu peux le voir, c'est très lourd en calculs. Logiquement, dans le matériel info moderne, c'est géré en hardware mais là pas de salut, faut tout se palucher en soft à la main
Ce que tu rencontres comme souci est malheureusement très classique dans les moteurs 3D. Il y a pas mal de solutions éprouvées, mais elles sont pas toutes sympas niveau calculs et algorithmes de résolution.
Edit : Ne connaissant pas le C-Basic, je sais pas ce qu'il est possible de faire ou pas. A mon avis le Back-Face Culling est jouable, pour le tri aussi (avec ce qu'on peut en espèrer), mais pour le reste je sais pas.
Bon courage
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Pas mal ! Puisque RTEXTURE supporte les triangles tu pourrais faire une projection perspective pour un effet de profondeur un peu plus prenant.
Slyvtt en a dit pas mal, mais je sais pas à quel point tu es assez proche de la méthode "classique" pour pouvoir appliquer tout ça. Est-ce que tu peux donner un aperçu de la méthode de calcul de points/rendu de textures ?
Salut Sylvtt !
Merci beaucoup pour tes conseils je vais me pencher là dessus !
Lephenixnoir a écrit : Slyvtt en a dit pas mal, mais je sais pas à quel point tu es assez proche de la méthode "classique" pour pouvoir appliquer tout ça. Est-ce que tu peux donner un aperçu de la méthode de calcul de points/rendu de textures ?
En gros, pour les textures des quadrilatères, RTEXTURE regarde le minimum en position X, le maximum, et pour chacunes des positions entre les deux il dessine une ligne sur cette position allant de la hauteur max à la hauteur min.
Ça marche que si les cotes sont parallèles deux à deux du coup, oui c’est immonde.
Pour les points… tu vas être déçu.
En fait au tout début de mon projet j’ai fait un pavé droit en FLine, je l’ai redessiné en l’inclinant et j’ai regardé ce qui changeait.
En fait :
Un point fixe ne dépend d’aucune variable.
Un point mobile se calcule de la manière suivante :
posx-B,posy+A , et on inverse les signes quand on passe de l’autre côté du centre de rotation.
C’est très dégueulasse, d’autant plus que quand on tourne la figure s’étire, donc pas de 360 degrés possible.
Donc oui c’est extrêmement brouillon
Ajouté le 02/03/2022 à 21:00 :
Lephenixnoir a écrit : Pas mal ! Puisque RTEXTURE supporte les triangles tu pourrais faire une projection perspective pour un effet de profondeur un peu plus prenant.
Qu’est ce que tu entends par « projection perspective » ?
Ok, je vois c'est un système très simple pour le déplacement. En général en 3D ce qu'on fait c'est que se donne trois coordonnées par point (... naturellement), ensuite on les transforme par des translations/rotations pour positionner la caméra, et enfin on les projette en 2D pour s'avoir où les mettre à l'écran.
Il y a différents types de projection. Ce que tu as fait correspond en gros à la perspective cavalière (ie. un offset constant en X/Y par unité de profondeur). La projection perspective consiste en gros à diviser chaque position X/Y par la profondeur, ce qui est le plus naturel.
Lephenixnoir a écrit : Ok, je vois c'est un système très simple pour le déplacement.
Oui, vraiment. Son nom est en partie dû à cela
Ah, merci pour l’explication. Je vais regarder sur Internet des détails sur la projection perspective mais c’est vrai que j’avais moi même du mal à comprendre mon propre système de coordonnées des points. Merci !
Juste une idée qui est pas toujours expliquée et qui m'a aidé à comprendre quand je suis passé par là : la perspective est facile à faire quand la caméra est à la position (0,0,0) du monde et quand elle regarde sur l'un des axes. Du coup quand elle est ailleurs on transforme le monde entier autour de la caméra pour faire comme si elle l'était (translation + deux ou trois rotations).
Il y a en particulier des chapitres sur :
- 3D Computer Graphics
- Hidden Surfaces (ce dont on parlait avec le Back Face / Z-Buffering ...)
- Projections (notamment les projections parallèles et en perspective)
Contrairement à ce que le nom du site peut faire penser, c'est indépendant du Java et donne les concepts de base pour comprendre ce qu'il faut faire.
@+
Sly
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Hello !
Merci beaucoup !
Je t’avoue avoir fait des tests qui n’ont rien donné, donc cette source me donne de l’espoir !
@RDP Ajouté le 11/03/2022 à 18:00 :
Salut !
Après des jours de travail, je suis heureux de vous annoncer la sortie de ~RUB3R V1.0~ !
Beaucoup de changements, voire une refonte quasi complète, installez vous !
Bon, évidemment le changement principal c'est la clarification du système de points.
Dans cette nouvelle version, rien de plus simple que de faire une ligne : on utilise cette syntaxe dans RMODEL :
//eventuellement : {R,G,B}→List 1
[[xpointdedépart,ypointdedépart,zpointdedépart][xpointd'arrivée,ypointd'arrivée,zpointd'arrivée]→Mat A
Prog "RLINE"
Et voilà, votre ligne est dessinée.
Donc au delà du changement de syntaxe, on peut maintenant réellement faire de la 3D, en utilisant les repères X, Y et Z.
Pour vous donner une idée, voici un fichier RMODEL utilisant l'ancienne syntaxe :
...et la nouvelle :
Yay, je suis assez fier je l'avoue.
Important : la caméra au départ est à X=4,Y=4 et Z=30.
Je vais rendre le programme RTEXTURE compatible avec cette version prochainement, j'ai essayé un autre algorithme qui réglerai les problèmes de l'actuel mais c'est trop lent...
Et évidemment, voici un petit rendu dont je ne suis pas peu fier : un bonhomme de neige, une maison et un petit panneau !
Re !
Alors... quelques bonnes/mauvaises nouvelles en même temps xD
Avec l'aide précieuse de Lephenixnoir (merci 1000x <3) j'ai implémenté un semblant de rotation dans mon système.
Donc après quelques creusages de cerveau, je suis arrivé à quelque chose qui ressemble à peu près à une rotation.
Je veux dire, on voit que c'est une rotation, mais :
-les lignes s'agrandissent au fur et à mesure de la rotation (ce qui fait l'étirement de la maison dans la vidéo à la fin de ce message vers 00:36) ce qui est extrêmement chiant et incompréhensible
-et puis... je ne sais pas vraiment pourquoi, mais cette rotation est bizarre. J'ai pas l'impression que la caméra tourne, plus l'impression que le monde entier tourne autour (je sais que c'est comme cela que doit se concevoir une rotation mais ça ne donne pas un truc naturel)
Voici la vidéo, j'en ai profité pour en faire une un peu plus propre. Le compteur de FPS fait de la merde on emulator, en vrai on est sur du ~4 FPS avec le preset 5 de FTUNE et ~1.5 FPS sans overclock.
Les problèmes arrivent vers 00:35.
Voilà, je suis en même temps content que ça ressemble pas à rien du tout et je m'interroge sur la question des problèmes évoqués ci dessus, je partage quand même car je me dis que vous pourrez peut être me donner des pistes !
Excellent ! Je crois que c'est bon, tu as juste un FOV immense. Tu te souviens que quand tu fais la projection tu divises par la profondeur, et en même temps (ou ensuite) tu multiples par une constante pour avoir l'affichage à l'écran ? Cette constante est trop petite, ce qui te donne un FOV très élevé. Augmente-là un bon coup ça devrait être beaucoup plus naturel
Au niveau de la rotation, ça donne l'impression que l'on met le "monde 3D" sur papier 2D et que c'est ce papier qui est incliné pour faire l'illusion de rotation.
P.S.
J'aime bien la musique
Un problème sans solution est un problème mal posé — Albert Einstein
Oui, c’est exactement ça Thebigbadboy.
Ce serait aussi simple que ça Lephe’ ? J’ai quelques arrangements à faire avec mon code (ça fait quand même 1 mois que j’y ai pas touché) et je vais essayer, ce serait super !
La musique c’est le 3ème mouvement du concerto pour piano no 3 de Rachmaninov. J’aime beaucoup aussi
Bon, j'ai quelques problèmes avec mon code qui est vraiment dégueulasse et que j'ai moi même du mal à comprendre.
Je vais essayer de me dépatouiller, peut être que si je n'y arrive vraiment pas et que ça ne te dérange pas je te demanderais quelques conseils Lephenixnoir, au cas où ce soit un problème "fondamental" et pas de code.
En attendant j'ai bricolé un système de craft assez rigolo. Sur la vidéo j'ai affiché le clavier pour mettre en évidence les touches.
Le problème principal c'est vraiment que ça devient lent au bout de plusieurs blocs.
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 02/03/2022 00:18 | #
Très propre comme rendu, bravo !
Citer : Posté le 02/03/2022 06:52 | #
Merci beaucoup ! Il reste encore quelques bugs (quand je descend en dessous du modèle à 0:04 de la vidéo sous émulateur, la texture violette passe au dessus de la rouge) mais globalement je suis assez content du résultat. C'est cool de voir que tu apprécie !
Citer : Posté le 02/03/2022 08:35 | #
Joli Potter360
pour ton problème de texture, logiquement ceci est géré par 2/3 approches dans un moteur 3D classique :
- la normale à la face à afficher est calculée et ensuite on regarde si le produit scalaire entre le vecteur de caméra et cette normale est positif ou pas, si positif c'est que la face est orientée de manière visible (et sera donc à afficher), sinon est est vue par l'arrière et est donc invisible (et donc pas à afficher). Cette opération s'appelle le "Back-Face Culling".
Note: ceci impose d'avoir un vecteur normal, de bien l'orienter à la définition initiale de la facette, puis de lui appliquer les mêmes transformations que la face pour savoir son évolution au cours des transformations (rotations, translations).
- ensuite il faut faire un rendu de l’arrière vers l'avant, c'est à dire commencer par les faces les plus éloignées et finir par les faces les plus proches, ce qui impose un tri sur un critère (coordonnée Z ???). En théorie c'est censé fonctionner, sauf que dans les faits si on a des faces de tailles très différentes, on obtient le même genre d'overlapping non maîtrisé de faces. Il vaut donc mieux utiliser la méthode suivante qui est par contre hyper lourde en calculs : le Z-Buffering.
- Le Z-Buffering consiste à tracer dans une zone tampon toutes les faces visibles (pas forcément triées je précise) en gardant une trace de la coordonnées Z (profondeur) du pixel correspondant. Ensuite avant de tracer un nouveau pixel sur une autre face, on vérifie dans le Z-buffer si le pixel est devant ou derrière celui déjà tracé. Si il est derrière, on fait rien, si il est devant, on le trace et on fait un update de la coordonnée Z correspondant dans le Z-Buffer. Comme tu peux le voir, c'est très lourd en calculs. Logiquement, dans le matériel info moderne, c'est géré en hardware mais là pas de salut, faut tout se palucher en soft à la main
Tu trouveras plus d'info ici (très généraliste) : https://www.wikiwand.com/fr/D%C3%A9termination_des_surfaces_cach%C3%A9es
Et une implémentation à titre d'exemple ici https://eccarrilloe.github.io/2017/09/24/Rasterization-Z-buffer-Algorithm/
Ce que tu rencontres comme souci est malheureusement très classique dans les moteurs 3D. Il y a pas mal de solutions éprouvées, mais elles sont pas toutes sympas niveau calculs et algorithmes de résolution.
Edit : Ne connaissant pas le C-Basic, je sais pas ce qu'il est possible de faire ou pas. A mon avis le Back-Face Culling est jouable, pour le tri aussi (avec ce qu'on peut en espèrer), mais pour le reste je sais pas.
Bon courage
Citer : Posté le 02/03/2022 10:43 | #
Pas mal ! Puisque RTEXTURE supporte les triangles tu pourrais faire une projection perspective pour un effet de profondeur un peu plus prenant.
Slyvtt en a dit pas mal, mais je sais pas à quel point tu es assez proche de la méthode "classique" pour pouvoir appliquer tout ça. Est-ce que tu peux donner un aperçu de la méthode de calcul de points/rendu de textures ?
Citer : Posté le 02/03/2022 12:26 | #
Salut Sylvtt !
Merci beaucoup pour tes conseils je vais me pencher là dessus !
Slyvtt en a dit pas mal, mais je sais pas à quel point tu es assez proche de la méthode "classique" pour pouvoir appliquer tout ça. Est-ce que tu peux donner un aperçu de la méthode de calcul de points/rendu de textures ?
En gros, pour les textures des quadrilatères, RTEXTURE regarde le minimum en position X, le maximum, et pour chacunes des positions entre les deux il dessine une ligne sur cette position allant de la hauteur max à la hauteur min.
Ça marche que si les cotes sont parallèles deux à deux du coup, oui c’est immonde.
Pour les points… tu vas être déçu.
En fait au tout début de mon projet j’ai fait un pavé droit en FLine, je l’ai redessiné en l’inclinant et j’ai regardé ce qui changeait.
En fait :
Un point fixe ne dépend d’aucune variable.
Un point mobile se calcule de la manière suivante :
posx-B,posy+A , et on inverse les signes quand on passe de l’autre côté du centre de rotation.
C’est très dégueulasse, d’autant plus que quand on tourne la figure s’étire, donc pas de 360 degrés possible.
Donc oui c’est extrêmement brouillon
Ajouté le 02/03/2022 à 21:00 :
Pas mal ! Puisque RTEXTURE supporte les triangles tu pourrais faire une projection perspective pour un effet de profondeur un peu plus prenant.
Qu’est ce que tu entends par « projection perspective » ?
Citer : Posté le 02/03/2022 21:23 | #
Ok, je vois c'est un système très simple pour le déplacement. En général en 3D ce qu'on fait c'est que se donne trois coordonnées par point (... naturellement), ensuite on les transforme par des translations/rotations pour positionner la caméra, et enfin on les projette en 2D pour s'avoir où les mettre à l'écran.
Il y a différents types de projection. Ce que tu as fait correspond en gros à la perspective cavalière (ie. un offset constant en X/Y par unité de profondeur). La projection perspective consiste en gros à diviser chaque position X/Y par la profondeur, ce qui est le plus naturel.
Citer : Posté le 02/03/2022 21:30 | #
Ok, je vois c'est un système très simple pour le déplacement.
Oui, vraiment. Son nom est en partie dû à cela
Ah, merci pour l’explication. Je vais regarder sur Internet des détails sur la projection perspective mais c’est vrai que j’avais moi même du mal à comprendre mon propre système de coordonnées des points. Merci !
Citer : Posté le 02/03/2022 23:22 | #
Juste une idée qui est pas toujours expliquée et qui m'a aidé à comprendre quand je suis passé par là : la perspective est facile à faire quand la caméra est à la position (0,0,0) du monde et quand elle regarde sur l'un des axes. Du coup quand elle est ailleurs on transforme le monde entier autour de la caméra pour faire comme si elle l'était (translation + deux ou trois rotations).
Citer : Posté le 02/03/2022 23:25 | #
Aaaah ! Ok, j'y vois plus clair, merci !
Citer : Posté le 03/03/2022 09:25 | #
Hello Potter360
tu pourras trouver des infos assez générales et transverses sur les opérations à comprendre pour faire un moteur 3D ici
https://www.javatpoint.com/computer-graphics-tutorial
Il y a en particulier des chapitres sur :
- 3D Computer Graphics
- Hidden Surfaces (ce dont on parlait avec le Back Face / Z-Buffering ...)
- Projections (notamment les projections parallèles et en perspective)
Contrairement à ce que le nom du site peut faire penser, c'est indépendant du Java et donne les concepts de base pour comprendre ce qu'il faut faire.
@+
Sly
Citer : Posté le 03/03/2022 16:47 | #
Hello !
Merci beaucoup !
Je t’avoue avoir fait des tests qui n’ont rien donné, donc cette source me donne de l’espoir !
@RDP
Ajouté le 11/03/2022 à 18:00 :
Salut !
Après des jours de travail, je suis heureux de vous annoncer la sortie de ~RUB3R V1.0~ !
Beaucoup de changements, voire une refonte quasi complète, installez vous !
Bon, évidemment le changement principal c'est la clarification du système de points.
Dans cette nouvelle version, rien de plus simple que de faire une ligne : on utilise cette syntaxe dans RMODEL :
[[xpointdedépart,ypointdedépart,zpointdedépart][xpointd'arrivée,ypointd'arrivée,zpointd'arrivée]→Mat A
Prog "RLINE"
Et voilà, votre ligne est dessinée.
Donc au delà du changement de syntaxe, on peut maintenant réellement faire de la 3D, en utilisant les repères X, Y et Z.
Pour vous donner une idée, voici un fichier RMODEL utilisant l'ancienne syntaxe :
...et la nouvelle :
Yay, je suis assez fier je l'avoue.
Important : la caméra au départ est à X=4,Y=4 et Z=30.
Je vais rendre le programme RTEXTURE compatible avec cette version prochainement, j'ai essayé un autre algorithme qui réglerai les problèmes de l'actuel mais c'est trop lent...
Et évidemment, voici un petit rendu dont je ne suis pas peu fier : un bonhomme de neige, une maison et un petit panneau !
Un grand merci à Lephenixnoir pour son aide si précieuse !
Et comme d'habitude, c'est sur Github !
@RDP
Citer : Posté le 19/05/2022 19:21 | #
Re !
Alors... quelques bonnes/mauvaises nouvelles en même temps xD
Avec l'aide précieuse de Lephenixnoir (merci 1000x <3) j'ai implémenté un semblant de rotation dans mon système.
Donc après quelques creusages de cerveau, je suis arrivé à quelque chose qui ressemble à peu près à une rotation.
Je veux dire, on voit que c'est une rotation, mais :
-les lignes s'agrandissent au fur et à mesure de la rotation (ce qui fait l'étirement de la maison dans la vidéo à la fin de ce message vers 00:36) ce qui est extrêmement chiant et incompréhensible
-et puis... je ne sais pas vraiment pourquoi, mais cette rotation est bizarre. J'ai pas l'impression que la caméra tourne, plus l'impression que le monde entier tourne autour (je sais que c'est comme cela que doit se concevoir une rotation mais ça ne donne pas un truc naturel)
Voici la vidéo, j'en ai profité pour en faire une un peu plus propre. Le compteur de FPS fait de la merde on emulator, en vrai on est sur du ~4 FPS avec le preset 5 de FTUNE et ~1.5 FPS sans overclock.
Les problèmes arrivent vers 00:35.
Voilà, je suis en même temps content que ça ressemble pas à rien du tout et je m'interroge sur la question des problèmes évoqués ci dessus, je partage quand même car je me dis que vous pourrez peut être me donner des pistes !
Citer : Posté le 19/05/2022 19:24 | #
Excellent ! Je crois que c'est bon, tu as juste un FOV immense. Tu te souviens que quand tu fais la projection tu divises par la profondeur, et en même temps (ou ensuite) tu multiples par une constante pour avoir l'affichage à l'écran ? Cette constante est trop petite, ce qui te donne un FOV très élevé. Augmente-là un bon coup ça devrait être beaucoup plus naturel
Citer : Posté le 19/05/2022 20:53 | #
Pas mal pour l'avancée
Au niveau de la rotation, ça donne l'impression que l'on met le "monde 3D" sur papier 2D et que c'est ce papier qui est incliné pour faire l'illusion de rotation.
P.S.
J'aime bien la musique
Citer : Posté le 19/05/2022 21:14 | #
Merci pour vos réponses !
Oui, c’est exactement ça Thebigbadboy.
Ce serait aussi simple que ça Lephe’ ? J’ai quelques arrangements à faire avec mon code (ça fait quand même 1 mois que j’y ai pas touché) et je vais essayer, ce serait super !
La musique c’est le 3ème mouvement du concerto pour piano no 3 de Rachmaninov. J’aime beaucoup aussi
Citer : Posté le 20/05/2022 21:18 | #
X/Z/tan(FOV/2) -> X
Citer : Posté le 25/05/2022 23:27 | #
Bon, j'ai quelques problèmes avec mon code qui est vraiment dégueulasse et que j'ai moi même du mal à comprendre.
Je vais essayer de me dépatouiller, peut être que si je n'y arrive vraiment pas et que ça ne te dérange pas je te demanderais quelques conseils Lephenixnoir, au cas où ce soit un problème "fondamental" et pas de code.
En attendant j'ai bricolé un système de craft assez rigolo. Sur la vidéo j'ai affiché le clavier pour mettre en évidence les touches.
Le problème principal c'est vraiment que ça devient lent au bout de plusieurs blocs.