Re: [osg-users] Dae plugin, textures not visible (related to Geode/Geometry changes ?)

2014-11-24 Thread Luc Frauciel
Hi Robert,

I've tried your modification and it works fine.
Thanks,

Luc


De : osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] De la part 
de Robert Osfield
Envoyé : vendredi 21 novembre 2014 18:26
À : OpenSceneGraph Users
Objet : Re: [osg-users] Dae plugin, textures not visible (related to 
Geode/Geometry changes ?)

Hi Luc,

I haven't tested it yet but the following is what I'm thinking of (file also 
attached), could you try it out and let me know how you get on.
Was about to fire off this email and wait for feedback, but have decided to go 
ahead and check this change into svn/trunk.  If there are issues we can amend 
it.

Robert.


Index: src/osg/CopyOp.cpp
===
--- src/osg/CopyOp.cpp  (revision 14485)
+++ src/osg/CopyOp.cpp  (working copy)
@@ -33,7 +33,6 @@
 }

 COPY_OP( Object,   DEEP_COPY_OBJECTS )
-COPY_OP( Node, DEEP_COPY_NODES )
 COPY_OP( StateSet, DEEP_COPY_STATESETS )
 COPY_OP( Image,DEEP_COPY_IMAGES )
 COPY_OP( Uniform,  DEEP_COPY_UNIFORMS )
@@ -49,6 +48,16 @@
 return const_castReferenced*(ref);
 }

