Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
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 ?
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.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 ?
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.Où peut-on trouver un pointeur vers vos créations ?
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.
J'ai rien compris de ta phrase. Un pilote pour CPU? Depuis quand on a besoin d'un pilote pour un CPU?Envoyé par Lolilolight
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.
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.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.
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.
Non, je ne compte pas copier coller son code, qui va me donner un FPS de 1 comme je l'ai déjà dit.
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.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.
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 ?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.
Au pire je ferai des logiciels d'imagerie, si au niveau optimisation ça devient, vraiment trop compliqué pour moi.
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.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?
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.
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.
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 ?)
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
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 ?De plus l'écran n'est pas branché sur la carte graphique, mais sur 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.)
Bah oui, je le fais pour mon projet :Apparemment on ne peut pas se passer du contexte opengl pour la portabilité. :/
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.
Ça va être très approximatif, mais ça va marcher. Au moins tu sauve en calculs.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 ?
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.
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.
En espérant que ce ne soit pas définitif et que tu vas gérer que les pixels dans le triangle ....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à.
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:
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?Faire son propre driver avec un système de raytracing en temps réel.
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
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.Afficher une image
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 :/.
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.
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.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager