Re: [osg-users] Need explanation about a strange behaviour with RenderBin

2008-11-18 Thread Sukender
Hi Robert,

I think I'll be able to reproduce the artifact I told you days ago (the models 
that flickers) in a much smaller source code, but this time it has nothing to 
do (I guess) with RenderBin nor a .osg model since I did the same with a 
simple box (ShapeDrawable).
I just need a little more time, and an answer to this stupid question: what 
happens if I add a LightSource with just rootNode-addChild(new 
osg::LightSource); when another light source already exists? Mays this cause 
lighting to flicker??? That sounds odd.
Thanks.

-- 
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 I'm already working with a .osg, and it seems that an external parameter 
 causes the problem since both working and not working models look the 
 same in osgViewer. I'll write a small OSG app that shows the problem and post 
 everything. But it may take a while since I don't have much time... I'll post 
 when it's ready.
 'till next time...

 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 Thanks for the openGL explanation.
 Well, I already checked for the normals (I didn't know for the 
 Material/ColorArray, but I knew for this!)... And they're ok (Lighting is 
 on).

 Are you able to export an .osg or .ive file that contains your
 complete but not working model?  Others could then load it to see if
 it's a platform specific issue.

 Robert.
 ___
 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] Need explanation about a strange behaviour with RenderBin

2008-11-10 Thread Robert Osfield
HI Sekender,

The colour array is required when you have the glColorMaterial
enabled, this is driven by osg::Material::setColorMode(), or when
lighting is disabled.  Have a read of OpenGL docs of the affect of
materials, color material and colour arrays on geometries and OpenGL
lighting.

As this has not fixed the issue then have a look to see if lighting is
on, but no normals are attached, again you need normals if you are
using lighting.

Robert.

On Sun, Nov 9, 2008 at 9:12 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi Robert and Jean-Sébastien,

 Thanks for your ideas. My model is an .osg so I know there is a normal array 
 and no texturing, and I manually replaced OPAQUE/DEFAULT.

 You both said that I need a colour array with at least one overall colour.
 Well, can you tell me why I need a colour array? I don't know why the color 
 array from some other drawables will bleed into any other drawable which does 
 not have a color array. Maybe an openGL consideration I'm not aware of...
 Anyway, there is a Material in my object (as posted before), but no colour 
 array. So I added:
  ColorArray 1 {
1.0 1.0 1.0 1.0
  }
  ColorBinding BIND_OVERALL
 in each Geometry in the .osg, just as you both suggested, but it has no 
 effect.

 That's *really really* strange... As maybe noone has enough time for such a 
 problem, I think I'm going to drop it and create a workaround by tweaking the 
 Blender exporter. If I'm wrong (= someone has enough time), just tell me so 
 that I send the code.

 Thank you very much for your help.

 --
 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 Le Fri, 07 Nov 2008 10:51:19 +0100, Robert Osfield [EMAIL PROTECTED] a 
 écrit:

 On Fri, Nov 7, 2008 at 12:14 AM, Sukender [EMAIL PROTECTED] wrote:
 Hi again Robert,

 I confirm that the strange behavior still exist while compiling against the 
 rev 9119 (branch osgWidget-dev).

 I don't have any further suggests beyond my earlier suggestion that
 some vertex data such as normals, texcoord or colour arrays aren't
 assigned to geometries that they should be.  Write you model out to
 .osg and have a look through them.  If you have lighting on then
 you'll need a normal array, if you are use default osg::Material
 you'll need at a colour array with at least one overall colour, if you
 are doing texturing then you'll need texture coords.

 Robert.
 ___
 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] Need explanation about a strange behaviour with RenderBin

2008-11-10 Thread Sukender
Hi Robert,

