Author Topic: Surfaces implicites en GLSL  (Read 4902 times)

0 Members and 1 Guest are viewing this topic.

Dr. Goulu

  • Soldier
  • **
  • Posts: 51
    • Dr. Goulu
Surfaces implicites en GLSL
« on: January 30, 2008, 05:21:38 PM »
Bon, je me suis (enfin) plongé jusqu'au cou dans le GLSL.
L'idée pour commencer c'est de faire tourner le joli code dont je parle ici sur ma carte ATI, donc de le traduire de Cg à GLSL.
Pour ça je me suis dit que RenderMonkey pourrait m'aider à mettre le shader au point, et qu'après je traduirai la partie C++ en LUA pour passer l'application sous Demoniak.
Et qu'après, je pourrais fignoler le code pour représenter d'autres "surfaces implicites". Je vais pondre un article sur www.3dmon.com là dessus très bientôt, mais en gros le principe c'est de faire une sorte de ray-tracing qui utilise une fonction itérative pour trouver l'intersection du rayon avec une fonction définie par f(x,y,z)=0, donc plus générale qu'un mesh. Le code travaille avec un quad en coordonnées écrans et deux textures dont on calcule les couleurs aux coins : une texture code les coordonnées (x,y,z) de l'origine des rayons, et l'autre leur direction.

Mais bon, pour l'instant je bute sur un blème déjà dans RenderMonkey : les shaders passent à la compilation mais pas au "link" : ça dit Fragment shader(s) failed to link,  vertex shader(s) failed to link.. Sans plus. Qu'est-ce qui peut foirer au link avec des shaders ?

Le fichier rendermonkey et le programme d'origine en C++/Cg sont dans une archive ici si vous pouvez jeter un oeil ...

3Dmon

JeGX

  • Global Moderator
  • Capo Crimine
  • *****
  • Posts: 2343
    • oZone3D.Net
Re: Surfaces implicites en GLSL
« Reply #1 on: January 30, 2008, 05:35:38 PM »
j'ai jetté un oeil dessus mais j'ai pas d'erreur de linking. Main le projet rendermonku est incomplet, il manque des 3ds. Donc j'ai aucune visu (scene noire).
Pourquoi tu te sers de ce truc reloud. Code directement avec Demoniak3D, c'est plus simple à debug ensuite.

shadow

  • Capo Regime
  • ***
  • Posts: 353
Re: Surfaces implicites en GLSL
« Reply #2 on: January 30, 2008, 09:16:07 PM »
Quote
Pourquoi tu te sers de ce truc reloud
parce que c'est fait pour ça ?  :roll:
Je bosse tous les jours sur Fx Composer, il comporte pas mal de bugs mais il est quand même sacrément utile, que ce soit pour coder, tester, évaluer les perfos de façon précise....
Coder ça uniquement sur notepad++ c'est loin d'être évident ! ;)
3D, photos panoramiques : http://www.shadows.fr

JeGX

  • Global Moderator
  • Capo Crimine
  • *****
  • Posts: 2343
    • oZone3D.Net
Re: Surfaces implicites en GLSL
« Reply #3 on: January 30, 2008, 11:58:43 PM »
yep je m'emporte toujours un peu  :oops: surtout quand c'est reloud  :twisted:
Plus sérieusement, ces gros environnement doivent être utiles mais j'avoue ne pas avoir touché à aucun des deux depuis des lustres. Mais FXC est mis à jour régulièrement alors que RM un peu moins (voire carrement plus?). Je vais tacher de regarder FXC un de ces quatres...

Steph3D

  • Capo Regime
  • ***
  • Posts: 399
Re: Surfaces implicites en GLSL
« Reply #4 on: February 24, 2008, 08:42:26 PM »
Pareil pour moi, je viens d'installer rendermonkey que je trouve vraiment très bien (celui de nvidia ne semble pas coder directement en glsl )

J'ai codé une semaine avec notepade ++ et démoniak, ben c'est chiant quand même pour apprendre. Faut préparer et bidouiller à chaque fois la scène pour chaque essai, c'est long ! Quand j'expérimente pour apprendre, je fais pas mal d'erreur qui fait cracher démoniak, a chaque je modifie, sauvegarde et relance démoniak, et puis si je veux ajouter des textures, c'est pas des plus ergonomique, ou pour mettre des variables dans LUA pour piloter le shades, etc... La, avec rendermonkey, je fais ça très rapidement, j'ai plus qu'a me soucier que du code GLSL, c'est très simple et rapide d'ajouter une variable virtuelle pour piloter le shader, poser une nouvelle texture dans la pile, ou échanger les objets en 2 clicks de souris. Je peu coder dans un éditeur ergonomique et très lisible, et compilé mes expérimentations sans avoir peur de tous craché, et je n'ai plus besoin non plus de jongler dans mes dossiers Windows avec pleins de scènes XML de test à ne plus savoir ou mettre la tete. En plus, RenderMonkey permet aussi de ranger très facilement plusieurs shaders dans la même scène, tres bien pour faire des couper-coller pour expérimenter des variantes, etc...

Pour apprendre, expérimenter et classer proprement nos shaders, et donc gagner un temps fou, rendermonkey est vraiment très utile.

Sinon, en plus simple, il y a aussi Shader Designer sur le site d'OpenGL, mais c'est pas un exemple de stabilité avec des runtimes java, j'aime pas le java, car les applis sont souvent instables et lourds. Faudrait foutre ça en l’aire, et que tout le monde programme en LUA un jour.

