Bonjour,

J'essai de changer la couleur de mon ciel en fonction de l'heure de la journée.

Pour le moment je fais un setVisible sur plusieurs nodes de skybox (skyboxMatin, skyboxmidi, skybox aprem,skybox  soir,skybox  nuit).
Chaque skybox a la même texture mais de couleur différente (Retouchées sur Gimp).
A chaque événement matin, midi, ... on affiche la skybox qui correspond.
Jusque là tout va bien ...
Le soucis c'est que je préférerais avoir une seule skybox et jouer sur sa coloration au niveau code du genre :

Sauf que çà, bien-sur çà ne marche pas...
Avez-vous une piste sur laquelle je pourrais m'orienter pour faire cela.

Merci

un petit coup de shader: (ici version 1.2)

sinon tu retouche directement la texture (donc garder un double en mémoire)
tu itère sur tous les pixel de ta texture et tu multipli par une couleur de reference

il faut évidement vérifier le type de la texture, ici je te les fait pour A8R8G8B8
dsl je n'ai pas toucher au texture d'irrlicht depusi un moment, il faudras tester

si tu compte ajouter d'autre effets plus complexe et dynamique a ton ciel il vaut mieux un shader

Merci Magun pour tas réponse.
Par contre en ce qui concerne les shaders je suis au niveau 0.
Je ne vois pas comment çà s'utilise, peux tu m'expliquer tas premiére solution stp ?

En attendant, j'ai essayé de tester la deuxième solution qui me parait plus gourmande :

Et çà ne fonctionne pas, mon programme compile mais plante littéralement. J'ai fais une erreur ?

Dernière modification par jonath313 (07-05-2017 02:07:05)

probablement que tes texture sont en rgb et non en rgba comme je tes dit il faut prendre en consideration le type de la texture
je retouche le code d'exemple d'irrlicht et je passe ça

pour ce qui est des shaders tu prend le code d'exemple http://irrlicht.sourceforge.net/docu/example010.html
pas très compliquer, deux fichier (*.vert pour le vertex shader (deformation) et un *.frag pour la rasterisation (~texture rendu))
tu fait un copier coller de l'initialisation -> addHighLevelShaderMaterialFromFiles et tu crée un IShaderConstantSetCallBack pour passer la couleur que tu veux au moment de l'affichage
je vais voir si j'ai le temp de te faire un bout de code

voila un premier example avec un effet sepia

ok super, cette solution fonctionne mais elle est pas trop gourmande en calcule si je l'applique 1 fois par secondes.
Sinon j'avais pensé calculer toutes les couleurs de textures que j'ai besoin dans les init mais çà risque de faire énormément de valeurs maintenues en mémoire non ?
Tu en pense coi toi ?

Dernière modification par jonath313 (07-05-2017 18:11:58)