Thanks for the openGL explanation.
Well, I already checked for the normals (I didn't know for the 
Material/ColorArray, but I knew for this!)... And they're ok (Lighting is on).

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Mon, 10 Nov 2008 10:29:14 +0100, Robert Osfield [EMAIL PROTECTED] a écrit:

 HI Sekender,

 The colour array is required when you have the glColorMaterial
 enabled, this is driven by osg::Material::setColorMode(), or when
 lighting is disabled.  Have a read of OpenGL docs of the affect of
 materials, color material and colour arrays on geometries and OpenGL
 lighting.

 As this has not fixed the issue then have a look to see if lighting is
 on, but no normals are attached, again you need normals if you are
 using lighting.

 Robert.

 On Sun, Nov 9, 2008 at 9:12 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi Robert and Jean-Sébastien,

 Thanks for your ideas. My model is an .osg so I know there is a normal array 
 and no texturing, and I manually replaced OPAQUE/DEFAULT.

 You both said that I need a colour array with at least one overall colour.
 Well, can you tell me why I need a colour array? I don't know why the color 
 array from some other drawables will bleed into any other drawable which 
 does not have a color array. Maybe an openGL consideration I'm not aware 
 of...
 Anyway, there is a Material in my object (as posted before), but no colour 
 array. So I added:
  ColorArray 1 {
1.0 1.0 1.0 1.0
  }
  ColorBinding BIND_OVERALL
 in each Geometry in the .osg, just as you both suggested, but it has no 
 effect.

 That's *really really* strange... As maybe noone has enough time for such a 
 problem, I think I'm going to drop it and create a workaround by tweaking 
 the Blender exporter. If I'm wrong (= someone has enough time), just tell me 
 so that I send the code.

 Thank you very much for your help.

 --
 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 Le Fri, 07 Nov 2008 10:51:19 +0100, Robert Osfield [EMAIL PROTECTED] a 
 écrit:

 On Fri, Nov 7, 2008 at 12:14 AM, Sukender [EMAIL PROTECTED] wrote:
 Hi again Robert,

 I confirm that the strange behavior still exist while compiling against 
 the rev 9119 (branch osgWidget-dev).

 I don't have any further suggests beyond my earlier suggestion that
 some vertex data such as normals, texcoord or colour arrays aren't
 assigned to geometries that they should be.  Write you model out to
 .osg and have a look through them.  If you have lighting on then
 you'll need a normal array, if you are use default osg::Material
 you'll need at a colour array with at least one overall colour, if you
 are doing texturing then you'll need texture coords.

 Robert.
 ___
 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

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Need explanation about a strange behaviour with RenderBin

2008-11-10 Thread Robert Osfield
On Mon, Nov 10, 2008 at 10:06 AM, Sukender [EMAIL PROTECTED] wrote:
 Thanks for the openGL explanation.
 Well, I already checked for the normals (I didn't know for the 
 Material/ColorArray, but I knew for this!)... And they're ok (Lighting is on).

Are you able to export an .osg or .ive file that contains your
complete but not working model?  Others could then load it to see if
it's a platform specific issue.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Need explanation about a strange behaviour with RenderBin

2008-11-09 Thread Sukender
Hi Robert and Jean-Sébastien,

Thanks for your ideas. My model is an .osg so I know there is a normal array 
and no texturing, and I manually replaced OPAQUE/DEFAULT.

You both said that I need a colour array with at least one overall colour.
Well, can you tell me why I need a colour array? I don't know why the color 
array from some other drawables will bleed into any other drawable which does 
not have a color array. Maybe an openGL consideration I'm not aware of...
Anyway, there is a Material in my object (as posted before), but no colour 
array. So I added:
  ColorArray 1 {
1.0 1.0 1.0 1.0
  }
  ColorBinding BIND_OVERALL
in each Geometry in the .osg, just as you both suggested, but it has no effect.

That's *really really* strange... As maybe noone has enough time for such a 
problem, I think I'm going to drop it and create a workaround by tweaking the 
Blender exporter. If I'm wrong (= someone has enough time), just tell me so 
that I send the code.

Thank you very much for your help.

