[osg-users] Has anyone write osg::AudioSink for openal?

[Lilinx]

hi,all 
  same as tile!!
 
Lilinx
lil...@21cn.com
　　2011-01-29
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [vpb] Build VPB Issue

[jamil farooq]

Hi,

I have all the following dependencies installed that i think relevant:

libgdal1-1.6.0
libgdal1-dev
libosgcal0
libosgcal-dev
libosgal1
libosgal-dev
openscenegraph 2.8.1-1.1build1
libopenscenegraph56

and i have also downloaded the libsquish

and i am downloading VPB 0.9.10, as osg version is 2.8.1.

I think there i have specify GDAL libs and header location somewhere in cmake. 
but i dont know how to.

could you plz help me out 


Thank you!

Cheers,
fly_hi

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





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

Re: [osg-users] about osg light

[Tysen Chan]

Thank you very much! I also find the problem when i get up today.

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





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

Re: [osg-users] Converting DrawArrays(TRIANGLE_STRIP)to DrawElements(TRIANGLES)

[Wojciech Lewandowski]

Hi Guys,

You probably know this but if not it may be other option for you. One can 
define restart index that works as terminator for triangle/quad strips 
(check GL_NV_primitive_restart extension) . So in practice multiple triangle 
strips can be separated by restart indices and put into one physical 
PrimitiveSet. Other option doing the same is adding 2 degenerated triangles 
(2 extra indices or vertices) linking  end of prior strip with start of next 
strip. And you can use  this trick on older boards in the same way as 
primitive terminator.


Cheers,
Wojtek

-Oryginalna wiadomość- 
From: Jean-Sébastien Guay

Sent: Friday, January 28, 2011 4:44 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Converting DrawArrays(TRIANGLE_STRIP)to 
DrawElements(TRIANGLES)


Hi Tim,


If I understand correctly how the sky dome mesh is constructed, there
was a lot of duplication of vertices in the triangle strip arrays, and
this has been carried forward into your indexed mesh approach. The
INDEX_MESH optimizer would remove these duplicates. The order of the
triangles in the output of INDEX_MESH should be the same as the input
order, but it might be tricky to pick corresponding triangles out of the
new mesh. Since this is such a regular mesh, the vertex cache optimizers
would make a small difference; however, you would totally lose the order
of the mesh.


Incidentally, I tried running the INDEX_MESH optimizer on the created
subgraph (at the end of the constructor in the file I attached in my
previous post) but it would crash in MyTriangleOperator::operator() - it
goes out of bounds on the _remapIndices list. The other two optimizers
also go out of bounds in similar ways.

Here's a modified Sphere.cpp with the code from the MeshOptimizers
simply copied into it (for simplicity of testing) if you want to have a
look.

I'm still not sure the order of the mesh is really important. I said
that before because it would have explained why the strips were arranged
like that, but I'm not sure now. So if I could get the INDEX_MESH
optimizer not to crash, I think using that and the other two (post/pre
transform) would probably work well. I could test it and see at least.


What was the actual performance difference?


With only the skydome in the scene, Draw went from about 0.45 to 0.4 on
my i7 920 + GTX 260. However it made the number of batches (draw calls)
go way down, of course - replacing 768 draw calls by 16 is good, but I
guess we could do better.

Thanks,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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 


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

Re: [osg-users] Optimizing scene structure and geometry

[Wojciech Lewandowski]

Hi Guys,

Its really interesting observation about this 3 ms bind time. I suspect this 
might be a shadow map. 3 ms could be actually a time needed for shadow map 
rendering stage to finish ...


If you are desperate you may consider building the database used only for 
shadow casting (and using proper Casts & Receives node masks to select it). 
Such database can be stripped from allmost all textures (only translucent 
textures are needed) and many other state attribs. Then it can be probably 
optimized till it hurts. Allmost all geometry can be probably put into 
single indexed triangle set. If you got coplanar geometry - some of it  can 
be removed. Of course such stripping the DB may be a challenge, but I 
believe J-S have done this already ;-)...


Wojtek Lewandowski

-Oryginalna wiadomość- 
From: Ramy Gowigati

Sent: Friday, January 28, 2011 4:38 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Optimizing scene structure and geometry

Hi,

I am in the same stage now, optimizing a shadowed scene that is 1.5M 
triangles big (according to the stats).


I did several optimizations, but still no where near what I am targeting 
for. Its the same, large outdoor scene, but in my case everything is fairly 
static. And the camera navigates around and in some areas the camera can see 
pretty much all the scene, and that is where the performance plummets pretty 
fast!


I tried to minimize the StateSets in my models when I load them. I simply 
grouped together the geometry that use a common StateSets. That helped in 
terms of StateSet changes and FPS time (I can't find my stats that I wrote 
down back then at the moment).


Also we created LODs on the high res models, that cut down a lot of tri's, 
but still not the performance we want. Something useful I found was to place 
an OcclusionQuery node on my models and hide them out when they are being 
occluded by another building or a small part of them is not shown.


But recently (and the most interesting to me so far), I tried out the nVidia 
nSight tool. I ran my application and it gave me a detailed analysis of the 
OpenGL calls and the min, max and agv. timing they took. So I discovered one 
of the glBindTexture commands took over 3 milliseconds! That was the highest 
since the average was somewhere around 0.5-0.7. Did anybody by any chance 
use nSight and saw how useful it is in the optimizing process? I will play 
around more on this tool and see what I can do.


I hope these suggestions would help if you haven't already tried them.
Always looking for new optimization techniques :D

Cheers,
Ramy

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





___
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] Linker error during execution

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

J-S,

I appreciate the input and insightful discussion. This is good information
to have for both new and experienced developers.

Thank you!

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Jean-Sébastien Guay
Sent: Friday, January 28, 2011 12:17 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Linker error during execution

Hi Shayne,

> The setting that you amply described IS what we do. We do it quite often
so
> that things don't run so slow when we're debugging our app (not OSG). We
may
> need to run a while before we break into our code for debugging. Running
> with OSG debug libs is too slow for this scenario so we use the release
libs
> instead with the settings set accordingly.

Yeah, that explains it. So it really was because my wording of "don't 
mix debug and release" was not thoroughly accurate... Sorry about that.

Still, I really recommend most users don't change the default settings, 
because then you're totally on your own. Any dependency you use, you'll 
have to recompile yourself from source, you won't be able to use any 
precompiled binaries. And for new users, I think it's easier just to say 
"link debug to debug, release to release and you're fine". See the OP of 
this thread for example, who was setting /MD in his debug build when OSG 
was built with /MDD.

Plus, just how slow it is in debug is a matter of perspective... It is 
much slower but if you're not debugging too often then it might not 
matter. Honestly, you haven't seen anything until you've used 
boost::persistence in debug. THAT's slow. :-)

And the other thing is, if you're not actively debugging, then you can 
run without attaching the debugger (use Ctrl-F5 instead of F5). Then 
it's much faster than running with the debugger attached (not quite as 
fast as release, but much faster). And then you can attach the debugger 
only when you get to a point where you want to debug the running code. 
That's how we survive using boost::persistence in debug - the 
persistence is used in loading/saving files, so we start without the 
debugger, load our scenario, and then attach the debugger. Loading is 
therefore much faster than with the debugger attached. But of course 
that doesn't work if we need to debug the actual loading of a scenario. 
Then we're screwed :-)

Another approach could be to always run in release, and just have 
another configuration with symbols (and possibly with optimization 
turned off). Sure, why not.

But I digress. To each his own. We use release and debug, with the 
default settings in debug, and just make sure not to mix the two. I 
recommend the same for new users, but more experienced users can do 
whatever they want and there are many different ways to get mostly the 
same result... It all comes down to knowing what you're doing, and if 
you don't want to know all the small details then you'd be better 
keeping the default settings I think.

I'll make sure to be more precise next time I talk about not mixing A 
and B... :-)

J-S
-- 
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
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


smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Linker error during execution

[Jean-Sébastien Guay]

Hi Shayne,


The setting that you amply described IS what we do. We do it quite often so
that things don't run so slow when we're debugging our app (not OSG). We may
need to run a while before we break into our code for debugging. Running
with OSG debug libs is too slow for this scenario so we use the release libs
instead with the settings set accordingly.


Yeah, that explains it. So it really was because my wording of "don't 
mix debug and release" was not thoroughly accurate... Sorry about that.


Still, I really recommend most users don't change the default settings, 
because then you're totally on your own. Any dependency you use, you'll 
have to recompile yourself from source, you won't be able to use any 
precompiled binaries. And for new users, I think it's easier just to say 
"link debug to debug, release to release and you're fine". See the OP of 
this thread for example, who was setting /MD in his debug build when OSG 
was built with /MDD.


Plus, just how slow it is in debug is a matter of perspective... It is 
much slower but if you're not debugging too often then it might not 
matter. Honestly, you haven't seen anything until you've used 
boost::persistence in debug. THAT's slow. :-)


And the other thing is, if you're not actively debugging, then you can 
run without attaching the debugger (use Ctrl-F5 instead of F5). Then 
it's much faster than running with the debugger attached (not quite as 
fast as release, but much faster). And then you can attach the debugger 
only when you get to a point where you want to debug the running code. 
That's how we survive using boost::persistence in debug - the 
persistence is used in loading/saving files, so we start without the 
debugger, load our scenario, and then attach the debugger. Loading is 
therefore much faster than with the debugger attached. But of course 
that doesn't work if we need to debug the actual loading of a scenario. 
Then we're screwed :-)


Another approach could be to always run in release, and just have 
another configuration with symbols (and possibly with optimization 
turned off). Sure, why not.


But I digress. To each his own. We use release and debug, with the 
default settings in debug, and just make sure not to mix the two. I 
recommend the same for new users, but more experienced users can do 
whatever they want and there are many different ways to get mostly the 
same result... It all comes down to knowing what you're doing, and if 
you don't want to know all the small details then you'd be better 
keeping the default settings I think.


I'll make sure to be more precise next time I talk about not mixing A 
and B... :-)


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] Linker error during execution

[Mukund Keshav]

Hi J-S,

Thanks a tonne! :)

It worked.

Cheers,
Mukund

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





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

Re: [osg-users] Android Development Plans

[Thomas Hogarth]

Hi Jason

Mines a little archos 43 tablet. Checked the site, no plans for a 2.3
release yet by the look of thing which is a shame. Well looks like there
might have to be some forking in any port for now. Perhaps two types of
viewer. One with native egl and one that requires a java template for
setting up egl for you.

The stl stuff is still a plus and I wounder what happens if I pull the egl
header and .so files into my version 8 sdk :)

Cheers
Tom

On 28 January 2011 15:31, Jason Daly  wrote:

> On 01/28/2011 05:26 AM, Thomas Hogarth wrote:
>
>> Hi Jason
>>
>> Never mind found it in the native-activity example. I also found this
>> thread
>>
>>
>> http://groups.google.com/group/android-ndk/browse_thread/thread/3c6dd147547ce056/b9d27d086990d1b1
>>
>> It says you need a 2.3 device, hope it's not true as mine is 2.2 :(
>>
>
>
> Unfortunately, all the docs I've read seem to confirm that.  You need an
> android-9 target for most of the new features.
>
> What phone do you have?  We've got a couple of Nexus One phones here that
> are still 2.2, but from what we've read, a 2.3 update is in the works for
> them.  I haven't heard of a hardware limitation in a 2.2 phone that would
> prevent it from being updated to 2.3 (just delays by the provider in getting
> the update out).
>
> --"J"
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Linker error during execution

[Jean-Sébastien Guay]

Hi Mukund,


Well, apart from the code, im linking the above mentioned libraries(im in the 
debug mode). and im linking as a multi-threaded DLL (/MD)


If you're in debug you should be using /MDD runtime (multi-threaded 
debug DLL). If not that could explain the linker errors, as the OSG 
debug DLLs are using /MDD.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] Linker error during execution

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

J-S,

The setting that you amply described IS what we do. We do it quite often so
that things don't run so slow when we're debugging our app (not OSG). We may
need to run a while before we break into our code for debugging. Running
with OSG debug libs is too slow for this scenario so we use the release libs
instead with the settings set accordingly.

Obviously we don't mix and match when we ship our product to customers...

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Jean-Sébastien Guay
Sent: Friday, January 28, 2011 10:19 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Linker error during execution

Hi Shayne,

> That's interesting because we have ran a debug solution with the release
OSG
> libs before without incident. We're using VC++ 9.0 on Vista 64 bit...

That's why I said "with default settings" in my previous post. There is 
one way to make that work: you change the project settings to disable 
iterator debugging in your debug builds of OSG, and make it link to the 
Debug runtime (/MD instead of /MDD), in which case there's no problem, 
release and debug can be mixed. I'm guessing that's what you did...

But in general that's not recommended because then THAT setting has to 
match for all libs / executables, and it's not the default so it's easy 
to get mixed up.

So to be precise, we shouldn't say "debug and release can't be mixed", 
we should say "_HAS_ITERATOR_DEBUGGING setting and runtime can't be 
mixed". But we generally use the former as shorthand.

Check it out, it's a common thing and I'm surprised you hadn't heard 
about it before.

J-S
-- 
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
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


smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] about osg light

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

Tysen,

If you suspect that your problem is due to lighting, I would suggest that you 
take a close look at the osglight example. It has code in there to properly 
set up and render with a light source.

Looking at your code below in method 2, it appears that you're setting up a 
spot light since you're calling both setPosition() (with w = 1.0) AND 
setDirection(). setDirection() applies to spotlights. I doubt this is what you 
wanted to do.

If you want a directional light source, use setPosition with the w component 
set to 0.0. If you want a positional light, specify the x,y,z and set w = 1.0. 
Don't use setDirection().

Hope this gives you some direction (pun intended)...

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tysen Chan
Sent: Friday, January 28, 2011 2:22 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] about osg light

Hi,

I load a 3ds file into osg viewer, but the color of the model is very dark, it 
is very different from the original model in sketchup. I guess that it is due 
to light config. So I use two methods, but they are not well. please help me. 
thankyou!
I just want to the global light which color is (1,1,1,1) as nature world. How 
to config the light source.

method1:

osg::ref_ptr spModelNode=osgDB::readNodeFile("1.3ds");
osg::ref_ptrstateset=new osg::StateSet;
stateset=spModelNode->getOrCreateStateSet ();
stateset->setMode(GL_LIGHTING, osg::StateAttribute::ON);
stateset->setMode(GL_NORMALIZE, osg::StateAttribute::ON);
spGroup->addChild(spModelNode);
m_pOSG->getViewer()->setCameraManipulator(new osgGA::TrackballManipulator());

method2:

osg::ref_ptr spModelNode=osgDB::readNodeFile("1.3ds");
spGroup->addChild(CreateLight(spModelNode));

osg::ref_ptr  CreateLight(osg::ref_ptr node) {
osg::ref_ptr lightRoot=new osg::Group();
lightRoot->addChild(node);
osg::ref_ptr  stateset=new osg::StateSet;
stateset=lightRoot->getOrCreateStateSet ();
stateset->setMode(GL_LIGHTING, osg::StateAttribute::ON);
stateset->setMode(GL_LIGHT0, osg::StateAttribute::ON);
stateset->setMode(GL_NORMALIZE, osg::StateAttribute::ON);

osg::BoundingSphere bs;
node->computeBound();
bs=node->getBound();

osg::ref_ptr light=new osg:light;
light->setLightNum(0);

light->setDirection(osg::Vec3(0.0f, 0.0f, 1.0f));
light->setPosition(osg::Vec4(bs.center().x(), bs.center().y(), 
bs.center().z()-bs.radius(), 1.0f));


light->setAmbient(osg::Vec4(1.0f,1.0f,1.0f,1.0f));
light->setDiffuse(osg::Vec4(1.0f,1.0f,1.0f,1.0f));
light->setSpecular(osg::Vec4(1.0f,1.0f,1.0f,1.0f));

osg::ref_ptr   lightSource=new osg:ightSource;
lightSource->setLight(light.get());
lightRoot->addChild(lightSource);
return lightRoot.get();

}

...

Thank you!

Cheers,
Tysen

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





smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Linker error during execution

[Mukund Keshav]

Hi Mourad,

Well, i don't think i can attach a vcproj file. i tried but it did not appear. 
It is not there in the supported formats i suppose.

Well, apart from the code, im linking the above mentioned libraries(im in the 
debug mode). and im linking as a multi-threaded DLL (/MD)

Thanks,
Mukund

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





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

[osg-users] Rotating slave camera brings clipping plane into view.

[Robert Kern]

Hi,

The specs on the HMD that I am working with calls for the view on each eye be 
rotated outward by 13 degrees. However when I do this I can see what appears to 
be a clipping plane. If both cameras are looking straight ahead, there is not a 
problem. However I do need to rotate them outward.

int xoffset = 40;
int yoffset = 40;

// left window + left slave camera
{
osg::ref_ptr traits = new 
osg::GraphicsContext::Traits;
traits->x = xoffset + 0;
traits->y = yoffset + 0;
traits->width = 600;
traits->height = 480;
traits->windowDecoration = true;
traits->doubleBuffer = true;
traits->sharedContext = 0;

osg::ref_ptr gc = 
osg::GraphicsContext::createGraphicsContext(traits.get());

osg::ref_ptr camera = new osg::Camera;
camera->setGraphicsContext(gc.get());
camera->setViewport(new osg::Viewport(0,0, traits->width, 
traits->height));
GLenum buffer = traits->doubleBuffer ? GL_BACK : GL_FRONT;
camera->setDrawBuffer(buffer);
camera->setReadBuffer(buffer);

this->addSlave(camera.get(), osg::Matrixd::rotate(-13, 
Vec3f(0,1,0)), osg::Matrixd());
}
   
// right window + right slave camera
{
osg::ref_ptr traits = new 
osg::GraphicsContext::Traits;
traits->x = xoffset + 600;
traits->y = yoffset + 0;
traits->width = 600;
traits->height = 480;
traits->windowDecoration = true;
traits->doubleBuffer = true;
traits->sharedContext = 0;

osg::ref_ptr gc = 
osg::GraphicsContext::createGraphicsContext(traits.get());

osg::ref_ptr camera = new osg::Camera;
camera->setGraphicsContext(gc.get());
camera->setViewport(new osg::Viewport(0,0, traits->width, 
traits->height));
GLenum buffer = traits->doubleBuffer ? GL_BACK : GL_FRONT;
camera->setDrawBuffer(buffer);
camera->setReadBuffer(buffer);
this->addSlave(camera.get(), osg::Matrixd::rotate(13, 
Vec3f(0,1,0)), osg::Matrixd());
}


