Re: [osg-users] QT and ModularEmitter (((
Hi Gammer I v' the same trouble few day ago, i solved it by add -DQT_NO_EMIT to the compilation flags. cheers, Antonin Linares Максим Гаммер a écrit : Hi List. Problem "QT and OSG ModularEmitter" make ... ... /usr/local/include/osgParticle/ModularEmitter:89: error: expected unqualified-id before ‘double’ ... ModularEmitter, line 89 : virtual void emit(double dt); emit - preprocessor word in QT (slot, signal, emit ...) How can I make my project? ) -- Gammer Maxim TSOGU, Tyumen, Russia ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Solved] ViewDependentShadow and material
Hi Wojtek,
Great thanks, it's exactly my problem and your piece of code just solve
it. \o/ \o/ \o/
So guy if you use shadow shader and you have random material switch take
a look of the Wojtek post.
Best regard.
Antonin
Hi Antonin,
Sounds like your issue might be related to GL_LIGHTING or
GL_MATERIAL_COLOR mode usage. GL_COLOR_MATERIAL selects source of
diffuse/ambient/emissive/specular term. Its either taken from material
or from color set in geometries. This fixed pipeline attribute is not
passed to Vertex Shaders as an uniform so shader coders may need to
make workarounds for it.
We had such problem with bunch of models using GL_COLOR_MATERIAL set
to AMBIENT_AND_DIFFUSE in which case actual ambient and diffuse
material values where not set in material but assumed tio be taken
from glColor. If they were not set in material they often were quite
random so they were causing the issues. We overcame this by approach
similar to your option number 2. We ran a visitor which found if
material set per drawable used GL_COLOR_MATERIAL with colors from
drawable and we cloned such material replacing its colors with these
from drawable color array. There should be a problem with drawables
with more than one color (colors set per vertex or per primitive) but
fortunately we did not have such cases. Below is source of the
function used by this visitor. Its inputs are drawable StateSet and
Color taken from drawable color array.
bool SubstituteColorMaterial( osg::StateSet * ss, osg::Vec4 color )
{
if( !ss ) return false;
osg::Material * material =
dynamic_cast
( ss->getAttribute( osg::StateAttribute::MATERIAL ) );
if ( !material || material->getColorMode() == osg::Material::OFF )
return false;
osg::ref_ptr< osg::Material >
newOsgMaterial = dynamic_cast
( material->clone(osg::CopyOp::SHALLOW_COPY) );
switch( newOsgMaterial->getColorMode() )
{
case osg::Material::AMBIENT_AND_DIFFUSE:
newOsgMaterial->setAmbient( osg::Material::FRONT_AND_BACK,
color );
newOsgMaterial->setDiffuse( osg::Material::FRONT_AND_BACK,
color );
break;
case osg::Material::AMBIENT:
newOsgMaterial->setAmbient( osg::Material::FRONT_AND_BACK,
color );
break;
case osg::Material::DIFFUSE:
newOsgMaterial->setDiffuse( osg::Material::FRONT_AND_BACK,
color );
break;
case osg::Material::SPECULAR:
newOsgMaterial->setSpecular( osg::Material::FRONT_AND_BACK,
color );
break;
case osg::Material::EMISSION:
newOsgMaterial->setEmission( osg::Material::FRONT_AND_BACK,
color );
break;
}
newOsgMaterial->setColorMode( osg::Material::OFF );
ss->setAttribute( newOsgMaterial.get() );
return true;
}
Maybe this helps a little,
Wojtek
- Original Message - From: "Antonin Linares"
To: "OpenSceneGraph Users"
Sent: Tuesday, May 05, 2009 4:23 PM
Subject: Re: [osg-users] ViewDependentShadow and Lod
Hi Wojtek,
Thanks for the vertex shader trick, but in this way i gate pure black
shadow and terrible artifact on my shadow caster model.
Actually i can see two way to solve my lighting problem.
-Make a vertex shader who can compute lighting with glMaterial and
glColor both.
but it's seem to me that it's impossible without using an uniform
switch.
-Use a nodeVisitor to replace vertex color attribute by a similar
material.
But here i dont now how to check actual color mode:
void setMatNodeVisitor::apply(osg::Node& node)
{
osg::Geode* geode = node.asGeode();
if(geode)
{
for(int i =0; i < geode->getNumDrawable(); i++)
{
osg::Material* mat = (osg::Matrial*)
geode->getDrawable(i)->getStateSet();
if(mat){
if(mat.getColorMode() == osg::Material::OFF)
//no material off in my scene ...
}
}
}
}
Wojciech Lewandowski a écrit :
Hi Antonin,
I am glad you had this sorted it out. You may try to replace shaders
with yours. Its possible to set only fragment shaders and use fixed
pipeline for vertices by setting MainVertexShader and
ShadowVertexShader to NULL.
Cheers,
Wojtek
- Original Message - From: "Antonin Linares"
To: "OpenSceneGraph Users"
Sent: Monday, May 04, 2009 4:11 PM
Subject: Re: [osg-users] ViewDependentShadow and Lod
Again,
Please don't care of my previous message, i'm wrong.
Some part of my terrain database use pure glColor(), so the shader
miss compute this part of database.
Sorry all.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-user
Re: [osg-users] ViewDependentShadow and Lod
Hi Wojtek,
Thanks for the vertex shader trick, but in this way i gate pure black
shadow and terrible artifact on my shadow caster model.
Actually i can see two way to solve my lighting problem.
-Make a vertex shader who can compute lighting with glMaterial and
glColor both.
but it's seem to me that it's impossible without using an uniform
switch.
-Use a nodeVisitor to replace vertex color attribute by a similar material.
But here i dont now how to check actual color mode:
void setMatNodeVisitor::apply(osg::Node& node)
{
osg::Geode* geode = node.asGeode();
if(geode)
{
for(int i =0; i < geode->getNumDrawable(); i++)
{
osg::Material* mat = (osg::Matrial*)
geode->getDrawable(i)->getStateSet();
if(mat){
if(mat.getColorMode() == osg::Material::OFF)
//no material off in my scene ...
}
}
}
}
Wojciech Lewandowski a écrit :
Hi Antonin,
I am glad you had this sorted it out. You may try to replace shaders
with yours. Its possible to set only fragment shaders and use fixed
pipeline for vertices by setting MainVertexShader and
ShadowVertexShader to NULL.
Cheers,
Wojtek
- Original Message ----- From: "Antonin Linares"
To: "OpenSceneGraph Users"
Sent: Monday, May 04, 2009 4:11 PM
Subject: Re: [osg-users] ViewDependentShadow and Lod
Again,
Please don't care of my previous message, i'm wrong.
Some part of my terrain database use pure glColor(), so the shader
miss compute this part of database.
Sorry all.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ViewDependentShadow and Lod
Again, Please don't care of my previous message, i'm wrong. Some part of my terrain database use pure glColor(), so the shader miss compute this part of database. Sorry all. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ViewDependentShadow and Lod
Hi all,
Finally i find where is the lighting problem, it's the specular
computation. Here's the change i made in the main vertex shader:
void DirectionalLight(in int
i,\n"
in vec3
normal,\n"
inout vec4
ambient,\n"
inout vec4
diffuse,\n"
inout vec4
specular)\n"
{
\n"
" float nDotVP; // normal . light
direction\n"
" float nDotHV; // normal . light half
vector\n"
" float pf; // power
factor\n"
"
\n"
" nDotVP = max(0.0,
dot(normal,\n"
"
normalize(vec3(gl_LightSource[i].position;\n"
" nDotHV = max(0.0,
dot(normal,\n"
"
vec3(gl_LightSource[i].halfVector)));\n"
"
\n"
"//CHANGE HERE
\n"
" // if (nDotVP ==
0.0)\n"
" // pf =
0.0;
\n"
" //
else
\n"
" // pf = pow(nDotHV,
gl_FrontMaterial.shininess); \n"
"//CHANGE TO
\n"
" if (nDotVP >
0.0) \n"
"pf = pow(nDotHV,
gl_FrontMaterial.shininess); \n"
"
else
\n"
" pf = 0.0;
\n"
"//END CHANGE
\n"
" ambient += gl_LightSource[i].ambient;
\n"
" diffuse += gl_LightSource[i].diffuse * nDotVP;
\n"
" specular += gl_LightSource[i].specular *
pf;\n"
"
\n"
"}
\n"
There are similarly problem in spot and point light.
I'm not understand exactly why, maybe equality check on float ?
best regard
Hi Wojtek,
Yes reference frame is set in StandardShadowMap, i didn't notice it
yesterday.
I made test and i found something new:
It's not a lod problem but a Lighting problem (geometry is good).
Actually i take a look in StandardShadowMap shader, if you have any idea.
[...]
Find where is the problem, gl_Color is miss compute (for my terrain
db) by the main vertex shader, by using a constant one in fragment i
solve
my lighing problem. I' m going to make my own vertex shader to keep
the lighting computation.
Thanks
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ViewDependentShadow and Lod
Hi Wojtek, Yes reference frame is set in StandardShadowMap, i didn't notice it yesterday. I made test and i found something new: It's not a lod problem but a Lighting problem (geometry is good). Actually i take a look in StandardShadowMap shader, if you have any idea. [...] Find where is the problem, gl_Color is miss compute (for my terrain db) by the main vertex shader, by using a constant one in fragment i solve my lighing problem. I' m going to make my own vertex shader to keep the lighting computation. Thanks Hi Antonin, As far as I remember, ABSOLUTE_RF_INHERIT_VIEWPOINT reference frame for Shadow map camera is set in osgShadow::StandardShadowMap and should be inherited and used by all derived classes including DebugShadowMap, MinimalCull/DrawBounds and all three LispSM flavours. So it looks like your problems may be caused by something else... We have been using LispSM with LODs and we have not seen major artifacts since this addition of ABSOLUTE_RF_INHERIT_VIEWPOINT which happened after discussion you referenced. Maybe you are using LODs switched by pixel sizes (not viewpoint distance ) ? I have not tested this scenario but I would guess that it would depend on shadow map resolution. Its also possible that LispSM skewed projection matrix may somehow cause wrong results in pixel size LOD computations. Sorry to say that but you caught me at bad moment. I am going on a 5 day trip tomorrow and will be offline till next Tuesday. If you are unable to solve the issue by then, send some more info and maybe we would come up with some fresh idea... Cheers, Wojtek Lewandowski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quaternion problem
Hi Steven,
Maybe, i'm not clear, I want to keep the current yaw angle, and change
pitch and roll by the terrain normal.
So i use getRotate to find my previous yaw angle, like you Steven, i
thinks thats not the solution. Maybe i need to store this yaw angle in
custom data.
Hi JP i use osg 2.8 an getRotate seem to returns angle and vector.
Antonin Linares
Steven Saunderson a écrit :
Hi Antonin,
I may be getting way out of my depth here but when I saw your problem this
morning it looked very similar to a problem I had just recently.
Looking at your original post :
Antonin Linares wrote:
//get height and normal under the tank
osg::Vec3f pos =
lsi->getFirstIntersection()->getWorldIntersectionPoint();
osg::Vec3f normal =
lsi->getFirstIntersection()->getWorldIntersectionNormal();
//Set up height
pat->setPosition(pos);
All looks fine so far
Antonin Linares wrote:
//Set up alignment with terrain
float rotation;
osg::Vec3f origine;
pat->getAtitude().getRotate(rotation, origine);
if((origine*normal) != 0){
osg::Quat corect;
corect.makeRotation(origine, normal);
pat->setAtitude(corect);
I don't understand why you have the getAtitude() here. It will return a quat
and the .getRotate will convert the value into an angle and vector. But what
quat value is it converting ?
What happens if you always calculate "corect" as you are doing and then apply
"rot" in the setAtitude call (i.e. pat->setAtitude (rot * corect) ) ?
//Set up alignment with terrain
float rotation;
osg::Vec3f origine (0,0,1);
osg::Quat corect;
corect.makeRotation(origine, normal);
// I'm not sure where you get rotation from ??
osg::Quat rot(rotation, origine);
pat->setAtitude(rot*corect);
I hope this helps or entices someone more knowledgeable to assist here.
-- Steven Saunderson
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=8598#8598
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quaternion problem
Thanks Steven
Yes i have, but i get something very strange (rot * correction) ==
(correction * rot)
Also actually i made:
//Set up alignment with terrain
float rotation;
osg::Vec3f origine;
pat->getAtitude().getRotate(rotation, origine);
if((osg::Vec3f(0,0,1)*normal) != 0){
osg::Quat corect;
corect.makeRotation(osg::Vec3f(0,0,1), normal);
osg::Quat rot(rotation, osg::Vec3f(0,0,1));
pat->setAtitude(rot * corect); //Yes rot must be applied last
}
Here the tank is well aligned with terrain, but now the rotation angle
are increase each frame, so the tank rotate with.
Antonin Linares
Steven Saunderson a écrit :
Have you tried : pat->setAtitude(rot*corect); ?
I'm wondering if the factor that should be applied last (i.e. rot) should be
first in the multiply here.
-- Steven Saunderson
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=8557#8557
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Quaternion problem
Hi osg users
I use an intersectionVisitor to place tank model on my terrain
i made something like that:
[...]
if(lsi->containIntersection())
{
//get height and normal under the tank
osg::Vec3f pos =
lsi->getFirstIntersection()->getWorldIntersectionPoint();
osg::Vec3f normal =
lsi->getFirstIntersection()->getWorldIntersectionNormal();
//Set up height
pat->setPosition(pos);
//Set up alignment with terrain
float rotation;
osg::Vec3f origine;
pat->getAtitude().getRotate(rotation, origine);
if((origine*normal) != 0){
osg::Quat corect;
corect.makeRotation(origine, normal);
pat->setAtitude(corect);
//here it's cool my tank was perfectly aligned with terrain but i
loose it's orientation
//so i test to do
osg::Quat rot(rotation, normal);
pat->setAtitude(corect*rot); //the tank was well oriented but
no more aligned with my terrain
}
}
I looking for any idea to make my tank aligned with the terrain but
keeping it's previous orientation.
Thanks
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
