Jeux en fausse 3d, Vertex Shader

[Aiekick]

Bonjour,

je fait un jeux 2d en ce moment qui représente des barres en fausse 3d grâce a la technique du 9 slice.



j'utilise des collider de box2d, et je n'utilise donc pas de mesh 3d rendu en 2d

les effets visuels sont vite limités.

comme ce jeux est a destination mobile, et que avec opengl es tout est représenté via des shaders, je me demandait si c'était une bonne idée je generer des barres via le vertex shaders.

ca me permettrai au passage de faire un lighting adaptatif, du flat shading au passage ou du toon shading si besoin.

en fait la question, est, est ce que générer un mesh via le vertex shader comme ce qu'on peut voir sur (https://www.vertexshaderart.com/) (les seul mesh que j'enverrai au gpu est un nombre de vertex) est plus couteux que rendre un mesh calculé par le cpu voir modifié par le cpu entre frame ?

le fragment j'ai l'habitude maintenant mais le vertex je l'ai pas trop expérimente. et je sais pas lequel des deux est le plus couteux sur le fps.

merci pour votre aide

[dragonjoker59]

Tu voudrais envoyer quoi, comme données au vertex shader ?

[Aiekick]

une lsite de points, comme ce que fait (https://www.vertexshaderart.com/), et en fonction de leur id, les organiser et faire une barre 3d. et rendre le shader en Gl_TRIANGLE_FAN ou autre modede rendu

c'est pas le probleme de la realisation, juste la question de savoir si en terme de cout c'est une bonne idée

[dragonjoker59]

Ca dépend, elles changent souvent ces barres ?
Parce que même si c'est le cas, avec l'instanciation hardware, c'est juste une question de mise à jour du buffer de matrices de transformation, généralement.

[Aiekick]

non, dans mon idée, la barre serait figée. et ce suerait le sprite rendu avec le sahder qui bougerait.

mais bon le vertex arrêterait pas d'organiser les points en continu. mais une barre c'est genre 8 point voir 7 si je calcule que les points visible.

si je fait faire du lighing habituel ca me ferait gerer le mesh avec de toute facon un shader pour l'eclairage.

la c'est juste la tranformation du sprite.

j'avais essayer l'autre methode qui consiste a faire un distance field dans un sahder et faire l’éclairage en calculant la normal avec la méthode différentielle.

comme ici avec mon shader : https://www.shadertoy.com/view/XsByzm ou https://www.shadertoy.com/view/4slBDM

mais a chaque fois le shader prenait trop de fps.

donc je me dit que peut etre que le vertex peut aller plus vite. j'aurais du mal a générer des contour doux mais avec un fbo au cul
je peux faire du traitement d'image genre renforcer legerement un blur. le fragment serait simplifié aussi, vu que je connais les normales de ma barre et peux les pousser dans le shader

en fait j'ai vu une appli mobile, dont je me rappelle plus le nom, ou les mec générait 50000 particules juste animées par le vertex et ca tournait super bien.
surement mieux qu'un système de particules par le cpu mème si plus limités.

donc si c'est seulement les transforation matricielle qui couterait, ya moyen d’être rapide, et ca m’autoriserait des modif dynamqiue du mesh mieux qu'avec le cpu non (dans ce cas ou la shape est super simple) ?

[Aiekick]

Rectification, VertexShaderArt envoi une liste d'index genre 0, 1, 2, 3, 4, 5, etc en attribut au GPU et pas une liste de points.

ensuite le mesh est généré en fonction de l'index, c'est encore plus simple que e que je pensais

[Aiekick]

Pas d'idée du cout du Vertex par rapport au fragment ? dans le cas du vertex c'est forcement lié au nombre de point. le fragment est aussi impacté indirectement par le nombre de point j'imagine ?

est ce qu'un mesh généré par le vertex et transformé dans celui ci serait plus rapide à l'affichage qu'un mesh généré par le cpu et transformé dans le cpu et uploadé dans le GPU apres ?

[LittleWhite]

Bonjour,

Pour moi, le vertex shader ne génère pas de mesh (modèle). Il ne fait que traiter les points qui sont en entrée.
Le fragment shader manipule des fragments (comparable à des pixels).
Le geometry shader, lui, est capable de générer des points qui seront traités par la suite dans le vertex shader.

Bref, de manière générale, c'est le CPU qui fournit les sommets au shaders.

[Aiekick]

Salut,

j'ai pas dit le contraire, ok c'est un abus de langage dans mon dernier post, mais si tu lit l'ensemble tiu comprendra que je le sais.
par contre ca ne répond pas a ma question sur le cout.

[LittleWhite]

Soit. Mais du coup, je ne vois pas comment vous voudriez générer des mesh à partir des shaders.

[Aiekick]

c'est expliqué dans le post voir le site https://www.vertexshaderart.com/

[Aiekick]

je ne genere pas un mesh, j'envoi au vertex une liste d'indice numéroté de 0 à Nombre de point. c'est la le seul attribut. en fonction de cet index j'organise les point en mesh.

c'est ce que fait vertexshaderart.

si je générais un mech via le cpu, j'enverrai une liste de point au vertex déjà positionné entre eux, le vertex devant appliquer la transformation de perspective et position.

la j’envoie juste la liste d'indices, et le vertex ferait a la fois la transformation de perceptive + position + posiition de chaque point entre eux.

l'op matricielle est toujours la si ce n'est que j’organise les point en plus dans le vertex. sauf que cette organisation, le cpu le fait qu'une fois dans mon cas, et le shader le ferai a chaque frame.

je sais pas ce qui est le plus couteux en fps. d'ou ma question

[LittleWhite]

Je connais "bien" les sites style shadertoy et compagnie.
Je comprends un peu votre idée, mais, n'ayez pas vu d'application de votre idée dans vertexshaderart, je ne suis pas sur que vous obtiendrez un résultat convenable.
La méthode naïve serait de faire :

Code :

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

1
2
3
4
5
switch(indice)
{
case 0:
    pos = vec2(0,0)
...

Sauf que les conditions, dans les shaders, ça casse certains principe de parallélisation et c'est la base de la rapidité des GPU. Donc, pour les mobiles, je suis perplexe.
Toutefois, il est certain que vous ayez une génération de vos mesh plus intelligente.

Sinon, les principes de shadertoy ou vertexshaderart,c'est bien, pour une boite de travail sur tel ou tel effet, ou encore pour les démo (demoscene), mais dans la réalité, on fait rarement ainsi. Le plus simple sera de bel et bien passé les données du CPU au GPU (c'est ainsi que cela se fait habituellement) et faire autrement, c'est intéressant que pour des cas d'optimisation ou d'impossibilité par le CPU (ce qui est rare).

Ah oui, un shader a aussi une limite (dépendant de la carte graphique) en taille. Sur mobiles, j'imagine que cela sera encore plus restreint que sur PC.

[micka132]

Petite digression, j'ai jamais trop compris comment les effets sont obtenus avec les shaders.
Quand je vois tous les codes sur ce genre de site, je m'amuse à modifier des valeurs par-ci par là, des fois je tombe sur des trucs sympas.
Est-ce que les gars qui font des shaders font pareil ou ils savent ce qu'ils veulent obtenir et surtout comment l'obtenir?

[Aiekick]

OK merci pour ton retour LittleWhite.

me reste plus qu'a tester les deux méthode et faire le comparatif perf. mon cas est très simple je veux juste afficher une barre.

[Aiekick]

Petite digression, j'ai jamais trop compris comment les effets sont obtenus avec les shaders.
Quand je vois tous les codes sur ce genre de site, je m'amuse à modifier des valeurs par-ci par là, des fois je tombe sur des trucs sympas.
Est-ce que les gars qui font des shaders font pareil ou ils savent ce qu'ils veulent obtenir et surtout comment l'obtenir?

dans un shader en tout cas, pour ma part, actuellement, 80% du code est voulu, 20% est du pif. principalement le tuning des variable de forme du df, ou de couleur, ambiance lumineuse etc...
mais l’ossature est voulu.

Sur Shadertoy, tu as des effet assez impressionnant mais tout les utilisateurs ne sont clairement pas dans le même partage. leur code est laissé tel quel et il faut ce débrouiller pour comprendre.
Certains code ont mème l'air intentionnellement offusqué, comme "DR2", son code est très compresse, avec des nom de variables imbitable. il fait de grande réalisation mais l'analyse de son code est très déroutante, en tout cas a mes yeux . ce qui est dommage pour un site de partage de code.

Le maitre des lieu 'IQ" fait des shaders très impressionnant, mais par contre son code c'est autre chose. alors que tu as d'autres codeurs comme "SHANE" qui commentent tout ce qu'il font.

j'ai découvert les shaders fin 2014, au début je modifiait le code au pif essayant de comprendre le fonctionnement, j'étais à 100% pif, puis peu a peu a force d’expérimenter, j'ai fini par de plus en plus comprendre pourquoi je faisais les choses, je savais qu'en faisant tel code, je produirait ci ou ca dans les grandes lignes, il y a toujours une part de tuning pifométrique. maintenant après 400 shaders, il y a un ensemble de technique qui n'ont plus de secret, mais tout un tas d'autres que je ne comprends pas encore complétement, mais a force d’expérimentation je les dompterai aussi.

si tu aimes ça ils faut expérimenter encore et encore. il y a aussi le blog de IQ qui peut aider. mais la encore ses explications sont très basique, il fait des fois des simplification dans son code qu'il n'explique pas du tout, d'autres ou il survole certain elements technique qu'il pense surement evidente, bref, faut vraiment s'acharner quoi

il manque un vrai forum à shadertoy a mon gout.

[LittleWhite]

OK merci pour ton retour LittleWhite.

me reste plus qu'a tester les deux méthode et faire le comparatif perf. mon cas est très simple je veux juste afficher une barre.

Absolument qu'une seule barre ? Dans tout le jeu ?
Dans tous les cas, j'ai bien peur (mais je zappe surement votre technique) que cela se résume en un : if(indice==0) faire_point_haut_gauche

[Aiekick]

une barre par sprite donc par shader oui.

je verrai bien j'ai bon espoir de trouver autre chose comme ce qu'on fait avec le modulo