Re: [osg-users] (no subject)

2018-05-02 Thread Robert Osfield
Hi Oran,

When optimizing OSG applications most of the task is really about
optimizing the scene graph to address bottlenecks.  You've taken the
first step in look at high level cull, draw dispatch (the OSG's draw
traversal dispatch data into the OpenGL FIFO) and draw GPU stats, and
listing the various scene graph stats that cause the performance
issues.

The next step is working out how to address the performance issues,
the first step in this is to look at which element of the frame is
longest and start there as this is likely the most fruitful place to
achieve gains.  In your case I expect each of the high cull, draw
dispatch and draw GPU are all linked to how fine grained the scene
graph is set up - you have large number of scene graph level objects
relative to the number vertices and primitives being dispatched.

The most effective way to improve performance will be merge
osg::Geometry and with it simplify the scene graph structure above it.
You can only merge osg::Geometry that share the same state so this may
require some adjustment to how you manage the state of objects.
Moving state changes from osg::StateSet's/osg::Material into the
osg::Geometry as per vertex data/per PrimitiveSet data may the be the
solution, it might be that shaders might be need to help with this.

For picking, if you merge a large number of osg::Geometry then CPU
based intersection testing may end up being slower, to resolve this
you can build osg::KdTree for the osg::Geometry and then the
IntersectionVisitor will be able to use the KdTree to speed up
intersection.

If you want to pick patches then you may want to keep each patch in
it's own osg::PrimitiveSet rather than merging these.   However,
merging osg::PrimitiveSet is something that will help performance,
just like merging osg::Geometry will do.  For modern graphics hardware
it's typically best to just use a single osg::DrawElementsUShort/UInt
with GL_TRIANGLES mode for all the triangles in an osg::Geometry
rather than using triangle strips.  So if you are wanting to pick and
edit patches that you once managed at the osg::Geometry level, then
you could merge all the triangles in the original osg::Geometry into a
single osg::DrawElementUShort/UInt and then merge the osg::Geometry
data whilst not further merging any of the primitives sets.

The osgUtil::Optimizer class has a collected of visitors that can help
with merging state and geometries, and the osgUtil::MeshOptimizers can
also help with generating efficient meshes.

Robert


On 2 May 2018 at 01:31, Oran Wallace  wrote:
>
> Hi All,
>
> Been using OSG for a while and have learned a lot and enjoyed it. I
> currently have an application with uses OSG and Qt for displaying a highly
> detailed model. A database is loaded which may cause colors in the model to
> change or additional geometries to be generated.
>
> My OSG viewport is a class which subclasses from QWidget and
> osgViewer::CompisiteViewer and is embedded into a QMainWindow. This works
> fine so I've stuck with it. The application can perform most CAD-like
> operations on the model with OSG.
>
> I've finally encountered a model which brings my application to around 1-2
> fps while interacting with it. I know there are various techniques used to
> help with performance but also understand the approach depends on the
> situation. I'm currently considering a major rewrite.
>
> Scene Details:
> 1. 540k vertices
> 2. 81000 drawables
> 3. 77000 sorted drawables
> 4. 81000 fast drawables
> 5. 81000 primitive sets
> 6. 10 triangles
> 7. 37000 quad
> 8. 181000 polygon ( probably hurting a lot)
> 9. 26000 unique state sets
> 10. 73000 instance state sets
> 11. 28000 groups
>
> Cull: 113.50, Draw: 390, GPU: 355 (never seen values this high on the
> forums)
> Additionally the graph doesn't seem to rendering correctly; the largest
> "bar" is Cull and last ~10% is the Draw, which doesnt seem to match the
> values. (Probably because a single frame takes so long?)
>
> Implementation Details:
> 1. I am orthographic project as it is a "CAD" style application.
> 2. Currently all objects are within Geode->Geometry nodes, each with
> their own vertex, color, and normal arrays.
> 3. The main "mode" of the application is a "ghosted" mode which is
> applied to the walls of the model. Each wall has an osg::Material set to it
> and blending turned on.
> 4. All objects are pickable and hold a variety of property data
> (extracted from the models file or the database). I have implemented
> "picking" using the PickHandler::pick example and code.
> 5. A user often views the whole model from afar interacting with other
> Qt widgets and watch how the scene changes, occasionally they will zoom in
> on a section but are never "inside" the model. I can clearly see when view
> frustum culling is working when zooming in.
> 6. My graph is VERY flat. Nearly all object are attached to the root

Re: [osg-users] (no subject)

2017-07-03 Thread Raymond de Vries

Hi Michael,

Nice job, will certainly use it!

Cheers,
Raymond



On 7/1/2017 10:04 AM, Robert Osfield wrote:

Great work Michael :-)

On 30 June 2017 at 18:16, michael kapelko  wrote:

Hi.

TL;DR Sample OpenSceneGraph application in Web:
https://ogstudio.github.io/openscenegraph-cross-platform-guide/
Give it a try!

-- Official --

I've finished my work on the OpenSceneGraph cross-platform guide:
https://github.com/OGStudio/openscenegraph-cross-platform-guide

It contains step-by-step instructions with screenshots how to build
and run sample OpenSceneGraph application under the following
platforms:
* Linux
* macOS
* Windows
* Android
* iOS
* Web

It also contains YouTube and downloadable (MP4) videos depicting every step.

I hope this guide fills the gap of good cross-platform documentation
for OpenSceneGraph.
I plan to maintain it and update whenever something changes in the
build process. Drop me a line if anything becomes outdated and/or I
have missed it.

-- Personal --

Last year once I got the first taste of my own game editor results (
opengamestudio.org ), I realized supporting only desktop in 2017 is a
no-go. So I started to research Android support.
Since OpenSceneGraph Android samples are of pre-AndroidStudio era and
I was a newbie in Android native development, I spent literally
several months trying to get OpenSceneGraph render under Android.
Then came iOS and Web, which were just a piece of cake, compared to Android.
I realized that there may be many people who waste as many months just
to get OpenSceneGraph to mobile and web. That's why I decided to share
the knowledge in the form of detailed tutorials with screenshots and
videos of the whole process.

I hope this saves you precious time!
___
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

---
This email has been checked for viruses by AVG.
http://www.avg.com



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


Re: [osg-users] (no subject)

2017-07-01 Thread Robert Osfield
Great work Michael :-)

On 30 June 2017 at 18:16, michael kapelko  wrote:
> Hi.
>
> TL;DR Sample OpenSceneGraph application in Web:
> https://ogstudio.github.io/openscenegraph-cross-platform-guide/
> Give it a try!
>
> -- Official --
>
> I've finished my work on the OpenSceneGraph cross-platform guide:
> https://github.com/OGStudio/openscenegraph-cross-platform-guide
>
> It contains step-by-step instructions with screenshots how to build
> and run sample OpenSceneGraph application under the following
> platforms:
> * Linux
> * macOS
> * Windows
> * Android
> * iOS
> * Web
>
> It also contains YouTube and downloadable (MP4) videos depicting every step.
>
> I hope this guide fills the gap of good cross-platform documentation
> for OpenSceneGraph.
> I plan to maintain it and update whenever something changes in the
> build process. Drop me a line if anything becomes outdated and/or I
> have missed it.
>
> -- Personal --
>
> Last year once I got the first taste of my own game editor results (
> opengamestudio.org ), I realized supporting only desktop in 2017 is a
> no-go. So I started to research Android support.
> Since OpenSceneGraph Android samples are of pre-AndroidStudio era and
> I was a newbie in Android native development, I spent literally
> several months trying to get OpenSceneGraph render under Android.
> Then came iOS and Web, which were just a piece of cake, compared to Android.
> I realized that there may be many people who waste as many months just
> to get OpenSceneGraph to mobile and web. That's why I decided to share
> the knowledge in the form of detailed tutorials with screenshots and
> videos of the whole process.
>
> I hope this saves you precious time!
> ___
> 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] (no subject)

2016-04-23 Thread Marko Käning
Hi Grendah,

On 23 Apr 2016, at 15:35 , Grendah Garidi  wrote:

> hi,  I want to use Qt with OSG(2.9.12_x86VC2008) and I need a Binaries 
> library of osg version 3.x.x

do you perhaps want to consider installing all dependencies needed to build OSG 
via MSYS2 [1]
and start using the MinGW toolchain instead of Microsoft’s Visual C++?

Greets,
Marko


[1] http://msys2.github.io/___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] (no subject)

2016-02-04 Thread Robert Osfield
Hi Anders,

There is a new mechanism for managing clean up of GL objects, which in
theory should help improve management of lifetimes of GL objects.

The warning suggests that something is try to do GL call after the
context is cleaned up, I don't know yet if this is a bug in the new
code or whether the new code is just revealling an old bug elsewhere.

Could you be more specific of how to reproduce the problem as there
isn't an --ssm option supported by the osgviewer example.

Robert.


On 4 February 2016 at 09:05, Anders Backman  wrote:
> Hi all.
>
> Trying OSG 3.5.1 and I have started to get some problems with objects
> (osg::Program/osg::Shaders etc.) being de-allocated after context is
> destroyed:
>
> Error: OpenGL version test failed, requires valid graphics context.
>
>
> Sometime it crasches sometimes it just print the warning.
>
> I can reproduce it with osgViewer --ssm
>
> The only solution so far has been to keep a static reference to the camera
> in the scene, which feels a lot like a hack.
> The same code worked in 3.4.0. So as you wrote in an earlier post, this
> probably reveals something that was not deallocated before.
>
> As soon as the viewer is destroyed, it takes the camera with it. Hence the
> Context is also destroyed.
>
> Not sure how to handle this in an general way.
>
> /Anders
>
>
> --
> __
> Anders Backman, HPC2N
> 90187 Umeå University, Sweden
> and...@cs.umu.se http://www.hpc2n.umu.se
> Cell: +46-70-392 64 67
>
> ___
> 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] (no subject)

2016-02-04 Thread Anders Backman
Yep sorry. I was having some (other) issue where text was not rendered when
I had enabled shadows, so I was messing with osgViewer.cpp copying sample
code from osgShadow there.