+Node* CopyOp::operator() (const Node* node) const
+{
+if (!node) return 0;
+
+const Drawable* drawable = node-asDrawable();
+if (drawable) return operator()(drawable);
+else if (_flagsDEEP_COPY_NODES) return osg::clone(node, *this);
+else return const_castNode*(node);
+}
+
 StateAttribute* CopyOp::operator() (const StateAttribute* attr) const
 {
 if (attr  _flagsDEEP_COPY_STATEATTRIBUTES)
[X]http://www.1spatial.com





[http://www.1spatial.com/wp-content/themes/1spatial/images/youtube.png]http://www.youtube.com/user/1SpatialGroup
 [http://www.1spatial.com/wp-content/themes/1spatial/images/facebook.png] 
https://www.facebook.com/1Spatial  
[http://www.1spatial.com/wp-content/themes/1spatial/images/linkedIn.png] 
http://www.linkedin.com/company/1spatial  
[http://www.1spatial.com/wp-content/themes/1spatial/images/twitter.png] 
http://www.twitter.com/1spatial



1Spatial France SAS

Les informations contenues dans cet e-mail sont confidentielles et uniquement 
adressées au destinataire. Les opinions qui y sont exprimées peuvent être 
celles de l'auteur et ne représentent pas nécessairement celles du Groupe 
1Spatial. Cet e-mail a été scanné et est garanti sans aucun virus. 1Spatial 
France SAS est une société de droit français, membre du Groupe 1Spatial. Siège 
Social : Immeuble AXEO2, 23-25 Avenue Aristide Briand, 94110 Arcueil, France. 
RCS CRETEIL 334 416 336
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Dae plugin, textures not visible (related to Geode/Geometry changes ?)

2014-11-21 Thread Luc Frauciel
Hi,

I've dug a little into osg ::clone operator and I think it is broken for Geodes 
since the Geode/Geometry change.
If a cloning is done on a Geode with the flag DEEP_COPY_DRAWABLES,
The clone function of osg::Group will be called, wich is correct to my 
understanding, but for childs (Drawables), the osg::Node cloning operator is 
called instead of Drawable/Geometry one.


The offending code :
osg::Geode *pCopiedOsgGeode = 
static_castosg::Geode*(pOsgGeode-clone(osg::CopyOp::DEEP_COPY_DRAWABLES));

pCopiedOsgGeode is NOT a deep copy of pOsgGeode

Robert, do you have an idea how it should work or be repaired ?

Luc

De : osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] De la part 
de Luc Frauciel
Envoyé : lundi 17 novembre 2014 10:52
À : osg-users@lists.openscenegraph.org
Objet : [osg-users] Dae plugin, textures not visible (related to Geode/Geometry 
changes ?)

Hi,

I've got a set of collada files that don't load anymore (no textures), see 
attachment.
I've tracked the problem down to daeReader.cpp / void 
daeReader::processBindMaterial
The geometry is cached and then texture coordinates arrays are copied to a 
clone geometry.
However, before copying, a call to getTexCoordArrayList().clear() is done on 
the clone geometry.
What is strange is that this call also clear the texcoordarray from the cached 
geometry, which invalidate the code following.
The cloned geometry is supposed to be a deep copy of cached geometry but share 
the same pointers.
I don't know if the deep copy mechanism is broken or what but something wrong 
here.

I'm using OSG 3.2.
Command line : osgviewer CubeSport.dae -O daeUseSequencedTextureUnits
This was working a few month ago (before I updated to the new Geode/Geometry 
logic).

Are you able to reproduce the problem ?
Do someone know the logic/expected behavior behind this cloning mechanism ?

 Regards

Luc Frauciel
Responsable RD
RD Manager

T +33 (0)1 71 33 01 48

http://1spatial.com/fr/event/club-des-utilisateurs-francophones-1spatial[Image
 supprimée par 
l'expéditeur.]http://1spatial.com/fr/event/club-des-utilisateurs-francophones-1spatialhttp://1spatial.com/fr/event/club-des-utilisateurs-francophones-1spatial










1Spatial France SAS

Les informations contenues dans cet e-mail sont confidentielles et uniquement 
adressées au destinataire. Les opinions qui y sont exprimées peuvent être 
celles de l'auteur et ne représentent pas nécessairement celles du Groupe 
1Spatial. Cet e-mail a été scanné et est garanti sans aucun virus. 1Spatial 
France SAS est une société de droit français, membre du Groupe 1Spatial. Siège 
Social : Immeuble AXEO2, 23-25 Avenue Aristide Briand, 94110 Arcueil, France. 
RCS CRETEIL 334 416 336

[X]http://www.1spatial.com





[http://www.1spatial.com/wp-content/themes/1spatial/images/youtube.png]http://www.youtube.com/user/1SpatialGroup
 [http://www.1spatial.com/wp-content/themes/1spatial/images/facebook.png] 
https://www.facebook.com/1Spatial  
[http://www.1spatial.com/wp-content/themes/1spatial/images/linkedIn.png] 
http://www.linkedin.com/company/1spatial  
[http://www.1spatial.com/wp-content/themes/1spatial/images/twitter.png] 
http://www.twitter.com/1spatial



1Spatial France SAS

Les informations contenues dans cet e-mail sont confidentielles et uniquement 
adressées au destinataire. Les opinions qui y sont exprimées peuvent être 
celles de l'auteur et ne représentent pas nécessairement celles du Groupe 
1Spatial. Cet e-mail a été scanné et est garanti sans aucun virus. 1Spatial 
France SAS est une société de droit français, membre du Groupe 1Spatial. Siège 
Social : Immeuble AXEO2, 23-25 Avenue Aristide Briand, 94110 Arcueil, France. 
RCS CRETEIL 334 416 336
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Handling of Vendor extra in Collada (dae) Reader/Writer

2013-09-17 Thread Luc Frauciel
Hi osg-users,

I have to support a type of Collada that contain specific vendor extra 
profiles.
For the moment, osg dae reader handle them with some hardcoded vendor 
specific profiles : GOOGLEEARTH, SCEI ,OpenSceneGraph
However, I've got the feeling that each Collada producer defines its own 
profile adapted to its needs.

What would be the proper way to handle this ?

- hardcode a newer vendor profile and submit it to OSG ?
- rewrite my own ReaderWriter from the current one ? (but this would 
require a bunch of  virtual on current one)
- add a form of callback mechanism to osg dae plugin to support custom 
extras handling ?
- another brillant idea ?

Regards,

Luc



Luc FRAUCIEL 







Département Produits/RD


Tél. : +33 1 71 33 01 48

E-mail : luc.frauc...@star-apic.com
Website : www.star-apic.com




   





 




image/gifimage/pngimage/pngimage/pngimage/jpegimage/pngimage/jpeg___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] adding barrel distortion for stereoscopic rendering in Oculus Rift head set

2013-03-21 Thread Luc Frauciel
Hi Christian,

I still haven't managed to get my hands on an Oculus Rift, but as soon as 
KickStarter rewards get delivered, I will work on this point.
There is already some kind of specific distortions implemented in OSG for 
dome projection (osgdistortion example).
From what I've heard, the distorsion shader for the Rift is quite easy to 
implement.

  Luc - VRGeek and Rift fan



De :
Christian Buchner christian.buch...@gmail.com
A :
OpenSceneGraph Users osg-users@lists.openscenegraph.org
Date:
20/03/2013 19:32
Objet :
[osg-users] adding barrel distortion for stereoscopic rendering in Oculus 
Rift head set
Envoyé par :
osg-users-boun...@lists.openscenegraph.org



Hi,

has anyone here started to add some Oculus Rift support as an additional 
stereoscopic mode of OSG?

It would require some barrel predistortion (with the exact parameters yet 
to be announced) and requires rendering at 60 FPS with vsync, side by 
side. 1280×800 resolution. It's probably a good idea to render each eye to 
an FBO and perform the barrel distortion in a pixel shader. Maybe the 
rendering to FBO needs to be done at a slightly higher resolution because 
the barrel distortion leads to a higher effective resolution at the center 
of the image. And you certainly don't want to see any aliasing there.

Christian
___
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] [osgPlugins] DDS Texture vanish withLINEAR_MIPMAP_LINEAR

2012-10-30 Thread Luc Frauciel
I've seen that kind of problems on AMD/ATI boards.

   Luc



De :
Robert Osfield robert.osfi...@gmail.com
A :
osg-users@lists.openscenegraph.org
Date:
30/10/2012 15:27
Objet :
Re: [osg-users] [osgPlugins] DDS Texture vanish with LINEAR_MIPMAP_LINEAR
Envoyé par :
osg-users-boun...@lists.openscenegraph.org



Hi Tim,

Try running your app on a system with a difference graphics
card/driver, there is a change the issue is a driver bug.

Robert.

On 30 October 2012 09:18, Tim Rambau tim.ram...@dlr.de wrote:
 Hi,

 I have a terrain model with 1024x1024 DXT1 textures. Using a min filter 
with LINEAR_MIPMAP_LINEAR the textures are gone, changing only this filter 
to LINEAR everything is back again. The textures contain 1 main image and 
10 mipmaps...

 Any ideas?

 Thanks  Cheers,
 Tim.

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=50877#50877





 ___
 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] Tesselator and output primitives

2012-10-11 Thread Luc Frauciel
Hi Albert,

I've answered the same question on this list a few weeks ago.
A search in the archives should get you to it.
And yes, it's possible, natively.

  Luc



De :
Aurelien Albert aurelien.alb...@alyotech.fr
A :
osg-users@lists.openscenegraph.org
Date:
10/10/2012 20:29
Objet :
[osg-users] Tesselator and output primitives
Envoyé par :
osg-users-boun...@lists.openscenegraph.org



Hi,

I use tesselator to generate a geometry from a LINE_LOOP primitive.

The tesselator output give me a TRIANGLES_FAN primitive which seems to be 
correct.

Now I would like to get the tesselator output as TRIANGLES primitive.

Is there anyway to control the primitive type built by the tesselator ?

Or is there any OSG tool function / visitor that can convert TRIANGLES_FAN 
to TRIANGLES ?

Thank you!

Cheers,
Aurelien

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=50551#50551





___
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] RTT camera and nested camera

2012-08-31 Thread Luc Frauciel
Hi everybody,

I'm stuck with a problem when trying to render to RTT camera.

I want to render a scene to a RTT camera (the way osgposter does it).
In my scene, I've got a osgephemeris SkyNode.
To avoid culling problems, the skynode is rendered with it's own Camera 
( see : http://osdir.com/ml/OpenSceneGraph-Users/2009-04/msg01170.html the 
suggestion of J-S Guay)

While rendering directly to frame buffer my scene is ok  : scene + skydome
While rendering to a RTT camera, the objects below the Skydome camera are 
not rendered in the texture.
I've tried to play with different parameters (render order etc...) but I 
don't understand how it work (or should work).

During the traversal of a scene rendered through a RTT camera, how the 
nested cameras behave ?
Do they automatically acquire the RTT camera target ? Do I have to set up 
something ?

  Luc


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


Re: [osg-users] RTT camera and nested camera

2012-08-31 Thread Luc Frauciel
Thanks Sergey, that was what I feared.

It will not be easy to get these rendertarget  parameters at the nested 
camera level.
I have searched for a way to 'copy' the render target from a camera in 
parent nodepath, but the Camera class does not seem to be taylored for 
that,
I will probably use a visitor to propagate RTT parameters to nested 
cameras.

   Luc 



De :
Sergey Polischuk pol...@yandex.ru
A :
OpenSceneGraph Users osg-users@lists.openscenegraph.org
Date:
31/08/2012 16:04
Objet :
Re: [osg-users] RTT camera and nested camera
Envoyé par :
osg-users-boun...@lists.openscenegraph.org



 
 
Hi

During the traversal of a scene rendered through a RTT camera, how the 
nested cameras behave ?
 
Same as usual, render to framebuffer by default. 
Do they automatically acquire the RTT camera target ? Do I have to set up 
something ?
 
Yes, you should specify rendertarget if you dont want to get result on 
framebuffer.
You should explicitly attach same rtt to both your cameras.
 
Cheers.
31.08.2012, 16:48, Luc Frauciel luc.frauc...@star-apic.com:
Hi everybody,

I'm stuck with a problem when trying to render to RTT camera.

I want to render a scene to a RTT camera (the way osgposter does it).
In my scene, I've got a osgephemeris SkyNode.
To avoid culling problems, the skynode is rendered with it's own Camera 
( see : http://osdir.com/ml/OpenSceneGraph-Users/2009-04/msg01170.html the 
suggestion of J-S Guay)

While rendering directly to frame buffer my scene is ok  : scene + skydome
While rendering to a RTT camera, the objects below the Skydome camera are 
not rendered in the texture.
I've tried to play with different parameters (render order etc...) but I 
don't understand how it work (or should work).

During the traversal of a scene rendered through a RTT camera, how the 
nested cameras behave ?
Do they automatically acquire the RTT camera target ? Do I have to set up 
something ?

  Luc

=
___
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] Example using osgUtil::Tessellator to only get back GL_TRIANGLE primitives?

2012-07-23 Thread Luc Frauciel
Hi Preet,

I recently submitted a modification to Tesselator that allows to do that.

You have to modify the underlying gluTesselator Callbacks to use 
GLU_TESS_EDGE_FLAG
Here is an example.

void CALLBACK noStripCallback(GLboolean userData)
{
}

#include osg/GLU
class CustomTessellator : public osgUtil::Tessellator
{
public:
  virtual void beginTessellation()
  {
reset();

if (!_tobj) _tobj = osg::gluNewTess();
 
osg::gluTessCallback(_tobj, GLU_TESS_VERTEX_DATA, 
(osg::GLU_TESS_CALLBACK) osgUtil::Tessellator::vertexCallback);
osg::gluTessCallback(_tobj, GLU_TESS_BEGIN_DATA, 
(osg::GLU_TESS_CALLBACK) osgUtil::Tessellator::beginCallback);
osg::gluTessCallback(_tobj, GLU_TESS_END_DATA, 
(osg::GLU_TESS_CALLBACK) osgUtil::Tessellator::endCallback);
osg::gluTessCallback(_tobj, 
GLU_TESS_COMBINE_DATA,(osg::GLU_TESS_CALLBACK) 
osgUtil::Tessellator::combineCallback);
osg::gluTessCallback(_tobj, GLU_TESS_ERROR_DATA, 
(osg::GLU_TESS_CALLBACK) osgUtil::Tessellator::errorCallback);
//Here is the New TESS Callback :
//Force to only creates triangles
osg::gluTessCallback(_tobj, GLU_TESS_EDGE_FLAG, 
(osg::GLU_TESS_CALLBACK) noStripCallback);
if (tessNormal.length()0.0) osg::gluTessNormal(_tobj, tessNormal.x(), 
tessNormal.y(), tessNormal.z());
osg::gluTessBeginPolygon(_tobj,this); 
  }

};

Luc



De :
Preet prismatic.proj...@gmail.com
A :
OpenSceneGraph Users osg-users@lists.openscenegraph.org
Date:
22/07/2012 07:14
Objet :
[osg-users] Example using osgUtil::Tessellator to only get back 
GL_TRIANGLE primitives?
Envoyé par :
osg-users-boun...@lists.openscenegraph.org



Is there anyway to use osgUtil::Tessellator to only get back
GL_TRIANGLE primitives? With the available examples, the tessellator
adds/changes the primitive sets of the osg::Geometry passed to it into
multiple triangle fans, triangle strips, and triangles. I want my
geometry to just consist of GL_TRIANGLE draw calls.

Also, there's another method of using the tessellator where it looks
like you manually define contours / add vertices, etc, but I can't
figure out how to use it. Could anyone provide a small example, or
maybe point out what I'm doing wrong:

osgUtil::Tessellator myTess;
myTess.setTessellationNormal(offsetVec);
myTess.beginTessellation();
myTess.beginContour();
for(int i=0; i  areaVx-size(); i++)   {
osg::Vec3 * someVertexPtr = someVertex;
myTess.addVertex(someVertexPtr);
}
myTess.endContour();
myTess.endTessellation();

std::cout  Num Contours   myTess.getContours().size();//
gives me a zero
___
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] Using osgShadow with osgEphemeris (or alternatives)

2012-04-05 Thread Luc Frauciel
Hi Gath,

I use osgShadow (VDSM) and osgEphemeris in conjunction, and they seem to 
work together.
However, there are known problems related to osgEphemeris which are 
broader :

- The Skydome in osgEphemeris can be very large, causing unwanted 
interaction with culling/ nearfar planes.
 see 
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-April/026772.html
long thread, but with useful hints towards solutions
 - I remember problems with clearing operation, but probably related to 
solutions to the previous problem.

If the only thing that you want is a skydome, osgEphemeris is an overkill 
for that.
You probably still have to consider the culling problems introduced by 
skydomes (a scene with a skydome is artificially big).

  Luc



De :
Garth D garthy_...@entropicsoftware.com
A :
OpenSceneGraph Users osg-users@lists.openscenegraph.org
Date:
05/04/2012 15:34
Objet :
[osg-users] Using osgShadow with osgEphemeris (or alternatives)
Envoyé par :
osg-users-boun...@lists.openscenegraph.org




Hi everyone,

In OpenSceneGraph 3.0.1, is there a known fundamental incompatibility 
between osgShadow and osgEphemeris (circa 4/4/12)? I am using osgShadow 
(namely ShadowTexture), with both animated and static models, and 
started to work in osgEphemeris in order to provide a more interesting 
sky than a single static colour.

One thing I noticed is that whenever osgEphemeris is working, the 
location of cast shadows shifted around significantly, and they are 
nowhere near the objects that are casting them (ie. the shadows were 
very clearly incorrect). Depending on the view angle, they also bounced 
around to different locations. I noticed that animated models no longer 
cast shadows, but that may have just been a symptom specific to my 
particular case.

In case the node mask was causing a problem (for osgShadow I am using 1 
to cast, and 2 to receive), I tried different values. Setting it to zero 
caused the EphemerisModel to vanish (is this normal?), and to four left 
it there, but didn't help the shadow situation. In any case, when the 
EphemerisModel was working, the shadows were shifted around and incorrect.

I've tried disabling lighting on the model (via state sets and 
GL_LIGHTING), as well as attaching it to different nodes, but I don't 
seem to have struck upon the correct combination.

Interestingly enough, if I use either on their own, they work fine. 
Shadows work fine, without ephemeris models; and ephemeris models seem 
to produce good results if I turn off shadows.

Can anyone suggest any things to try, confirm there are known problems, 
or otherwise?

On a side note, I began to investigate osgEphemeris in the first case as 
I needed a simple sky. My requirements are pretty low, as the sky is 
merely decorative, so I don't necessarily *have* to use osgEphemeris 
specifically. I am wondering what the best approach to sky creation in 
OSG 3.0.1 would be? The potential solutions I ran into were:

- Use the sky code osghangglide as a base/inspiration.
- Find a spare $1.5k and use SilverLining (a bit overkill for my 
application at present!)
- Use skydome.osgt from the OpenSceneGraph data dir (I gave this a 
shot, but I wasn't able to successfully get it working correctly with 
the rest of my app)
- Build up my own geometry, customising the texture coordinates as I 
need (the most flexible approach, but the most time consuming, and the 
most pointless if someone has done it already), and grab or buy some 
existing sky textures to match the expected texture.
- Use osgEphemeris, which is what I'm looking at above.

Are there other solutions that I should be exploring as well, or in 
preference?

Garth

___
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] Using osgShadow with osgEphemeris (or alternatives)