J'ai aussi testé mental mil, c'est énorme se truc sans avoir besoin de coder, mais à l'export, le code des shaders sont vraiment une grosse usine à gaz, presque inexpoitble à la main. Il est du style à créer une 10e de fonctions pour un truc qui se code en 2 lignes.

JeGX

  • Global Moderator
  • Capo Crimine
  • *****
  • Posts: 2343
    • oZone3D.Net
Re: Surfaces implicites en GLSL
« Reply #5 on: February 25, 2008, 11:07:45 AM »
en meme temps pour tout ce qui est code Demoniak3D (lua ou glsl) je ne suis absolument pas objectif car pour ce que j'ai besoin de faire, je suis largement rapide pour mettre au point les routines directement avec un notepad-like. Mais pour des personnes moins à l'aise avec les subtilités de Demoniak3D, si des env comme RM ou FXC permettent de mettre au point les shaders GLSL alors faut les utiliser.

shadow

  • Capo Regime
  • ***
  • Posts: 353
Re: Surfaces implicites en GLSL
« Reply #6 on: February 25, 2008, 11:23:36 AM »
Quote
Mais pour des personnes moins à l'aise avec les subtilités de Demoniak3D, si des env comme RM ou FXC permettent de mettre au point les shaders GLSL alors faut les utiliser.
Ou tout simplement pour ceux qui veulent des fonctions avancées...
Je connais un certain nombre de programmeurs en C++ qui n'utilisent pas le bloc notes :roll: .

Le bloc notes ne donne pas d'infos sur les erreurs de compilation, sur les perfos de ton shader sur différentes cartes, il ne permet pas de modifier en temps réel tel ou tel paramètre. Fx Composer, si. 8)
3D, photos panoramiques : http://www.shadows.fr

Steph3D

  • Capo Regime
  • ***
  • Posts: 399
Re: Surfaces implicites en GLSL
« Reply #7 on: February 26, 2008, 10:24:23 AM »
Et après on se demande pourquoi JeGX passe des heures pour trouver les bons réglages d'un shader d'eau  :lol:

Par ce qu'une fois passés la théorie et les concepts mathématiques, il faut passé à la pratique, et réglé ça à l'oeil pour trouvé des réglages réalistes et crédibles, se que ton code, tes math, et ton notepad ne pourra jamais faire  :nop!:  Et à ce moment la, il faut pouvoir modifier les choses le plus vites possible ! Rendemonkey permet déjà de piloter les variables dans une interface en temps réel, ce qui n’est deja pas rien, en plus du reste ;)

JeGX

  • Global Moderator
  • Capo Crimine
  • *****
  • Posts: 2343
    • oZone3D.Net
Re: Surfaces implicites en GLSL
« Reply #8 on: February 26, 2008, 11:29:46 AM »
bon arretez de discuter sur ma façon très bourine de coder mes scènes  :RED: 
Oui je suis battu, FXC et RM sont super cool. Dès que je retouve une souris, j'essaierai ces tools  :mrgreen:

Mais n'oublions pas qu'il est tout à fait possible de coder une appli demoniak3d qui offre une interface visuelle avec sliders et autres widgets pour mettre au point de manière interactive ses demos.  Alors, des volontaires ?   Sur ça demande un petit effort de codage mais après c'est tout bénéf.

Steph3D

  • Capo Regime
  • ***
  • Posts: 399
Re: Surfaces implicites en GLSL
« Reply #9 on: February 26, 2008, 06:46:51 PM »
Ouais, j'en avais même déjà fait en 3D dans C4D pour piloter mes perso directement dans la vue. Suffit de rendre un objet déplaçable à la souris, clamper ça position sur Y par exemple, et faire un pourcentage de ça valeur de position nini/maxi.

Mais, il n'y a absolument rien de productif à faire ça en LUA, interface ou 3d, même en copier-coller à remettre à chaque fois en scène.

Sinon faudrait faire une interface pour Demoniak basé sur les mêmes architectures que 3DS Max ou C4D.

Le principe à la base de ces logiciels, c'est d'avoir un moteur 3D qui gérer déjà tout le principale en 3d et en rendu, avec au coeur un interpréteur de code basic, le maxscript pour max, le cooffee pour c4d, additionné à une interface basique comportant les bases homme/machine. Ensuite ces logiciels ne sont qu'un immense centenaire de plug-ins scripts, chaque boutons et outils n'est autre qu'un déclencheur de script. Dans C4D, il y à plusieurs constructeurs de script, le script bouton, le script menu, le script tag, le script de la timeline, le shader script, etc... et les scripts peuvent interagir entre eux garce à leur id unique, un script boutons, peut appeler un script objet, etc...

Bon maintenant imagine que tu fais une interface très basic, un peu inspiré de rendermonkey, une fenêtre 3D principale, des palettes pour pouvoir poser des boutons, et un workspace avec l'arbre de scène.
Ensuite tout le reste, tu le fais à la C4D, que des boutons est outils fait en en LUA que tu places dans un dossier plug-in-script. En fonction de l'instruction de depart, Demoniak va interpréter le script comme un bouton, un menu, etc... + un p'tit tool pour organiser simplement les scripts sur l'interface et memoriser une organisation personaliser des scripts. Résultat pour la suite, tu pourras coder rapidement des fonctionnalités additionnelles, mais surtout, les utilisateurs pourront rapidement compléter ton taf en LUA, et demoniak avancera bien plus vite. Souvan, c'est les boitent de JV qui font avancé Max, en adaptant des MaxScript à leurs propres besoins, à ...  :med: