Discussion :

[Jbx 2.0b]

Toi t'es /ignore direct, mon plugin pour cacher les messages indésirables fonctionne apparemment super bien, ah ouais et t'es personne pour juger quelqu'un de raisonnable ou pas, un random white knight, raaa mais pourquoi je te réponds j'arrête.

On a bien compris qu'il y avait de "légers" problèmes d’ego & d'assimilation du côté de Lolilolight. Il n'empêche que sur developpez.com, on sort pas les armes comme tu le fais. C'est pas les forums de jeuxvideo.com ici, ou c'est celui qui gueule le plus fort qui gagne. Ici on se bat avec son cerveau, son code, sa technique. Aligner les "XD" ça fonctionne pas. Et même si dans le fond tu as plutôt (complètement ?) raison, tes réponses me dérangent (comme tes mutes, on est pas sur le chat de LOL ou Dota 2...). C'est au moins aussi puérile que le comportement de Lolitruc quand il n'écoute pas les conseils.

Etre cinglant de temps en temps, pour essayer de lui faire prendre conscience de ses erreurs, ok. Pourrir un sujet qui de toute façon ne t'intéresse pas, je vois pas l’intérêt.

Ah, et tu peux me classer dans les "whiteknights" aussi, si ça te fais plaisir. Et me mute. Sniff, j'vais pas en dormir de la nuit.

[Invité]

Je vois qu'on ressasse mes vieux topic ici.

Pour le bug avec libcrypto c'est réglé, l'erreur venait d'ici :

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
void AES_ENC::ossl_setKey(char* sKey) {
           delete ossl_key;
           ossl_key = new unsigned char[strlen(sKey)];
           for (unsigned int i = 0; i < strlen(sKey); i++) {
                ossl_key[i] = (unsigned char) sKey[i];
           }
        }
        void AES_ENC::ossl_setIv(char* sIv) {
           delete iv;
           iv = new unsigned char[strlen(sIv)];
           for (unsigned int i = 0; i < strlen(sIv); i++) {
                iv[i] = (unsigned char) sIv[i];
           }
        }

Fallait que je delete et que je réalloue lors du changement de clé plutôt que de faire directement un cast : ossl_key = (unsigned char*) sKey;

Sinon ça ne recopiait pas bien les bytes dans le tableau..., d'ou, l'erreur lors du décryptage.

Au niveau de la transparence le problème est simple pourtant, imaginons, j'ai un sprite rouge (1, 0, 0, 1) et un sprite bleu bleu. (0, 0, 1, 1), le sprite bleu à un z de 1, le sprite rouge un z de 0. (DSTCOL = rouge, SRCCOL = bleu)

Le problème c'est que le dephtest ne va pas dessiner les fragments du sprite rouge vu qu'il est derrière le sprite bleu, donc si le sprite bleu est semi-transparent je n'aurai pas la bonne couleur si les deux sprites se superpose.

Alors je me suis posé cet question, comment savoir quel est la couleur au centre, sans faire de depthtest ?

La réponse est simple, si le sprite bleu est au dessus du rouge on fait le bête blending par défaut :

SRCCOL * SRCA + DSTCOL * 1 - SRCA

(0, 0, 1, 1) * 1 + (1, 0, 0, 1) * (1 - 1) = (0, 0, 1, 1) + (0, 0, 0, 0) = (0, 0, 1, 1) ce qui donne la couleur bleue.

Maintenant changeons l'ordre (donc le z du sprite bleu est a 0 et celui du rouge à 1 cette fois) , si le sprite bleu est en dessous du rouge, alors, il faut changer la formule :

DSTCOL * DSTA + SRCCOL * 1 - DSTA

(1, 0, 0, 1) * 1 + (0, 0, 1, 1) * (1-1) = (1, 0, 0, 1) + (0, 0, 0, 0) = (1, 0, 0, 1) ce qui donne la couleur rouge.

Donc j'ai bien le même résultat que si je faisais un dephtest classique!
A part que ça fonctionne aussi avec la semi-transparence.

C'est la seule différence par rapport au pipeline par défaut de opengl qui ignore la transparence.

[maeiky]

Mais tu ne comprend vraiment rien de rien, ça dois faire au moins 50 fois que je te le dis, dès la page 7 :

D'après ce que j'ai compris tu fais un blending "normal" peut-importe l'ordre, sans trier les éléments. Ce qui donne un résultat totalement faux lorsqu'il y à plus d'une transparence. De plus ta formule change si l’élément est devant ou derrière et puisque tu n'utilise pas le blending intégrer à OGL, tu dois lire 2 textures différentes ce qui ralentie, en plus des calculs et ta condition.

Il n'y a pas 36 solutions :

Soit tu abandonne la transparence, il y à plein de moteur 3D très bien sans.
Soit tu les affiche dans l'ordre.
Soit tu fait ta transparence à part avec un procéder multiplicatif ou additif.
Soit tu utilise la méthode du weight : https://mynameismjp.wordpress.com/20...d-blended-oit/
Ou que tu utilise des linked list avec OGL 4+