2012-04-05 Thread Luc Frauciel
May I ask re your usage of osgShadow and osgEphemeris, which shadow 
technique you were using?

VDSM (View Dependant Shadow Map), with custom shaders for multi-texturing, 
transparency, fog, etc...
I exclude the skydome of osgephemeris from culling (cf thread) and disable 
depth test on it.
VDSM works quite well for non human-like viewpoints (near the ground, 
looking towards horizon).

   Luc 



De :
Garth D garthy_...@entropicsoftware.com
A :
OpenSceneGraph Users osg-users@lists.openscenegraph.org
Date:
05/04/2012 16:15
Objet :
Re: [osg-users] Using osgShadow with osgEphemeris (or alternatives)
Envoyé par :
osg-users-boun...@lists.openscenegraph.org




Hi Luc,

Thanks for the fast reply on that one. I hadn't considered checking out 
interactions with the clip planes. I've had to manually override their 
calculation in a past project, so this could be worth checking out. 
Incidentally, I did shrink the ephemeris model via setSkyDemoRadius a 
fair bit before starting, but the presence of the geometry is likely 
going to move the clip planes around.

May I ask re your usage of osgShadow and osgEphemeris, which shadow 
technique you were using?

And yes, osgEphemeris is probably overkill ultimately. ;)