The example that reveals the issue at shutdown is plainly osgShadow.cpp


Output:

osgshadow.exe --window 0 0 1024 768
FOV is 29.1484
Error: OpenGL version test failed, requires valid graphics context.

And a crasch. Interestingly only if you first move the camera (left mouse
move) in the graphics window.
If you do not interact with the scene, it only show the error message.

/Anders



On Thu, Feb 4, 2016 at 11:57 AM, Robert Osfield 
wrote:

> Hi Anders,
>
> There is a new mechanism for managing clean up of GL objects, which in
> theory should help improve management of lifetimes of GL objects.
>
> The warning suggests that something is try to do GL call after the
> context is cleaned up, I don't know yet if this is a bug in the new
> code or whether the new code is just revealling an old bug elsewhere.
>
> Could you be more specific of how to reproduce the problem as there
> isn't an --ssm option supported by the osgviewer example.
>
> Robert.
>
>
> On 4 February 2016 at 09:05, Anders Backman  wrote:
> > Hi all.
> >
> > Trying OSG 3.5.1 and I have started to get some problems with objects
> > (osg::Program/osg::Shaders etc.) being de-allocated after context is
> > destroyed:
> >
> > Error: OpenGL version test failed, requires valid graphics context.
> >
> >
> > Sometime it crasches sometimes it just print the warning.
> >
> > I can reproduce it with osgViewer --ssm
> >
> > The only solution so far has been to keep a static reference to the
> camera
> > in the scene, which feels a lot like a hack.
> > The same code worked in 3.4.0. So as you wrote in an earlier post, this
> > probably reveals something that was not deallocated before.
> >
> > As soon as the viewer is destroyed, it takes the camera with it. Hence
> the
> > Context is also destroyed.
> >
> > Not sure how to handle this in an general way.
> >
> > /Anders
> >
> >
> > --
> > __
> > Anders Backman, HPC2N
> > 90187 Umeå University, Sweden
> > and...@cs.umu.se http://www.hpc2n.umu.se
> > Cell: +46-70-392 64 67
> >
> > ___
> > 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
>



-- 
__
Anders Backman, HPC2N
90187 Umeå University, Sweden
and...@cs.umu.se http://www.hpc2n.umu.se
Cell: +46-70-392 64 67
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] (no subject)

2016-02-04 Thread Anders Backman
Seems that this actually caused a lot more problem than I first thought...

The fact that you need to have a valid reference while tearing down nodes,
means that our system with plugins (dll:s loaded etc) now causes problems.
The Camera it self, has references to a scene, states, (Renderer) etc, and
if I keep a reference of the Camera to last, I get crashes when the camera
destructor is called, due to the fact that most of the nodes, shaders,
programs where created (allocated) in dll:s that has already been unloaded.


So to recap:

I need a context when a node is removed (if the node contains for example a
shader/program).
If I keep a reference to the Camera (hence the context), the camera also
keep references to just about everything I put into the scenegraph, meaning
that I delay the destruction of objects very late.

Right now I do not really see a solution for this. It was working in 3.4.0.

/A

On Thu, Feb 4, 2016 at 12:25 PM, Anders Backman  wrote:

> Yep sorry. I was having some (other) issue where text was not rendered
> when I had enabled shadows, so I was messing with osgViewer.cpp copying
> sample code from osgShadow there.
>
> The example that reveals the issue at shutdown is plainly osgShadow.cpp
>
>
> Output:
>
> osgshadow.exe --window 0 0 1024 768
> FOV is 29.1484
> Error: OpenGL version test failed, requires valid graphics context.
>
> And a crasch. Interestingly only if you first move the camera (left mouse
> move) in the graphics window.
> If you do not interact with the scene, it only show the error message.
>
> /Anders
>
>
>
> On Thu, Feb 4, 2016 at 11:57 AM, Robert Osfield 
> wrote:
>
>> Hi Anders,
>>
>> There is a new mechanism for managing clean up of GL objects, which in
>> theory should help improve management of lifetimes of GL objects.
>>
>> The warning suggests that something is try to do GL call after the
>> context is cleaned up, I don't know yet if this is a bug in the new
>> code or whether the new code is just revealling an old bug elsewhere.
>>
>> Could you be more specific of how to reproduce the problem as there
>> isn't an --ssm option supported by the osgviewer example.
>>
>> Robert.
>>
>>
>> On 4 February 2016 at 09:05, Anders Backman  wrote:
>> > Hi all.
>> >
>> > Trying OSG 3.5.1 and I have started to get some problems with objects
>> > (osg::Program/osg::Shaders etc.) being de-allocated after context is
>> > destroyed:
>> >
>> > Error: OpenGL version test failed, requires valid graphics context.
>> >
>> >
>> > Sometime it crasches sometimes it just print the warning.
>> >
>> > I can reproduce it with osgViewer --ssm
>> >
>> > The only solution so far has been to keep a static reference to the
>> camera
>> > in the scene, which feels a lot like a hack.
>> > The same code worked in 3.4.0. So as you wrote in an earlier post, this
>> > probably reveals something that was not deallocated before.
>> >
>> > As soon as the viewer is destroyed, it takes the camera with it. Hence
>> the
>> > Context is also destroyed.
>> >
>> > Not sure how to handle this in an general way.
>> >
>> > /Anders
>> >
>> >
>> > --
>> > __
>> > Anders Backman, HPC2N
>> > 90187 Umeå University, Sweden
>> > and...@cs.umu.se http://www.hpc2n.umu.se
>> > Cell: +46-70-392 64 67
>> >
>> > ___
>> > 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
>>
>
>
>
> --
> __
> Anders Backman, HPC2N
> 90187 Umeå University, Sweden
> and...@cs.umu.se http://www.hpc2n.umu.se
> Cell: +46-70-392 64 67
>



-- 
__
Anders Backman, HPC2N
90187 Umeå University, Sweden
and...@cs.umu.se http://www.hpc2n.umu.se
Cell: +46-70-392 64 67
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] (no subject)

2016-02-04 Thread Robert Osfield
Hi Anders,

On 4 February 2016 at 13:19, Robert Osfield  wrote:
> However, let me investigate the bug at my end. This should clarify
> things.  I haven't had a chance to investigate yet as I've been
> testing and checking a block of work this morning.

I have tracked the problem down to the various
osgShadow::ShadowTechnique not implementing the resizeGLObjects() and
releaseGLObjects() methods that they should have been implementing all
along, this is a bug in these classes, which have been revealed by the
changes to the core OSG w.r.t release GL objects.  Fixes for these
ommissions is something I'm currently working on.  These changes would
be appropriate to older versions of the OSG as well as.

I will complete these fixes and get them checked in, once I do I'll
update this thread.

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


Re: [osg-users] (no subject)

2016-02-04 Thread Robert Osfield
Hi Anders,

On 4 February 2016 at 13:03, Anders Backman  wrote:
> Seems that this actually caused a lot more problem than I first thought...
>
> The fact that you need to have a valid reference while tearing down nodes,
> means that our system with plugins (dll:s loaded etc) now causes problems.
> The Camera it self, has references to a scene, states, (Renderer) etc, and
> if I keep a reference of the Camera to last, I get crashes when the camera
> destructor is called, due to the fact that most of the nodes, shaders,
> programs where created (allocated) in dll:s that has already been unloaded.
>
>
> So to recap:
>
> I need a context when a node is removed (if the node contains for example a
> shader/program).
> If I keep a reference to the Camera (hence the context), the camera also
> keep references to just about everything I put into the scenegraph, meaning
> that I delay the destruction of objects very late.

I wouldn't worry to much right now as I haven't yet worked out what is
going wrong in your case.  The changes to the core OSG aren't meant to
cause new restrictions on usage.  The only case where we might not be
able to retain support for is if there was originally buggy code that
was doing things wrong and somehow by luck didn't cause problems now
causes problems.  For the later case we need to find the problem in
client code.

However, let me investigate the bug at my end. This should clarify
things.  I haven't had a chance to investigate yet as I've been
testing and checking a block of work this morning.

> Right now I do not really see a solution for this. It was working in 3.4.0.

Right now just go back to OSG-3.4.0,

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


Re: [osg-users] (no subject)

2016-02-04 Thread Robert Osfield
Hi Anders et.al,

On 4 February 2016 at 14:34, Robert Osfield  wrote:
> I will complete these fixes and get them checked in, once I do I'll
> update this thread.

I have fixed the problems in osgShadow and checked in fixes to git master.

Gotta be said that some elements of the osgShadow code is right mess,
far more complicated and difficult to follow than it should be.  There
are quite a few classes in there that I should never have merged as
they really make a mockery of clean and clear class design and
implementation.  I'm wondering whether I should just remove such parts
of the OSG as we go forward.

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


Re: [osg-users] (no subject)

2015-05-25 Thread Robert Osfield
Hi Joshua,

I'm not sure what you mean by video canvas.  If you want to render a
video as a texture on a geometry then the osgmovie example is the place to
look.

Robert.

On 24 May 2015 at 21:39, Joshua Robinson shooki.robin...@gmail.com wrote:


 Howdy OSG-Users  Volcans,

 I am a newbie to OSG and need help to do :

 Add a video canvas to scale the video. It should do :
 1) Create a video canvas.
 2) Assign texture coordinates to the video canvas, I prefer manually, it
 can be automatically (function).
 Specify the number of columns and rows on your own, need to have more
 than 2.
 3) Use texture coordinate  video image rendering.

 I have no idea how, a small sample(s) code will be appreciate .

 Cheers, (oyori),
 -Joshua Robinson
 PS.  Live long and prosper.

 ___
 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] (no subject)

2015-02-04 Thread Jeremy
I am having this problem with OSG 3.3.3 and Qt5 and MSVC2013

Commenting out the #define GL_ARB_vertex_buffer_object in osg/BufferObject
does indeed allow it to compile.