une fois par seconde ça va, c'est pas si gourmant que sa
tout garder un mémoire, ça depend de la taille de ta texture sauf que si tu génère une fois par second ça fait beaucoup oui
après il y a d'autre solution avec le multi-texturing (une texture de 1px qui donne la couleur superposer par la "vrai"), et/ou modifier la couleurs des vertices de la skybox
mais a la fin un shader ça reste plus simple et ça te permet de faire des effets temps réel ( http://glslsandbox.com/e#39812.0 ), évidement ça a un coup aussi

A ouais carrément il y a des effets bluffants là dessus.

Et moi qui pinaille a faire changer la texture d'une skybox pour faire des nuages ...



Enfin bref çà fonctionne.

Dernière modification par jonath313 (16-05-2017 23:29:58)

Magun,

J'utilise t'as fonction de coloration des pixels et j'ai un petit soucis :
Je colorie l'image plusieurs fois de suite et du coups je repart de la nouvelle coloration pour recolorier la suivante.
Le soucis c'est que quand je me rapproche du noir, il m'est impossible de revenir sur un bleu ciel ...

J'ai alors pensé a avoir 2 fois le même texture, une qu'on ne touche pas qui sert de base pour calculer la nouvelle couleur .
Je ne vois pas comment modifier pour faire cela, j'ai bien essayé de remplacer dans le code mais çà ne fonctionne pas.

tu doit crée une nouvelle texture (irrlicht met en cache quand tu fait getTexture et donc c'est la même que u modifi je suppose)
donc tu utilise rendered.push_back(driver->addTexture(skybox[0]-> getSize(), "skybox_left", skybox[0]-> getColorFormat()))

il te suffi de lock les deux texture, un memcpy de l'original vers la copie, et tu fait ton operation sur les pixel ou les deux a la fois

Ok merci pour ton aide c'est vraiment sympas.
Néanmoins il m'affiche la même texture sur tous les layer ...

Utilisation :

Initialisation :

Il y a quelque chose qui m'échappe ?


... Bon je viens de ruiner tout mon code ...
Après y avoir fait fonctionné, je me suis rendu compte que çà lagait énnormément.
J'ai alors pensé charger les 24 textures x 6 textures correspondants chacune à une heure de la journée pour la coloration du ciel et là je me suis perdu et mon programme est planté.

Visiblement quand je fais le code suivant les textures ne sont pas appliquées correctement :

    skyboxNode->setMaterialTexture(0, SkyTexRender[0]);
    skyboxNode->setMaterialTexture(1, SkyTexRender[1]);
    skyboxNode->setMaterialTexture(2, SkyTexRender[2]);
    skyboxNode->setMaterialTexture(3, SkyTexRender[3]);
    skyboxNode->setMaterialTexture(4, SkyTexRender[4]);
    skyboxNode->setMaterialTexture(5, SkyTexRender[5]);

On ne peut pas réappliquer une texture existante sur une skybox ? (j'ai essayé sur un skydome çà fonctionne)

Je me demande si je devrais pas plutot créer 24 skybox et faire toutes les couleurs à la main sur Gimp parceque là je ne vois vraiment pas comment çà peut se résoudre

Dernière modification par jonath313 (11-05-2017 22:57:22)

ba oui surment, déjà tu crée de nouvelle texture a chaque frame qui ne sont pas nécéssaire
et puis je suis pas sur pour le setMaterialTexture

Ok ton code fonctionne, effectivement çà fait énormément de calculs refaits inutilement car une fois qu'on a calculé toutes les couleurs qu'on a besoin, il faut juste les afficher.

Tu pense que faire deux fonctions du style suivant serait possible:

Du coups c'est la mémoire qu'on va blinder de couleurs de pixel, çà fait quand même 24x256x256x3 = 4,7 millions de float en mémoire ...

Bon avec cette solution visiblement soit je péte le nombre de calculs du cpu soit je péte la mémoire...

Si je fais la seconde possibilité qui est de créer 24 skybox avec 24 textures différentes et d'afficher uniquement celle que je veux a un instant t, aurais-je un gain de performance ?

C'est coi la différence ? Est-ce que le type de mémoire utilisée par le cpu est différent ? (du style solution 1 -> tout en cache et solution 2 tout en RAM ?)

Merci encore pour ton aide.

4718592*6*32/8/1024/1024 = 108Mo (tu as oublier un x6 -> 6 texture par skybox)
bon en terme de coup d'espace mémoire sa va (si je suis pas a coter de la plaue)
tu auras forcement une optimisation coter rendu oui

après évidemeent tu peut faire du multi-threading (6 thread) avec openmp par exemple (#pragma omp parralel for avec une synchro sur le lock/unlock)
tu peut optimiser le pipline de ton cpu avec des calcules sse (diminue le nombre de cycle necessaire par operation)

mais sa ne vaudras jamais un calcule gpu avec un shader, puisque l'architecture materiel "super-scalaire" est prévue pour ça
http://docs.nvidia.com/cuda/cuda-c-prog … second.png

sur gpu tu as ~1024 thread et beaucoup d'operation realiser en 1 cycle
sur cpu tu as ~4       thread et il faut optimiser a la main

ensuite oui tu as beaucoup de mémoire différente (registre, L1, L2, L3, L4, Ram)
sauf que les mémoires sur cpu nécéssite des codes particulier pour être utiliser correctement, sinon c'est l'os qui le fait

en général dans ton code, le system charge une petite zone mémoire que tu veut traiter, tu fait le traiement
et quand tu veut utiliser une adresse qui n'est pas en cache il remplace le cache par la nouvelle zone mémoire pour faire le traitement
c'est ce qu'on apelle un soft-miss, et ça a un cout, la plus part du temp ce cout de transfert n'est pas pris en compte par le cout théorique d'un algo,
sauf que ba en pratique un algo peut être bien plus performant que théoriquement avec ces histoires

mais toi dans ton cas tu en faite tu utilise deux caches, un en ram (image) l'autre en gpu (texture)
en gros tu as un cache en ram pour irrlicht, pourque tu puisse faire tes operations (lock)
et tu as un cache sur le gpu qui est transferer quand tu as fini (unlock)

et comme c'est ce dernier qui est utiliser pour l'affichage tu as bien une optimisation
et que tu as tout mis en cache, tu suprimme le cout calculatoire dans la boucle principal
et tu suprimme le cout de mise en cache et de transfert de tes texture de la ram vers le gpu (qui as aussi un cout non négligable)

ok effectivement la différence est significative. Mais du coups si je charge 24 texture et que je fais un setMaterialTexture et que je me contente d'appliquer la texture que je veux sur mon node j'utilise les ressources CPU ou GPU ?

ok effectivement la différence est significative. Mais du coups si je charge 24 texture et que je fais un setMaterialTexture et que je me contente d'appliquer la texture que je veux sur mon node j'utilise les ressources CPU ou GPU ?

pour construire la mise en cache tu utilise le cpu
apres une fois que tu las tu as 6 affectation c'est raisonable et tu n'utilise pas de ressource cpu ou gpu

Ok super alors j'ai modifié mon code et j'ai commencé le travail de mes 24 images sur Gimp. Je vais essayer de faire une vidéo du résultat quand çà sera fini. J'aimerai être le plus progressif possible sur les changement de couleurs, je vais voir comment je vais faire parce que seulement 24 image pour passer du jaune à un bleu ciel puis orange puis noir çà reste quand même assais violent. Sinon il faut que je crée un shader mais vue que j'y connais rien çà va me prendre du temps.

regarde par la:
https://openclassrooms.com/courses/3d-t … -shaders-2
http://www.lighthouse3d.com/tutorials/g … e-texture/

et par la tu as des examples:
https://github.com/genekogan/Processing … aders/data

si tu as besoin d'aide fait moi signe, moi j'ai un oral a préparer

1)
Je commence tout doucement à regarder les shaders, j'ai récupéré un shader qui fait une surface water, je l'utilise sans soucis, mais par contre niveau performance avec shaders je suis à 50 fps et CPU à 50% et sans shader 60fps et CPU 1% de ressource sur mon jeu.

J'ai essayé de le paramétrer mais je ne trouve rien qui puisse lui faire moins consommer... Je t'envois du code par mail si tu veux regarder.

2)
Petite question, c'est possible de réutiliser les codes de ce site :
http://glslsandbox.com/e#39753.0


Par exemple, si je veux essayer de voir à coi ressemble les shaders de ce site sur mon prog irrlicht :
https://github.com/genekogan/Processing … aders/data
Je dois m'y prendre comment ?

Ok bon courage pour ton oral !

Dernière modification par jonath313 (17-05-2017 19:16:04)

Salut

1) envoie moi du code sur le forum ou par mail ce n'est pas normal la consommation
2) oui tu peut utiliser ce genre de shader (glslsandbox) , tu donne juste ces trois parametres:
        uniform float time;
        uniform vec2 mouse;
        uniform vec2 resolution;
    mais ici c'est du raymarching
    le but c'est de faire croire que l'interrieur est un rendu en lui meme et donc de voir un "monde"
    sur ce que tu voi il y a 2 polygones : un quad devans l'ecran -> bref ce n'est pas sa que tu cherche pour le moment