Garth

On 05/04/12 23:30, Luc Frauciel wrote:
 Hi Gath,

 I use osgShadow (VDSM) and osgEphemeris in conjunction, and they seem to
 work together.
 However, there are known problems related to osgEphemeris which are
 broader :

 - The Skydome in osgEphemeris can be very large, causing unwanted
 interaction with culling/ nearfar planes.
 see
 
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-April/026772.html

 long thread, but with useful hints towards solutions
 - I remember problems with clearing operation, but probably related to
 solutions to the previous problem.

 If the only thing that you want is a skydome, osgEphemeris is an
 overkill for that.
 You probably still have to consider the culling problems introduced by
 skydomes (a scene with a skydome is artificially big).

 Luc


 De :   Garth D garthy_...@entropicsoftware.com
 A :OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Date:  05/04/2012 15:34
 Objet :[osg-users] Using osgShadow with osgEphemeris (or 
alternatives)
 Envoyé par :   osg-users-boun...@lists.openscenegraph.org


 




 Hi everyone,

 In OpenSceneGraph 3.0.1, is there a known fundamental incompatibility
 between osgShadow and osgEphemeris (circa 4/4/12)? I am using osgShadow
 (namely ShadowTexture), with both animated and static models, and
 started to work in osgEphemeris in order to provide a more interesting
 sky than a single static colour.

 One thing I noticed is that whenever osgEphemeris is working, the
 location of cast shadows shifted around significantly, and they are
 nowhere near the objects that are casting them (ie. the shadows were
 very clearly incorrect). Depending on the view angle, they also bounced
 around to different locations. I noticed that animated models no longer
 cast shadows, but that may have just been a symptom specific to my
 particular case.

 In case the node mask was causing a problem (for osgShadow I am using 1
 to cast, and 2 to receive), I tried different values. Setting it to zero
 caused the EphemerisModel to vanish (is this normal?), and to four left
 it there, but didn't help the shadow situation. In any case, when the
 EphemerisModel was working, the shadows were shifted around and 
incorrect.

 I've tried disabling lighting on the model (via state sets and
 GL_LIGHTING), as well as attaching it to different nodes, but I don't
 seem to have struck upon the correct combination.

 Interestingly enough, if I use either on their own, they work fine.
 Shadows work fine, without ephemeris models; and ephemeris models seem
 to produce good results if I turn off shadows.

 Can anyone suggest any things to try, confirm there are known problems,
 or otherwise?

 On a side note, I began to investigate osgEphemeris in the first case as
 I needed a simple sky. My requirements are pretty low, as the sky is
 merely decorative, so I don't necessarily *have* to use osgEphemeris
 specifically. I am wondering what the best approach to sky creation in
 OSG 3.0.1 would be? The potential solutions I ran into were:

 - Use the sky code osghangglide as a base/inspiration.
 - Find a spare $1.5k and use SilverLining (a bit overkill for my
 application at present!)
 - Use skydome.osgt from the OpenSceneGraph data dir (I gave this a
 shot, but I wasn't able to successfully get it working correctly with
 the rest of my app)
 - Build up my own geometry, customising the texture coordinates as I
 need (the most flexible approach, but the most time consuming, and the
 most pointless if someone has done it already), and grab or buy some
 existing sky textures to match the expected texture.
 - Use osgEphemeris

Re: [osg-users] Methods to improve large scene shadows with ViewDependentShadowMap

2012-03-12 Thread Luc Frauciel
Hi Wang Rui,

I'm also working on very large urban areas with  
osgShadow::ViewDependentShadowMap.
I encounter the same problems.
I also had to use some kind of PCF to reduce some inacceptable noise (huge 
'Moiré' effects).
I tried to use PSSM recently introduced in ViewDependentShadowMap to cope 
with aliasing effects with no success :
- PSSM procuce some strange artifacts on half of the view when mixing the 
two shadow textures (each half shadow  is ok)
- the separation line is not adapted to a 'human walking' point of view 
(too far in the scene)

I doubt that changing the depth of the shadow map will produce noticable 
effects : numerical instabilities will exist, whatever the depth.

At what angles did you encounter innacceptable alisasing issues ?
For views that are not near tangent to the ground plane, the results I got 
seems ok. 
Is your problem global or limited to certain points of view ?
Is your target resolution way beyond the resolution of the shadow map 
(1*1) per ex ?

   Luc



De :
Wang Rui wangra...@gmail.com
A :
OpenSceneGraph Users osg-users@lists.openscenegraph.org
Date:
12/03/2012 10:39
Objet :
[osg-users] Methods to improve large scene shadows with 
ViewDependentShadowMap
Envoyé par :
osg-users-boun...@lists.openscenegraph.org



Hi all,

I'm currently working on an example that uses 
osgShadow::ViewDependentShadowMap for generating dynamic shadows on a 
large area of buildings. It can work correctly on a huge city which is 
created by CityEngine and then converted to OSG styled scene graph. It 
also generates aliasing issues as expected, but I'm still looking for some 
good solutions to reduce such problem and want to discuss them in this 
thread if possible. My test program and a simple shader file can be found 
in attachement.

I've already read a similar topic at:
http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2011-August/053731.html

And I believe it is necessary to apply some filters on the shadow map (the 
test shader file simply uses PCF here) and increase the texture resolution 
as well. But for huge scene, a 4096-sized RTT texture will be a heavy 
burden. So I wonder if there are some more methods to choose, for example, 
is it possible to change the internal format of the texture to 
GL_DEPTH_COMPONENT32 to improve the shadow comparision process?

Meanwhile, is it necessary to perform a screen space blurring to reduce 
the aliasing effect? It is a serious problem for my scene now as I can't 
use a very high resolution. Could anyone suggest some other possible 
methods on the post-processing level? To be honest, the 
ViewDependentShadowMap is the best shadow solution for me at present as it 
is easy to be integrated with custom shaders and embedded into a deferred 
shading framework.