Thank you!

Cheers,
Robert

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





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

Re: [osg-users] OSG 2.9.10 on iOS

[Alessandro Terenzi]

Thanks again Stephan,
I just tried using the latest tagged source code. I've set CMake's options
as you've suggested and also:

1) set CMake to point to the iPhone's freetype lib/headers (is this
necessary?)

2) changed the code signing identity in XCode (otherwise I get an error)

but I was still getting linking errors. The linker complied because it could
not find both the Cocoa and OpenGL frameworks (note: I wrote OpenGL not
OpenGLES, even though I checked only the GLES1 option in CMake). So I tried
to remove them from the Other Linker Flags, but I was getting other errors
because of references not found by imageio (but in CMake it was set
quicktime not imageio), so I also removed imageio from the linker's flags.

Finally I had to modify the Bundle Identifier because I was getting an error
due to the character '_' that seems not to be a valid character for a bundle
identifier name.

After all the above steps, I managed to build the application, but it
crashes while it is starting, in the console I get:

   Program received signal:  “EXC_BAD_ACCESS”.

warning: Could not open fork matching current architecture for OSO archive
"/Users/alex/Desktop/Build/3rdParty-iOS/lib/libFreeType_iphone_universal.a"

warning: Could not open OSO file
/Users/alex/Desktop/Build/3rdParty-iOS/lib/libFreeType_iphone_universal.a(ftinit.o)
to scan for pubtypes for objfile
/Users/alex/Desktop/Build/OpenSceneGraph-2.9.11-build-iOS/bin/osgViewerIPhone.app/osgViewerIPhone
...(and many copies of this last warning)...

The last thing I tried was to start from scratch but set CMake to use
imageio and not quicktime but same runtime error (this solved some linking
problems described above, but of course not the runtime crash).

Am I suppose to use another version of freetype?

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

Re: [osg-users] Linker error during execution

[Jean-Sébastien Guay]

Hi Shayne,


That's interesting because we have ran a debug solution with the release OSG
libs before without incident. We're using VC++ 9.0 on Vista 64 bit...


That's why I said "with default settings" in my previous post. There is 
one way to make that work: you change the project settings to disable 
iterator debugging in your debug builds of OSG, and make it link to the 
Debug runtime (/MD instead of /MDD), in which case there's no problem, 
release and debug can be mixed. I'm guessing that's what you did...


But in general that's not recommended because then THAT setting has to 
match for all libs / executables, and it's not the default so it's easy 
to get mixed up.


So to be precise, we shouldn't say "debug and release can't be mixed", 
we should say "_HAS_ITERATOR_DEBUGGING setting and runtime can't be 
mixed". But we generally use the former as shorthand.


Check it out, it's a common thing and I'm surprised you hadn't heard 
about it before.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] Linker error during execution

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

J-S,

That's interesting because we have ran a debug solution with the release OSG
libs before without incident. We're using VC++ 9.0 on Vista 64 bit...

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Jean-Sébastien Guay
Sent: Friday, January 28, 2011 8:26 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Linker error during execution

Hi Shayne,

> Unless you're debugging into OSG code, I would not use the debug
libraries.
> Things will run SLOOOW.

Or debugging into your own code... Or any other code for that matter.

With Visual Studio and default settings, you can't mix debug and release 
libraries / executable. They have to all match. So if he wants to debug 
his own code, not necessarily into OSG itself, he still has to link to 
the debug OSG libs.

J-S
-- 
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
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


smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Discussion: metadata & readerwriters output

[Paul Martz]

If a specific node in a scene graph can be reliably identified, application data 
can be stored separately from the scene graph. Unfortunately, OSG's mechanism 
for identifying a node (the NodePath) is address-based, making it unsuitable for 
this task, as addresses change from one app invocation to the next.


osgWorks has a solution for this. It has a set of NodePathUtils that identify 
nodes based on child index, node name, and class name, along with conversion 
utilities to switch between NodePaths and the string representation. Because the 
string isn't address-based, these utilities allow an app to identify a specific 
node between application invocations. Application-specific data can be stored 
saved to a database keyed by the NodePath's string representation, then restored 
later, for example.


Just wanted to mention this, as the osgWorks metadata solution is already 
available and requires no changes to core OSG.

   -Paul


On 1/28/2011 2:54 AM, Sukender wrote:

Hi Robert, hi (SELECT name FROM "OSG_USERS" WHERE name<>"Robert Osfield";),

** Context **
I spotted the DAE plugin is able to "return" some values to the calling program by writing in the "plugin 
data" (options->getPluginData()). But when writing, this plugin data is... const! This thus requires an ugly and unsafe 
const_cast<>  (or an even uglier C-style cast). In other words: readers should not return any value except the scene graph 
itself, or generally speaking "predefined return values". I also think that using "void*" is just a 
maintanability pain, with high risks of writing unallocated memory parts, and such.