On Sun, Feb 1, 2015 at 10:56 AM, Robert Osfield robert.osfi...@gmail.com
wrote:

 Hi Phileppe,

 I presume Qt5.4 is define the various GL values in it's headers as well as
 the OSG.  You could try changing the include order of the Qt and OSG
 headers to see if that can resolve the issue.  I don't have Qt5.4 on my
 system to test against so I'll have to defer to you to see if you can find
 a solution.  If you do just let me know the changes required and we can
 then discuss how to tweak the OSG or it's Qt usage to avoid the issues.

 Robert.

 On 31 January 2015 at 22:03, philippe renon philippe_re...@yahoo.fr
 wrote:

 I am also seeing this warnings multiple times:

 [ 92%] Building CXX object
 src/applications/osgearth_package_qt/CMakeFiles/application_osgearth_package_qt.dir/package_qt.cpp.obj
 In file included from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0,
  from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39,
  from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgQt/GraphicsWindowQt:17,
  from
 d:/Projects/OpenPilot/3rdparty/osgearth/src/osgEarthQt/ViewerWidget:26,
  from
 d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:26:
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:2431:0:
 warning: GL_SHADER_STORAGE_BARRIER_BIT redefined
  #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000
  ^
 In file included from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLExtensions:18:0,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/BufferObject:19,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Array:46,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Shape:21,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/KdTree:17,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/Registry:21,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/FileUtils:17,
  from
 d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:21:
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLDefines:496:0:
 note: this is the location of the previous definition
  #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000
  ^

 PS : sorry for the missing email object.




   Le Samedi 31 janvier 2015 21h44, philippe renon 
 philippe_re...@yahoo.fr a écrit :



 Hi,

 Compilation of osg 3.2.1 against Qt 5.4.0 (mingw) was working perfectly
 fine.

 After switching to 3.3.3 we are seeing this compilation error :

 In file included from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0,
  from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39,
  from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1,
  from
 d:/Projects/OpenPilot/3rdparty/osg/include/osgQt/GraphicsWindowQt:17,
  from
 d:\Projects\OpenPilot\3rdparty\osg\examples\osgviewerQt\osgviewerQt.cpp:12:
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:10653:130:
 error: 'GLintptrARB' has not been declared
  typedef void (APIENTRYP PFNGLBINDVIDEOCAPTURESTREAMBUFFERNVPROC) (GLuint
 video_capture_slot, GLuint stream, GLenum frame_region, GLintptrARB offset);

 The issue comes from a conflict between
osg/include/osg/BufferObject
 and
qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h

 within the section starting with:
#ifndef GL_ARB_vertex_buffer_object
#define GL_ARB_vertex_buffer_object

 I beleive that this issue was introduced by openscenegraph/osg
 https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c


 [image: image]
 https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c





 openscenegraph/osg
 https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c
 osg - OpenSceneGraph git mirror
 Afficher sur github.com
 

Re: [osg-users] (no subject)

2015-02-03 Thread Robert Osfield
Hi Philippe,

Unfortunately the forum has messed up the attachments.  The mailing list is
such much more reliable for attachments, alas forum's are so modern that
most new users seem to prefer it.

Could you just email me directly the changed files.

Thanks for you patience,
Robert.

On 3 February 2015 at 00:03, Philippe Renon philippe_re...@yahoo.fr wrote:

 Hi Robert,

 Thanks for the quick answers.
 Please find attached the two modified files (originals are from version
 3.3.3):
 The files are:
 - include/osg/BufferObject
 - include/osg/GLDefines

 Qt also uses the #ifdef #define pattern so switching include order might
 not be ideal (haven't tested...).

 I guess it is easier to change osg than Qt ;)
 But there is a somewhat related Qt bug open :
 https://bugreports.qt.io/browse/QTBUG-43748
 Qt unnecessarily exposes GL constants publicly.

 Regards,
 Philippe

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




 Attachments:
 http://forum.openscenegraph.org//files/4674_1422921720._672.
 http://forum.openscenegraph.org//files/4674_1422921695._155.


 ___
 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] (no subject)

2015-02-02 Thread Philippe Renon
Hi Robert,

Thanks for the quick answers.
Please find attached the two modified files (originals are from version 3.3.3):
The files are:
- include/osg/BufferObject
- include/osg/GLDefines

Qt also uses the #ifdef #define pattern so switching include order might not be 
ideal (haven't tested...).

I guess it is easier to change osg than Qt ;)
But there is a somewhat related Qt bug open : 
https://bugreports.qt.io/browse/QTBUG-43748
Qt unnecessarily exposes GL constants publicly.

Regards,
Philippe

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




Attachments: 
http://forum.openscenegraph.org//files/4674_1422921720._672.
http://forum.openscenegraph.org//files/4674_1422921695._155.


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


Re: [osg-users] (no subject)

2015-02-02 Thread Philippe Renon

robertosfield wrote:
 
 
 Could you try removing the #define GL_ARB_vertex_buffer_object line from the 
 include/osg/BufferObject header to see if that allows the Qt header to 
 compile fine.
 
 


Removing the #define GL_ARB_vertex_buffer_object line did the trick.

Fixing the GL_SHADER_STORAGE_BARRIER_BIT redefine warning is also 
straightfoward:


 
 diff --git a/include/osg/GLDefines b/include/osg/GLDefines
 index e89bd3a..11ef3d2 100644
 --- a/include/osg/GLDefines
 +++ b/include/osg/GLDefines
 @@ -493,7 +493,7 @@ typedef char GLchar;
  #endif
 
  #ifndef GL_VERSION_4_3
 -#define GL_SHADER_STORAGE_BARRIER_BIT 0x2000
 +#define GL_SHADER_STORAGE_BARRIER_BIT 0x2000
 

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





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


Re: [osg-users] (no subject)

2015-02-02 Thread Philippe Renon

robertosfield wrote:
 Hi Phileppe,
 
 
 I presume Qt5.4 is define the various GL values in it's headers as well as 
 the OSG.  You could try changing the include order of the Qt and OSG headers 
 to see if that can resolve the issue.  I don't have Qt5.4 on my system to 
 test against so I'll have to defer to you to see if you can find a solution.  
 If you do just let me know the changes required and we can then discuss how 
 to tweak the OSG or it's Qt usage to avoid the issues.
 
 Robert.
 
 


It is exactly that and I tend to include OSG first and then Qt.
Will try the other way around although fixing OSG is pretty simple (see my last 
post on that subject).

Philippe.

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





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


Re: [osg-users] (no subject)

2015-02-02 Thread Robert Osfield
Hi Phileppe,

Good to hear you've been able to fix the problems.  Could you send me the
whole modified files so I can do graphical diff to make sure I get all the
correct modifications.

Thanks,
Robert.

On 1 February 2015 at 12:08, Philippe Renon philippe_re...@yahoo.fr wrote:


 robertosfield wrote:
 
 
  Could you try removing the #define GL_ARB_vertex_buffer_object line from
 the include/osg/BufferObject header to see if that allows the Qt header to
 compile fine.
 
 


 Removing the #define GL_ARB_vertex_buffer_object line did the trick.

 Fixing the GL_SHADER_STORAGE_BARRIER_BIT redefine warning is also
 straightfoward:


 
  diff --git a/include/osg/GLDefines b/include/osg/GLDefines
  index e89bd3a..11ef3d2 100644
  --- a/include/osg/GLDefines
  +++ b/include/osg/GLDefines
  @@ -493,7 +493,7 @@ typedef char GLchar;
   #endif
 
   #ifndef GL_VERSION_4_3
  -#define GL_SHADER_STORAGE_BARRIER_BIT 0x2000
  +#define GL_SHADER_STORAGE_BARRIER_BIT 0x2000
 

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





 ___
 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] (no subject)

2015-02-01 Thread Robert Osfield
Hi Phileppe,

I presume Qt5.4 is define the various GL values in it's headers as well as
the OSG.  You could try changing the include order of the Qt and OSG
headers to see if that can resolve the issue.  I don't have Qt5.4 on my
system to test against so I'll have to defer to you to see if you can find
a solution.  If you do just let me know the changes required and we can
then discuss how to tweak the OSG or it's Qt usage to avoid the issues.

Robert.

On 31 January 2015 at 22:03, philippe renon philippe_re...@yahoo.fr wrote:

 I am also seeing this warnings multiple times:

 [ 92%] Building CXX object
 src/applications/osgearth_package_qt/CMakeFiles/application_osgearth_package_qt.dir/package_qt.cpp.obj
 In file included from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0,
  from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39,
  from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgQt/GraphicsWindowQt:17,
  from
 d:/Projects/OpenPilot/3rdparty/osgearth/src/osgEarthQt/ViewerWidget:26,
  from
 d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:26:
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:2431:0:
 warning: GL_SHADER_STORAGE_BARRIER_BIT redefined
  #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000
  ^
 In file included from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLExtensions:18:0,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/BufferObject:19,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Array:46,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Shape:21,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/KdTree:17,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/Registry:21,
  from
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/FileUtils:17,
  from
 d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:21:
 D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLDefines:496:0:
 note: this is the location of the previous definition
  #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000
  ^

 PS : sorry for the missing email object.




   Le Samedi 31 janvier 2015 21h44, philippe renon philippe_re...@yahoo.fr
 a écrit :



 Hi,

 Compilation of osg 3.2.1 against Qt 5.4.0 (mingw) was working perfectly
 fine.

 After switching to 3.3.3 we are seeing this compilation error :

 In file included from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0,
  from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39,
  from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1,
  from
 d:/Projects/OpenPilot/3rdparty/osg/include/osgQt/GraphicsWindowQt:17,
  from
 d:\Projects\OpenPilot\3rdparty\osg\examples\osgviewerQt\osgviewerQt.cpp:12:
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:10653:130:
 error: 'GLintptrARB' has not been declared
  typedef void (APIENTRYP PFNGLBINDVIDEOCAPTURESTREAMBUFFERNVPROC) (GLuint
 video_capture_slot, GLuint stream, GLenum frame_region, GLintptrARB offset);

 The issue comes from a conflict between
osg/include/osg/BufferObject
 and
qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h

 within the section starting with:
#ifndef GL_ARB_vertex_buffer_object
#define GL_ARB_vertex_buffer_object

 I beleive that this issue was introduced by openscenegraph/osg
 https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c


 [image: image]
 https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c





 openscenegraph/osg
 https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c
 osg - OpenSceneGraph git mirror
 Afficher sur github.com
 https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c
 Aperçu par Yahoo


 Regards,
 Philippe.




 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 