-- 
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Fri, 07 Nov 2008 10:51:19 +0100, Robert Osfield [EMAIL PROTECTED] a écrit:

 On Fri, Nov 7, 2008 at 12:14 AM, Sukender [EMAIL PROTECTED] wrote:
 Hi again Robert,

 I confirm that the strange behavior still exist while compiling against the 
 rev 9119 (branch osgWidget-dev).

 I don't have any further suggests beyond my earlier suggestion that
 some vertex data such as normals, texcoord or colour arrays aren't
 assigned to geometries that they should be.  Write you model out to
 .osg and have a look through them.  If you have lighting on then
 you'll need a normal array, if you are use default osg::Material
 you'll need at a colour array with at least one overall colour, if you
 are doing texturing then you'll need texture coords.

 Robert.
 ___
 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] Need explanation about a strange behaviour with RenderBin

2008-11-07 Thread Jean-Sébastien Guay

Hi Sukender,

However, the first problem still exists and *exists on others configs* (!): changing from OPAQUE_BIN to DEFAULT_BIN removes a strange behaviour. 


You mentioned earlier in the thread that your objects did not have a 
color array. This is exactly what would happen when that's the case, 
because the color array from some other drawables will bleed into any 
other drawable which does not have a color array. And the colors will 
change depending on what is culled in the current frame, which is why 
the color of your objects seem to change like that at seemingly random 
moments.


So just give your objects a color array of size 1, white color, and 
BIND_OVERALL. Even if your objects use materials for their colors, they 
need a color array.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Need explanation about a strange behaviour with RenderBin

2008-11-07 Thread Robert Osfield
On Fri, Nov 7, 2008 at 12:14 AM, Sukender [EMAIL PROTECTED] wrote:
 Hi again Robert,

 I confirm that the strange behavior still exist while compiling against the 
 rev 9119 (branch osgWidget-dev).

I don't have any further suggests beyond my earlier suggestion that
some vertex data such as normals, texcoord or colour arrays aren't
assigned to geometries that they should be.  Write you model out to
.osg and have a look through them.  If you have lighting on then
you'll need a normal array, if you are use default osg::Material
you'll need at a colour array with at least one overall colour, if you
are doing texturing then you'll need texture coords.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Need explanation about a strange behaviour with RenderBin

2008-11-06 Thread Robert Osfield
Hi Sukender,

My guess is that the problem is not related to the bin management,
rather missing vertex colour or vertex normals on some of the
geometry.  If it's not this then perhaps you have transparency issues.

Robert.

On Thu, Nov 6, 2008 at 12:34 AM, Sukender [EMAIL PROTECTED] wrote:
 Hi,

 I found a strange behavior, and I would like someone to explain, if possible.
 In an .osg model (exported from Blender) the rendering_hint OPAQUE_BIN 
 line in some StateSets causes my model to be lit in a funky way. It is 
 sometimes correctly lit, sometimes not (looks like diffuse got away). In my 
 app, I have:
 - a pStateset-setRenderBinDetails(11,RenderBin) used to render HUD 
 components,
 - and a pStateset-setRenderBinDetails(-1, RenderBin) elsewhere for my sky 
 sphere.

 But if I change OPAQUE_BIN to DEFAULT_BIN, then my model is correctly 
 lit...
 Can someone explains what happened?
 Thanks.

 Sincerely,

 --
 Sukender
 ___
 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] Need explanation about a strange behaviour with RenderBin

2008-11-06 Thread Sukender
Robert,

Thank you for your answer. I've checked what you pointed. But my exported model:
- Has no coulour array (just a material)
- Has 196 vertex and 196 normals (so probably no missing normals)
- And has no transparency

I really don't understand. Any idea?

Note that I load the model using the cache (ReaderWriter::Options::CACHE_ALL) 
and that I duplicate it (in order to modify it without affecting the cached 
object) by using:
  myGroup = new osg::Group(*loadedCachedModel, osg::CopyOp::DEEP_COPY_OBJECTS | 
osg::CopyOp::DEEP_COPY_NODES);
I also tried DEEP_COPY_AL but that has no effect. Anyway, I'm not sure it is 
related to my problem...

I seen that on top of the geodes, there are MatrixTransforms with a stange 
StateSet { 0xba1 ON } line (Exactly the same in each MatrixTransform), but 
removing it didn't change anything.


