Discussion :

[Cirrus Minor]

Salut,
pourquoi conclues-tu par "Et voila comment faire son propre driver" ?
Tu n'as pas implémenté un pilote pour ta carte graphique, si ?

Comment fais-tu le rendu sans passer par la carte graphique ? C'est quoi le principe ?
Tu utilises une méthode portable, ou c'est dépendant de ton OS ?

[Invité]

Salut,
pourquoi conclues-tu par "Et voila comment faire son propre driver" ?
Tu n'as pas implémenté un pilote pour ta carte graphique, si ?

Ce n'est pas un pilote pour carte graphique, mais un pilote pour le CPU, ceci dans le but d'être portable quel que soit la carte graphique.

Où peut-on trouver un pointeur vers vos créations ?

Mes créations d’auparavant sont passé à la trappe avec mon ancien PC ou bien on été revendue pour pas cher et puis de toute façon c'étaient des clones de jeux classique.

J'étais parti sur un mmorpg en 3D iso avec une équipe à l'époque mais comme la plupart n'étaient que des grosses têtes, j'ai fini en solo sur projet de plus petite envergure : un moteur compatible avec tout les drivers graphiques. (Comme je n'avais pas envie de refaire un petit jeux qui de toute façon ne vaut plus grand chose à l'heure actuelle. :/)

De plus les if et les sampler2D dans les shaders ce n'est pas ce qu'il y a de plus performant. :/

Car, sinon, je n'ai pas les bons résultats pour les calculs avec les drivers au niveau des shaders (surtout pour la gestion en z des fragments avec la semi-transparence) et je dois faire un tas de tests pour savoir quel type de shader est supporté , j'ai donc changé ma conception pour faire tout les calculs au niveau du CPU, et passer le framebuffer au GPU avec des images chargée en mémoire, plutôt que de faire les calculs dans les shaders.

Bref, skeud m'a passé un super lien pour ça avec de bons rendus.

[skeud]

Ce n'est pas un pilote pour carte graphique, mais un pilote pour le CPU, ceci dans le but d'être portable quel que soit la carte graphique.

J'ai rien compris de ta phrase. Un pilote pour CPU? Depuis quand on a besoin d'un pilote pour un CPU?

Si tu exécutes ton code sur le CPU uniquement, pourquoi avoir de besoin de la carte graphique alors?