Re: [osg-users] (no subject)

2015-01-31 Thread Robert Osfield
Hi Philippe,

Could you try removing the #define GL_ARB_vertex_buffer_object line from
the include/osg/BufferObject header to see if that allows the Qt header to
compile fine.

Robert.

On 31 January 2015 at 20:44, philippe renon philippe_re...@yahoo.fr wrote:

 Hi,

 Compilation of osg 3.2.1 against Qt 5.4.0 (mingw) was working perfectly
 fine.

 After switching to 3.3.3 we are seeing this compilation error :

 In file included from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0,
  from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39,
  from
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1,
  from
 d:/Projects/OpenPilot/3rdparty/osg/include/osgQt/GraphicsWindowQt:17,
  from
 d:\Projects\OpenPilot\3rdparty\osg\examples\osgviewerQt\osgviewerQt.cpp:12:
 d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:10653:130:
 error: 'GLintptrARB' has not been declared
  typedef void (APIENTRYP PFNGLBINDVIDEOCAPTURESTREAMBUFFERNVPROC) (GLuint
 video_capture_slot, GLuint stream, GLenum frame_region, GLintptrARB offset);

 The issue comes from a conflict between
osg/include/osg/BufferObject
 and
qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h

 within the section starting with:
#ifndef GL_ARB_vertex_buffer_object
#define GL_ARB_vertex_buffer_object

 I beleive that this issue was introduced by openscenegraph/osg
 https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c


 [image: image]
 https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c





 openscenegraph/osg
 https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c
 osg - OpenSceneGraph git mirror
 Afficher sur github.com
 https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c
 Aperçu par Yahoo


 Regards,
 Philippe.


 ___
 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] (no subject)

2015-01-31 Thread philippe renon
I am also seeing this warnings multiple times:
[ 92%] Building CXX object 
src/applications/osgearth_package_qt/CMakeFiles/application_osgearth_package_qt.dir/package_qt.cpp.obj
In file included from 
d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0,
 from 
d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39,
 from 
d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1,
 from 
D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgQt/GraphicsWindowQt:17,
 from 
d:/Projects/OpenPilot/3rdparty/osgearth/src/osgEarthQt/ViewerWidget:26,
 from 
d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:26:
d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:2431:0:
 warning: GL_SHADER_STORAGE_BARRIER_BIT redefined
 #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000
 ^
In file included from 
D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLExtensions:18:0,
 from 
D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/BufferObject:19,
 from 
D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Array:46,
 from 
D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Shape:21,
 from 
D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/KdTree:17,
 from 
D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/Registry:21,
 from 
D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/FileUtils:17,
 from 
d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:21:
D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLDefines:496:0:
 note: this is the location of the previous definition
 #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000
 ^
PS : sorry for the missing email object.


 

 Le Samedi 31 janvier 2015 21h44, philippe renon philippe_re...@yahoo.fr 
a écrit :
   
 

 Hi,
Compilation of osg 3.2.1 against Qt 5.4.0 (mingw) was working perfectly fine.
After switching to 3.3.3 we are seeing this compilation error :
In file included from 
d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0,
 from 
d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39,
 from 
d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1,
 from 
d:/Projects/OpenPilot/3rdparty/osg/include/osgQt/GraphicsWindowQt:17,
 from 
d:\Projects\OpenPilot\3rdparty\osg\examples\osgviewerQt\osgviewerQt.cpp:12:
d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:10653:130:
 error: 'GLintptrARB' has not been declared
 typedef void (APIENTRYP PFNGLBINDVIDEOCAPTURESTREAMBUFFERNVPROC) (GLuint 
video_capture_slot, GLuint stream, GLenum frame_region, GLintptrARB offset);

The issue comes from a conflict between 
   osg/include/osg/BufferObjectand   
qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h
within the section starting with:   #ifndef GL_ARB_vertex_buffer_object
   #define GL_ARB_vertex_buffer_object
I beleive that this issue was introduced by openscenegraph/osg

|   |
|   |  |   |   |   |   |   |
| openscenegraph/osgosg - OpenSceneGraph git mirror |
|  |
| Afficher sur github.com | Aperçu par Yahoo |
|  |
|   |


Regards,Philippe.
  


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


Re: [osg-users] (no subject)

2014-10-11 Thread Chris Hanson
LineSegmentIntersector will almost never hit non-polygon geometry. A
perfect hit between a line and another line is difficult with floating
point math.

You should probably use the PolytopeIntersector (
http://trac.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00616.html
) which intersects a VOLUME representing the intersection ray against the
lines of the geometry, being much more inclusive.

PolytopeIntersector is slower of course.


On Fri, Oct 10, 2014 at 11:42 PM, jiang.sa...@gmail.com 
jiang.sa...@gmail.com wrote:

 Hi guys,

 Recently, I have build a test application based on osg 3.2 and osgEarth
 2.5 which loads some linestring geometry.
 Then I tried to calculate the spatial distance between two lines using














 *osgUtil::LineSegmentIntersector::Intersections results; if (getMapNode()
  view-computeIntersections(x, y, results, _intersectionMask)) { // find
 the first hit under the mouse:
 osgUtil::LineSegmentIntersector::Intersection first = *(results.begin());
 osg::Vec3d point = first.getWorldIntersectPoint(); double lat_rad, lon_rad,
 height;
 getMapNode()-getMap()-getProfile()-getSRS()-getEllipsoid()-convertXYZToLatLongHeight(
 point.x(), point.y(), point.z(), lat_rad, lon_rad, height); lat =
 osg::RadiansToDegrees(lat_rad); lon = osg::RadiansToDegrees(lon_rad); hgt =
 height;*
 *}*

 But always is the intersection point on terrain, not linestring.

 Do you have any suggestion to complish it ?
 Thanks!

 --
 jiang.sa...@gmail.com

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




-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography
• Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS •
Android
@alphapixel https://twitter.com/alphapixel facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] (no subject)

2014-08-02 Thread Christopher Bruns
Thanks Robert for the detailed analysis. This is very helpful.

Is there a way for me to directly access the slave cameras in my Viewer object, 
so I could, in the short term, hack in a change to the colorMasks, and thus 
perhaps not need to recompile OpenSceneGraph?

Longer term, it might be nice to add an API for setting the color mask, in 
DisplaySettings. The most direct approach would be to add methods something like
  
  
Code:
DisplaySettings.setLeftAnaglyphColorMask(bool, bool, bool)



Passing a bunch of boolean values like that smells a little bad, but it would 
expose the full constellation of possibilities presented by the underlying 
glColorMask() approach. I'm not sure what the corresponding getter method would 
look like.

Regards,
Christopher


