Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - moudubou

Pages: [1] 2 3
1
Ça a l'air sympa cette techno, ça me fait penser à unlimited details d'Euclideon


2
Code / Re : Re : Textures cycliques avec un atlas
« on: 26 March 2014 à 22:46:50  »
Tu peux te passer des binds de texture sans atlas, en utilisant des tableaux de texture, qui n’ont qu’un seul binding point.

Ah merci, je ne me suis pas encore documenté là dessus. Je vais regarder ça!

3
Code / Textures cycliques avec un atlas
« on: 26 March 2014 à 10:45:40  »
Hello
Je me demandais comment on pouvait faire pour faire cycler une texture quand on a un atlas
J'ai cru comprendre qu'on pouvait au niveau du shader ne récupérer que la fraction de la coordonnée et ensuite ajouter un offset en fonction du numéro de la texture
Mais j'vois pas du tout comment l'écrire ni envoyer l'information du numéro de texture au shader

Reste la solution d'avoir plus de géométrie (minimum deux triangles par cycle)

Ou alors je me prends la tête pour rien et les bindings de texture c'est pas si gourmand que ça

Z'en pensez quoi vous?


4
Merci pour ces explications. Dans mon cas, j'ai besoin de m'approcher assez du sol du landscape donc j'essaierai, pourquoi pas, de faire de l'adaptatif en fonction de mon altitude rapport au sol  ;)

5
Code / Re : Re : Re : Souci de zBuffer, enfin je crois
« on: 18 June 2013 à 10:48:02  »
Par contre, j'ai résolu mon problème en diminuant le zNear (logique non?) puisque ça clippait trop vite.
Du coup, j'ai diminué le zFar

Suite à mon souci de zNear/zFar, je me demandais ce que vous utilisiez comme valeurs, mais aussi, que est l'intervalle de données que vous traitez? (j'ouvre un nouveau sujet?)

Par exemple, en ce moment, j'essaie de faire un landscape dont les valeurs géométriques sont plutôt grandes vu que mes triangles isocèles font 16m de côté (ou 16 unités). À l'écran, je génère des polygones jusqu'à 8km du centre (rapport au lod).

Du coup, j'ai un peu de mal à comprendre pourquoi avec un zNear à 0.5 c'était toujours trop grand et que ça clippait comme valeur.

6
Code / Re : Re : Souci de zBuffer, enfin je crois
« on: 17 June 2013 à 22:53:31  »
En fait la précision du zbuffer est en fonction du rapport znear/zfar... (ou l'inverse je ne sais plus). Bref, plus l'écart entre ton znear et ton zfar est élevé, plus la précision est faible. Evite de mettre znear à 0 déjà, 0.5 c'est pas mal...

Sinon essaye GL_LEQUAL à la place de GL_LESS aussi...

Concernant la précision du zbuffer par rapport à znear et zfar :
source : http://www.talisman.org/opengl-1.1/Reference/glFrustum.html

C'était bien une histoire de zNear / zFar, merci!

Par contre, j'ai résolu mon problème en diminuant le zNear (logique non?) puisque ça clippait trop vite.

Du coup, j'ai diminué le zFar

Le GL_LESS ou LEQUAL ne semble pas avoir d'effet sur le rendu (pour le moment)

7
Code / Re : Re : Souci de zBuffer, enfin je crois
« on: 15 June 2013 à 17:04:30  »
Aussi, as-tu essayer de tourner autour de ton objet ? Voir si ça clip toujours au même endroit, ou pas.

Ça change quand je bouge autour de l'objet.

Et sinon, le znear, zfar, c'est le calcul de la matrice projection? Y a que là que j'ai un "far" et un "near" quand je calcule le frustum mais j'vois pas bien le rapport avec le zbuffer

Si c'est ça, j'ai mis 0.1 et 100.0 mais ça devrait clipper au fond, pas devant avec de telles valeurs  :o

Sinon j'ai ça de notable

        glEnable(GL_DEPTH_TEST);
        glDepthFunc(GL_LESS);
        glEnable(GL_CULL_FACE);

Mais rien qui initialise un zbuffer, j'avais l'impression que c'était automatique  ;D



J'suis vraiment un noob en openGL

8
Code / [résolu] Souci de zBuffer, enfin je crois (zNear en fait)
« on: 14 June 2013 à 23:16:44  »
Hello

J'essaie de balancer plein de polygones à ma carte pour afficher un landscape mais j'ai du mal à saisir pourquoi mes polygones clippent si rapidement?

Ça donne ce genre de chose à l'écran.

Que j'utilise des objets très petits ou bien très grands comme là, j'ai un clipping 3D qui arrive bien tôt et ça m'énerve, est-ce une erreur de débutant? (oui, sûrement)


9
Productions / Re : Re : Dancing feuille...
« on: 03 June 2013 à 09:27:42  »
je te somme d'aller foutre des culs et des nichons sur shadertoy !!!

et non t'as pas le choix


10
Productions / Re : Dancing feuille...
« on: 26 May 2013 à 01:43:57  »
Je déprimais, du coup j'ai passé mon après-midi sur shadertoy et voilà : https://www.shadertoy.com/view/lssGDH ;D

écran noir et erreur en rouge dans le source chez moi, un souci?

11
Code / Re : Re : Extracteur d'enveloppe
« on: 26 May 2013 à 00:14:21  »
Tout dépend de ce que tu veux comme synchro. Tout faire manuellement prend beaucoup de temps (un décalage de quelques millisecondes peut ruiner l'effet) et c'est à refaire à chaque démo. Alors oui, il y a toujours une part manuelle, mais il y a souvent une part automatisable.

Mon approche est de combiner les données de la partition (format midi par exemple) et la FFT. Les deux donnent des informations complémentaires, on ne fait pas les mêmes effets avec l'une ou l'autre. Mais j'aime beaucoup l'idée derrière envextract. Je testerai peut-être.


Même si les démos sont souvent finies à l'arrache (parce qu'il y a toujours des choses à fignoler ou à ajouter), elles sont généralement commencées en temps raisonnable.

Oui, en fait je viens de réaliser, que pour certains effets, il faut avoir l'enveloppe avant que le son arrive, donc c'est plus simple d'avoir tout en mémoire quelque part qui ait été fait à l'avance ;)