Ensuite, partir sur un moteur en raytracing, c'est pas une mauvaise idée, mais niveau optimisation c'est bien plus compliqué que openGL. Il faut etre bien calé en méta et microprogrammation, voir même codé tes primitives en assembleur (chose que j'ai fait pour mon moteur d’ailleurs). Mais du coup tu perds la compatibilité dont tu sembles te préoccuper.

En même temps, il est sur que tu pourras te faire remarqué bien plus facilement dans le milieu en faisant un moteur en raytracing qu'avec openGL surtout si il est aussi puissant et pratique que tu nous l’annonce.

[maeiky]

Ensuite, partir sur un moteur en raytracing, c'est pas une mauvaise idée, mais niveau optimisation c'est bien plus compliqué que openGL. Il faut etre bien calé en méta et microprogrammation, voir même codé tes primitives en assembleur (chose que j'ai fait pour mon moteur d’ailleurs). Mais du coup tu perds la compatibilité dont tu sembles te préoccuper.

Exactement, programmer c'est pas juste appliquer quelques petites formules mathématique ici et là, faire ça optimisé c'est un art en soi. Oublie tout ce que tu as appris en OpenGL.

J'ai dû passer plus de 6 mois sur le même bout de code à faire de la manipulation graphique incluant l'interpolation linéaire et le blending de façon le plus optimisé possible. Rien de farfelue comme raycasting et tout. Chaque petites instructions est pensé et calculé de façon la plus rapide possible en évitant les variables flottantes, le tout en opérations bitwises. Tout ça pour un résultat correct.

De plus j’évite de faire des choses stupide comme dessiné de l'arrière à l'avant.

Si tu ne fais que copier notre cher amis Grégory Massal, je t’applaudis si t'arrive à 1 frame seconde. À moins bien sûr que ton moteur graphique ne serve qu'à des logiciels d'imageries.

[Invité]

Non, je ne compte pas copier coller son code, qui va me donner un FPS de 1 comme je l'ai déjà dit.

J'ai dû passer plus de 6 mois sur le même bout de code à faire de la manipulation graphique incluant l'interpolation linéaire et le blending de façon le plus optimisé possible. Rien de farfelue comme raycasting et tout. Chaque petites instructions est pensé et calculé de façon la plus rapide possible en évitant les variables flottantes, le tout en opérations bitwises. Tout ça pour un résultat correct.

De plus j’évite de faire des choses stupide comme dessiné de l'arrière à l'avant.

Ca, ça fait un bon bout de temps que je ne le fais plus : dessiné de l'arrière vers l'avant, pas optimisé pour la 3D en plus cette technique te force à découpé les polygone non convexe ce qui n'est pas gratuit au niveau des performances.

Si tu ne fais que copier notre cher amis Grégory Massal, je t’applaudis si t'arrive à 1 frame seconde. À moins bien sûr que ton moteur graphique ne serve qu'à des logiciels d'imageries.

J'ai une question à se sujet, est ce que si j'entoure chaque objet d'une sphère pour effectuer le calcule, cela va me donner un résultat correct même pour des cubes ou tout autres formes ?

Au pire je ferai des logiciels d'imagerie, si au niveau optimisation ça devient, vraiment trop compliqué pour moi.

J'ai rien compris de ta phrase. Un pilote pour CPU? Depuis quand on a besoin d'un pilote pour un CPU?

Si tu exécutes ton code sur le CPU uniquement, pourquoi avoir de besoin de la carte graphique alors?

Le pilote CPU me sert à avoir la couleur de chaque fragment pour les calculs, disons que le but est de faire l'interpolation et le blending le plus rapidement possible et de façon, parallèle.

SFML ne permet pas d'afficher une image sur la fenêtre sans utiliser la carte graphique, donc pour l'instant j'affiche la framebuffer avec le GPU (en fait, je charge l'image en mémoire que j'affiche avec un sprite sur toute la fenêtre)

Apparemment on ne peut pas se passer du contexte opengl pour la portabilité. :/

Voici la réponse que j'ai eu sur gamedev.

Well direct frame buffer access is actually much harder than just using opengl with render to texture. It's also a lot less portable. On Linux systems, for example, you'd have to write a kernel module to shuffle buffer data directly. Also you risk obliterating data from other applications etc. There's a reason Opengl gives applications a context to make calls through and mitigate access to the gpu device.

[skeud]

SFML ne permet pas d'afficher une image sur la fenêtre sans utiliser la carte graphique, donc pour l'instant j'affiche la framebuffer avec le GPU (en fait, je charge l'image en mémoire que j'affiche avec un sprite sur toute la fenêtre)

FAUX, je n'ais pas de carte graphique sur mon PC et j'arrive bien à afficher l'image, donc SFML utilisera la carte graphique si elle est dispo (normal c'est le boulot de la carte graphique). Donc si tu n'arrives pas à utiliser SFML, c'est un soucis de ton coté et non pas du coté de SFML. Pour faire un moteur de rendu raytracing, tu peux très bien utiliser SFML, c'est d'ailleurs ce que j'ai fait pour mon moteur de rendu.

[Woum_]

FAUX, je n'ais pas de carte graphique sur mon PC et j'arrive bien à afficher l'image

C'est peut-être une question bête, mais c'est possible ça ? Il faut pas forcément au moins un chipset graphique ?
(Ou alors c'est juste que chipset graphique != carte graphique ?)

[skeud]

Oui c'est possible l'écran n'est qu'un registre. Une représentation des pixels en mémoire, en modifiant ce registre, tu modifies l'affichage.
La carte graphique est là car son processeur est optimisé pour certains calcul, là ou le processeur en lui-même ne l'est pas.
L'avantage de la carte graphique n'est pas d'afficher des images mais de faire des calculs spécifique aux images.

Les premiers ordinateurs n'avaient pas de carte graphique et pouvaient quand même afficher des choses à l'écran .

Un test tout simple à faire, débranche ta carte graphique, et tu verras que ton ordi fonctionne toujours, avec un affichage très ralenti certes, mais fonctionnel .

De plus l'écran n'est pas branché sur la carte graphique, mais sur la carte mère .

[Woum_]

De plus l'écran n'est pas branché sur la carte graphique, mais sur la carte mère .

Donc quand je branche mon pc sur le port de la carte graphique pour l'écran, au finale je suis quand même branché à la carte mère ? Et quand on lit qu'une carte graphique peut faire fonctionner plusieurs écran, c'est qui qui gère le multi écran au finale ? La carte mère ?
Du coup la limitation du nombre d'écran quand on a une carte graphique, c'est juste parce-que sinon elle a trop du mal pour les calculs ?

Parce-que j'ai des ports différents, ceux qui viennent de la carte graphique, et un qui est directement à la carte mère. Et je pensais que c'était possible d'en avoir un sur la carte mère, parce-que la carte mère a un chipset graphique.
Mais sinon c'est vrai que les premiers pc devaient pas avoir de carte et pourtant ça marchait .

(Désolé de faire dévier un peu , mais ça me surprend car j'y avais jamais vraiment réfléchi.)

[maeiky]

Apparemment on ne peut pas se passer du contexte opengl pour la portabilité. :/

Bah oui, je le fais pour mon projet :

Linux:
(Bouton droit->enregistrer sous, ensuite Bouton droit sur l'application -> Propriété -> Permissions -> Cochez "Allow executing file as program")

GroundZero_Linux_x32_v0.00
GroundZero_Linux_x64_v0.00

Ça devrait marcher peu importe le drivers graphique.

J'ai une question à se sujet, est ce que si j'entoure chaque objet d'une sphère pour effectuer le calcule, cela va me donner un résultat correct même pour des cubes ou tout autres formes ?

Ça va être très approximatif, mais ça va marcher. Au moins tu sauve en calculs.

Tu peux toujours t'essayer, mais si tu fais trop de chose extravagante en même temps, tu risque d'être déçu niveau performance.

[Invité]

Nouvel article : le mappage de textures!
J'optimiserai au fur et à mesure le code, pour que, cela reste performant.

https://lolilolightdevblog.wordpress...en-temps-reel/

La suite sera plus intéressante et traitera du rendu au raytracing en temps réel.

[maeiky]

Sur la page précédente le FPS n’est pas très optimal, ceci est dû au fait que l’on parcour tout les pixels de l’éran, pour tester si ils sont dans le triangle, pour optimiser cela, je vais simplement prendre le rectangle englobant le triangle, et parcourir l’écran dans cette zone là.

En espérant que ce ne soit pas définitif et que tu vas gérer que les pixels dans le triangle ....

[skeud]

Plusieurs remarques sur la forme de ton blog:
_ Ton blog n'est pas du tout agréable à lire pour le code, pour le reste, c'est plutôt bien.
_ Pas de commentaire dans le code, c'est illisible du coup

Ensuite pour le reste:

Faire son propre driver avec un système de raytracing en temps réel.

Un mec qui passe et qui lis ça te prendra pour un gros rigolo, je suis désolé mais c'est la vérité: que vient faire le mot driver et raytracing dans la même phrase?

Ensuite pour tout le reste, bah comment dire, tu te goures complètement de direction ....

Un moteur de raytracing ne va pas tester tout les pixel de l'écran pour savoir si il est dans le triangle, mais va tester pour chaque pixel de l'écran, quel est l'intersection avec une forme de la scène, c'est l’opposé complet de ce que tu fais là.
Et si tu utilise openGL, alors tu ne fais pas de raytracing, car le raytracing, la seule fonction de rendu dont tu as besoin c'est

Afficher une image

Tout le reste se passe en mémoire sur un buffer de travail. Tu n'as pas besoin de tout ce dont tu as parler avant.

Et soit dis en passant:
40 FPS pour un triangle, c'est (désolé des mots) complètement nul.
Avec juste des forme primitive type sphère et cube, mon moteur tournait à plus de 100 FPS (sans les lumière, juste l'intersection des formes).

Je te conseil donc sérieusement de revoir complètement ton truc, tu te lances beaucoup trop vite dans le code. Prends un peu plus de temps, tu n'es pas pressé, ça t'évitera de faire des erreurs. Prévois un cahier des charges, un début de conception, d'idée. Car là tu pars un peu au petit bonheur la chance, donc tu te cassera la figure à coup sur :/.

[Invité]

Si tu n'utilises pas opengl, comment fais tu pour, dessiner tes triangles à l'écran des objets de ta scène ?

Comment fais tu pour gérer les transformations, les projections, etc... ? (Comme le fait opengl)


Je pense que tu n'as pas bien lu, j'ai un FPS de plus de 60 maintenant en dessinant tout les pixels qui sont dans mes triangles.

Mais je n'utilise opengl que pour dessiner l'image finale, et je fais mon propre rasterizer, ça m'évite d'avoir à projeter chaque rayons vers chaque pixel de l'écran.

Mais c'est un peu compliqué à expliqué ici même. :/

Et puis faire les calculs d'intersections sur chaque triangles serait trop coûteux.

Bref, attendez de voir les screens.

[Invité]

Bon, j'ai abandonné l'idée d'utiliser uniquement le CPU mais je laisse les articles à titre informatif pour avoir une idée de comment le CPU fonctionne, je vais également faire un article sur le raytracing plus tard sûrement. (Côté CPU également)

Mais en tirant partie des avantages de l'un (le CPU) et de l'autre (le GPU), les perfs sont nettement meilleures!

Par exemple, j'utilise le CPU pour effectuer les transformations pour les objets statiques et le GPU pour les objets dynamique.