robertosfield wrote:
 HI Christopher,
 
 Currently the ANAGLYPHIC stereo support is hardwired to red-cyan.  Curiously 
 you are the first to ask for anything else.
 
 
 To implement for other interpretations of anaglyphic you'd need to implement 
 it using osgViewer::View slave Camera's, one slave Camera for the left eye 
 and one for the right - you'd attach the appropriate osg::ColorMask for each 
 slave Camera to get the effect you want.
 
 
 The code that sets up stereo in svn/trunk can be found in 
 OpenSceneGraph/src/osgViewer/View.cpp assignStereoOrKeystoneToCamera(..) 
 method, the code block of interest looks like:
 
 
    switch(ds-getStereoMode())
     {
         case(osg::DisplaySettings::QUAD_BUFFER):
         {
             // disconect the camera from the graphics context.
             camera-setGraphicsContext(0);
 
 
             // left Camera left buffer
             osg::ref_ptrosg::Camera left_camera = assignStereoCamera(ds, 
 gc.get(), 0, 0, traits-width, traits-height, traits-doubleBuffer ? 
 GL_BACK_LEFT : GL_FRONT_LEFT, -1.0);
             
 left_camera-setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
             left_camera-setRenderOrder(osg::Camera::NESTED_RENDER, 0);
 
 
             // right Camera right buffer
             osg::ref_ptrosg::Camera right_camera = assignStereoCamera(ds, 
 gc.get(), 0, 0, traits-width, traits-height, traits-doubleBuffer ? 
 GL_BACK_RIGHT : GL_FRONT_RIGHT, 1.0);
             
 right_camera-setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
             right_camera-setRenderOrder(osg::Camera::NESTED_RENDER, 1);
 
 
 
 You could implement this without going via the osg::DisplaySettings/default 
 configuration, the other alternative would be to extend DisplaySettings and 
 the View.cpp code to handle customization of the anaglyphic settings.
 
 
 Robert.
 
 
 
 
 
 
 
 On 31 July 2014 16:07, Christopher Bruns  () wrote:
 
  Hi,
  
  Is it possible to display stereo 3D rendering for green-magenta anaglyph 
  glasses in OpenSceneGraph? (as opposed to red-cyan glasses)
  
  I can get stereo working well with old-fashioned red-(blue-cyan) glasses. 
  Is there a way to change the color settings of anaglyph mode?
  
  Below is a complete twelve line python program that renders in stereo for 
  red/cyan glasses.
  
  
  Code:
  
  from osgswig import osg, osgDB, osgViewer, osgGA
  print %d.%d.%d % (osg.OSG_VERSION_MAJOR, osg.OSG_VERSION_MINOR, 
  osg.OSG_VERSION_PATCH) # prints 3.2.1
  cow = osgDB.readNodeFile(cow.osg)
  # Use custom DisplaySettings to create a stereoscopic view
  display_settings = osg.DisplaySettings()
  display_settings.setStereoMode(osg.DisplaySettings.ANAGLYPHIC) # Red-cyan 
  ONLY !?!?
  display_settings.setStereo(True)
  viewer = osgViewer.Viewer()
  viewer.setSceneData(cow)
  viewer.setUpViewInWindow(100, 100, 500, 500, 1)
  viewer.setDisplaySettings(display_settings)
  viewer.run()
  
  
  
  
  How would I modify this program to display stereo for modern green-magenta 
  filtered glasses?
  
  Thank you!
  
  Cheers,
  Christopher
  
  
  ___
  osg-users mailing list
   ()
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
  (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
  
  
 
 
  --
 Post generated by Mail2Forum


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





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


Re: [osg-users] (no subject)

2014-07-31 Thread Christopher Bruns
Sorry I neglected to put a subject line. I think once I have two posts, I will 
be able to edit my question subject on the forum.
Christopher

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





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


Re: [osg-users] (no subject)

2014-07-31 Thread Robert Osfield
HI Christopher,

Currently the ANAGLYPHIC stereo support is hardwired to red-cyan.
 Curiously you are the first to ask for anything else.

To implement for other interpretations of anaglyphic you'd need to
implement it using osgViewer::View slave Camera's, one slave Camera for the
left eye and one for the right - you'd attach the appropriate
osg::ColorMask for each slave Camera to get the effect you want.

The code that sets up stereo in svn/trunk can be found in
OpenSceneGraph/src/osgViewer/View.cpp assignStereoOrKeystoneToCamera(..)
method, the code block of interest looks like:

   switch(ds-getStereoMode())
{
case(osg::DisplaySettings::QUAD_BUFFER):
{
// disconect the camera from the graphics context.
camera-setGraphicsContext(0);

// left Camera left buffer
osg::ref_ptrosg::Camera left_camera = assignStereoCamera(ds,
gc.get(), 0, 0, traits-width, traits-height, traits-doubleBuffer ?
GL_BACK_LEFT : GL_FRONT_LEFT, -1.0);

left_camera-setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
left_camera-setRenderOrder(osg::Camera::NESTED_RENDER, 0);

// right Camera right buffer
osg::ref_ptrosg::Camera right_camera = assignStereoCamera(ds,
gc.get(), 0, 0, traits-width, traits-height, traits-doubleBuffer ?
GL_BACK_RIGHT : GL_FRONT_RIGHT, 1.0);

right_camera-setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
right_camera-setRenderOrder(osg::Camera::NESTED_RENDER, 1);

You could implement this without going via the osg::DisplaySettings/default
configuration, the other alternative would be to extend DisplaySettings and
the View.cpp code to handle customization of the anaglyphic settings.

Robert.




On 31 July 2014 16:07, Christopher Bruns cmbr...@rotatingpenguin.com
wrote:

 Hi,

 Is it possible to display stereo 3D rendering for green-magenta anaglyph
 glasses in OpenSceneGraph? (as opposed to red-cyan glasses)

 I can get stereo working well with old-fashioned red-(blue-cyan) glasses.
 Is there a way to change the color settings of anaglyph mode?

 Below is a complete twelve line python program that renders in stereo for
 red/cyan glasses.

 [code]
 from osgswig import osg, osgDB, osgViewer, osgGA
 print %d.%d.%d % (osg.OSG_VERSION_MAJOR, osg.OSG_VERSION_MINOR,
 osg.OSG_VERSION_PATCH) # prints 3.2.1
 cow = osgDB.readNodeFile(cow.osg)
 # Use custom DisplaySettings to create a stereoscopic view
 display_settings = osg.DisplaySettings()
 display_settings.setStereoMode(osg.DisplaySettings.ANAGLYPHIC) # Red-cyan
 ONLY !?!?
 display_settings.setStereo(True)
 viewer = osgViewer.Viewer()
 viewer.setSceneData(cow)
 viewer.setUpViewInWindow(100, 100, 500, 500, 1)
 viewer.setDisplaySettings(display_settings)
 viewer.run()
 [/code]

 How would I modify this program to display stereo for modern green-magenta
 filtered glasses?

 Thank you!

 Cheers,
 Christopher

 ___
 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] (no subject)

2013-04-25 Thread Trajce Nikolov NICK
Hi Daniel,

somewhere in the header of the txp archive should be something like
GetVersion or such. Look in the trpage_* headers

Nick


On Thu, Apr 25, 2013 at 1:10 PM, Daniel Krikun krikun.dan...@gmail.comwrote:

 Hello Nick,

 How can I check what version of the txp is the format of the terrain?

 Mess ag e: 2 Date: Mon, 22 Ap r 20 13 09 :4 4: 5 5 +0 20 0 From : Tr ajc e
 Nik olov NIC K  traj ce .n iko lov. ni ck @g m ail .c om  To : Ope nS c
 eneG rap h Us ers  osg - use rs@ lis ts . open sc ene gr aph .or g  Su
 bj ect : Re: [osg - use rs] txp lod prob lem : sw itc hi ng in cyc l es
 Mess ag e - ID:  CA O - +zi kU 6a UW pV C g uT 8M S 0qb y3 - + NkU D_ C 60
 zKg sK tDZ0 G3 iS w @m ai l. gm ai l. c om  Con tent - Ty pe: text/ p lai
 n; ch ars et= is o - 88 59 - 1

 Hi Dani el,

 I am run nin g larg e terr ain (txp ) on my lapt op wi th no prob lem s wi
 th the lates t cod e fr om the trun k (alt houg h I don' t thin k the txp
 load er was touc hed latel y). Wha t is the vers ion of your arc hi ve ? It
 seam that the cod e in the repo sit ory wor ks the bes t wi th 2. 1 arc hi
 ves. Al so, goo d prac ti ce is to use s3 textu re com pr es sio n (dx t3
 and dxt5 ) wh en bui ldi ng the arc hi ve in Te rra Vi sta . If you can bui
 ld a bloc k and post it I can take a look wh at is happ eni ng

 Let me know Nic k

 On Mon, Ap r 22 , 20 13 at 9: 02 AM , Dani el Krik un  kri ku n. dani el@g 
 mai l. c om  wr ote:

  Hel lo,   I have a he avy appl ic ati on wh ic h use s osg view er
 and a TX P terr ain .  Af te r som e tim e the appl ic ati on is run nin g
 , LOD level of the terr ain  star ts bein g sw itc he d hig h er and low
 er all the tim e in cyc l es, so one  sec ond I have trees and bui ldi ng
 bein g dis pla yed and one sec ond later - they dis appe ar.  Inter est
 ing , if I run jus t 2 ins tanc es of osg vie we r. exe wi th a larg e TX P
  terr ain , af ter som e tim e, I ach ieve the sam e ef f ec t.   I sus
 pec t, TX P load er detec ts low me mor y avail abl e and sw itc he s LOD
 dow n,  then wh en som e me mor y is fr eed due to this LOD sw itc hi ng ,
 the load er  sw itc he s the LOD up, the me mor y ge ts low and it con tin
 ues in cyc l es.   An y idea s ?   I'm run nin g Win dow s XP, 32 -
 bit, GT X 67 0. Both osg - 2. 9. 8 and 3. 0. 1 exh ibi t  this beha viou
 r.   Th ank s,   - - Dani el Krik un   __ __ _ __ _ __ __ _ __ _ __
 _ __ __ _ __ _ __ _ __ __ _ __ _ __ __ _ __ _ _  osg - use rs mai li ng
 lis t  osg - use rs@ lis ts . open sc ene gr aph .or g  http: / / li
 sts .op ens ce neg r aph. org / li sti nf o. cg i /

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




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


Re: [osg-users] (no subject)

2012-09-07 Thread Sergey Polischuk
Hi RigTransformSoftware is not a node, it is helper class which implements skinning animation inside RigGeometry (which is not a node either, its drawable).Just dont touch vertex positions array and use gl_Vertex in shader instead of your position attribute (dont do this: geom-setVertexAttribArray(0, vertex_data_array); ). So your example vertex shader will look like this:attribute vec4 color_attribute;varying vec4 color;void main(){color = color_attribute;gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;}  Cheers.06.09.2012, 21:28, "Peterakos" hay...@gmail.com:Hello.First of all the SceneGraph that is created after i read the dae file doesnt have any RigTransformSoftware node. Does that mean the values in the vertex array in the rig geometry will stay the same during the program execution (and they will never get the updated value) ?In order for me to pass to the shader's position_attribute the correct updated value what do i have to do ?Do i have to call setVertexAttribArray in every loop, passing the as parameter the udapted values ?Is there any way to received these updated vertex positions without using the RigTransformSoftware and without having to multiply with the transformation matrices i received from bones ??Thnx again and sorry for the long thread. ,___osg-users mailing listosg-users@lists.openscenegraph.orghttp://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] (no subject)

2012-09-06 Thread Sergey Polischuk
Hi RigGeometry vertex\normal arrays updated according to animation when software rig transform implementation is used. Have a look at RigTransformSoftware::operator() source. If you set vertex position with setVertexAttribArray, it woudnt be updated, else if you set it with setVertexArray it would be overwritten with array calculated by rig transform implementation. If you just need transformed values - use gl_Vertex in shader, and dont touch vertex array. Cheers. 06.09.2012, 14:54, "Peterakos" hay...@gmail.com:Hello.My task is to render an animated dae character with shaders.I have created a simple vertex shader:attribute vec4 position_attribute;attribute vec4 color_attribute;varying vec4 color; void main(){color = color_attribute;gl_Position = gl_ModelViewProjectionMatrix * position_attribute;} After that i use stateset-setAttributeAndModes to assign the program to the model .I assign the position and color atrtibute to the corresponding location according to this:gl_Vertex0gl_Normal2gl_Color3gl_SecondaryColor4 Everything works fine.The problem comes when i try to pass manually the vertex array and color array using:geom-setVertexAttribArray(attrib_num, data_array);geom-setVertexAttribBinding(attrib_num, attrib_binding); I pass the RigGeometry's VertexArray as data array, but the character is not animated because the defaultgeometry's values are passed. Watching the osganimationhardware example i noticed that i have to pass the bone matricesas well and multiply with vertex position.Is there any Array which keeps the updated vertex positions according to the animation?If there is, i can match this array's values to position attribute, without having to pass the matrices in the shader.Thank you for your time and sorry for the long post.,___osg-users mailing listosg-users@lists.openscenegraph.orghttp://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] (no subject)

2012-09-06 Thread Peterakos
Hello.


First of all the SceneGraph that is created after i read the dae file
doesnt have any RigTransformSoftware node.
Does that mean the values in the vertex array in the rig geometry will stay
the same during the program execution (and they will never get the updated
value) ?

In order for me to pass to the shader's position_attribute the correct
updated value what do i have to do ?
Do i have to call setVertexAttribArray in every loop, passing the as
parameter the udapted values ?
Is there any way to received these updated vertex positions without using
the RigTransformSoftware and without having to multiply with the
transformation matrices i received from bones ??

Thnx again and sorry for the long thread.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] (no subject)

2012-07-02 Thread Chris Hanson
Spam. Do not visit this link.

On Mon, Jul 2, 2012 at 3:18 PM, m...@arne-kreutzmann.de wrote:

 http://newmodeluk.com/time.php?ocean208.png
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio •
LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] (no subject)

2011-12-12 Thread Sergey Polischuk
Hi,
Short answer: there are no simple way,
You should get all drawables, grab all primitivesets and set instance count for 
them, write shaders that make use of instanceID to calculate vertex position.
also with instanced drawing you should disable display lists, so for 
performance reasons make sure that your drawables have low primitivesets count 
(single primitiveset is good goal), i'd recommend to use osg optimizer with 
INDEX_MESH | VERTEX_PRETRANSFORM | VERTEX_POSSTRANSFORM on models you gonna 
draw instanced.

03.12.2011, 07:03, michael.a.bo...@l-3com.com:
 Hi Everyone,
 I'm trying to implement a fairly dense forested area and simply adding
 in a bunch of osg::MatrixTransform nodes predictably causes the cull to
 crash. I could try reorganizing the scene around an oct-tree as was
 suggested by a previous discussion on this topic, but for draw
 performance reasons, since each tree is the same model, I would like to
 use the new draw instanced arb. I see that osgdrawinstanced has been
 referenced in many similar threads, but osgdrawinstanced creates its
 geometry on the fly, and in doing so can quite easily use the command
 syntax for instancing. I am trying to apply the technique to a loaded
 model and there is no obvious easy method.

 My question is this, if I load a file using

 osgDB::readNodeFile(somefile.osg);

 How would I set it up for instanced drawing?

 My guess is that I would need to write a node-visitor that collects all
 of the geometry - drawables and sets them up to use the instanced call
 overload instead of the default. I have tried doing this, but my
 implementation has gotten pretty complex, and I want to make sure there
 isn't a more simple way I have overlooked.

 Thank you very much for your time.

 Michael A Bosse'

 ___
 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] (no subject)

2011-12-03 Thread Sebastian Messerschmidt

Hello Michael,

I guess with instancing you mean not loading the geometry more than once.
By default, when loading a let's say openflight database OSG will load 
every external, even it has been encountered before.

There are 2 options you can try.
1, Set up a readFileCallback and cache the model yourself
2. use the osgDB caching:

osgDB::ReaderWriter::Options* opt = 
osgDB::Registry::instance()-getOptions();

if (opt == NULL)
{
opt = new osgDB::ReaderWriter::Options();
}
// setup caching
opt-setObjectCacheHint(osgDB::ReaderWriter::Options::CACHE_ALL);

also you might consider using sharing of states and textures:

osgDB::SharedStateManager::ShareMode mode = 
osgDB::SharedStateManager::SHARE_ALL;
mode = static_castosgDB::SharedStateManager::ShareMode(mode | 
osgDB::SharedStateManager::SHARE_STATESETS | 
osgDB::SharedStateManager::SHARE_TEXTURES);
osgDB::Registry::instance()-getOrCreateSharedStateManager()-setShareMode(mode); 



For a real instancing/pseudo-instancing or different methods to draw 
massive amounts of trees you might also want to take a look into the 
osgforest example.


P.S. Please provide a subject, as it might raise your chances to appear 
on the readers radar ;-)