The test city models are about 180MB. If any of you think it important for 
digging into the problem. I'd like to share them freely, too, as I believe 
these automatically generated models should not have any copyrights with 
them. :-)

Cheers,

Wang Rui
[pièce jointe screen_space_shadow.cpp supprimée par Luc 
Frauciel/STAR-APIC] [pièce jointe shadowRenderer.frag supprimée par Luc 
Frauciel/STAR-APIC] ___
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] Slow rendering with displaylist.

2012-02-28 Thread Luc Frauciel
Hi Martin,

Be aware that for some combinaison of driver/hardware, VBO just don't work 
properly.
I've encoutered the case on  some Intel/ATI chipsets. 
A simple terrain created with VPB couldn't be loaded.
With VBO OFF, everything was OK.

Be also aware that if you use small geometries, there is a high overhead 
with VBO at initialization. 

It could be a good idea to make VBO you default implementation, but don't 
forget to have fallbacks when things will go wrong (especially if you have 
no control over target hardware)

http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2011-July/052968.html
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-August/015543.html

   Luc



De :
Martin Großer grosser.mar...@gmx.de
A :
OpenSceneGraph Users osg-users@lists.openscenegraph.org
Date:
28/02/2012 13:01
Objet :
Re: [osg-users] Slow rendering with displaylist.
Envoyé par :
osg-users-boun...@lists.openscenegraph.org



Hello,

thanks to you, it was very helpful. Now I will only use VBOs.

Greetings,
Martin


 Original-Nachricht 
 Datum: Tue, 28 Feb 2012 12:44:15 +0100
 Von: Daniel Trstenjak daniel.trsten...@science-computing.de
 An: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Betreff: Re: [osg-users] Slow rendering with displaylist.

 
 Hi Martin,
 
  That is basically true. I want to get a feeling about DisplayLists and
  VBOs. I know that the display list is a precompiled sequence of OpenGL
  commands. That is the reason that I tought the display lists should be
  faster. But the question isn't the comparison, but the slow render
  performance when I want to use display lists. I think everything is
  wrong in my implementation. But I don't know what.
 
 My point about system/graphics card memory is wrong. I thought
 about glVertexPointer, but this call isn't even compiled into
 a display list and shouldn't be used with one.
 
 So OSG will most likely use glBegin/glEnd to put the vertex data into
 the display list.
 
 It boils down to what Mathias ;) said, it's an implementation issue,
 dirty corner cases and driver developers don't optimize the
 display lists anymore, because they're deprecated and just not used
 that much anymore.
 
 
 Greetings,
 Daniel
 
 -- 
  
 
  Daniel Trstenjak Tel   : +49 (0)7071-9457-264
  science + computing ag   FAX   : +49 (0)7071-9457-511
  Hagellocher Weg 73   mailto: daniel.trsten...@science-computing.de
  D-72070 Tübingen WWW   : http://www.science-computing.de/ 
 
 -- 
 Vorstand/Board of Management:
 Dr. Bernd Finkbeiner, Michael Heinrichs, 
 Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech
 Vorsitzender des Aufsichtsrats/
 Chairman of the Supervisory Board:
 Philippe Miltin
 Sitz/Registered Office: Tuebingen
 Registergericht/Registration Court: Stuttgart
 Registernummer/Commercial Register No.: HRB 382196
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
___
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] OSG 2.8.3 3.0.1 view dependent shadowclippingplane

2011-08-25 Thread Luc Frauciel
Hi Robert and J-S,

In fact, that was what I was doing too. (with 
LighSpacePerspectiveShadowMap)
Our data/global parameters are dynamically build and we have to adapt 
dynamically the shaders applied
However, in the old way,  the searchAndReplace stuff was mixing up custom 
shaders too.
I had to create a CustomShadowMap with a no-op 
searchAndReplaceShaderSource to avoid that.

And of form of 'generic uniforms' provided by ShadowMap can make the 
adaptation of the technique easier.
For example, a setBaseTextureCoordIndex( std::vectorunsigned int index ) 
could allow to declare multiple texture units.
Even if this units are not used by the Base Shader itself, you can easily 
acces them and the base shader will not crush them.
For sure Shader Composition would be an elegant way to handle that.

I'm not working on shadows for the moment, but when I'll get back to that 
part, I'll try the new technique and see what can be done to make it more 
flexible (if ever it were not enough).

  Luc



De :
Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com
A :
OpenSceneGraph Users osg-users@lists.openscenegraph.org
Date:
08/25/2011 12:31 AM
Objet :
Re: [osg-users] OSG 2.8.3  3.0.1 view dependent shadowclippingplane
Envoyé par :
osg-users-boun...@lists.openscenegraph.org



Hi Robert, Luc,

 The shader supplied by this
 technique doesn't implement any handling of multi-texturing itself so
 it'll be up to the user to provide their own shaders to do this.

As a side note Luc, nothing forced you to use the
ShadowMap's own shaders and searchAndReplace... functionality. You could 
simply replace the shaders, define your own uniforms for sampler name - 
texture unit mapping, and do multi-texturing that way. That's what we did.

No shader provided by a library can be 100% flexible and support all use 
cases (at least until shader composition is done). The shaders in the 
older shadow techniques were no exception, but luckily you could replace 
them.

Hope this helps,

J-S
-- 
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
 http://whitestar02.dyndns-web.com/
___
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] OSG 2.8.3 3.0.1 view dependent shadowclippingplane

2011-08-24 Thread Luc Frauciel
Hi,

Great news !

Will this new technique handle multitexturing ?
That was one of the problems in older osgShadow techniques: the shadow 
shaders used   
void setBaseTextureUnit( unsigned int unit )  with a single texture unit
and then void searchAndReplaceShaderSource was rewriting over the base 
shader.