If you want, the geode data looks like:
Geode {
  UniqueID Corps_geode
  DataVariance DYNAMIC
  name Corps_geode
  cullingActive TRUE
  num_drawables 1
  Geometry {
StateSet {
  UniqueID Corps_stateset
  DataVariance STATIC
  rendering_hint OPAQUE_BIN
  GL_BLEND OFF
  Material {
DataVariance STATIC
ColorMode OFF
diffuseColor 0.30011921 0.5 0.0 1.0
specularColor 1.0 1.0 1.0 1
emissionColor 0.111620302463 0.186033830047 0.0 1
shininess 24.5960784314
  }
}
VertexArray 196 {...}
NormalBinding PER_VERTEX
NormalArray 196 {...}
PrimitiveSets 2 {...}
  }
}


-- 
Sukender


Le Thu, 06 Nov 2008 10:26:49 +0100, Robert Osfield [EMAIL PROTECTED] a écrit:

 Hi Sukender,

 My guess is that the problem is not related to the bin management,
 rather missing vertex colour or vertex normals on some of the
 geometry.  If it's not this then perhaps you have transparency issues.

 Robert.

 On Thu, Nov 6, 2008 at 12:34 AM, Sukender [EMAIL PROTECTED] wrote:
 Hi,

 I found a strange behavior, and I would like someone to explain, if possible.
 In an .osg model (exported from Blender) the rendering_hint OPAQUE_BIN 
 line in some StateSets causes my model to be lit in a funky way. It is 
 sometimes correctly lit, sometimes not (looks like diffuse got away). In my 
 app, I have:
 - a pStateset-setRenderBinDetails(11,RenderBin) used to render HUD 
 components,
 - and a pStateset-setRenderBinDetails(-1, RenderBin) elsewhere for my sky 
 sphere.

 But if I change OPAQUE_BIN to DEFAULT_BIN, then my model is correctly 
 lit...
 Can someone explains what happened?
 Thanks.

 Sincerely,

 --
 Sukender

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Need explanation about a strange behaviour with RenderBin

2008-11-06 Thread Robert Osfield
Hi Sukender,

Strange artefacts indeed, but I still don't think they are render bin related.

There looks to be an issue with state leakage, such as with my
suggestion of missing vertex attributes, or perhaps now more likely
given the screenshot a driver bug.

What OS/hardware/drivers are you using?  Try other machines if you
have access to them.

Do you have an custom OpenGL code that might be causing problems?

Robert.

On Thu, Nov 6, 2008 at 3:16 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi,

 That becomes stranger and stranger: now that I display another exported 
 model, some of my objects have back face culling problems as the moment the 
 object is added to the scene graph. Moreover, I have a HeightField which has 
 inverted culling on HALF of it! I joined before-after screenshots to this 
 message.
 If anyone has an idea of the problem, please tell me!
 (I use OSG 2.7.1)

 --
 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 Le Thu, 06 Nov 2008 12:50:28 +0100, Sukender [EMAIL PROTECTED] a écrit:

 Robert,

 Thank you for your answer. I've checked what you pointed. But my exported 
 model:
 - Has no coulour array (just a material)
 - Has 196 vertex and 196 normals (so probably no missing normals)
 - And has no transparency

 I really don't understand. Any idea?

 Note that I load the model using the cache 
 (ReaderWriter::Options::CACHE_ALL) and that I duplicate it (in order to 
 modify it without affecting the cached object) by using:
   myGroup = new osg::Group(*loadedCachedModel, 
 osg::CopyOp::DEEP_COPY_OBJECTS | osg::CopyOp::DEEP_COPY_NODES);
 I also tried DEEP_COPY_AL but that has no effect. Anyway, I'm not sure it is 
 related to my problem...

 I seen that on top of the geodes, there are MatrixTransforms with a stange 
 StateSet { 0xba1 ON } line (Exactly the same in each MatrixTransform), but 
 removing it didn't change anything.


 If you want, the geode data looks like:
 Geode {
   UniqueID Corps_geode
   DataVariance DYNAMIC
   name Corps_geode
   cullingActive TRUE
   num_drawables 1
   Geometry {
 StateSet {
   UniqueID Corps_stateset
   DataVariance STATIC
   rendering_hint OPAQUE_BIN
   GL_BLEND OFF
   Material {
 DataVariance STATIC
 ColorMode OFF
 diffuseColor 0.30011921 0.5 0.0 1.0
 specularColor 1.0 1.0 1.0 1
 emissionColor 0.111620302463 0.186033830047 0.0 1
 shininess 24.5960784314
   }
 }
 VertexArray 196 {...}
 NormalBinding PER_VERTEX
 NormalArray 196 {...}
 PrimitiveSets 2 {...}
   }
 }

 ___
 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] Need explanation about a strange behaviour with RenderBin