cheers
Sebastian


Hi Everyone,
I'm trying to implement a fairly dense forested area and simply adding
in a bunch of osg::MatrixTransform nodes predictably causes the cull to
crash. I could try reorganizing the scene around an oct-tree as was
suggested by a previous discussion on this topic, but for draw
performance reasons, since each tree is the same model, I would like to
use the new draw instanced arb. I see that osgdrawinstanced has been
referenced in many similar threads, but osgdrawinstanced creates its
geometry on the fly, and in doing so can quite easily use the command
syntax for instancing. I am trying to apply the technique to a loaded
model and there is no obvious easy method.

My question is this, if I load a file using

osgDB::readNodeFile(somefile.osg);

How would I set it up for instanced drawing?

My guess is that I would need to write a node-visitor that collects all
of the geometry -  drawables and sets them up to use the instanced call
overload instead of the default. I have tried doing this, but my
implementation has gotten pretty complex, and I want to make sure there
isn't a more simple way I have overlooked.

Thank you very much for your time.

Michael A Bosse'

___
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] (no subject)

2011-06-22 Thread Robert Osfield
Sorry abou this unsavoury spam getting through - it looks to be a case
of a guinuine osg-user that has their mail account compromised by the
spammers.  I've unsubscribed the problem account and notified the
account holder.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] (no subject)

2011-05-09 Thread Wang Rui
Hi,

FYI, Paul Martz's OpenSceneGraph Quick Start Guide is preferred for
beginners in my opinion. And Qian Xuelei and I wrote a book
OpenSceneGraph Beginners Guide in the end of last year, which is
published by the Packt Publishing. Do some search in the osg-users
archives could be of a lot help, too.

As I guess you are from China, I'll also suggest the osgChina forum
(bbs.osgchina.org), and some Chinese materials, like The Longest Frame
(in Chinese, 最长的一帧) written by me, and two OSG publications published
by the Tsinghua University Press.

Wang Rui


在 2011年5月10日 上午7:55,蜡笔小新 841224...@qq.com 写道:
 hello,everyone,i'd like to ask some question about osg.
 I 'm trying to analysis the architecture of osg depending on the source
 code.
 As i'm a researcher and i try to do something on graphics,I have to do some
 reseach.
 Can anybody give me any suggestions

 ___
 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] (no subject)

2011-03-27 Thread Gordon Tomlinson
Manage/stop your subscription at the same place you signed up at

 

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

 

 

 


__

Gordon Tomlinson 

 http://www.photographybygordon.com/ www.photographybyGordon.com

 http://www.gordontomlinson.com/ www.gordontomlinson.com 

 http://www.vis-sim.com/ www.vis-sim.com 



Self defence is not a function of learning tricks  but is a function of how


quickly and intensely one can arouse one's instinct for survival 
-Master Tambo Tetsura 

 

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Vivek Kumar
Dwivedi
Sent: Sunday, March 27, 2011 10:10 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] (no subject)

 

DON'T SEND MESSAGE PLEASE.

-- 
Vivek Dwivedi, 

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


Re: [osg-users] (no subject)

2011-01-12 Thread Robert Osfield
On Wed, Jan 12, 2011 at 6:21 AM, Vivek Kumar Dwivedi
vivekcsjm...@gmail.com wrote:
 Pléase don't send me queries.

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


If want to disable subscription or unsubscribe then simply follow the
list to the mailing list admin page - it's appended to all posts (see
above you post even had all the info you need).

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


Re: [osg-users] (no subject)

2011-01-12 Thread Mourad Boufarguine
Hi Robert,

Could you remove him from the mailing list ? he have sent dozens of mails
like this.

Mourad


 If want to disable subscription or unsubscribe then simply follow the
 list to the mailing list admin page - it's appended to all posts (see
 above you post even had all the info you need).

 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] (no subject)

2010-09-22 Thread Robert Osfield
Hi Vivek,

On Wed, Sep 22, 2010 at 6:44 AM, Vivek Kumar Dwivedi
vivekcsjm...@gmail.com wrote:
 Hi,do not send mail. I am very busy.

Too busy to be polite or to take control of your own subscription?

At the bottom of all emails there is the link to the mailing list
admin pages, simple log in and disable your receipt of mailing lists
posts or simply subscribe.

 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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


Re: [osg-users] (no subject)

2010-07-26 Thread Tomlinson, Gordon
This is a spam and spam link, 



Gordon Tomlinson
Product Manager 3d Technology  Project Wyvern
Overwatch®
An Operating Unit of Textron Systems
__
WARNING: Documents that can be viewed, printed or retrieved from this E-Mail 
may contain technical data whose export is restricted by the Arms Export 
Control Act (Title 22, U.S.C., Sec 2751, et seq,) or the Export Administration 
Act of 1979, as amended, Title 50, U.S.C., App. 2401 et seq. and which may not 
be exported, released or disclosed to non-U.S. persons (i.e. persons who are 
not U.S. citizens or lawful permanent residents [green card holders]) inside 
or outside the United States, without first obtaining an export license.  
Violations of these export laws are subject to severe civil, criminal and 
administrative penalties.

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Yurii Monakov
Sent: Saturday, July 24, 2010 9:21 PM
To: osg-users@lists.openscenegraph.org; pavelpel...@ya.ru
Subject: [osg-users] (no subject)

http://sites.google.com/site/gGtjM8SvxU11/yhhyksvy
___
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] (no subject)

2010-07-26 Thread Robert Osfield
On Mon, Jul 26, 2010 at 12:39 PM, Tomlinson, Gordon
gtomlin...@overwatch.textron.com wrote:
 This is a spam and spam link,

I spotted it too, and don't know how it got into osg-users list.  The
mailing addresses on the post aren't subscribed and the mailing list
is set to reject all posts from non subscribed members.  The only
exception to this is ones sent via the forum which get sent through
the forums subscribed account, but this spam post didn't seem to come
through this route.

Any ideas?  Has mailman been hacked?

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


Re: [osg-users] (no subject)

2010-03-03 Thread Robert Osfield
Hi John,

I would suggest adding the directory where the collada lib is into your lib
search path.  I can't recall exactly what this is under windows, could it
just be PATH?  The other alternative is to copy the lib into the directory
where you've installed the OSG libs.

Robert.