In particular, using osgShadows in conjunction with osgEarth was a 
nightmare

Luc



De :
Robert Osfield robert.osfi...@gmail.com
A :
OpenSceneGraph Users osg-users@lists.openscenegraph.org
Date:
08/24/2011 04:17 PM
Objet :
Re: [osg-users] OSG 2.8.3  3.0.1 view dependent shadow clippingplane
Envoyé par :
osg-users-boun...@lists.openscenegraph.org



Hi All,

I now have enough of the new ViewDependentShadowMap technique
implemented for members of the community to start testing it out on
their own data.  From the testing I've done so far it looks to be
signifcantly faster and produces more consistently high quality
results than any of the other techniques we have had so far.  The
algorithm isn't based on any one paper, but one could say it in
similar to perspective/light space perspective shadow maps but I
abdoned the maths behind these approaches as I just couldn't get them
to work reliably enough over a wide range of data.

The new technique isn't finished yet, it's certainly far enough along
for others to start testing and to report back results.  The new
technique isn't compatible with depth partitioning yet, and while it
does handle spot lights it do so avoiding tackling the perspective
transform in light space.

My hope with the shdow implementation is that it'll be robust and
flexible enough to replace all the old shadow techniques.  The new
techhnique also lays down the framework for future support of mltiple
shadow maps such as with cascaded or parallel split shadow maps, as
well handling multiple lights+shadows.  If we can get it working
robust enough I'll removal all the old techniques and enable us to
have a lighter weight osgShadow library.

All the changes are now checked into svn/trunk.  To test use the
--vdsm option in osgshadow, or use the new
osgShadow::ViewDepedentShadowMap technique class in place of your
existing shadow technique used in your application.

Please let me know how you get on.

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] ATI FirePro M8900

2011-07-11 Thread Luc Frauciel
I work on a Dell M6400 with a FirePro M7740  on Windows 7 64-bit.
Same issue.
Hours of installation/desinstallation of different drivers did nothing.

The only workaround I've found is to disable VBO :
pager-setDrawablePolicy(osgDB::DatabasePager::USE_DISPLAY_LISTS);
There is also an Env setting to do that I think.

It put an end to Geometric nightmare and random crashes.


I really don't know what's pro in Ati FirePro...

  Luc




De :
J.P. Delport jpdelp...@csir.co.za
A :
osg users osg-users@lists.openscenegraph.org
Date:
07/11/2011 05:18 PM
Objet :
[osg-users] ATI FirePro M8900
Envoyé par :
osg-users-boun...@lists.openscenegraph.org



Hi all,

we've got users with shiny new Dell Precision M6600 laptops with the 
FirePro M8900 ATI chips on Windows 7 64-bit. Terrain databases that work 
perfectly well almost everywhere produce artistic but not quite pleasing 
results in osgviewer, see attached.

Any ideas on how to work around ATI's OpenGL uselessness? We've already 
suggested buying NVidia cards :/

Help on installing other driver versions, other than those blessed by 
Dell with AMD shrugging their shoulders [1], would also be welcome.

cheers
jp

[1] 
http://support.amd.com/us/kbarticles/Pages/737-28041SupportforATIMobility.aspx


-- 
This message is subject to the CSIR's copyright terms and conditions, 
e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at 
http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by 
MailScanner, 
and is believed to be clean.

[pièce jointe ati-junk.jpg supprimée par Luc Frauciel/STAR-APIC] 
___
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] TerraPage terrain LODs are jumping again - have LOD ranges to be sorted?

2010-09-08 Thread Luc Frauciel
Robert Osfield  Wrote:
For PagedLOD nodes the children should always be ordered from lowest
resolution/ furthest distance first, to highest resolution/near
distance last.   What you describe fits this just fine.

Would it be possible to add this constraint in PagedLOD header ?

The only information available in the source for now is in LOD header :
LOD may display multiple children simultaneously
if their corresponding ranges overlap. Children can be in any order,
and don't need to be sorted by range or amount of detail. If the 
number of
ranges (m) is less than the number of children (n), then children m+1 
through
n are ignored.

and could be misleading regarding the behaviour of PagedLOD which inherits 
from LOD.
I've been fooled by this in the past :)


  Best Regards,

Luc




Robert Osfield robert.osfi...@gmail.com 
Envoyé par : osg-users-boun...@lists.openscenegraph.org
09/08/2010 02:19 PM
Veuillez répondre à
OpenSceneGraph Users osg-users@lists.openscenegraph.org


A
osg-users@lists.openscenegraph.org
cc

Objet
Re: [osg-users] TerraPage terrain LODs are jumping again - have LOD ranges 
to be sorted?






Hi Martin,

For PagedLOD nodes the children should always be ordered from lowest
resolution/ furthest distance first, to highest resolution/near
distance last.   What you describe fits this just fine.

The TerraPage plugin has extra scheme above PagedLOD that seek to hold
back use of higher resolution children when a neighbouring tile is of
too low a resolution for the boundary meshes to be able to fit
together.  This scheme is pretty complicated and is very specific to
the way that TerraPage maintains central and boundary meshes.  I
haven't personally seen the cycling you talk about but my guess is
that this is the most fruitful area to look at when searching for a
cause.

Robert.

On Wed, Sep 8, 2010 at 12:18 PM, Martin Scheffler osgfo...@tevs.eu 
wrote:
 Hi,

 this is a problem that was fixed some time ago but pops up again now. I 