pour ce qui est du lien github, tu peut aussi les utiliser directement
ensuite encore une fois tu donne simplement les valeurs pour les differents uniforms
et si tu voie un "varying / in" la c'est un peut plus compliquer, c'est un shader "precedent" qui donne la valeur ( geometry -> vertex -> fragment )

Salut !

Ok je vais gratter un peut là dessus, en attendant je t'ai envoyé mon code par mail sur le mail .ovh. Je me suis acharné à changer pleins de paramétres du shader sans que rien n'y fasse, le seul moyen de baisser la conso est de virer le OnAnimate . Tiens moi au jus si tu as bien reçu le mail.

Encore merci.

Juste par curiositer, les charactéristiques de ton pc sont les quelles ?
Je suis étonner que mon pc portable donne de meilleurs performances 60fps 10% cpu c'est pourtant pas une bête

mes première impression c'est que tu utilise beaucoup trop de varaible locales et/ou global utilise d'avantage les classes !
par exemple, ta classe CMapWater n'est pas mal, mais a chaque itération:

    pourquoi ajouter et supprimer une camera ? et pas avoir une camera reserver une bonne fois pour toute ?
    pourquoi la reflection est calculer dans CMapWater et pas CMapCore ?
    pourquoi dereference le device pour avoir le driver et pas les stockers definitivement ?
    bon en terme de performances, c'est mineur

le soucis pour le moment c'est que OnAnimate est apeller pendant le smgr->drawAll or ton CMapWater fait lui même un smgr->drawAll dans le OnAnimate
c'est pour ça je pensse que tu as introduit "IsVisible && Pass", mais que ce passe t-il si tu as deux CMapWater ?

    je pensse donc que tu devraient introduire une nouvelle classe pour la reflection,
    je vais me renseigner sur la docs puisque, j'ai réécris le scene manager donc je ne me souvient plus très bien ...

Cepandant avans de commencer as passer quelques heures, peut-tu m'expliquer un peu ton code ?