2008-11-06 Thread Sukender
Hi again Robert,

I don't have any custom OpenGL code.
Configuration : Core 2 Duo, integrated chipset (Intel 82945G), Windows XP 32 
bits SP3.
Driver is the factory default one, and I never saw such effets in any other 
app.
The first bug (strange lightning) has been seen on another configuration, but 
not he last one yet (I will test ASAP and inform you).
I'm going to try linking against OSG 2.7.4 (or maybe the wxWidget branch as I 
already compiled half of it), but I think that won't change anything.
The problem may not be render-bin related, but I still don't understand... What 
a strange effect!
Thank you for taking time for this.

-- 
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Thu, 06 Nov 2008 16:35:17 +0100, Robert Osfield [EMAIL PROTECTED] a écrit:

 Hi Sukender,

 Strange artefacts indeed, but I still don't think they are render bin related.

 There looks to be an issue with state leakage, such as with my
 suggestion of missing vertex attributes, or perhaps now more likely
 given the screenshot a driver bug.

 What OS/hardware/drivers are you using?  Try other machines if you
 have access to them.

 Do you have an custom OpenGL code that might be causing problems?

 Robert.

 On Thu, Nov 6, 2008 at 3:16 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi,

 That becomes stranger and stranger: now that I display another exported 
 model, some of my objects have back face culling problems as the moment the 
 object is added to the scene graph. Moreover, I have a HeightField which has 
 inverted culling on HALF of it! I joined before-after screenshots to this 
 message.
 If anyone has an idea of the problem, please tell me!
 (I use OSG 2.7.1)

 --
 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 Le Thu, 06 Nov 2008 12:50:28 +0100, Sukender [EMAIL PROTECTED] a écrit:

 Robert,

 Thank you for your answer. I've checked what you pointed. But my exported 
 model:
 - Has no coulour array (just a material)
 - Has 196 vertex and 196 normals (so probably no missing normals)
 - And has no transparency

 I really don't understand. Any idea?

 Note that I load the model using the cache 
 (ReaderWriter::Options::CACHE_ALL) and that I duplicate it (in order to 
 modify it without affecting the cached object) by using:
   myGroup = new osg::Group(*loadedCachedModel, 
 osg::CopyOp::DEEP_COPY_OBJECTS | osg::CopyOp::DEEP_COPY_NODES);
 I also tried DEEP_COPY_AL but that has no effect. Anyway, I'm not sure it 
 is related to my problem...

 I seen that on top of the geodes, there are MatrixTransforms with a stange 
 StateSet { 0xba1 ON } line (Exactly the same in each MatrixTransform), 
 but removing it didn't change anything.


 If you want, the geode data looks like:
 Geode {
   UniqueID Corps_geode
   DataVariance DYNAMIC
   name Corps_geode
   cullingActive TRUE
   num_drawables 1
   Geometry {
 StateSet {
   UniqueID Corps_stateset
   DataVariance STATIC
   rendering_hint OPAQUE_BIN
   GL_BLEND OFF
   Material {
 DataVariance STATIC
 ColorMode OFF
 diffuseColor 0.30011921 0.5 0.0 1.0
 specularColor 1.0 1.0 1.0 1
 emissionColor 0.111620302463 0.186033830047 0.0 1
 shininess 24.5960784314
   }
 }
 VertexArray 196 {...}
 NormalBinding PER_VERTEX
 NormalArray 196 {...}
 PrimitiveSets 2 {...}
   }
 }

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Need explanation about a strange behaviour with RenderBin