have a terrapage terrain that loads fine, but every few seconds the 
detailed LODs are swapped against lower res ones and back again. This 
looks funny and bogs down the system. After poking around with a debugger 
the only thing that I noticed is that the LOD ranges are sorted high to 
low:
 For example:
 _rangeList[0] goes from 1000 to MAX_FLOAT
 _rangeList[1] goes from 0 to 1000

 Can this cause these problems?

 Thank you!

 Cheers,
 Martin

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=31409#31409





 ___
 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] [osgPlugins] collada: use of bind_vertex_input

2010-08-17 Thread Luc Frauciel
Hi,

I've encoutered kmz files with dae files inside that look like that :

Code:

bind_material
technique_common
  instance_material symbol=building_0 
target=#building_0/instance_material
  instance_material symbol=building_1 target=#building_1
bind semantic=CHANNEL1 target=#b1-obj-tverts/bind
  /instance_material
/technique_common
  /bind_material




The texture coords are not loaded.
If I add a bind_vertex_input element, textures works.


Code:

bind_material
technique_common
  instance_material symbol=building_0 
target=#building_0/instance_material
  instance_material symbol=building_1 target=#building_1
bind semantic=CHANNEL1 target=#b1-obj-tverts/bind
bind_vertex_input semantic=CHANNEL1 
input_semantic=TEXCOORD input_set=1/ 
  /instance_material
/technique_common
  /bind_material




Do someone know what's happening ? Is it a problem in the file or the dae 
reader ? The file is opened correctly in GoogleEarth.


Thank you!

Cheers,
Luc

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=30846#30846





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


Re: [osg-users] [osgPlugins] collada: use of bind_vertex_input

2010-08-17 Thread Luc Frauciel

lucfrauciel wrote:
 Hi,
 
 I've encoutered kmz files with dae files inside that look like that :
 
 Code:
 
 bind_material
 technique_common
   instance_material symbol=building_0 
 target=#building_0/instance_material
   instance_material symbol=building_1 target=#building_1
 bind semantic=CHANNEL1 target=#b1-obj-tverts/bind
   /instance_material
 /technique_common
   /bind_material
 
 
 
 
 The texture coords are not loaded.
 If I add a bind_vertex_input element, textures works.
 
 
 Code:
 
 bind_material
 technique_common
   instance_material symbol=building_0 
 target=#building_0/instance_material
   instance_material symbol=building_1 target=#building_1
 bind semantic=CHANNEL1 target=#b1-obj-tverts/bind
   bind_vertex_input semantic=CHANNEL1 
 input_semantic=TEXCOORD input_set=1/ 
   /instance_material
 /technique_common
   /bind_material
 
 
 
 
 Do someone know what's happening ? Is it a problem in the file or the dae 
 reader ? The file is opened correctly in GoogleEarth.
 
 
 Thank you!
 
 Cheers,
 Luc


The issue is similar to :
http://forum.openscenegraph.org/viewtopic.php?t=2676  (more recent thread)

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=30855#30855





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


[osg-users] RE Loading an Osg model from memory

2010-04-29 Thread Luc Frauciel
Hi,

osgDB::ReaderWriter::ReadResult will keep a handle on the node.
At the end of your function (after return), the reference count of you 
object (maintained by ReadResult)  will drop to Zero = object destroyed.
I don't know what is the official way to avoid that, but one way or 
another, you will have to keep a ref_count pointer on your node to keep it 
alive.


   Luc





Manolo Padron Martinez manol...@gmail.com 
Envoyé par : osg-users-boun...@lists.openscenegraph.org
29/04/2010 16:30
Veuillez répondre à
OpenSceneGraph Users osg-users@lists.openscenegraph.org


A
osg-users@lists.openscenegraph.org
cc

Objet
[osg-users] Loading an Osg model from memory






Hi:

We're trying to load an osg model from an stream. We got the code like 
this

   membuf sb((char *)Data, Size);
   std::istream stream(sb);
   osgDB::ReaderWriter* reader =
osgDB::Registry::instance()-getReaderWriterForExtension(osg);
   if(reader)
   {
   osgDB::ReaderWriter::ReadResult rr = 
reader-readNode(stream,0);
   if(rr.success())
   {
   osg::Node *new_model = new 
osg::Node(*rr.getNode());
   return new_model;
   }
   }

   return NULL;

 Its seems to load as it should. Rr is successfull but when I try to
add the node to a treenode I didn't saw it on screen. If I change the
code before for the code to load it from disk It works perfectly. Any
idea? There are a problem with the plugin of osg file when a stream is
used to read the node?

Regards from Canary Islands
___
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] Improving the OpenSceneGraph project efficiency andbalance

2010-02-23 Thread Luc Frauciel
How would you go about setting up automatic testing of the examples?
What could you test here and how would you do it?
-- 
Philip Lowman

Hi,

An idea could be to mimic the way VTK handle that question (
http://www.vtk.org)
They generate a bunch of reference automatic screenshots through CTest and 
then do image comparisons.
I admit that the initial setup seems quite high but I don't see any other 
way to do automatic testing of a graphic library.

   Luc




Philip Lowman phi...@yhbt.com 
Envoyé par : osg-users-boun...@lists.openscenegraph.org
23/02/2010 12:17
Veuillez répondre à
OpenSceneGraph Users osg-users@lists.openscenegraph.org


A
OpenSceneGraph Users osg-users@lists.openscenegraph.org
cc

Objet
Re: [osg-users] Improving the OpenSceneGraph project efficiency and 
balance






On Tue, Feb 23, 2010 at 4:32 AM, Tim Moore timoor...@gmail.com wrote:
 Is there a critical mass of power users willing to use an experimental 
tree?
 I'm not sure. Even if not, automated testing of the examples would help
 verify any OSG tree.

How would you go about setting up automatic testing of the examples?
What could you test here and how would you do it?

-- 
Philip Lowman

___
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