ps: pensse a utiliser des dossier pour les sources
      ainssi que des namespace et potentielement un style d'indentation plus "stricte"
      (perso j'ai un style Allman a ma sauce)

Alors, mon pc portable est un peut vieux :
Packard Bell EasyNote LJ65
Intel(R) core(TM)2 Duo CPU  P7450 @ 2.13 GHz   2.13 GHz
RAM 4.00 Go
Système d'exploitation 64 bits
Carte graphique GeForce GT 240M 1Go

Sur le code :
CMapCore    : Gére toutes les autres classes liées à l'envirronnement (application du splat sur le node du terrain, creation de l'ocean, ... ici on géré les taille, les positions, ...)
CMapMeteo  : S'occupe de la partie météo (changement couleur du ciel, du soleil, génération des orages ...)
CMapSplat   : Shader pour le terrain splating
CMapWater  : Shader pour l'ocean

La classe Water incluant le shader a été faite par Copland, à l'époque il m'a juste montré ce qu'était un shader. Je ne maîtrise pas du tout son code ni pourquoi il a fait comme çà.

Je ne serais pas te répondre sur le  pourquoi la reflection est calculer dans CMapWater et pas CMapCore. Visiblement c'est la reflexion qui consomme énormément de ressources.

J'aimerai améliorer ce shader pour qu'il ne consomme moins, mais je ne vois pas trop comment.

ps: en fouillant sur le net, j'ai trouvé l'origine du code :
http://irrlicht.sourceforge.net/forum/v … ;start=225

Dernière modification par jonath313 (21-05-2017 02:04:53)

bon c'est vrais que ton pc n'ai vraiment pas adapter pour dev surtout de la 3D

Pour ce qui est de ton code, essaye de me préparer une démo simple, minimal et propre, qui ne prend que les aspects utiles a ton problème
par ce que moi la, j'arrive dans ton code : entres les différentes erreurs de syntaxe c++ et l'organisation du code ça devient difficile à comprendre et je n'ai pas le temps de tout réécrire:

        1) ta essayer de faire du bump mapping ? pour l'instant je voie un gros "paté" au millieu de la carte avec des couleurs chelou qui ressemble a une texture de normal ... -> ????
        2) trouver pourquoi je n'ai pas d'eau -> ah ! c'est commenter dans CMapCore
        3) bon j'ai de l'eau mais le rendu est horrible  -> erreur de matrice ? mauvais shader ?
        4) pourquoi y a pas de transparence ? a quoi correspond la skydom étrange au millieu ? les particules ?

alors oui ça compile, mais même à l'execution je ne comprend pas ce que je voie, entre ce que ta essayer de faire, et le rendu final je preçois une intension,
mais je ne suis pas sur si c'est voulu, ou des erreurs, ou irrlicht, ou ma machine ...
c'est pas pratique et ça me prend du temps (par exemple un post comme celui-ci me prend environ  1h40 sans parler du code et de la doc)

mais honêtement tu ne pourras pas gagner plus de performance si tu veut garder un rendu "equivalent",
la seul solution c'est évidement d'enlever la reflexion c'est tout, et c'est très gourmant par ce que irrlicht n'est pas adapter

      le soucis vien entre autres du rendu du scenemanager en changent la camera de place
      à chaque itération il a besoin de recalculer les transformations, de retrier les objets par distance et ça deux fois, la ça va
      mais le pire, c'est le terrain, il ne met pas en caches ces informations et ne ce base que sur la distance de la caméra -> donc il doit recalculer le niveau de détail en permanance ce qui est très couteux

donc en fonction de ce que tu veut gagner -> en général on laisse le joueur choisir en fonction des performances de sont pc
    -soit tu fait pas de reflexion,
    -soit tu fait une reflexion uniquement de la skydome (ta météo)
    -soit tu desactive le shader du terrain et tu fait un rendue avec un niveau de détail très bas et tu désactive le rendu des petits objets
    -etc

premier solutions: pour faire ça, je ferais un filtre basé sur ILightManager comme ça ta différent choix (reflexion du skydome, des objets transparent, du shadow, .... etc) et pratique avec OnRenderPassPreRender/OnNodePreRender/OnNodePostRender/OnRenderPassPostRender
deuxième solution: ISceneManager est en fait un CSeneManager qui lui mếmé dérive de ISceneNode, donc du coup tu peut crée un ISceneNodeAnimator qui filtre @Children pour désactiver le rendu de certain node et faire un rendu de la reflexion avans le rendu de la scene "normal"
troixième solution: tu écrit un shader spécial que tu applique partout qui te permet de crée une caméra virtuel différente de irrlicht qui te permetra de changer la position sans impacter les performances dans le cas ici présent une frame sur deux (pour la réflexion)
tu copie donc simplement la matrice de la camera d'irrlicht que tu rebricole au besoin

il y a plien d'autres solutions possibles !

sinon ba il faut ce pencher sur des techniques beaucoup plus avancer avec des optimisations dont tu n'a pas encore le niveau et dont les limites d'irrlicht ne permet pas sans une réécriture partiel