** Topic **
More generally, it is hard to store and pass "not predifined" variables between main 
program and plugins, or between OSG itself and the main program (I mean "adding some type-safe 
user values to the graph").
This makes me think about something I discussed a bit before: the ability to handle "metadata" in OSG (post 
named "Suggestion: Add components in nodes (aggregation)"). To sum up the discussion, it was roughly said 
that "it's on user side", and "use userData!".

However, the "meta" system I implemented for my app is now quite used and 
stable. I want it to be open sourced so that partners using OSG also have access to 
metadata, and I propose this to be integrated. But I don't wan't to simply copy-paste it 
into a submission; I'd like to have a real reflexion around it, to make it useable for 
all. After all, more and more file formats handle these metas, so why not OSG, as long as 
it does not disturb existing features?

** Ideas **
So... starting the reflexion, I have a few ideas:

1. What is a meta?
A meta is a "name/typed value" pair. Possible implementation is to have a base class (with the name, say 
"MetaBase"), and several derived (Meta, deriving from MetaBase, and then 
Meta...). There could be as many meta types as you wish, but only a few "standard" ones 
should be defined in OSG (int, double, string...).

2. How to store them (the container)?
2.1. Have a simple, yet easy and stable way: a basic container (vector/list). 
Duplicate meta names should be handled on user's side if necessary.
2.2. Have a name->value map. Implementation may be a bit less flexible, but 
this ensures faster lookup (is this necessary?), and name unicity (is this 
necessary?).
2.3. Other ideas: multimap, unordered_map, etc.
2.4. Have a user-defined container. That way, user may ask for a simple vector, or a very 
complex DataBase-type container. As my colleague told me: "usages can be too 
different to tell beforehand the container type". This is surely a good idea, but 
how to implement it? Work with iterators? Have a container base class? Use templates 
somewhere? Help!

FYI: my implementation uses a vector container (having generally less than 10-20 
metas in a container), with the MetaBase / Meta  idea.

3. Where to store them?
- Maybe there is a need to store them just in another variable, alongside userData. 
This is one of my needs, but I still can use userData as I do, even if that's not as 
clean as having directly a container in osg::Object. Note: to avoid burdening 
osg::Object too much, this could be a ref_ptr<>  to a container.
- Maybe there is a need for ReaderWriters, as I told at the begining of my email? I guess 
so, but this does not solve the "constness" problem if put in the Options 
structure. Or maybe we should provide ReaderWriter a non const container to play with?

4. How to serialize/deserialize them?
I personnally have straightforward "toString()/fromString()" methods to convert back and 
forth. This is then used by my own plugins to read/write those metas. This is certainly not the 
best implementation, but surely the simplest. Another idea would be make plugins (or other code) 
directly read values and (de)serialize them as they want; however, I suggest to keep the 
"toString()/fromString()" methods in order to handle unknown types.

Many thanks to those who have read entirety this text.

Re: [osg-users] Discussion: metadata & readerwriters output

[Sukender]

Hi Peter, Robert, & all

Thanks for your ideas, Peter.
I really appreciate the proposal of having values in a separate structure with 
weak references. But is this a singleton? If so, how would you handle the case 
where you have to process things between two models (say you want to load two 
files and merge/process them anyhow)?

Robert, what is your opinion on Peter's idea?

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

- "Peter Amstutz"  a écrit :

> I have run into the same problem trying to get metadata from the
> OpenFlight loader.
> 
> In my application I handled the attributes problem by using the
> "Description" field on osg::Node, which stores an arbitrary list of
> strings and unlike UserData can be serialized by various osgDB
> plugins. 
> I encoded attributes in "Key=Value" form, with only the most trivial
> parsing of splitting on the '=' and any further type coercion handled
> on
> the user side.  This works for my needs but is obviously unsuitable
> for
> storing large or complex data.
> 
> For a thorough solution to this problem, my suggestion would be:
> 
> a) Define a few primitive types, like integer, float and string. 
> Define
> a couple of container types, vector and map.  Containers can contain
> other containers.
> 
> b) Serializerizers translate the generic structure to/from other
> formats
> such as binary, XML, JSON, prettyprint etc as appropriate for target
> format.
> 
> c) Consider maintaining metadata in a table separately from the scene
> graph.  So instead of adding a getMetadata() to osg::Node, there
> might
> be an osgDB::Metadata object with a method
> getMetadataForNode(osg::Node*).  This avoids burdening the scene
> graph
> with additional fields.  The osgDB::Metadata would hold weak
> references
> so it doesn't interfere with the existing object lifecycle of nodes. 
> This also has the advantage of being separate from the osg core and
> not
> requiring as much buy-in from Robert if he doesn't like it :-)
> 
> Cheers,
> Pete
> 
> On 1/28/2011 4:54 AM, Sukender wrote:
> > Hi Robert, hi (SELECT name FROM "OSG_USERS" WHERE name<>"Robert
> Osfield";),
> >
> > ** Context **
> > I spotted the DAE plugin is able to "return" some values to the
> calling program by writing in the "plugin data"
> (options->getPluginData()). But when writing, this plugin data is...
> const! This thus requires an ugly and unsafe const_cast<> (or an even
> uglier C-style cast). In other words: readers should not return any
> value except the scene graph itself, or generally speaking "predefined
> return values". I also think that using "void*" is just a
> maintanability pain, with high risks of writing unallocated memory
> parts, and such.
> >
> > ** Topic **
> > More generally, it is hard to store and pass "not predifined"
> variables between main program and plugins, or between OSG itself and
> the main program (I mean "adding some type-safe user values to the
> graph").
> > This makes me think about something I discussed a bit before: the
> ability to handle "metadata" in OSG (post named "Suggestion: Add
> components in nodes (aggregation)"). To sum up the discussion, it was
> roughly said that "it's on user side", and "use userData!".
> >
> > However, the "meta" system I implemented for my app is now quite
> used and stable. I want it to be open sourced so that partners using
> OSG also have access to metadata, and I propose this to be integrated.
> But I don't wan't to simply copy-paste it into a submission; I'd like
> to have a real reflexion around it, to make it useable for all. After
> all, more and more file formats handle these metas, so why not OSG, as
> long as it does not disturb existing features?
> >
> > ** Ideas **
> > So... starting the reflexion, I have a few ideas:
> >
> > 1. What is a meta?
> > A meta is a "name/typed value" pair. Possible implementation is to
> have a base class (with the name, say "MetaBase"), and several derived
> (Meta, deriving from MetaBase, and then Meta...).
> There could be as many meta types as you wish, but only a few
> "standard" ones should be defined in OSG (int, double, string...).
> >
> > 2. How to store them (the container)?
> > 2.1. Have a simple, yet easy and stable way: a basic container
> (vector/list). Duplicate meta names should be handled on user's side
> if necessary.
> > 2.2. Have a name->value map. Implementation may be a bit less
> flexible, but this ensures faster lookup (is this necessary?), and
> name unicity (is this necessary?).
> > 2.3. Other ideas: multimap, unordered_map, etc.
> > 2.4. Have a user-defined container. That way, user may ask for a
> simple vector, or a very complex DataBase-type container. As my
> colleague told me: "usages can be too different to tell beforehand the
> container type". This is surely a good idea, but how to implement it?
> Work with iterators? Have a container base class? Use templates
> somewhere? Help!
> >
> > FYI: my implementation uses a vector c

Re: [osg-users] Converting DrawArrays(TRIANGLE_STRIP) to DrawElements(TRIANGLES)

[Jean-Sébastien Guay]

Hi Tim,


If I understand correctly how the sky dome mesh is constructed, there
was a lot of duplication of vertices in the triangle strip arrays, and
this has been carried forward into your indexed mesh approach. The
INDEX_MESH optimizer would remove these duplicates. The order of the
triangles in the output of INDEX_MESH should be the same as the input
order, but it might be tricky to pick corresponding triangles out of the
new mesh. Since this is such a regular mesh, the vertex cache optimizers
would make a small difference; however, you would totally lose the order
of the mesh.


Incidentally, I tried running the INDEX_MESH optimizer on the created 
subgraph (at the end of the constructor in the file I attached in my 
previous post) but it would crash in MyTriangleOperator::operator() - it 
goes out of bounds on the _remapIndices list. The other two optimizers 
also go out of bounds in similar ways.


Here's a modified Sphere.cpp with the code from the MeshOptimizers 
simply copied into it (for simplicity of testing) if you want to have a 
look.


I'm still not sure the order of the mesh is really important. I said 
that before because it would have explained why the strips were arranged 
like that, but I'm not sure now. So if I could get the INDEX_MESH 
optimizer not to crash, I think using that and the other two (post/pre 
transform) would probably work well. I could test it and see at least.



What was the actual performance difference?


With only the skydome in the scene, Draw went from about 0.45 to 0.4 on 
my i7 920 + GTX 260. However it made the number of batches (draw calls) 
go way down, of course - replacing 768 draw calls by 16 is good, but I 
guess we could do better.


Thanks,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
/*
 ---
 | osgEphemeris - Copyright (C) 2007  Don Burns|
 | |
 | This library is free software; you can redistribute it and/or modify|
 | it under the terms of the GNU Lesser General Public License as published|
 | by the Free Software Foundation; either version 3 of the License, or|
 | (at your option) any later version. |
 | |
 | This library is distributed in the hope that it will be useful, but |
 | WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY  |
 | or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public |
 | License for more details.   |
 | |
 | You should have received a copy of the GNU Lesser General Public License|
 | along with this software; if not, write to the Free Software Foundation,|
 | Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.   |
 | |
 ---
 */

#include 
#include 

#include 
#include 

#include 
#include 
#include 

using namespace osgEphemeris;


namespace
{

// Optimization options that were added to osgUtil::Optimizer in 2.9.8+
// Note: We keep the same enum values so it stays consistent.
enum NewOptimizationOptions
{
INDEX_MESH =(1 << 18),
VERTEX_POSTTRANSFORM =  (1 << 19),
VERTEX_PRETRANSFORM =   (1 << 20),
};

// Helper that collects all the unique Geometry objects in a subgraph.
class GeometryCollector : public osgUtil::BaseOptimizerVisitor
{
public:
GeometryCollector(osgUtil::Optimizer* optimizer,
  NewOptimizationOptions options)
  : osgUtil::BaseOptimizerVisitor(optimizer, options) {}
void reset();
void apply(osg::Geode& geode);
typedef std::set GeometryList;
GeometryList& getGeometryList() { return _geometryList; };
protected:
GeometryList _geometryList;
};

// Convert geometry that uses DrawArrays to DrawElements i.e.,
// construct a real mesh. This removes duplicate vertices.
class IndexMeshVisitor : public GeometryCollector
{
public:
IndexMeshVisitor(osgUtil::Optimizer* optimizer = 0)
: GeometryCollector(optimizer, INDEX_MESH)
{
}
void makeMesh(osg::Geometry& geom);
void makeMesh();
};

// Optimize the triangle order in a mesh for best use of the GPU's
// post-transform cache. This uses Tom Forsyth's algorithm described
// at http://home.comcast.net/~tom_forsyth/papers/fast_vert_cache_opt.html
class VertexCacheVisitor : public GeometryCollector
{
public:
VertexCache

Re: [osg-users] Optimizing scene structure and geometry

[Ramy Gowigati]

Hi,

I am in the same stage now, optimizing a shadowed scene that is 1.5M triangles 
big (according to the stats).

I did several optimizations, but still no where near what I am targeting for. 
Its the same, large outdoor scene, but in my case everything is fairly static. 
And the camera navigates around and in some areas the camera can see pretty 
much all the scene, and that is where the performance plummets pretty fast!

I tried to minimize the StateSets in my models when I load them. I simply 
grouped together the geometry that use a common StateSets. That helped in terms 
of StateSet changes and FPS time (I can't find my stats that I wrote down back 
then at the moment).

Also we created LODs on the high res models, that cut down a lot of tri's, but 
still not the performance we want. Something useful I found was to place an 
OcclusionQuery node on my models and hide them out when they are being occluded 
by another building or a small part of them is not shown.

But recently (and the most interesting to me so far), I tried out the nVidia 
nSight tool. I ran my application and it gave me a detailed analysis of the 
OpenGL calls and the min, max and agv. timing they took. So I discovered one of 
the glBindTexture commands took over 3 milliseconds! That was the highest since 
the average was somewhere around 0.5-0.7. Did anybody by any chance use nSight 
and saw how useful it is in the optimizing process? I will play around more on 
this tool and see what I can do.

I hope these suggestions would help if you haven't already tried them. 
Always looking for new optimization techniques :D

Cheers,
Ramy

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





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

Re: [osg-users] Linker error during execution

[Jean-Sébastien Guay]

Hi Shayne,


Unless you're debugging into OSG code, I would not use the debug libraries.
Things will run SLOOOW.


Or debugging into your own code... Or any other code for that matter.

With Visual Studio and default settings, you can't mix debug and release 
libraries / executable. They have to all match. So if he wants to debug 
his own code, not necessarily into OSG itself, he still has to link to 
the debug OSG libs.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] Android Development Plans

[Jason Daly]

On 01/28/2011 10:01 AM, Jean-Sébastien Guay wrote:


Yeah, really nice. Anyone try to compile OSG with this NDK? I guess
since they say it supports RTTI and has STLPort for the STL, it should
work fine...


Actually, there are four different C++ libraries available in NDK 5, and 
the only one that supports exceptions and RTTI is a static build of GNU 
libstdc++.  There are both static and dynamic STLPort builds but neither 
supports RTTI or exceptions.


They're working on a dynamic version of GNU libstdc++ for a future release.

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

Re: [osg-users] Please test svn/trunk in prep for 2.9.11 dev release

[Jean-Sébastien Guay]

Hi Thomas,


So upgrading to the latest drivers has sorted the problem, wonder what
the cause was?


Yeah, it was like that for a while and recent drivers do a better job. 
There have been discussions on this list about that :-)


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] Android Development Plans

[Jean-Sébastien Guay]

Hi all,


Yeah, I just downloaded and looked through it. There's an example
without a single Java class in it. It just goes straight to EGL and
GLES2 in the .c file. Very cool!


Yeah, really nice. Anyone try to compile OSG with this NDK? I guess 
since they say it supports RTTI and has STLPort for the STL, it should 
work fine...


Another step closer to getting an OSG app on Android. Though I hear 
debugging native Android code (as opposed to Java code running on 
Android's VM) is a bit hard...


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] Discussion: metadata & readerwriters output

[Peter Amstutz]

I have run into the same problem trying to get metadata from the
OpenFlight loader.

In my application I handled the attributes problem by using the
"Description" field on osg::Node, which stores an arbitrary list of
strings and unlike UserData can be serialized by various osgDB plugins. 
I encoded attributes in "Key=Value" form, with only the most trivial
parsing of splitting on the '=' and any further type coercion handled on
the user side.  This works for my needs but is obviously unsuitable for
storing large or complex data.

For a thorough solution to this problem, my suggestion would be:

a) Define a few primitive types, like integer, float and string.  Define
a couple of container types, vector and map.  Containers can contain
other containers.

b) Serializerizers translate the generic structure to/from other formats
such as binary, XML, JSON, prettyprint etc as appropriate for target format.