On Tue, Mar 2, 2010 at 6:29 PM, Montgomery, John T. 
j.t.montgom...@abdn.ac.uk wrote:

 Hello All,

 I am trying, for the first time, to export a Blender model into OSG -
 specifically, present3D.

 I have compiled OSG debug version with Collada,
 Exported a DAE from Blender 'eye.dae'.
 Run this in the standard plain vanilla way for present3D - within a
 slide/layer:
 slide
background/background
titleEye Modelled in Blender/title
duration20/duration
layer
model coordinate_frame=slide
  scale=1.0images/eye.dae/model
/layer
 /slide

 Run with:
 C:\2010-02-22_OSG\bin\present3Dd.exe C:\dropbox\tutorial\eye.p3d

 (Some of the) console debug output:
 SlideShowConstructor::addModel(images/eye.dae)
 readNode(images/eye.dae)
 itr='C:\2010-02-22_OSG\bin'
 FindFileInPath() : trying
 C:\2010-02-22_OSG\bin\osgPlugins-2.9.7\osgdb_daed.dll ...
 FindFileInPath() : USING
 C:\2010-02-22_OSG\bin\osgPlugins-2.9.7\osgdb_daed.dll
 DynamicLibrary::failed loading osgPlugins-2.9.7/osgdb_daed.dll
 No valid object found for images/eye.dae
 Warning: Could not find plugin to read objects from file images/eye.dae.
 end of SlideShowConstructor::addModel(images/eye.dae)

 In the running application, a dialogue reports.
 This application has failed to start because libcollada14dom2l-d.dll was
 not found.  Re-installing the application may fix this problem.
 ( Technically, the application isn't installed, I didn't build 'INSTALL'.
  Does this matter? )

 The dll is in the folder
 C:\2010-02-22_OSG\bin\osgPlugins-2.9.7\osgdb_daed.dll,  however,
 libcollada14dom2l-d.dll is in
 C:\OSG_dev\collada \dom\build\vc9-1.4-d\libcollada14dom21-d.dll  (miles
 away)
 This directory \collada\ is at the same level, *but not inside* the OSG
 3rdParty dependencies folder.
 I have an environmental variable COLLADA_DIR= C:\OSG_dev\collada
 Also, have C:\OSG_dev\collada \dom\build\vc9-1.4-d\ in PATH variable.
 I tried copying the DLL to C:\2010-02-22_OSG\bin\osgPlugins-2.9.7 - but,
 didn't help.


 The minimal slide contains two things, and I don't think is the cause of
 the problem:
 1.  The title which displays and handles as normal,
 2. The DAE model (not) - which of course doesn't appear.

 I would be grateful for any ideas what might be going wrong here, please?


 :-)
 John Montgomery, Glassel, Scotland.








 The University of Aberdeen is a charity registered in Scotland, No
 SC013683.
 ___
 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] (no subject)

2010-03-03 Thread Mourad Boufarguine
Hi John,

Is there a reason why you write libcollada14dom2l-d.dll with an L rather
than a 1 ?

Mourad


On Tue, Mar 2, 2010 at 7:29 PM, Montgomery, John T. 
j.t.montgom...@abdn.ac.uk wrote:

 Hello All,

 I am trying, for the first time, to export a Blender model into OSG -
 specifically, present3D.

 I have compiled OSG debug version with Collada,
 Exported a DAE from Blender 'eye.dae'.
 Run this in the standard plain vanilla way for present3D - within a
 slide/layer:
 slide
background/background
titleEye Modelled in Blender/title
duration20/duration
layer
model coordinate_frame=slide
  scale=1.0images/eye.dae/model
/layer
 /slide

 Run with:
 C:\2010-02-22_OSG\bin\present3Dd.exe C:\dropbox\tutorial\eye.p3d

 (Some of the) console debug output:
 SlideShowConstructor::addModel(images/eye.dae)
 readNode(images/eye.dae)
 itr='C:\2010-02-22_OSG\bin'
 FindFileInPath() : trying
 C:\2010-02-22_OSG\bin\osgPlugins-2.9.7\osgdb_daed.dll ...
 FindFileInPath() : USING
 C:\2010-02-22_OSG\bin\osgPlugins-2.9.7\osgdb_daed.dll
 DynamicLibrary::failed loading osgPlugins-2.9.7/osgdb_daed.dll
 No valid object found for images/eye.dae
 Warning: Could not find plugin to read objects from file images/eye.dae.
 end of SlideShowConstructor::addModel(images/eye.dae)

 In the running application, a dialogue reports.
 This application has failed to start because libcollada14dom2l-d.dll was
 not found.  Re-installing the application may fix this problem.
 ( Technically, the application isn't installed, I didn't build 'INSTALL'.
  Does this matter? )

 The dll is in the folder
 C:\2010-02-22_OSG\bin\osgPlugins-2.9.7\osgdb_daed.dll,  however,
 libcollada14dom2l-d.dll is in
 C:\OSG_dev\collada \dom\build\vc9-1.4-d\libcollada14dom21-d.dll  (miles
 away)
 This directory \collada\ is at the same level, *but not inside* the OSG
 3rdParty dependencies folder.
 I have an environmental variable COLLADA_DIR= C:\OSG_dev\collada
 Also, have C:\OSG_dev\collada \dom\build\vc9-1.4-d\ in PATH variable.
 I tried copying the DLL to C:\2010-02-22_OSG\bin\osgPlugins-2.9.7 - but,
 didn't help.


 The minimal slide contains two things, and I don't think is the cause of
 the problem:
 1.  The title which displays and handles as normal,
 2. The DAE model (not) - which of course doesn't appear.

 I would be grateful for any ideas what might be going wrong here, please?


 :-)
 John Montgomery, Glassel, Scotland.








 The University of Aberdeen is a charity registered in Scotland, No
 SC013683.
 ___
 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] (no subject)

2010-03-03 Thread Montgomery, John T.
Hi Robert,   (Sorry about the 'no subject'.)

You gave me an idea - put 'libcollada14dom2l-d.dll' in the System32 folder - 
and it worked!

Thanks very much.
:-)
John Montgomery, Glassel, Scotland.


From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: 03 March 2010 08:46
To: OpenSceneGraph Users
Subject: Re: [osg-users] (no subject)

Hi John,

I would suggest adding the directory where the collada lib is into your lib 
search path.  I can't recall exactly what this is under windows, could it just 
be PATH?  The other alternative is to copy the lib into the directory where 
you've installed the OSG libs.

Robert.


The University of Aberdeen is a charity registered in Scotland, No SC013683.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] (no subject)

2010-03-03 Thread Montgomery, John T.
Hi Mourad,
You have eagle eyes! :-)

Reason: I used irfanview's OCR to translate the error message in the dialogue 
screenshot, and didn't notice it had mistranslated.

But, it's working now, thanks for your interest.
:-)
John Montgomery, Glassel, Scotland.



From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Mourad 
Boufarguine
Sent: 03 March 2010 09:01
To: OpenSceneGraph Users
Subject: Re: [osg-users] (no subject)

Hi John,

Is there a reason why you write libcollada14dom2l-d.dll with an L rather than 
a 1 ?

Mourad



The University of Aberdeen is a charity registered in Scotland, No SC013683.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] (no subject)

2009-03-05 Thread Jesper D. Thomsen
Oh, and sorry about the no subject. I hit the Send button to soon.

Jesper D. Thomsen

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


Re: [osg-users] (no subject)

2009-02-03 Thread Robert Osfield
HI Sunitha,

In future posts could you use a relevant subject line as this helps
with mail clients to thread appropriately, and also for others down
the line to find threads on particular topics in the archives.

When you load a scene graph from any of the 3d loaders you'll get a
complete scene graph with a single node at it's root, the StateSets
that contain the OpenGL state will be distributed across this graph,
and will rarely just be contained at the root node.  This means you'll
need to traverse the scene graph to find the StateSets, to do this the
best way is to write a custom NodeVisitor.  There are many examples of
custom NodeVisitor all over the OSG source code and examples - just do
a search for NodeVisitor to see it in action.

Robert.

On Tue, Feb 3, 2009 at 6:42 AM, sunitha sunagad
sunithassuna...@gmail.com wrote:


 --
 How can i get the staeset of the model i have lodeaded to the
 openScenegraph
 I am loading an iv file which has the state set attribute in it i need the
 current state set attribute does any one know...
 I am using getStateset but its returning  null.











 Always
   Keep
  Smiling!

  Defeat the defeat before defeat defeats you 




 Regards
 Sunitha.S.Sunagad
 ___
 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] (no subject)

2008-06-12 Thread David Callu
Hi Pecoraro

thank to spot the bug
please send your submissions on osg-submissions the next time.


after review the original code, at line Optimizer.cpp:1561

lod-getNumRanges() is used to know how many iteration will be done in the
for loop, and
getNumRanges have to be equal to getNumChild, so lod-getChild(i) at line
1563 is not the problem.

Perhaps you LOD is not synchronised (num of  children and num of range are
not equal)i don't know why or how is possible.
Anyway, in a case of a PagedLOD, only the code of LOD is used, so not
special case for a PagedLOD.

correct me if i'm wrong.

Cheers
David Callu

2008/6/6 Pecoraro, Alexander N [EMAIL PROTECTED]:


 I think there is a bug in the osgUtil::Optimizer::CombineLODVisitor - at
 line 1530 of Optimizer.cpp it does a dynamic_cast on and osg::Node* to
 osg::LOD* and then at line 1563 it calls getChild(i) (even if
 getNumChildren() == 0) on the dynamically casted LOD node. This works
 fine when the node is an LOD node, but when it is a PagedLOD node then
 it causes in invalid access to the _children vector. I attached a screen
 shot to show what I mean.

 This situation would only ocurr when a PagedLOD node was a sibling of an
 LOD node, which is probably why it hasn't been spotted before.

 Not sure if this is the accepted way to submit a fix, but anyway I made
 a fix to the Optimizer code (version 2.4) and attached it to the email.

 Alex

 ___
 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] (no subject)

2008-03-31 Thread Robert Osfield
Hi Maya,

Sorry about this, changed the API but missed updating the wrappers.
They are now updated and checked in.

Robert.