Et je viens de te dire que ça marche 2 sur sprites, car tu ne calcul pas les sprites intermédiaire aléatoirement:

Ok, si ton moteur se limite à 2 sprites, ça passe.

Lolilolight pense qu'il peu appliquer un depth test dessus pour pouvoir afficher les pixels individuellement dans n'importe quel ordre et ainsi révolutionner le OIT.
Dans cette logique, Il peu arrivé que qu’il affiche le dernier, le premier en ensuite celui du milieu. Dans ce cas il a déjà interpolé les couleurs opposé et il tente d’obtenir la couleur intermédiaire, ce qui est faux. Sans parler de l’imprécision du point flottant qu’a va varier d’un affichage aléatoire à l’autre dans le cas d’un batching par exemple.

Je vais tenté traduire ce que tu tente de faire :
Moi Lolilolight, je veux pouvoir superposé 2 sprites "semi-transparent", dans n'importe quel ordre (j'ai inventé mon OIT sur 2 sprites, m'voyer) et du coup le batching ne marche plus, je vais donc attendre Vulkan qui me permet de faire des calcul atomique, les pixels vont donc s’actualiser, là aussitôt. Mais là, Vulkan requière une plateforme supportant OGL 4.X, je vais donc coder mon propre drivers pour que ça puisse fonctionné sur mon ordinausaure.

Bref, il est irrécupérable.

[Invité]

Salut.

J'ai réfléchi à la question et il est vrai que pour les sprites intermédiaires, la formule ne parait pas bonne, j'ai donc tenté ceci :

Un rendu basique (sans shader donc), en n'écrivant que ce qui est opaque dans le depthbuffer.

Malheureusement il n'y a rien qui se dessine. :/ (Et je ne peux même pas créer une texture à la quelle j'attache un "depthbuffer") : glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, depthTexId, 0)
Sinon glCheckFrameBufferStatus échoue.

Par ailleurs, j'ai tenté un rendu de 10 sprites semi-transparents dans n'importe quel ordre, j'obtient bien à chaque fois le même résultat.

Je trouve ça null de ne pas pouvoir faire de batching, mais bon..., je préfère ça et avoir un résultat correct, plutôt que de faire du batching et qu'il me blend toujours avec la couleur du fond car ma texture ne se remet pas à jour à chaque fois qu'un pixel est écris, mais seulement à chaque fois qu'un draw est appelé, ce qui me donne la mauvaise couleur au centre.

[NevilClavain]

faire du batching et qu'il me blend toujours avec la couleur du fond car ma texture ne se remet pas à jour à chaque fois qu'un pixel est écris, mais seulement à chaque fois qu'un draw est appelé

Je trouve ça vachement surprenant comme comportement (ou bien y a un truc que j'ai pas compris).

Perso, de ma modeste expérience : je fais du D3D9, j'affiche 400 sprites en un seul draw call (si c'est bien ça que tu entend par "batching") et mon alpha blending (AsCs + (1-As)Cd) se fait correctement
(je ne fais pas d'OIT, j'ai un thread séparé pour re-ordonner si besoin mes quads en fct de la pos camera dans le vertex buffer entre deux draw calls).

sauf erreur, l'alpha blending est mis en oeuvre dès que tu écrit un pixel, que ça soit à l’écran ou dans une target texture, non ????

et de mon point de vue, je ne vois pas pourquoi OpenGL procéderait différemment. A moins peut être de l'avoir configuré d'une façon "particulière", mais encore une fois je ne comprends pas comment c’est possible ???

[Iradrille]

(je ne fais pas d'OIT, j'ai un thread séparé pour re-ordonner si besoin mes quads en fct de la pos camera dans le vertex buffer entre deux draw calls).

Lolilolight ne veut pas trier parce qu'il est évidemment plus rapide de faire 1000 draw calls que de trier 1000 éléments.

[maeiky]

@NevilClavain

Il n'y aucun problème à faire du batching + alpha blending si tu utilise les fonction "build-in" du gpu, ces fonctions sont conçu pour ça.

Mais, Lolilolight s'entête à utilisé un frambuffer qui tente de "s'auto-lire", mais dans ce cas les pixel sont traité par section et non directement dans l'ordre si plusieurs se superposent dans le cas de batching.

[Invité]

Bref ce problème ne se pose pas avec les fonctions build-in du gpu, mais le problème pourrait très bien se poser si on a besoin de faire autre chose que du blending, c'est à dire dans d'autres cas ou l'on aurait besoin de lire les pixels du framebuffer et/ou du depthbuffer.

Imaginons le cas des masques de calque.

Obligation donc de faire 1000 draw calls plutôt que de n'en faire qu'un seul. :/

Bref, les shaders sont beaucoup utilisés de nos jours, donc, ça ne me surprendrais pas qu'on en ai besoin pour faire autre chose que du blending, dans ce cas le batching poserait également problème.

