C++

[GLSL-OSG] probleme avec les shaders GLSL sous osg

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : [GLSL-OSG] probleme avec les shaders GLSL sous osg

nmantelier

Bonjour!

je suis entrain de réaliser un application permetant de charger un model 3D et de le visualiser dans un viewer a l'aide de QT et d'osg.
Et certain model on des normal inverser qui sont donc rendu noir par le rendu openGL de base.

Donc Premiere question:
- je voulais passer par les shader GLSL pour calculer moi meme l'éclairage et paré ce problème cela est t'il une bonne idée ? ou puis je faire plus simple avec les parametre de GL_LIGHT et les GL_FRONT and BACK et dans ce cas que faut t'il faire

Deuxieme question :
-Je me suis déja pas mal pencher sur les shader GLSL avant de venir vous embeter, mais j'ai aussi quelque probleme qui rende rallentise enormement mon programme.
-J'ai donc définie mon vertex shader

Code :

varying vec3 normal, eyeVec;
void main(void)
{
normal = gl_NormalMatrix * gl_Normal;
vec3 vVertex = vec3 ( gl_ModelViewMatrix*gl_Vertex);
eyeVec = -vVertex;
gl_Position = ftransform();
}

ainsi que mon fragment shader

Code :

varying vec3 normal , eyeVec;
void main()
{
vec4 diffuse = vec4 (0.0);
vec4 specular = vec4 (0.0);
float att = 0.0;
vec3 norm = normalize ( normal );
vec3 light = vec3( gl_LightSource[0].position.xyz + eyeVec );
light = normalize(light);
vec4 ambient = gl_FrontMaterial.ambient ;// * gl_LightSource[0].ambient;
ambient = normalize ( ambient );
float NdotL = abs(dot ( norm , light ));
diffuse = (gl_FrontMaterial.diffuse * gl_LightSource[0].diffuse * NdotL);// + gl_FrontMaterial.emission;
diffuse = (diffuse + gl_FrontMaterial.emission)/2.0;
vec3 eye = normalize (eyeVec);
vec3 refl = reflect ( -light, norm);
float spec = max( dot ( refl , eye ), 0.0 );
spec = pow( spec , gl_FrontMaterial.shininess );
specular = gl_FrontMaterial.specular * gl_LightSource[0].specular * spec;
float dist = length ( light );
att = 1.0 / (gl_LightSource[0].constantAttenuation + (gl_LightSource[0].linearAttenuation*dist) + (gl_LightSource[0].quadraticAttenuation*dist*dist) );
gl_FragColor = ambient + ( diffuse + specular) * att;
gl_FragColor[3] = gl_FragColor[3]/2.0;
//gl_FragColor = diffuse ;
}

si j'applique mon shader a mon model sur le node racine je me retrouve avec le meme materiau sur tout mon object
ce qui fait que pour parer a ce probleme je fait mon appel de shader sur tout les node avec un materiau.
Mais je pense que normalement je ne devrai pas faire ca.
Et evidament cette methode reduit considérablement ma vitesse d'execution.

je l'appel donc dans mon code (pour le moment) de cette facon

Code :

bool MyOptimizer::ShaderVisitor::loadShaderSource(osg::Shader* obj, const std::string& fileName )
{
std::string fqFileName = osgDB::findDataFile(fileName);
if( fqFileName.length() == 0 )
{
// std::count << "File \"" << fileName << "\" not found." << std::endl;
return false;
}
bool success = obj->loadShaderSourceFromFile( fqFileName.c_str());
if ( !success )
{
//std::count << "Couldn't load file: " << fileName << std::endl;
return false;
}
else
{
return true;
}
}
void MyOptimizer::ShaderVisitor::applyShader(osg::StateSet* pstate)
{
osg::StateAttribute * pstatsAtt;
osg::StateAttribute* stateAtt;
osg::Material* poMat;
bool ok = false;
{
pstatsAtt = pstate->getAttribute(osg::StateAttribute::MATERIAL);
if (pstatsAtt ) // si il y a un materiau
{
stateAtt = pstate->getAttribute(osg::StateAttribute::PROGRAM);
if ( stateAtt )// si il y a déja un program
m_pEclairageProgram = (osg::Program*) stateAtt;
else
m_pEclairageProgram = new osg::Program();
m_pEclairageProgram->setDataVariance(osg::Object::DYNAMIC);
m_pEclairageProgram->setName( "eclairage" );
m_pEclairageVertObj = new osg::Shader( osg::Shader::VERTEX );
m_pEclairageFragObj = new osg::Shader( osg::Shader::FRAGMENT );
ok = loadShaderSource( m_pEclairageVertObj, QFileInfo(qApp->argv()[0]).dir().filePath("data/shaders/MyVertexShader.vert" ).latin1())
&& loadShaderSource( m_pEclairageFragObj, QFileInfo(qApp->argv()[0]).dir().filePath("data/shaders/MyFragmentShader.frag" ).latin1()) ;
}
}
if(ok)
{
m_pEclairageProgram->addShader( m_pEclairageFragObj );
m_pEclairageProgram->addShader( m_pEclairageVertObj );
pstate->setAttributeAndModes(m_pEclairageProgram, osg::StateAttribute::ON);
}
}