c) Consider maintaining metadata in a table separately from the scene
graph.  So instead of adding a getMetadata() to osg::Node, there might
be an osgDB::Metadata object with a method
getMetadataForNode(osg::Node*).  This avoids burdening the scene graph
with additional fields.  The osgDB::Metadata would hold weak references
so it doesn't interfere with the existing object lifecycle of nodes. 
This also has the advantage of being separate from the osg core and not
requiring as much buy-in from Robert if he doesn't like it :-)

Cheers,
Pete

On 1/28/2011 4:54 AM, Sukender wrote:
> Hi Robert, hi (SELECT name FROM "OSG_USERS" WHERE name<>"Robert Osfield";),
>
> ** Context **
> I spotted the DAE plugin is able to "return" some values to the calling 
> program by writing in the "plugin data" (options->getPluginData()). But when 
> writing, this plugin data is... const! This thus requires an ugly and unsafe 
> const_cast<> (or an even uglier C-style cast). In other words: readers should 
> not return any value except the scene graph itself, or generally speaking 
> "predefined return values". I also think that using "void*" is just a 
> maintanability pain, with high risks of writing unallocated memory parts, and 
> such.
>
> ** Topic **
> More generally, it is hard to store and pass "not predifined" variables 
> between main program and plugins, or between OSG itself and the main program 
> (I mean "adding some type-safe user values to the graph").
> This makes me think about something I discussed a bit before: the ability to 
> handle "metadata" in OSG (post named "Suggestion: Add components in nodes 
> (aggregation)"). To sum up the discussion, it was roughly said that "it's on 
> user side", and "use userData!".
>
> However, the "meta" system I implemented for my app is now quite used and 
> stable. I want it to be open sourced so that partners using OSG also have 
> access to metadata, and I propose this to be integrated. But I don't wan't to 
> simply copy-paste it into a submission; I'd like to have a real reflexion 
> around it, to make it useable for all. After all, more and more file formats 
> handle these metas, so why not OSG, as long as it does not disturb existing 
> features?
>
> ** Ideas **
> So... starting the reflexion, I have a few ideas:
>
> 1. What is a meta?
> A meta is a "name/typed value" pair. Possible implementation is to have a 
> base class (with the name, say "MetaBase"), and several derived (Meta, 
> deriving from MetaBase, and then Meta...). There could be as 
> many meta types as you wish, but only a few "standard" ones should be defined 
> in OSG (int, double, string...).
>
> 2. How to store them (the container)?
> 2.1. Have a simple, yet easy and stable way: a basic container (vector/list). 
> Duplicate meta names should be handled on user's side if necessary.
> 2.2. Have a name->value map. Implementation may be a bit less flexible, but 
> this ensures faster lookup (is this necessary?), and name unicity (is this 
> necessary?).
> 2.3. Other ideas: multimap, unordered_map, etc.
> 2.4. Have a user-defined container. That way, user may ask for a simple 
> vector, or a very complex DataBase-type container. As my colleague told me: 
> "usages can be too different to tell beforehand the container type". This is 
> surely a good idea, but how to implement it? Work with iterators? Have a 
> container base class? Use templates somewhere? Help!
>
> FYI: my implementation uses a vector container (having generally less than 
> 10-20 metas in a container), with the MetaBase / Meta idea.
>
> 3. Where to store them?
> - Maybe there is a need to store them just in another variable, alongside 
> userData. This is one of my needs, but I still can use userData as I do, even 
> if that's not as clean as having directly a container in osg::Object. Note: 
> to avoid burdening osg::Object too much, this could be a ref_ptr<> to a 
> container.
> - Maybe there is a need for ReaderWriters, as I told at the begining of my 
> email? I guess so, but this does not solve the "constness" problem if put in 
> the

Re: [osg-users] Simultanious use of TrackballDragger and TranslateAxisDragger

[Jean-Sébastien Guay]

Hi David,


Thanks! It turns out that I had it almost right. It was adding the scaling to 
the translateaxis that made it work. I did not know that was necessary.


Well, it wouldn't have been necessary if the TrackballDragger didn't 
have an invisible sphere in the middle.


If you look at the way it creates the geometry used for intersection 
(the one that's set to always cull), it has 3 cylinders for constrained 
rotation around one axis each, and a sphere in the middle for 
unconstrained rotation. This sphere is pretty much the same size as the 
axes of the TranslateAxisDragger, so it receives clicks before the axes 
(because from most points of view the surface of the sphere will be 
intersected before the axes). Also we found that people wanted to be 
able to click on the translation axes inside the rotation cylinders, and 
so the sphere was really in the way (and since it's invisible, users 
were confused when the object would start rotating when they clicked 
there). So we subclassed the TrackballDragger to remove that sphere, as 
I said in my previous message.


So, the scale was not strictly required, it's just that in your case, 
since the sphere is still there, it makes the axes larger than the 
sphere and therefore clickable.


BTW, one way I found to debug these interaction problems was to subclass 
the draggers, copy the contents of the setupDefaultGeometry() method 
from the base class to the derived one, and comment out the 
setDrawableToAlwaysCull() calls. That way you will see what geometry is 
used for the intersection tests, and it will become clear why the 
dragger is behaving the way it is. In your case, you would have seen 
that the TrackballDragger's sphere was completely encompassing the 
TranslateAxisDragger's axes, so that's why that dragger was never 
getting any intersections.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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

[osg-users] Tonemapping, RTT, PixelDataBufferObject, GPU-CPU copy pixel value

[Dan Warrior]

Hi,

I have implemented the global tonemapping operator (Reinhard). For this task I 
use a downsampling pass which downsamples the input texture (with log luminance 
per pixel) to a 1x1 texture computing the avarage log luminance of the input 
texture. The next step, I try to do, is to copy the avarage log luminance from 
the 1x1 texture from the GPU to an array in the main application. I have to 
store the average log luminance for the last n frames. These values can then be 
used to compute the adaptive temporal tonemapping. 



Code:

// first create the 1x1 output texture for the avarage log luminance
osg::ref_ptr tmLogLumAvarageTex = new osg::Texture2D();
tmLogLumAvarageTex->setTextureSize(1, 1);
tmLogLumAvarageTex->setInternalFormat(GL_LUMINANCE16F_ARB);
tmLogLumAvarageTex->setSourceFormat(GL_RGBA);
tmLogLumAvarageTex->setSourceType(GL_FLOAT);

// downsampling pass
// 

// capture the state set from the final downsampling pass
osg::ref_ptr< osg::StateSet > currentStateSet = new osg::StateSet();
currentStateSet = 
tmTexDownSampPass->getPassByIndex(tmTexDownSampPass->getNumOfPasses()-1)->getCamera()->getStateSet();
// capture the state from the final downsampling pass' state set
osg::ref_ptr< osg::State > currentState = new osg::State();
currentState->captureCurrentState(*currentStateSet);

float pixelData[4];

// create pixelbuffer object to copy the content from texture 
// and copy the buffer's content to a data pointer
osg::PixelDataBufferObject* pdbo = new osg::PixelDataBufferObject();
// bind buffer in write mode and copy texture content into the buffer (write to 
buffer)
pdbo->bindBufferInWriteMode(*currentState); // GL_PIXEL_PACK_BUFFER_ARB
currentState->applyTextureAttribute(/*unit*/ 0, /*texture*/ 
tmLogLumAvarageTex.get()); 
// copy content from texture to the pbo 
glGetTexImage(GL_TEXTURE_2D, 0, GL_LUMINANCE16F_ARB, GL_FLOAT, 
pixelData);
pdbo->unbindBuffer(currentState->getContextID()); 





The screen stays black and I get the following message when I run my program:
"Warning: TextureRectangle::apply(..)  failed, texture rectangle is not support 
by your OpenGL drivers"

Please help!!!

Thank you!

Cheers,
Dan

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





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

[osg-users] OpenSceneGraph 2.9.11 dev release tagged

[Robert Osfield]

Hi All,

I'm delighted to announce that I have just tagged the 2.9.11 dev
release, which you can grab with:

source package : OpenSceneGraph-2.9.11.zip
svn tag: svn co
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.9.11
OpenSceneGraph

As usual these details can be found on the DeveloperReleases page on
the OSG website:

   http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases

I haven't added the specific details on what goes in 2.9.11 vs 2.9.10
yet, but will do this later - right now I have to head out the door to
go coach some kids how to run cross country races!

Thanks to all those who's helped test, debug and improve the OSG since
2.9.11.  We're now getting very very close to a feature freeze and
3.0.0-rc1 :-)

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