ps: À 60 images par seconde, une précision de 16ms suffit (je chipote, je chipote)


12
Code / Re : Re : Extracteur d'enveloppe
« on: 25 May 2013 à 20:54:02  »
Je pense pas que tu ais lu ce que j'ai marqué.

Déjà, les demos sont faites à l'arrache? J'oserais pas faire cette assertion pour tous les groupes, surtout sur les synchros qui sont peut-être le point le plus important d'une demo... tu peux avoir un moteur simple, des effets simples et tout sauver avec deux choses: design + sync.

En quoi ce que je dis empêche le fait que ça soit quand même fait à l'arrache ou bien optimisé pour un seul morceau.... c'est un tool, juste un tool qui permet de facilement faire des synchros en utilisant directement un DAW.

Je pars effectivement du postulat que les démos sont optimisées pour un morceau. Et jusqu'à preuve du contraire, ça a toujours été le cas  ;D. De là, une fois que tu as repéré les timings, il n'y a qu'à se mettre des bornes dans le code.

C'est sûrement moins propre que s'amuser à compter le tempo d'un morceau et calculer des enveloppes, mais ça fonctionne très bien.

Bref, je pense que pour une démo, faire du code générique de synchro n'a pas grand intérêt.

Ce n'est pas dévalorisant (on a l'impression que tu le prends comme tel), au contraire, c'est plutôt réaliste, ne pas perdre son temps sur un point qui ne le mérite pas.

13
Code / Re : Extracteur d'enveloppe
« on: 25 May 2013 à 18:06:10  »
Parce que les démos sont faites à l'arrache et optimisées pour un seul morceau?


14
Code / Re : Re : Librairie OpenAL, mais où est-elle vraiment?
« on: 25 May 2013 à 12:01:05  »
Tu veux lire quoi comme musique en fait ? Perso j’use fmodex et je vais me mettre à minifmod. OpenAL c’est un truc assez usine à gaz je crois non ?

De ce que j'ai vu, la quasi-totalité des librairies audio sont des usines à gaz chiantes à utiliser.

Du coup, je suis en train de me faire un soundsystem basé sur libao http://www.xiph.org/ao/

J'ai deux threads, un qui balance à la carte son des buffers et l'autre (le mixeur) qui rempli ces buffers

Mais à tout hasard, j'aurai bien jeté un œil à OpenAL au cas où ça ne soit pas trop pénible à utiliser vu que là, je suis sur le gros morceau: Les sons 3D

La finalité de mon truc, c'est un truc facile à utiliser dans lequel on balance des samples mais on peut très bien imaginer lire une musique avec.

15
Code / Re : Re : Extracteur d'enveloppe
« on: 25 May 2013 à 11:50:41  »
Bonne question : à quoi ça sert ? :p
C'est spécifique pour la démo, en gros imaginons que tu veux faire un effet dont un paramètre suive le volume d'une piste audio (exemple: le kick, une nappe), tu va demander à ton musicien de la sortir en solo sans reverb puis la passer la-dedans. Ca te sort un tableau que tu peux utiliser comme courbe.
L'alternative à ça c'est l'analyse d'une FFT en temps-réel mais dans ce cas pas de séparation entre pistes.
C'est TRES pratique quoique imparfait pour synchroniser une voix avec des lèvres qui bougent.

Ah ok, asservir les mouvements à la musique.


Pages: [1] 2 3