On Mon, Mar 31, 2008 at 12:34 AM, maya leonard [EMAIL PROTECTED] wrote:

  Hi Robert

  While trying to compile the latest svn version from today I get the
 following compile errors for osgDB and osgTerrain Wrappers.

  Thanks
  Maya

  3-- Build started: Project: Wrapper osgDB, Configuration: Release x64
 --
  2Compiling...
  3Compiling...
  3DatabasePager.cpp
  2Terrain.cpp
  3.\osgDB\DatabasePager.cpp(296) : error C2039:
 'setMaximumNumOfRemovedChildPagedLODs' : is not a member of
 'osgDB::DatabasePager'
  3
 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgDB/DatabasePager(42)
 : see declaration of 'osgDB::DatabasePager'
  3.\osgDB\DatabasePager.cpp(296) : error C2065:
 'setMaximumNumOfRemovedChildPagedLODs' : undeclared identifier
  3.\osgDB\DatabasePager.cpp(301) : error C2039:
 'getMaximumNumOfRemovedChildPagedLODs' : is not a member of
 'osgDB::DatabasePager'
  3
 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgDB/DatabasePager(42)
 : see declaration of 'osgDB::DatabasePager'
  3.\osgDB\DatabasePager.cpp(301) : error C2065:
 'getMaximumNumOfRemovedChildPagedLODs' : undeclared identifier
  3.\osgDB\DatabasePager.cpp(306) : error C2039:
 'setMinimumNumOfInactivePagedLODs' : is not a member of
 'osgDB::DatabasePager'
  3
 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgDB/DatabasePager(42)
 : see declaration of 'osgDB::DatabasePager'
  3.\osgDB\DatabasePager.cpp(306) : error C2065:
 'setMinimumNumOfInactivePagedLODs' : undeclared identifier
  3.\osgDB\DatabasePager.cpp(311) : error C2039:
 'getMinimumNumOfInactivePagedLODs' : is not a member of
 'osgDB::DatabasePager'
  3
 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgDB/DatabasePager(42)
 : see declaration of 'osgDB::DatabasePager'
  3.\osgDB\DatabasePager.cpp(311) : error C2065:
 'getMinimumNumOfInactivePagedLODs' : undeclared identifier
  3Build log was saved at
 file://d:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\src\osgWrappers\osgwrapper_osgDB.dir\Release\BuildLog.htm
  3Wrapper osgDB - 8 error(s), 0 warning(s)
  2.\osgTerrain\Terrain.cpp(73) : error C2039: 'setTerrainTechnique' : is
 not a member of 'osgTerrain::Terrain'
  2
 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgTerrain/Terrain(26)
 : see declaration of 'osgTerrain::Terrain'
  2.\osgTerrain\Terrain.cpp(73) : error C2065: 'setTerrainTechnique' :
 undeclared identifier
  2.\osgTerrain\Terrain.cpp(78) : error C2039: 'getTerrainTechnique' : is
 not a member of 'osgTerrain::Terrain'
  2
 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgTerrain/Terrain(26)
 : see declaration of 'osgTerrain::Terrain'
  2.\osgTerrain\Terrain.cpp(78) : error C2065: 'getTerrainTechnique' :
 undeclared identifier
  2.\osgTerrain\Terrain.cpp(83) : error C2039: 'getTerrainTechnique' : is
 not a member of 'osgTerrain::Terrain'
  2
 D:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\include\osgTerrain/Terrain(26)
 : see declaration of 'osgTerrain::Terrain'
  2.\osgTerrain\Terrain.cpp(83) : error C2065: 'getTerrainTechnique' :
 undeclared identifier
  2Build log was saved at
 file://d:\Projects\OpenSceneGraph\osg64bit\OpenSceneGraph\src\osgWrappers\osgwrapper_osgTerrain.dir\Release\BuildLog.htm
  2Wrapper osgTerrain - 6 error(s), 0 warning(s)

 
 Windows Live Hotmail is giving away Zunes. Enter for your chance to win.
 ___
  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] (no subject)

2008-02-15 Thread Robert Osfield
Hi,

A 60ms draw time is high, and may be high simply because the OpenGL
fifo is full and stalling draw dispatch, or could be that you could
requires a round trip from CPU to GPU.  I wouldn't have though having
lots of Camera in itself would be the cause of the slow draw times.

W.r.t multipass, using of multiple Camera is probably the way, but one
thing osg::Camera possibly doesn't yet support is sharing of FBO's, I
say possibly because I haven't tried to implement this type of
rendering myself yet, and osg::Camera is setup with the assumption
that each camera will create and manage its own FBO.  One might be
able to assign an already created FBO and share between multiple
Cameras, but I can't say for sure as I haven't tried it in code yet...

Robert.

On Sun, Feb 3, 2008 at 11:32 PM,  [EMAIL PROTECTED] wrote:
 Hi all,

  I have a problem in which I have to do multipass rendering. When I say
  multipass, it's in fact rendering to a texture which is the input for the
  next rendering, etc... and that about a hundreds time... I could explain
  why, but only if necessary, but let's say that no there is no better way
  than doing a cascaded rendering with that amount of steps, and in fact,
  that's sphecifically why I'm doing it on GPU...

  Moving on to OSG related problem, it seems to me that every time you want
  to render to a texture you have to add a Camera node. I've heard that you
  could maybe do a little bit better, by having only one Camera node, but
  several paths leading to it with differents statesets. But in my case, I
  can't have only one camera, and several statesets, because each time, I
  have to change
  the fbo to render to, that can only be done by adding a new camera, with a
  different texture to render to ...

  So my question is, is there a better way to do this kind of multipass
  rendering, than adding a camera for each step ? (better in the sense of
  less costly ...)
  I'm asking this because when I look at the stats, drawing takes about 60 ms,
  and gpu time is 80ms. I expected the value for the gpu, because for each
  camera, there is a fragment shader associated. But I didn't expect the
  draw time to be so high, and I really think that is because of the way I'm
  doing it (too many nodes maybe ... :( )

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

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


Re: [osg-users] (no subject)

2008-01-02 Thread Robert Osfield
Hi Pedro,

Have you added the core osg libraries to you link line?  Are the osg
libraries built OK and on your paths?

Robert.

On Jan 2, 2008 2:06 PM, Pedro José Muñoz Martínez
[EMAIL PROTECTED] wrote:

  Hello all,
 I am trying to load Images in my application and it compiles ok but when
 linking it appears the following errors:

   Creating library ../bin/ExerciseImpl.lib and object
 ../bin/ExerciseImpl.exp
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual void __thiscall
 osg::Texture::compileGLObjects(class osg::State )const 
 ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) protected: virtual void __thiscall
 osg::Texture2D::computeInternalFormat(void)const 
 ([EMAIL PROTECTED]@osg@@MBEXXZ)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) protected: virtual void __thiscall
 osg::Texture2D::allocateMipmap(class osg::State )const 
 ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual int __thiscall
 osg::Texture2D::getTextureDepth(void)const 
 ([EMAIL PROTECTED]@osg@@UBEHXZ)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual int __thiscall
 osg::Texture2D::getTextureHeight(void)const 
 ([EMAIL PROTECTED]@osg@@UBEHXZ)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual void __thiscall
 osg::Object::computeDataVariance(void)
 ([EMAIL PROTECTED]@osg@@UAEXXZ)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual int __thiscall
 osg::Texture2D::getTextureWidth(void)const 
 ([EMAIL PROTECTED]@osg@@UBEHXZ)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual unsigned int __thiscall
 osg::Texture2D::getNumImages(void)const 
 ([EMAIL PROTECTED]@osg@@UBEIXZ)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual class osg::Image const * __thiscall
 osg::Texture2D::getImage(unsigned int)const 
 ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@[EMAIL PROTECTED])
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual class osg::Image * __thiscall
 osg::Texture2D::getImage(unsigned int)
 ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@[EMAIL PROTECTED])
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual void __thiscall
 osg::Texture2D::setImage(unsigned int,class osg::Image *)
 ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual unsigned int __thiscall
 osg::Texture2D::getTextureTarget(void)const 
 ([EMAIL PROTECTED]@osg@@UBEIXZ)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual enum osg::StateAttribute::Type
 __thiscall osg::Texture2D::getType(void)const 
 ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@[EMAIL PROTECTED])
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual char const * __thiscall
 osg::Texture2D::className(void)const 
 ([EMAIL PROTECTED]@osg@@UBEPBDXZ)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual char const * __thiscall
 osg::Texture2D::libraryName(void)const 
 ([EMAIL PROTECTED]@osg@@UBEPBDXZ)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual bool __thiscall
 osg::Texture2D::isSameKindAs(class osg::Object const *)const 
 ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual class osg::Object * __thiscall
 osg::Texture2D::clone(class osg::CopyOp const )const 
 ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@Z)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) class osg::Image * __cdecl osgDB::readImageFile(class
 std::basic_stringchar,struct std::char_traitschar,class
 std::allocatorchar  const ,class osgDB::ReaderWriter::Options const *)
 ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL 
 PROTECTED]@@[EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED]@1@@Z)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual class osg::Object * __thiscall
 osg::Texture2D::cloneType(void)const 
 ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@XZ)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: virtual bool __thiscall
 osg::StateAttribute::checkValidityOfAssociatedModes(class osg::State )const
 
 ([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@@Z)
 1prueba.obj : error LNK2001: unresolved external symbol
 __declspec(dllimport) public: class osgDB::ReaderWriter::Options *
 __thiscall osgDB::Registry::getOptions(void)
 

Re: [osg-users] (no subject)

2007-10-15 Thread Paul Melis
Silvère Besse wrote:

in the daily builds :
OpenSG\Source\System\FieldContainer\OSGFieldDescription.cpp
is missing, no way to compile :(
  

Looks like you posted to the mailing list of the wrong scene graph ;-)
Try the one at www.opensg.org

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


Re: [osg-users] (no subject)

2007-09-25 Thread David Callu
Hi Jan

Take a look to the ShapeDrawable::accept(const HeightField field) to see
how osg
render a height field.

Take a look to the osgtexture2d example to know how to enable and render
texture.

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