Re: [osg-users] OSG 2.9.10 on iOS

[Stephan Maximilian Huber]

Hi

to clarify my previous post: here are all cmake-vars needed to get a
xcodeproject-file from cmake which is suitable for the iphone-device and
GLES 1:

/usr/bin/cmake -G Xcode \
  -D OSG_BUILD_PLATFORM_IPHONE:BOOL=ON \
  -D 'CMAKE_CXX_FLAGS:STRING=-ftree-vectorize
-fvisibility-inlines-hidden -mno-thumb -arch armv6 -pipe -no-cpp-precomp
-miphoneos-version-min=3.1 -mno-thumb'  \
  -D OSG_BUILD_FRAMEWORKS:BOOL=OFF \
  -D OSG_WINDOWING_SYSTEM:STRING=IOS \
  -D 'CMAKE_OSX_ARCHITECTURES:STRING=armv6;armv7'  \
  -D
CMAKE_OSX_SYSROOT:STRING=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
 \
  -D OSG_GL1_AVAILABLE:BOOL=OFF  \
  -D OSG_GL2_AVAILABLE:BOOL=OFF  \
  -D OSG_GLES1_AVAILABLE:BOOL=ON  \
  -D OSG_GL_DISPLAYLISTS_AVAILABLE:BOOL=OFF \
  -D OSG_GL_FIXED_FUNCTION_AVAILABLE:BOOL=ON \
  -D OSG_GL_LIBRARY_STATIC:BOOL=OFF  \
  -D OSG_GL_MATRICES_AVAILABLE:BOOL=ON \
  -D OSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE:BOOL=ON \
  -D OSG_GL_VERTEX_FUNCS_AVAILABLE:BOOL=OFF
  -D DYNAMIC_OPENTHREADS:BOOL=OFF
  -D DYNAMIC_OPENSCENEGRAPH:BOOL=OFF .

cheers,

Stephan

Am 28.01.11 12:19, schrieb Stephan Maximilian Huber:
> Hi,
> 
> Am 27.01.11 12:58, schrieb Alessandro Terenzi:
>> I tried again with the latest OSG source from svn but I still have problems.
>> I followed the instructions in the README.txt and also:
>>
>>  1) removed  "-mmacosx-version-min=10.5" from CMAKE_CXX_FLAGS
>>  2) tried with either OSG_GLES1_AVAILABLE or OSG_GLES2_AVAILABLE
>>  3) tried with either OSG_GL_DISPLAYLISTS_AVAILABLE on or off
>>  4) tried to set the base SDK as the 4.1
>>  5) set to use armv6;armv7 architectures because I want to build for the
>> device
>>
>> but:
>>
>>  a) after configuring, CMAKE complains with the OPENGLES_LIBRARY_NOTFOUND
>> message
> 
> you can ignore this message.
> 
> 
>>  b) after generating the project, I still see that the base SDK is 3.2 (so I
>> manually change it to 4.1)
> 
> 
>>  c) if I build in Xcode, everything is fine with OpenThreads, but as soon as
>> I build osg, I get lots of errors regarding OpenGL
> 
> With cmake it's only possible to create project files for the simulator
> OR the device. Check the setting inside xcode, they have to correspond,
> otherwise you'll get a lot of compile-errors.
> 
> Be sure to set the OSG_GL_flags correct. I am using these values for
> OSG_GLES1_AVAILABLE: (set the other OSG_GL*_AVAILABLE to off
> 
> OSG_GL_DISPLAYLISTS_AVAILABLE:BOOL=OFF
> OSG_GL_FIXED_FUNCTION_AVAILABLE:BOOL=ON
> OSG_GL_LIBRARY_STATIC:BOOL=OFF
> OSG_GL_MATRICES_AVAILABLE:BOOL=ON
> OSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE:BOOL=ON
> OSG_GL_VERTEX_FUNCS_AVAILABLE:BOOL=OFF
> 
>>  d) moreover, beyond osgversion and present3D, no other applications'
>> targets are in the project
> 
> Did you enable OSG_BUILD_EXAMPLES in CMake? There's only one example for
> IOS, which does not work out of the box, but you can tweak the
> configuration in xcode to get it compiling and linking. I failed when
> trying to get the cmake-configuration right for the example-app.
> 
> HTH,
> Stephan
> ___
> 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] Calling OSX Dev's, Cocoa/Carbon support required for new osgGA feature

[Robert Osfield]

Hi Stephan,

On Fri, Jan 28, 2011 at 1:15 PM, Stephan Maximilian Huber
 wrote:
> AFAIK they are ready. Please merge, so others have to test the new code. ;-)

Thanks Stephan, changes now merged and submitted to svn/trunk.

Unfortunately I credited Ulrich Hertlein with the submission, sorry
about that - I merged changes from Ulrich earlier today and must have
not rebooted my brain properly between each submission...

 Thanks for the changes,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Linker error during execution

[Mourad Boufarguine]

Hi Mukund,

I do not see the vcproj file. I think it is a problem in the config rather
than in the code itself.

Mourad


On Fri, Jan 28, 2011 at 12:49 PM, Mukund Keshav  wrote:

> Hi Mourad,
>
> Thanks for the reply. i have attached the project file and the source file.
>
> ...
>
> Hi Shayne
>
> >>Unless you're debugging into OSG code, I would not use the debug
> libraries.
>
>
> Well i am very new to OSG. im still looking into the classes. So i am still
> executing in the debug mode.
>
> Thanks,
> Mukund
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=36096#36096
>
>
>
>
> Attachments:
> http://forum.openscenegraph.org//files/test_676.cpp
>
>
> ___
> 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] Calling OSX Dev's, Cocoa/Carbon support required for new osgGA feature

[Stephan Maximilian Huber]

Hi Robert,

Am 28.01.11 13:26, schrieb Robert Osfield:

> Thanks for the changes.  Do you feel they are ready to merge?

AFAIK they are ready. Please merge, so others have to test the new code. ;-)

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

Re: [osg-users] Calling OSX Dev's, Cocoa/Carbon support required for new osgGA feature

[Stephan Maximilian Huber]

Hi Robert,

Am 28.01.11 13:35, schrieb Robert Osfield:
> I have now fixed this and checked it into svn/trunk.  Could you please
> do an svn update and let me know if it's fixed now.

Thanks for the fix -- works fine now.

cheers,
Stephan

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

Re: [osg-users] Calling OSX Dev's, Cocoa/Carbon support required for new osgGA feature

[Robert Osfield]

Hi Stephan,

On Fri, Jan 28, 2011 at 11:07 AM, Stephan Maximilian Huber
 wrote:
> P.S. as reported before the default-font is currently broken, see
> attached screenshot.

I have now fixed this and checked it into svn/trunk.  Could you please
do an svn update and let me know if it's fixed now.

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

Re: [osg-users] Calling OSX Dev's, Cocoa/Carbon support required for new osgGA feature

[Robert Osfield]

Hi Stephan,

Thanks for the changes.  Do you feel they are ready to merge?

Robert.

On Fri, Jan 28, 2011 at 11:07 AM, Stephan Maximilian Huber
 wrote:
> Hi all,
>
> I adapted the Cocoa implementation so that it reports the unmodified key
> and the modified key as requested. Can other OS X developers please test
> the attached file, to make sure it works for everybody?
>
> I fixed the problem with the caps-lock-key, too.
>
> P.S. as reported before the default-font is currently broken, see
> attached screenshot.
>
> cheers,
> Stephan
>
>
> Am 27.01.11 17:40, schrieb Robert Osfield:
>> Hi OSX dev's,
>>
>> This afternoon I merged a submission from Alexander Sinditskiy, that
>> addressed a limitation in osgGA::GUIEventAdapter where the getKey()
>> method would return only the modified variation of the keycode that
>> was pressed - so this would be Ctrl-C, 'C' or 'c', and if your you
>> didn't want to worry about the modified key status you'd have to
>> handle each of these cases in your event code.
>>
>> The way that Alexander addressed this was to add a new UnmodifiedKey
>> property to GUIEventAdapter, with support added to the
>> osgGA::EventQueue as well as the X11 and Win32 implementations found
>> in GraphicsWindowX11.cpp and GraphicsWindowWin32.cpp.  Alexander and
>> his colleagues don't have access to OSX so couldn't add the required
>> support into GraphicsWindowCocoa/Carbon so for now you'll just get a 0
>> for the UnmofidiedKey.
>>
>> Now this won't affect most apps as they won't yet be using the
>> UnmodifiedKey property, but osgkeyboard has now been modified to use
>> the UnmodifiedKey property as this illustrates it's usage and also
>> simplifies the example as it no longer needs to doing multiple
>> mappings to handle upper and lower case letters.  However, osgkeyboard
>> will now just get a 0 for UnmodifiedKey so the keys on screen won't
>> toggle on/off correctly.  At least this is what I'm expecting - I
>> don't have on OSX box in front of me so I can't test this.
>>
>> Could OSX users try out OSG in svn/trunk and run osgkeyboard and see
>> how things behave and then have a look into the possibility of
>> providing the UmodifiedKey property as GraphicsWindowWin32.cpp and
>> GraphicsWindowX11.cpp now do.  The unmodified keys now map the 'A' and
>> 'a' to be 'a', X11 is already uses this convention while Win32 have
>> 'A' as the unmodified state, but Alexander's revision addresses this
>> so both produce an GUIEventAdapter::KEY_A which is mapped to 'a'.  OSX
>> will need to use the same convention.
>>
>> Thanks in advance with any help you can provide in adding this
>> functionality to OSX.
>>
>> Cheers,
>> 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] lose texture when load 3ds or obj files