2008-11-06 Thread Robert Osfield
Hi Sukender,

Intel drivers are known for being rather poor, so it may well just be
driver bug, I would certainly check for updated drivers.  Also get
yourself a cheap Nvidia card an pop it in the machine, you may well
get quite a different experience and will give you a sanity test.

Robert.

On Thu, Nov 6, 2008 at 4:24 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi again Robert,

 I don't have any custom OpenGL code.
 Configuration : Core 2 Duo, integrated chipset (Intel 82945G), Windows XP 32 
 bits SP3.
 Driver is the factory default one, and I never saw such effets in any other 
 app.
 The first bug (strange lightning) has been seen on another configuration, but 
 not he last one yet (I will test ASAP and inform you).
 I'm going to try linking against OSG 2.7.4 (or maybe the wxWidget branch as I 
 already compiled half of it), but I think that won't change anything.
 The problem may not be render-bin related, but I still don't understand... 
 What a strange effect!
 Thank you for taking time for this.

 --
 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 Le Thu, 06 Nov 2008 16:35:17 +0100, Robert Osfield [EMAIL PROTECTED] a 
 écrit:

 Hi Sukender,

 Strange artefacts indeed, but I still don't think they are render bin 
 related.

 There looks to be an issue with state leakage, such as with my
 suggestion of missing vertex attributes, or perhaps now more likely
 given the screenshot a driver bug.

 What OS/hardware/drivers are you using?  Try other machines if you
 have access to them.

 Do you have an custom OpenGL code that might be causing problems?

 Robert.

 On Thu, Nov 6, 2008 at 3:16 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi,

 That becomes stranger and stranger: now that I display another exported 
 model, some of my objects have back face culling problems as the moment the 
 object is added to the scene graph. Moreover, I have a HeightField which 
 has inverted culling on HALF of it! I joined before-after screenshots to 
 this message.
 If anyone has an idea of the problem, please tell me!
 (I use OSG 2.7.1)

 --
 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 Le Thu, 06 Nov 2008 12:50:28 +0100, Sukender [EMAIL PROTECTED] a écrit:

 Robert,

 Thank you for your answer. I've checked what you pointed. But my exported 
 model:
 - Has no coulour array (just a material)
 - Has 196 vertex and 196 normals (so probably no missing normals)
 - And has no transparency

 I really don't understand. Any idea?

 Note that I load the model using the cache 
 (ReaderWriter::Options::CACHE_ALL) and that I duplicate it (in order to 
 modify it without affecting the cached object) by using:
   myGroup = new osg::Group(*loadedCachedModel, 
 osg::CopyOp::DEEP_COPY_OBJECTS | osg::CopyOp::DEEP_COPY_NODES);
 I also tried DEEP_COPY_AL but that has no effect. Anyway, I'm not sure it 
 is related to my problem...

 I seen that on top of the geodes, there are MatrixTransforms with a stange 
 StateSet { 0xba1 ON } line (Exactly the same in each MatrixTransform), 
 but removing it didn't change anything.


 If you want, the geode data looks like:
 Geode {
   UniqueID Corps_geode
   DataVariance DYNAMIC
   name Corps_geode
   cullingActive TRUE
   num_drawables 1
   Geometry {
 StateSet {
   UniqueID Corps_stateset
   DataVariance STATIC
   rendering_hint OPAQUE_BIN
   GL_BLEND OFF
   Material {
 DataVariance STATIC
 ColorMode OFF
 diffuseColor 0.30011921 0.5 0.0 1.0
 specularColor 1.0 1.0 1.0 1
 emissionColor 0.111620302463 0.186033830047 0.0 1
 shininess 24.5960784314
   }
 }
 VertexArray 196 {...}
 NormalBinding PER_VERTEX
 NormalArray 196 {...}
 PrimitiveSets 2 {...}
   }
 }

 ___
 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] Need explanation about a strange behaviour with RenderBin

2008-11-06 Thread Sukender
Hi again Robert,