Merci d'avance

Message cité 1 fois

Publicité

IrmatDen

Salut,

nmantelier a écrit :

Donc Premiere question:
- je voulais passer par les shader GLSL pour calculer moi meme l'éclairage et paré ce problème cela est t'il une bonne idée ? ou puis je faire plus simple avec les parametre de GL_LIGHT et les GL_FRONT and BACK et dans ce cas que faut t'il faire

GLSL ne te sera pas d'une grande aide dans ce cas. Il n'est apellé que pour ce qui est actuellement dessiné, et si le modèle et/ou le noeud est mal préparé tu ne pourras rien faire. Le plus propre est assurément de t'assurer que les modèles ont les bonnes normales... Sinon, tout dépend de l'usage; tu peux fournir un paramètre flipNormal dans ton code de chargement, et inverser les normales à la mano si ce flag est activé. Tu peux peut-être détecter les modèles dont les normales sont inversées par programmation?
Si aucune de ces solutions ne peut convenir, alors il faudra que tu désactives GL_CULL_FACE, au détriment du temps de rendu...

Pour ta 2nde question, je ne connais pas osg, donc je m'abstiendrais de partir sur n'importe quelle supposition (en espérant déjà ne pas me planter sur ta première question )

nmantelier

Citation :

Le plus propre est assurément de t'assurer que les modèles ont les bonnes normales...

Oui ca aurai ete le plus simple mais le probleme c que je fait un filer de choix de model pour des utilisateur non experimenter qui peuvent charger nimporte quel model. Donc je ne peu pas controler les model d'entrer.

Citation :

Sinon, tout dépend de l'usage; tu peux fournir un paramètre flipNormal dans ton code de chargement, et inverser les normales à la mano si ce flag est activé. Tu peux peut-être détecter les modèles dont les normales sont inversées par programmation?

Cette methode j'ai deja essayer de retourner les normals ( enfin avec osg et non flipnormal) mais le resultat est le meme.
C'est a dire que je ne peu pas définir une normal comme dans le mauvais sens puisque tout dépend de la position de l'obs ;'(.
ce qui fait que j'ai fait une methode automatique qui test les normals sur tout les intersection entre le vecteur de vue et mon model pour ensuite retourner les normals qui sont orienter dans la mauvaise direction.
Pb depend du point de vue (donc corrige que partielement l'objet) et de plus tres tres long puisque il calcul une intersection par pixel donc sur une fenetre 400 300 (voir plus resize) ca fait un certain nombre de calcul.

Citation :

Si aucune de ces solutions ne peut convenir, alors il faudra que tu désactives GL_CULL_FACE, au détriment du temps de rendu...

Cette option est deja active (avec posibilite de la désactiver ou non) mais le résultat ne va pas puisque si je désactive le culling je me retrouve avec des faces noires o milieu de certain model du au calcul d'eclairage OpenGL. D'ou mon idée de partir sur les shader pour parer a ce probleme.

IrmatDen

As-tu un éclairage ambiant ou uniquement des éclairages directionnels? Si le pixel est noir en sortie, il n'est pas éclairé, si? Tu peux peut-être essayer vite fait d'ajouter un spot en direction de la face (enfin, orienté vers la normale de la face).

FORUM HardWare.fr

Programmation

C++

[GLSL-OSG] probleme avec les shaders GLSL sous osg

Sujets relatifs
problème avec flash et Internet explorer [RESOLU]	probleme: ajouter une valeur taper dans un formulaire dans une table
Problème de connection à site web	[Résolu] problème avec Switch et MySQL
Problème de requetes imbriquées	Probleme de configuration PHP pour fonction exec("")
[RESOLU] Problème avec la fonction mail()	probleme egalité de deux double
Problème d'ajout dans un array	Probleme d'utilisation de l'API C de mysql sous linux
Plus de sujets relatifs à : [GLSL-OSG] probleme avec les shaders GLSL sous osg

Page générée en 0.075 secondes