[Alberto Luaces]

"Tysen Chan" writes:

> I Load a 3ds file into osg. The file contain a model with texture.  I use 
> readNodeFile function. but when i load the file to osg ,the texture is 
> losing. why and how to solve it. is there has example about this ?

It's fine as it is. Look executing the program from a console if the
program can reach the texture files.

-- 
Alberto

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

Re: [osg-users] Linker error during execution

[Mukund Keshav]

Hi Mourad,

Thanks for the reply. i have attached the project file and the source file.

...

Hi Shayne

>>Unless you're debugging into OSG code, I would not use the debug libraries.


Well i am very new to OSG. im still looking into the classes. So i am still 
executing in the debug mode. 

Thanks,
Mukund

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




Attachments: 
http://forum.openscenegraph.org//files/test_676.cpp


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

Re: [osg-users] Please test svn/trunk in prep for 2.9.11 dev release

[Per Fahlberg]

Hi Robert,

Thanks for merging. I was thinking of posting to osg-submission but I 
was afraid it wouldn't make it into 2.9.11 if you decided to go for 
2.9.11 today, next time I'll cross post to both lists.


Regards,
Per

On 01/28/2011 12:10 PM, Robert Osfield wrote:

Hi Per,

I've merged the changes to daeWriter.cpp and ConvertFromPerformer.cpp,
but the change to domSourceReader.h shouldn't be required as I've just
merged a similar fix from Ulrich Hertlein.

For further submissions could you post them to osg-submissions as it's
a more reliable way of making sure I spot the submission as I can
occasionally miss posts due to the number that pour in each day.

Thanks,
Robert,

On Thu, Jan 27, 2011 at 8:37 PM, Per Fahlberg  wrote:
   

Hi Robert,

The dae plugin is giving me a couple of errors and warnings with gcc 4.4.4.
I have attached a modifed file that removes the errors and warnings.

I've also attached a minor warning fix in the pfb plugin.

With the attached fixes the OSG compiles warning and error free with gcc
4.4.4.

Regards,
Per

On 01/27/2011 07:51 PM, Robert Osfield wrote:
 

Hi All,

I'm going to have another attempt at making 2.9.11 tomorrow, as I'm
now back up to date with submissions and bug fixes.

Could users test svn/trunk and let me know how you get on across
platfroms?

Thanks,
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] OSG 2.9.10 on iOS

[Stephan Maximilian Huber]

Hi,

Am 27.01.11 12:58, schrieb Alessandro Terenzi:
> I tried again with the latest OSG source from svn but I still have problems.
> I followed the instructions in the README.txt and also:
> 
>  1) removed  "-mmacosx-version-min=10.5" from CMAKE_CXX_FLAGS
>  2) tried with either OSG_GLES1_AVAILABLE or OSG_GLES2_AVAILABLE
>  3) tried with either OSG_GL_DISPLAYLISTS_AVAILABLE on or off
>  4) tried to set the base SDK as the 4.1
>  5) set to use armv6;armv7 architectures because I want to build for the
> device
> 
> but:
> 
>  a) after configuring, CMAKE complains with the OPENGLES_LIBRARY_NOTFOUND
> message

you can ignore this message.


>  b) after generating the project, I still see that the base SDK is 3.2 (so I
> manually change it to 4.1)


>  c) if I build in Xcode, everything is fine with OpenThreads, but as soon as
> I build osg, I get lots of errors regarding OpenGL

With cmake it's only possible to create project files for the simulator
OR the device. Check the setting inside xcode, they have to correspond,
otherwise you'll get a lot of compile-errors.

Be sure to set the OSG_GL_flags correct. I am using these values for
OSG_GLES1_AVAILABLE: (set the other OSG_GL*_AVAILABLE to off

OSG_GL_DISPLAYLISTS_AVAILABLE:BOOL=OFF
OSG_GL_FIXED_FUNCTION_AVAILABLE:BOOL=ON
OSG_GL_LIBRARY_STATIC:BOOL=OFF
OSG_GL_MATRICES_AVAILABLE:BOOL=ON
OSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE:BOOL=ON
OSG_GL_VERTEX_FUNCS_AVAILABLE:BOOL=OFF

>  d) moreover, beyond osgversion and present3D, no other applications'
> targets are in the project

Did you enable OSG_BUILD_EXAMPLES in CMake? There's only one example for
IOS, which does not work out of the box, but you can tweak the
configuration in xcode to get it compiling and linking. I failed when
trying to get the cmake-configuration right for the example-app.

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

Re: [osg-users] Please test svn/trunk in prep for 2.9.11 dev release

[Robert Osfield]

Hi Per,

I've merged the changes to daeWriter.cpp and ConvertFromPerformer.cpp,
but the change to domSourceReader.h shouldn't be required as I've just
merged a similar fix from Ulrich Hertlein.

For further submissions could you post them to osg-submissions as it's
a more reliable way of making sure I spot the submission as I can
occasionally miss posts due to the number that pour in each day.

Thanks,
Robert,

On Thu, Jan 27, 2011 at 8:37 PM, Per Fahlberg  wrote:
> Hi Robert,
>
> The dae plugin is giving me a couple of errors and warnings with gcc 4.4.4.
> I have attached a modifed file that removes the errors and warnings.
>
> I've also attached a minor warning fix in the pfb plugin.
>
> With the attached fixes the OSG compiles warning and error free with gcc
> 4.4.4.
>
> Regards,
> Per
>
> On 01/27/2011 07:51 PM, Robert Osfield wrote:
>>
>> Hi All,
>>
>> I'm going to have another attempt at making 2.9.11 tomorrow, as I'm
>> now back up to date with submissions and bug fixes.
>>
>> Could users test svn/trunk and let me know how you get on across
>> platfroms?
>>
>> Thanks,
>> 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] Android Development Plans

[Thomas Hogarth]

Hi Jason

Never mind found it in the native-activity example. I also found this thread

http://groups.google.com/group/android-ndk/browse_thread/thread/3c6dd147547ce056/b9d27d086990d1b1

It
says you need a 2.3 device, hope it's not true as mine is 2.2 :(

Cheers
Tom

On 28 January 2011 09:48, Thomas Hogarth  wrote:

> Hi Jason
>
> >>Yeah, I just downloaded and looked through it.  There's an example
> >>without a single Java class in it.  It just goes straight to EGL and
> >>GLES2 in the .c file.  Very cool!
>
> I've looked through my samples and I can't find this. I've got the
> hello-gl2 sample but no other gl related ones, could you point me in the
> right direction?. I've spotted the stl sample though, which is nice :).
>
> Cheers
> Tom
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] What is the difference between the first and the next instantiations of a view?

[Robert Osfield]

Hi Werner,

It sounds to me like there is an issue with the osg::State::ContextID
not being incremented for each of these contexts, resulting in the OSG
uses the same ConextID for both, and as consequence using the same
display lists + texture objects for both contexts, even though GL
isn't set up by the AdapterWidget code to share them.

Personally I wouldn't recommend using AdapterWidget for anything other
than single context, single threaded apps.  In svn/trunk we'd actually
removed the example that uses AdapterWidget and instead with have a
osgQt library that provides a GraphicsWindowQt implementation that is
more flexible and feature rich.

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

[osg-users] Discussion: metadata & readerwriters output

[Sukender]

Hi Robert, hi (SELECT name FROM "OSG_USERS" WHERE name<>"Robert Osfield";),

** Context **
I spotted the DAE plugin is able to "return" some values to the calling program 
by writing in the "plugin data" (options->getPluginData()). But when writing, 
this plugin data is... const! This thus requires an ugly and unsafe 
const_cast<> (or an even uglier C-style cast). In other words: readers should 
not return any value except the scene graph itself, or generally speaking 
"predefined return values". I also think that using "void*" is just a 
maintanability pain, with high risks of writing unallocated memory parts, and 
such.