Donc je ne m'en tête pas, j'ai juste opté pour un rendu plus lent, mais qui permet de faire bien plus de choses avec les shaders, plutôt qu'un rendu plus rapide mais dépendant du gpu.

Mon moteur n'est pas destiné que à des jeux.

PS : Il n'y a qu'avec les versions d'opengl toute récente que l'ont peut faire autrement mais, elles ne sont pas encore supportée sur toutes les plateformes ainsi que les cartes graphiques. (Ma carte graphique ne semble pas supporter les "per-pixel-linked list" ainsi que les opérations atomiques, ou bien alors c'est mesa driver qui ne les supporte pas, soit...)
Et comme je ne m'y connais absolument pas là dedans, je préfère laisser cette tâche au constructeur, plutôt que de bidouiller dans un code ou je ne sais même pas ce que je fais.

Au moins avec cette technique, je sais ce que je fais.

PS 2 : OpenCL j'écarte aussi car pas top niveau compatibilité également.

[maeiky]

Et comme je ne m'y connais absolument pas là dedans, je préfère laisser cette tâche au constructeur, plutôt que de bidouiller dans un code ou je ne sais même pas ce que je fais.
...

PS 2 : OpenCL j'écarte aussi car pas top niveau compatibilité également.

Hein? Mais, tu commence enfin à comprendre

Bref, les shaders sont beaucoup utilisés de nos jours, donc, ça ne me surprendrais pas qu'on en ai besoin pour faire autre chose que du blending, dans ce cas le batching poserait également problème.

Autre chose qui demande un ordre? Je vois pas ... je dois manquer d'imagination.

Et puis, tu semble oublier tout le potentiel d'un deferred shading.

[NevilClavain]

Et puis, tu semble oublier tout le potentiel d'un deferred shading.

Je plussoie

[Invité]

En quoi le deferred shading peut t'il aider ?

Je ne vois pas.

A mon sens le deferred shading, cela permet de calculer la lumière uniquement là ou elle est, et pas sur toute la surface. (Chose que je fais déjà)

[maeiky]

A mon sens le deferred shading, cela permet de calculer la lumière uniquement là ou elle est, et pas sur toute la surface. (Chose que je fais déjà)

*sigh*

Tes lumières et tes .... "ombres", encore des choses que tu fais n'importe comment.

Tu sais, rien ne t’empêche de prendre 5 minutes pour étudier le sujet.

[Invité]

Pour mes lumières je fais un bête dégradé, et pour les ombres j'utilise le shadow mapping.

C'est plutôt toi qui raconte n'importe quoi. xD

[maeiky]

Pour mes lumières je fais un bête dégradé, et pour les ombres j'utilise le shadow mapping.

C'est plutôt toi qui raconte n'importe quoi. xD

Ok et tu avais l'intention de faire un bump mapping sur ton dégrader?

[Invité]

Oui, car il y a non seulement la géométrie de la scène mais également la géométrie des textures, je dois donc combiner combiner les deux pour calculer la lumière.

[maeiky]

le bump mapping ne se fait pas sur du Gouraud shading ...

[skeud]

Je suis la discussion depuis un moment, et je commence à être perdu, si quelqu'un pouvait éclairer ma lanterne:

Je croyais que openGL pouvait gérer l'éclairage à partir de sources de lumière?

[maeiky]

Je suis la discussion depuis un moment, et je commence à être perdu, si quelqu'un pouvait éclairer ma lanterne:

Je croyais que openGL pouvait gérer l'éclairage à partir de sources de lumière?

Tu parle des fonctions OGL avec pipeline de lumière limité à 8?
Ici, il est plus question d'OpenGL moderne ... bon c'est encore drôle.
Le but est d'exploiter les shaders pour avoir nombre quasi-infinie de lumières dynamiques.

[skeud]

Je sais pas exactement, j'avais souvenir d'avoir fait un petit projet avec openGL et une lumière, j'ai pas trop compris ta réponse, mais je vais considérer que c'est non du coup ^^.

[Jbx 2.0b]

Je sais pas exactement, j'avais souvenir d'avoir fait un petit projet avec openGL et une lumière, j'ai pas trop compris ta réponse, mais je vais considérer que c'est non du coup ^^.

L'ancien OpenGL (avant OpenGL 2.0) était basé sur un pipeline fixe. En gros il était implémenté en dur un modèle de gestion de la lumière (qui était en fait un système dit ADS - Ambient-Diffuse-Specular - calculé au vertex près). Il suffisait alors de choisir les paramètres de la lumière et de la placer dans la scène. Super simple mais aussi super rigide.

Aujourd'hui ce pipeline est devenu programmable, et les programmes exécutes sont les shaders. Ils permettent d'implémenter son propre système de lumière (par exemple un ADS calculé au pixel près) mais aussi peuvent être utilisés pour faire énormément d'autres choses, comme appliquer des posts effects, générer de la géométrie, faire du calcul parallèle...