I confirm that the strange behavior still exist while compiling against the rev 
9119 (branch osgWidget-dev).

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
 
 
Le Thu, 06 Nov 2008 17:28:53 +0100, Robert Osfield [EMAIL PROTECTED] a écrit:
 
 Hi Sukender,

 Intel drivers are known for being rather poor, so it may well just be
 driver bug, I would certainly check for updated drivers.  Also get
 yourself a cheap Nvidia card an pop it in the machine, you may well
 get quite a different experience and will give you a sanity test.

 Robert.

 On Thu, Nov 6, 2008 at 4:24 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi again Robert,

 I don't have any custom OpenGL code.
 Configuration : Core 2 Duo, integrated chipset (Intel 82945G), Windows XP 32 
 bits SP3.
 Driver is the factory default one, and I never saw such effets in any 
 other app.
 The first bug (strange lightning) has been seen on another configuration, 
 but not he last one yet (I will test ASAP and inform you).
 I'm going to try linking against OSG 2.7.4 (or maybe the wxWidget branch as 
 I already compiled half of it), but I think that won't change anything.
 The problem may not be render-bin related, but I still don't understand... 
 What a strange effect!
 Thank you for taking time for this.

 --
 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 Le Thu, 06 Nov 2008 16:35:17 +0100, Robert Osfield [EMAIL PROTECTED] a 
 écrit:

 Hi Sukender,

 Strange artefacts indeed, but I still don't think they are render bin 
 related.

 There looks to be an issue with state leakage, such as with my
 suggestion of missing vertex attributes, or perhaps now more likely
 given the screenshot a driver bug.

 What OS/hardware/drivers are you using?  Try other machines if you
 have access to them.

 Do you have an custom OpenGL code that might be causing problems?

 Robert.

 On Thu, Nov 6, 2008 at 3:16 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi,

 That becomes stranger and stranger: now that I display another exported 
 model, some of my objects have back face culling problems as the moment 
 the object is added to the scene graph. Moreover, I have a HeightField 
 which has inverted culling on HALF of it! I joined before-after 
 screenshots to this message.
 If anyone has an idea of the problem, please tell me!
 (I use OSG 2.7.1)

 --
 Sukender
 PVLE - Lightweight cross-platform game engine - 
 http://pvle.sourceforge.net/


 Le Thu, 06 Nov 2008 12:50:28 +0100, Sukender [EMAIL PROTECTED] a écrit:

 Robert,

 Thank you for your answer. I've checked what you pointed. But my exported 
 model:
 - Has no coulour array (just a material)
 - Has 196 vertex and 196 normals (so probably no missing normals)
 - And has no transparency

 I really don't understand. Any idea?

 Note that I load the model using the cache 
 (ReaderWriter::Options::CACHE_ALL) and that I duplicate it (in order to 
 modify it without affecting the cached object) by using:
   myGroup = new osg::Group(*loadedCachedModel, 
 osg::CopyOp::DEEP_COPY_OBJECTS | osg::CopyOp::DEEP_COPY_NODES);
 I also tried DEEP_COPY_AL but that has no effect. Anyway, I'm not sure it 
 is related to my problem...

 I seen that on top of the geodes, there are MatrixTransforms with a 
 stange StateSet { 0xba1 ON } line (Exactly the same in each 
 MatrixTransform), but removing it didn't change anything.


 If you want, the geode data looks like:
 Geode {
   UniqueID Corps_geode
   DataVariance DYNAMIC
   name Corps_geode
   cullingActive TRUE
   num_drawables 1
   Geometry {
 StateSet {
   UniqueID Corps_stateset
   DataVariance STATIC
   rendering_hint OPAQUE_BIN
   GL_BLEND OFF
   Material {
 DataVariance STATIC
 ColorMode OFF
 diffuseColor 0.30011921 0.5 0.0 1.0
 specularColor 1.0 1.0 1.0 1
 emissionColor 0.111620302463 0.186033830047 0.0 1
 shininess 24.5960784314
   }
 }
 VertexArray 196 {...}
 NormalBinding PER_VERTEX
 NormalArray 196 {...}
 PrimitiveSets 2 {...}
   }
 }
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org