** Topic **
More generally, it is hard to store and pass "not predifined" variables between 
main program and plugins, or between OSG itself and the main program (I mean 
"adding some type-safe user values to the graph").
This makes me think about something I discussed a bit before: the ability to 
handle "metadata" in OSG (post named "Suggestion: Add components in nodes 
(aggregation)"). To sum up the discussion, it was roughly said that "it's on 
user side", and "use userData!".

However, the "meta" system I implemented for my app is now quite used and 
stable. I want it to be open sourced so that partners using OSG also have 
access to metadata, and I propose this to be integrated. But I don't wan't to 
simply copy-paste it into a submission; I'd like to have a real reflexion 
around it, to make it useable for all. After all, more and more file formats 
handle these metas, so why not OSG, as long as it does not disturb existing 
features?

** Ideas **
So... starting the reflexion, I have a few ideas:

1. What is a meta?
A meta is a "name/typed value" pair. Possible implementation is to have a base 
class (with the name, say "MetaBase"), and several derived (Meta, deriving 
from MetaBase, and then Meta...). There could be as many meta 
types as you wish, but only a few "standard" ones should be defined in OSG 
(int, double, string...).

2. How to store them (the container)?
2.1. Have a simple, yet easy and stable way: a basic container (vector/list). 
Duplicate meta names should be handled on user's side if necessary.
2.2. Have a name->value map. Implementation may be a bit less flexible, but 
this ensures faster lookup (is this necessary?), and name unicity (is this 
necessary?).
2.3. Other ideas: multimap, unordered_map, etc.
2.4. Have a user-defined container. That way, user may ask for a simple vector, 
or a very complex DataBase-type container. As my colleague told me: "usages can 
be too different to tell beforehand the container type". This is surely a good 
idea, but how to implement it? Work with iterators? Have a container base 
class? Use templates somewhere? Help!

FYI: my implementation uses a vector container (having generally less than 
10-20 metas in a container), with the MetaBase / Meta idea.

3. Where to store them?
- Maybe there is a need to store them just in another variable, alongside 
userData. This is one of my needs, but I still can use userData as I do, even 
if that's not as clean as having directly a container in osg::Object. Note: to 
avoid burdening osg::Object too much, this could be a ref_ptr<> to a container.
- Maybe there is a need for ReaderWriters, as I told at the begining of my 
email? I guess so, but this does not solve the "constness" problem if put in 
the Options structure. Or maybe we should provide ReaderWriter a non const 
container to play with?

4. How to serialize/deserialize them?
I personnally have straightforward "toString()/fromString()" methods to convert 
back and forth. This is then used by my own plugins to read/write those metas. 
This is certainly not the best implementation, but surely the simplest. Another 
idea would be make plugins (or other code) directly read values and 
(de)serialize them as they want; however, I suggest to keep the 
"toString()/fromString()" methods in order to handle unknown types.

Many thanks to those who have read entirety this text.
More thanks for your thougts/ideas/remarks/insults(?)/comments/whatever.

Cheers,

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Android Development Plans

[Thomas Hogarth]

Hi Jason

>>Yeah, I just downloaded and looked through it.  There's an example
>>without a single Java class in it.  It just goes straight to EGL and
>>GLES2 in the .c file.  Very cool!

I've looked through my samples and I can't find this. I've got the hello-gl2
sample but no other gl related ones, could you point me in the right
direction?. I've spotted the stl sample though, which is nice :).

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

[osg-users] What is the difference between the first and the next instantiations of a view?

[Werner Modenbach]

Hi all,

is there any diffenrence when instanciation a second instance of a view 
(Qt and AdapterWidget)

compared to the first one?
I'm experiencing strange effects (models are drawn with random 
vertices) in the second window.
The same model in the same display class creates this reproducable 
problem.
The same happens when I delete my first instance and recreate it. Also 
any further instances 3,4,5, ..) show the same behaviour.


Is there any initialization skipped in the second instance? I.e. maybe 
because of the existance of global variables?


I'm spending now many days allready on that and I'm seriously running 
out of ideas.


Thanks for any hints.

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

Re: [osg-users] MinimalShadowMap and specular

[Cyril Bondue]

Hi Wojtek, thank you very much!
Specular is now rendered using StandardShadowMap sub classes, works like a 
charm :)
I simply recompiled OSG (no warnings) and did not change anything else, i 
attached the new render, nice job Wojtek! thanks!

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




Attachments: 
http://forum.openscenegraph.org//files/minimalshadowmap_specular_210.jpg


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

Re: [osg-users] [vpb] Build VPB Issue

[Robert Osfield]

Hi Jamil,

VirtualPlanetBuilder's (VPB) main dependencies are the OSG and GDAL,
when you install these, or point VPB at them with env vars or CMake
settings.  You'll need both the libs and the headers, when using a
debian based distro like Ubuntu you'll want to use something like:

sudo apt-get install libgdal1-dev

Robert.

On Fri, Jan 28, 2011 at 5:37 AM, jamil farooq  wrote:
> Hi,
>
> I am trying to build VirtualPlanetBuilder in ubuntu 10.04 by writing
> ./configure command in Terminal and getting this error can anyone
> guide my wot is wrong with configure. I have already installed OSG
> and libgdal both.
>
>
>
>
>
> CMake Error: The following variables are used in this project, but they are 
> set to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the CMake 
> files:
> GDAL_LIBRARY
>    linked by target "vpb" in directory 
> /media/software_/projects/flightgear/VirtualPlanetBuilder/src/vpb
>    linked by target "application_osgdem" in directory 
> /media/software_/projects/flightgear/VirtualPlanetBuilder/applications/osgdem
>    linked by target "application_vpbcache" in directory 
> /media/software_/projects/flightgear/VirtualPlanetBuilder/applications/vpbcache
>    linked by target "application_vpbsizes" in directory 
> /media/software_/projects/flightgear/VirtualPlanetBuilder/applications/vpbsizes
>    linked by target "application_vpbmaster" in directory 
> /media/software_/projects/flightgear/VirtualPlanetBuilder/applications/vpbmaster
>
> -- Configuring incomplete, errors occurred!
>
>
>
> Thank you!
>
> Cheers,
> fly_hi
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=36073#36073
>
>
>
>
>
> ___
> 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] osgShadow under OS/X

[Alessandro Terenzi]

Hi,
I know this is quite an old topic, anyway I'm experiencing exactly the same
problems as Adrian BUT I'm using the latest svn/trunk code (downloaded just
yesterday).

I can also add that if I execute osgshadow with the --SingleThreaded switch
then the artifacts are not there anymore.

I use a MacBook Pro (i3) with a NVIDIA GeForce GT 330M and Mac OS X 10.6.5.

Regards.
Alessandro

On Mon, Oct 1, 2007 at 10:46 PM, Adrian Egli <3dh...@gmail.com> wrote:

> hi robert,
>
> i come from testing the osg under OS/X. all osgShadow doesn't work well, or
> it doesn't work at all on my mac book pro (ATI X1600, ... )
> the whole scene is black, and only black. if i add --sv as parameter then
> it seems to work, but with hundereds of artefacts.
>
> did we change anything in the past, texturing, ... ... ...
>
> /regards
> adegli
>
> --
> 
> Adrian Egli
> ___
> 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] Please test svn/trunk in prep for 2.9.11 dev release

[Thomas Hogarth]

Hi Robert


> I'll install latest drivers etc after my breakfast and try running on my
> other box. Will let you know what happens.
>

So upgrading to the latest drivers has sorted the problem, wonder what the
cause was?

So for anyone else with blank full screen on nvidia card an upgrade from
258.96 to 266.58 drivers has sorted the issue for me. (They sound pretty old
so guess was my own fault :) )

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

Re: [osg-users] Please test svn/trunk in prep for 2.9.11 dev release

[Thomas Hogarth]

Hi Robert

I've had a bit of a strange issue with the latest trunk and probably one you
don't want to hear right now :).

Every example that runs full screen, gives me one frame (ish), then the
screen goes black. Any windowed apps and my own code all seem fine (i.e.
CompositeView example works, cubemap does not). I haven't yet tried running
the broken apps in windowed mode but I get the feeling they will work, I'm
just not seeing the fullscreen mode.

It's been ages since I ran anything on Windows so could have been like it
for a while. The build/hardware specs are

Built with VS 2008 on 32 bit windows
Hardware is Intel based MacBook running windows 7 via boot camp, Geforce
9400M, driver version 258.96.

I'll install latest drivers etc after my breakfast and try running on my
other box. Will let you know what happens.

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

[osg-users] [vpb] Build VPB Issue

[jamil farooq]

Hi,

I am trying to build VirtualPlanetBuilder in ubuntu 10.04 by writing
./configure command in Terminal and getting this error can anyone
guide my wot is wrong with configure. I have already installed OSG 
and libgdal both.





CMake Error: The following variables are used in this project, but they are set 
to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake 
files:
GDAL_LIBRARY
linked by target "vpb" in directory 
/media/software_/projects/flightgear/VirtualPlanetBuilder/src/vpb
linked by target "application_osgdem" in directory 
/media/software_/projects/flightgear/VirtualPlanetBuilder/applications/osgdem
linked by target "application_vpbcache" in directory 
/media/software_/projects/flightgear/VirtualPlanetBuilder/applications/vpbcache
linked by target "application_vpbsizes" in directory 
/media/software_/projects/flightgear/VirtualPlanetBuilder/applications/vpbsizes
linked by target "application_vpbmaster" in directory 
/media/software_/projects/flightgear/VirtualPlanetBuilder/applications/vpbmaster

-- Configuring incomplete, errors occurred!



Thank you!

Cheers,
fly_hi

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





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

Re: [osg-users] Android Development Plans

[Thomas Hogarth]

Hi Chuck

Must have missed that info when I downloaded it, looks like I need to do a
bit more reading :)

Thanks for the heads up
Tom
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org