Re: [osg-users] OSG gathering during my visit to Virginia in December

[Jeremy Smith]

Hey Robert,

One of my coworkers replied on Monday but is still waiting approval.

A few of us are interested in meeting up. Thursday evening would work best. We 
know the area well and can pick a venue. Let us know!

Thanks,
Jeremy

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





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

[osg-users] PBuffer causing error when profiling on Linux

[Jeremy Smith]

Hi,

I am trying to profile my Linux application using the NVIDIA Linux Graphics 
Debugger, but I get an error when I perform a frame capture that the 
'glXCreatePbuffer' command is not supported. This command is located in 
osgViewer/PixelBufferX11.cpp.

>From my research it seems that PBuffers have been deprecated in OpenGL and 
>that FBOs should be used instead. This is probably why the debugger doesn't 
>support it.

My question is: Can OSG be configured to use FBOs for the X11 viewer? If not, 
does anyone have a suggestion on how to modify PixelBufferX11.cpp to use FBOs?

I'm using OSG 3.4.0 and CentOS 7.

Thank you!
Jeremy

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





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

Re: [osg-users] Pruning content

[Jeremy]

Excellent thanks. Looks like that's called in place of the default read
implementations how would one invoke the default read functions and then do
my filtering afterwards

On Mon, Dec 14, 2015, 8:33 AM Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:

> Hi Jeremy,
>
> >How would you do this with respect to the pager? I don't see a mechanism
> to inject a custom visitor to the pager to modify loaded content, ideally
> before caching to the file cache.
>
> Actually there is a way. You can use database read callback and have your
> visitor do stuff with the model when a tile/file is read in (paged in).
> Have a look at:
>
> osgDB::Registry::instance()->setReadFileCallback
> osgDB::Registry::ReadFileCallback
>
> Nick
>
> On Mon, Dec 14, 2015 at 3:03 PM, Jeremy  wrote:
>
>> What's the preferred method of loading a model, for example an open
>> flight model, and pruning it of unneeded data? I assume that would be by
>> making a custom visitor that modifies the hierarchy. Is that correct?
>>
>> How would you do this with respect to the pager? I don't see a mechanism
>> to inject a custom visitor to the pager to modify loaded content, ideally
>> before caching to the file cache. I'm inclined to add a custom visitor
>> pointer to the options class like a "postLoad" to post process the models
>> in a way that is compatible with the pager and file caching. Does that seem
>> reasonable? Did I miss any alternative methods?
>>
>> ___
>> 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Pruning content

[Jeremy]

What's the preferred method of loading a model, for example an open flight
model, and pruning it of unneeded data? I assume that would be by making a
custom visitor that modifies the hierarchy. Is that correct?

How would you do this with respect to the pager? I don't see a mechanism to
inject a custom visitor to the pager to modify loaded content, ideally
before caching to the file cache. I'm inclined to add a custom visitor
pointer to the options class like a "postLoad" to post process the models
in a way that is compatible with the pager and file caching. Does that seem
reasonable? Did I miss any alternative methods?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgDB::FileCache for network sources

[Jeremy]

That's fine. I'll do a custom subclass. I was just thinking given the
simplicity of the need(make a cache copy of everything), that it would be
reasonable to have a 'cache everything' option on the built in file cache.
I'm not looking for some complex mechanism for determining more selectively
what should and shouldn't be cached, just something to ensure that I have a
file cache hierarchy with all the referenced content all together within
the same structure. That meets the needs of archival and deployment of a
very focused set of data a good deal cleaner than only remote files cached,
but perhaps better off implemented as a custom subclass.

Thanks

On Fri, Dec 11, 2015 at 6:39 AM Robert Osfield 
wrote:

> On 11 December 2015 at 11:33, Jeremy  wrote:
>
>> That's fine, I will probably do that, but is it not reasonable for the
>> default to be able to handle network paths and construct working cache
>> paths as well?
>>
> How is one supposed to determine which "network" paths are appropriate to
> be cached locally on the machine?
>
> This type of issue will depend totally on the configuration of your
> network, your data and how your file system mounts networked files.  It's
> *very* domain specific.
>
> This is very different from remotely mounted files pulled in over http
> which is what the FileCache was written for.
>
> 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] osgDB::FileCache for network sources

[Jeremy]

That's fine, I will probably do that, but is it not reasonable for the
default to be able to handle network paths and construct working cache
paths as well?

On Fri, Dec 11, 2015, 2:10 AM Robert Osfield 
wrote:

> Hi Jeremy,
>
> The FileCache::isFileAppropriateForFileCache(..) method is virtual so you
> can subclass from FileCache override this method and than construct your
> own FIleCache and attach it to the osgDB::Registry by doing:
>
>osgDB::Registry::instance()->setFileCache(new MyFileCache);
>
> Robert.
>
> On 11 December 2015 at 02:10, Jeremy  wrote:
>
>> I have a large data set that is on a network that my application pulls
>> small sections of. I want to use the file cache to build local caches of
>> only the content the application needs without needing to clone the entire
>> tree.
>>
>> When i register a file cache with my prototype application(which is
>> currently just a slightly hacked osgViewer). I then proceed to load up my
>> content using the network mapped paths(on windows, this amounts to a bunch
>> of calls to \\somecomputer\somepath\whatever.flt for the terrain tiles, and
>> then that in turn will pull in external references etc.
>>
>> The problem I'm having is that the file cache doesn't cache all these
>> files like I would prefer it to. After a bit of debugging,
>> the FileCache::isFileAppropriateForFileCache returns false because the url
>> isn't prefixed with the known protocols(ftp, http, etc). As a quick
>> workaround I made this function return true always to see if it would
>> cache, and the next place that failed was when it tried to write out the
>> cached file, since a network URL sent through createCacheFileName doesn't
>> produce a valid file path.
>>
>> This is probably something I can get working with local modifications but
>> I would like to ask that the developers consider some additional FileCache
>> options so that one can tell it to cache all files, and not just the ones
>> it deems to be "appropriate", which appears to be limited to remote url
>> paths.The standalone osgfilecache application I think has the right idea
>> with caching everything, but I'm wanted to avoid the need to run a
>> preprocessing step. It appears as well that even if I created and populated
>> the cache myself externally, the case(HANDLE_NON_HTTP): in the pager still
>> only checks the cache given the success of
>> the isFileAppropriateForFileCache.
>>
>> Perhaps it's also reasonable for this check to identify network URLs as
>> viable candidates too?
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgDB::FileCache for network sources

[Jeremy]

I have a large data set that is on a network that my application pulls
small sections of. I want to use the file cache to build local caches of
only the content the application needs without needing to clone the entire
tree.

When i register a file cache with my prototype application(which is
currently just a slightly hacked osgViewer). I then proceed to load up my
content using the network mapped paths(on windows, this amounts to a bunch
of calls to \\somecomputer\somepath\whatever.flt for the terrain tiles, and
then that in turn will pull in external references etc.

The problem I'm having is that the file cache doesn't cache all these files
like I would prefer it to. After a bit of debugging,
the FileCache::isFileAppropriateForFileCache returns false because the url
isn't prefixed with the known protocols(ftp, http, etc). As a quick
workaround I made this function return true always to see if it would
cache, and the next place that failed was when it tried to write out the
cached file, since a network URL sent through createCacheFileName doesn't
produce a valid file path.

This is probably something I can get working with local modifications but I
would like to ask that the developers consider some additional FileCache
options so that one can tell it to cache all files, and not just the ones
it deems to be "appropriate", which appears to be limited to remote url
paths.The standalone osgfilecache application I think has the right idea
with caching everything, but I'm wanted to avoid the need to run a
preprocessing step. It appears as well that even if I created and populated
the cache myself externally, the case(HANDLE_NON_HTTP): in the pager still
only checks the cache given the success of
the isFileAppropriateForFileCache.

Perhaps it's also reasonable for this check to identify network URLs as
viable candidates too?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Node/Object Serialization

[Jeremy]

Robert. Are there plans to expose more information through this interface?
Currently It appears that it is largely exposing the properties that are
serialized, and I was also hoping to expose read only access to
informational data about the various object types as well.

On Wed, Feb 4, 2015 at 5:08 AM, Jeremy  wrote:

> Excellent. Sounds perfect for my needs. I will check that out. I'm on 3.2
> at the moment.
> On Feb 4, 2015 2:30 AM, "Robert Osfield"  wrote:
>
>> Hi Jeremy,
>>
>> You don't really provide enough info about how you are doing things to
>> know what be going amiss so I'll provide general information.
>>
>> Since OSG-3.2 I have done quite a bit of work on making the serialization
>> scheme support introspection sufficient for the purposes of integrating the
>> OSG with scripting languages.  There is now a lua plugin that uses this to
>> allow you to create and modify scene graphs all with lua and have this
>> integrated with the OSG application via callbacks etc.
>>
>> The make the introspection a bit more user friendly I have write a
>> osgDB::ClassInterface class that provides a range of methods for enquiring
>> about properties of classes, creating objects and setting/getting
>> properties and invoking methods.  This is available in the OSG-3.3.x dev
>> releases and svn/trunk.
>>
>> I would have thought your usage case would fit well with the capabilities
>> of the new ClassInterface.
>>
>> Robert.
>>
>>
>>
>> On 4 February 2015 at 01:12, Jeremy  wrote:
>>
>>> Is the serialization support of osg in active development? I made an
>>> attempt to implement a custom osgDB::OutputStream class along
>>> with writeObjectFields in order to try and piggy back the built in
>>> serialization functionality in order to be able to populate a GUI tree view
>>> I'm working on.
>>>
>>>
>>> https://www.dropbox.com/s/07t5zk7hw8jp2r7/Screenshot%202015-01-24%2023.06.38.png?dl=0
>>>
>>> It quickly became apparent that the serialization output in OSG is
>>> lacking in enough ways that it doesn't appear that I can use it in this
>>> way, which is very unfortunate. The same issues I ran into appear to be
>>> issues with the in built serialization mechanisms, because the ascii and
>>> xml versions of ReaderWriterOSG2 appear to be awkwardly formatted as well.
>>>
>>> Since the serializers are implemented as a streaming set of values,
>>> including 'count' type variables, there isn't enough context interleaved
>>> through the stream to isolate the write* values for the property values
>>> from formatting writes such as counts and type names and such.
>>>
>>> I don't suppose there is any ongoing effort to improve upon this or
>>> possibly add an alternate parallel reflection interface that one could
>>> query and iterate the named properties of the entire hierarchy. Ultimately
>>> I'm looking for a way to visualize the internal state of all the various
>>> osg object types to a UI, or to script interfaces or whatever.
>>>
>>> Thanks
>>> Jeremy
>>>
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] (no subject)

[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 
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 
> 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
>> 
>>
>>
>> [image: image]
>> 
>>
>>
>>
>>
>>
>> openscenegraph/osg
>> 

Re: [osg-users] Node/Object Serialization

[Jeremy]

Excellent. Sounds perfect for my needs. I will check that out. I'm on 3.2
at the moment.
On Feb 4, 2015 2:30 AM, "Robert Osfield"  wrote:

> Hi Jeremy,
>
> You don't really provide enough info about how you are doing things to
> know what be going amiss so I'll provide general information.
>
> Since OSG-3.2 I have done quite a bit of work on making the serialization
> scheme support introspection sufficient for the purposes of integrating the
> OSG with scripting languages.  There is now a lua plugin that uses this to
> allow you to create and modify scene graphs all with lua and have this
> integrated with the OSG application via callbacks etc.
>
> The make the introspection a bit more user friendly I have write a
> osgDB::ClassInterface class that provides a range of methods for enquiring
> about properties of classes, creating objects and setting/getting
> properties and invoking methods.  This is available in the OSG-3.3.x dev
> releases and svn/trunk.
>
> I would have thought your usage case would fit well with the capabilities
> of the new ClassInterface.
>
> Robert.
>
>
>
> On 4 February 2015 at 01:12, Jeremy  wrote:
>
>> Is the serialization support of osg in active development? I made an
>> attempt to implement a custom osgDB::OutputStream class along
>> with writeObjectFields in order to try and piggy back the built in
>> serialization functionality in order to be able to populate a GUI tree view
>> I'm working on.
>>
>>
>> https://www.dropbox.com/s/07t5zk7hw8jp2r7/Screenshot%202015-01-24%2023.06.38.png?dl=0
>>
>> It quickly became apparent that the serialization output in OSG is
>> lacking in enough ways that it doesn't appear that I can use it in this
>> way, which is very unfortunate. The same issues I ran into appear to be
>> issues with the in built serialization mechanisms, because the ascii and
>> xml versions of ReaderWriterOSG2 appear to be awkwardly formatted as well.
>>
>> Since the serializers are implemented as a streaming set of values,
>> including 'count' type variables, there isn't enough context interleaved
>> through the stream to isolate the write* values for the property values
>> from formatting writes such as counts and type names and such.
>>
>> I don't suppose there is any ongoing effort to improve upon this or
>> possibly add an alternate parallel reflection interface that one could
>> query and iterate the named properties of the entire hierarchy. Ultimately
>> I'm looking for a way to visualize the internal state of all the various
>> osg object types to a UI, or to script interfaces or whatever.
>>
>> Thanks
>> Jeremy
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Node/Object Serialization

[Jeremy]

Is the serialization support of osg in active development? I made an
attempt to implement a custom osgDB::OutputStream class along
with writeObjectFields in order to try and piggy back the built in
serialization functionality in order to be able to populate a GUI tree view
I'm working on.

https://www.dropbox.com/s/07t5zk7hw8jp2r7/Screenshot%202015-01-24%2023.06.38.png?dl=0

It quickly became apparent that the serialization output in OSG is lacking
in enough ways that it doesn't appear that I can use it in this way, which
is very unfortunate. The same issues I ran into appear to be issues with
the in built serialization mechanisms, because the ascii and xml versions
of ReaderWriterOSG2 appear to be awkwardly formatted as well.

Since the serializers are implemented as a streaming set of values,
including 'count' type variables, there isn't enough context interleaved
through the stream to isolate the write* values for the property values
from formatting writes such as counts and type names and such.

I don't suppose there is any ongoing effort to improve upon this or
possibly add an alternate parallel reflection interface that one could
query and iterate the named properties of the entire hierarchy. Ultimately
I'm looking for a way to visualize the internal state of all the various
osg object types to a UI, or to script interfaces or whatever.

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

Re: [osg-users] Loading .obj files inefficiently

[Jeremy]

I need to maintain my focus on developing my app, so I'm not sure when I
could get to it. My small temporary fixes are enough to get me by
satisfactorily for the time being. It may not be worth me personally
spending time on, since ultimately my app will load content through other
channels than obj files(network mostly). I wanted to at least mention it so
someone that has a bigger stake at the obj file support might be interested
in improving it.. I happened to notice it when my code that constructs the
GUI hierarchy tree view ground to a halt trying to populate the tree with
191k items for each individual face.

On Sun, Jan 25, 2015 at 4:01 AM, Robert Osfield 
wrote:

> Hi Jeremy,
>
> I just had a quick look at the code.  It's rather dated.
>
> I'd be inclined to replace almost all the code in the
> ReaderWriterOBJ::convertElementListToGeometry() method to one that uses
> DrawElementsUShort/UInt, and GL_TRIANGLES when handling the POLYGON, with
> the local method breaking up the polygons.  One could possible use the glu
> tesselation routes if the POLYGON has concavities.
>
> Feel free to scalpel to it and we can then discuss the results :-)
>
> Robert.
>
>
>
> On 25 January 2015 at 05:30, Jeremy  wrote:
>
>> I am working on a visualization/debugging UI and in the process of
>> displaying the scene graph to a tree view in my gui, I noticed that there
>> appears to be an issue with the .obj file loader that could be improved
>> significantly.
>>
>> The first problem I came to is seeing that the resulting osg::Geometry
>> node that comes from loading the obj had 191,000+
>> osg::Geometry::getNumPrimitiveSets(). Turns out, the obj reader creates
>> a osg::DrawArrays for each individual face of the model, and my particular
>> model 191639 faces.
>>
>> Not a huge deal I thought, I'll add a quick option to the reader to
>> optimize it before returning it, as I'm not so comfortable butchering up
>> the ReaderWriterOBJ::convertElementListToGeometry code as of yet.
>>
>> if ( localOptions.mergeMeshes )
>> {
>> osgUtil::Optimizer opt;
>> opt.optimize( node, osgUtil::Optimizer::MERGE_GEOMETRY );
>> }
>>
>> Surprisingly, this didn't work, and the culprit I found is that the
>> optimizer cannot merge geometry forTRIANGLE_FAN, which is what was being
>> used in ReaderWriterOBJ::convertElementListToGeometry for triangles.
>> Changing this to TRIANGLES allowed the optimizer to merge this huge number
>> of primitive sets down to 1.
>>
>> Here's a shot of the UI after my fixes where the model has been merged as
>> desired.
>>
>> https://www.dropbox.com/s/07t5zk7hw8jp2r7/Screenshot%202015-01-24%2023.06.38.png?dl=0
>>
>> Hopefully someone on the dev side can at least change the TRIANGLE_FAN
>> part trivially, though it would be nice if the reader didn't create such
>> bad primitive sets up front.
>>
>> Thanks
>> Jeremy
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Loading .obj files inefficiently

[Jeremy]

I am working on a visualization/debugging UI and in the process of
displaying the scene graph to a tree view in my gui, I noticed that there
appears to be an issue with the .obj file loader that could be improved
significantly.

The first problem I came to is seeing that the resulting osg::Geometry node
that comes from loading the obj had 191,000+
osg::Geometry::getNumPrimitiveSets(). Turns out, the obj reader creates
a osg::DrawArrays for each individual face of the model, and my particular
model 191639 faces.

Not a huge deal I thought, I'll add a quick option to the reader to
optimize it before returning it, as I'm not so comfortable butchering up
the ReaderWriterOBJ::convertElementListToGeometry code as of yet.

if ( localOptions.mergeMeshes )
{
osgUtil::Optimizer opt;
opt.optimize( node, osgUtil::Optimizer::MERGE_GEOMETRY );
}

Surprisingly, this didn't work, and the culprit I found is that the
optimizer cannot merge geometry forTRIANGLE_FAN, which is what was being
used in ReaderWriterOBJ::convertElementListToGeometry for triangles.
Changing this to TRIANGLES allowed the optimizer to merge this huge number
of primitive sets down to 1.

Here's a shot of the UI after my fixes where the model has been merged as
desired.
https://www.dropbox.com/s/07t5zk7hw8jp2r7/Screenshot%202015-01-24%2023.06.38.png?dl=0

Hopefully someone on the dev side can at least change the TRIANGLE_FAN part
trivially, though it would be nice if the reader didn't create such bad
primitive sets up front.

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

Re: [osg-users] Aircrft HUD, how to make viewports to contain different HUD indicators ?

[Jeremy Moles]

On 06/03/2013 01:07 AM, Mahdi Samadzad wrote:


Dear All,

I need to create an aircraft HUD with its many indicators for 
airspeed, altitude, heading, Horizontal Situation Display and Vertical 
Deviation Indicator. It should look like this: 
http://www.loop-net.info/hud/fl.html


I think I should be able to draw all lines using osg::Geometry and 
show all texts using osg::Text. But where I cannot figure out the way 
to go is in creating different viewports that contain scrolling texts 
and the rotating VDI.


Would you please help ? by the way do you know any tutorial on 
creating aircraft HUDs ?


Many thanks in advance,
Mahdi

Depending on your performance needs, you might be able to get away with 
using a 2D vector drawing library like Cairo and have that render into a 
texture (or group of textures) to draw your HUD. I've done exactly this 
many, many times for various clients using OpenSceneGraph (mostly little 
widgets for software in the medical industry) but it's fast enough on 
modern hardware, even with Intel GPUs.


You could also look into using the NV_path_rendering (and/or osgNVPR), 
if your software will only ever run on NVidia cards. It's the kind of 
thing the extension was designed for, it just hasn't caught on like it 
could since ATI doesn't have anything similar...


___
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] Culling w/ RTT

[Jeremy Moles]

On 05/28/2013 01:20 PM, Farshid Lashkari wrote:

Hi Jeremy,

This sound very similar to an issue I've encountered before. Does your 
RTT Camera object use a RELATIVE or ABSOLUTE reference frame? Also, 
are you applying any ComputeBoundingSphereCallbacks to you scene or 
override the "computeBound" method of any nodes?



ABSOLUTE.

And no, I'm not applying any BoundingSphere callbacks...

Cheers,
Farshid



On Mon, May 27, 2013 at 11:07 AM, Jeremy Moles <mailto:cubic...@gmail.com>> wrote:


Hello everyone! I'm running into a problem in my application where
I'm trying to switch between two different subgraphs as the result
of some event (key press or similar). The first of these two
objects is a standard subgraph with nothing too sophisticated
going on. The second of these is a RTT "stack" of Camera objects.

The problem manifests in that if I switch FROM the standard graph
(just a random grouping of models) to the RTT Camera stack, the
bounds of the previous node are used for the RTT Camera. This
means that while the same scene rendered within my RTT stack is
fine as long as you don't adjust the view matrix, as soon as you
move the scene around it begins to get culled. I can remedy this
problem by disabling culling on the main viewer camera when my RTT
stack is "in effect", but I feel like I'm doing something wrong...
the reason I think this is because I can add the RTT stack to my
scene as the FIRST scene (and never toggle it to anything else)
and the culling occurs correctly. The problem only manifests when
I switch from the RTT stack to a standard node AND THE BACK to the
RTT scene.

Has anyone tried anything like this in the past? Does anyone have
any hints? :)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




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


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

[osg-users] Culling w/ RTT

[Jeremy Moles]

Hello everyone! I'm running into a problem in my application where I'm 
trying to switch between two different subgraphs as the result of some 
event (key press or similar). The first of these two objects is a 
standard subgraph with nothing too sophisticated going on. The second of 
these is a RTT "stack" of Camera objects.


The problem manifests in that if I switch FROM the standard graph (just 
a random grouping of models) to the RTT Camera stack, the bounds of the 
previous node are used for the RTT Camera. This means that while the 
same scene rendered within my RTT stack is fine as long as you don't 
adjust the view matrix, as soon as you move the scene around it begins 
to get culled. I can remedy this problem by disabling culling on the 
main viewer camera when my RTT stack is "in effect", but I feel like I'm 
doing something wrong... the reason I think this is because I can add 
the RTT stack to my scene as the FIRST scene (and never toggle it to 
anything else) and the culling occurs correctly. The problem only 
manifests when I switch from the RTT stack to a standard node AND THE 
BACK to the RTT scene.


Has anyone tried anything like this in the past? Does anyone have any 
hints? :)

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

Re: [osg-users] Raspberry pi

[Jeremy Moles]

On 05/14/2013 04:47 AM, Bruno Ronzani wrote:

Hi Jeremy,

Very cool indeed ! Thank you for adding the pre-compiled OSG too ;)

I just needed a quick example to test everything out.

If I can show that OSG works fine - means at least 30fps, with image rendering, 
interactions and movements - on the PI, I will probably get the time and money 
to do the devs you are talking about :) (it still seems to me very optimistic 
though)

On your example, there is no working input (keyboard, mouse), right ?

In the example I've posted in my last message, the guy was using the SDL to get 
them. Maybe I should do the same ?
In Linux, you use the kernel's evdev API (/usr/include/linux/input.h) 
and read input_event structures one at a time from the appropriate 
device node in /dev/input. Evdev is documented thoroughly on the web, so 
a quick google search will reveal everything you need to know. The API 
is simple and easy to use.


SDL may have some wrapper around it, but using the RPi it's very likely 
you'll have some custom input device being developed with your final 
product, so knowing how to use evdev directly (which is really just a 
lunch-break research project) is useful.

Thanks again,

Bruno

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





___
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] Raspberry pi

[Jeremy Moles]

Take a look at this little project I started:

http://osgrpi.googlecode.com

I'm not done polishing things up (and I don't even use X11 at all here), 
but those kinds of things could be resolved with the right time/money. :)


I would imagine that for most people want to use the RPi and OSG, X wont 
actually be "desired." They'll like have some other embedded form of 
input (like a 9DOF mems device, a Kinect, etc.), but who knows. There 
are lots of paths for adding more traditional OSG support...


1) Write a new osgViewer::GraphicsWindow object. This would be good for 
the short-term, but would be hardly better than the EmbeddedViewer code.


2) Write (or wait for someone to write) a proper DRI driver for X for 
the Broadcom/VideoCore device. This would let us just the standard X11 
GraphicsWindow, without caring one way or another.


On 05/13/2013 12:01 PM, Bruno Ronzani wrote:

Hi,

I haven't found anything recent about making OpenSceneGraph work on a Raspberry 
Pi.

This example (nothing to do with OSG) works quite well, without X11 : 
https://bitbucket.org/benedek/rpi-simple-paramplot/overview

Anyone tried something (maybe not) similar with OSG on a Pi ?

Would be very nice to have our favorite scene graph working on this great 
little thing ;)

Cheers,

Bruno

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





___
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] osgWidget::EventInterface possible memory leak

[Jeremy Moles]

On 04/15/2013 12:37 PM, Judson Weissert wrote:

Hello,

I have been experimenting with the osgWidget library recently, and 
came across what I believe to be a memory leak. I added a break point 
to the osgWidget::Callback destructor, and it is never called when 
running the osgwidgetcanvas example program (the constructor is called 
a number of times).


The osgWidget::EventInterface::CallbackList typedef line in 
osg/include/osgWidget/EventInterface is:


typedef std::list > CallbackList;

Therefore, the osgWidget::EventInterface object is not managing the 
callback's memory. Clients could make the mistake of passing in a 
temporary ref_ptr which would then go out of scope before the callback 
is used, or if the client passes in an unmanaged pointer (like in the 
osgWidget examples), there will be a memory leak unless the caller 
explicitly deallocates the callback at some point in the future after 
the callback is no longer associated with the scene.


Should the CallbackList type be a std::list > 
instead?


I just checked this as well, and you appear to be correct. I'm trying to 
remember what the INTENTION was, but its been so long I can't recall.

Thanks,

Judson
___
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] What's the progress of osgPango?

[Jeremy Moles]

On 04/03/2013 09:20 AM, michael kapelko wrote:

Hi.
I've been researching Cairo / Pango for GUI use with OSG, and googled 
this up:

http://forum.openscenegraph.org/viewtopic.php?t=6394

The osgPango page ( http://code.google.com/p/osgpango/ ) says:

Screenshots
COMING BACK SOON (August, 2012)

I don't have anywhere to put them, I stopped paying for my Linode 
account since I never really used it.


osgPango and osgCairo both work just fine (I just used them in some paid 
work, actually). However, I've been wanting to use Harfbuzz instead 
(Pango is built on Harfbuzz), but haven't had a chance to yet. Like 
Chris said, very busy.

I wonder how's osgPango doing?
Thanks.


___
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] osgWidget Frame borders

[Jeremy Moles]

On 03/15/2013 12:42 AM, Alexandre Valdetaro wrote:

I am having this same problem here. Did anyone find a solution for it? Does 
anyone not have this problem?

I'll take a look later today and see if I can't figure out what is going on.

Thanks,
Alex

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





___
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] changing a osgWidget::Box position

[Jeremy Moles]

On 03/14/2013 12:14 PM, Aitor Ardanza wrote:

Hi,

I don't understand the Jeremy answer... when you say call update() function, 
you are refering to osgWidget::Box update?

I need to reposition some GUI box when the window is resized. If I call..

void HyperPatientVRGUI::resize(int w, int h)
{
  _hyperLogoBox->setPosition(0.0f, h-500, 0.0f);
  _hyperLogoBox->update();
 .
}
I imagine that since you're setting the Z value here, you're just 
causing it to go out of your projection. Try just using setOrigin(), 
instead.

hyperLogoBox disapears...

Thank you!

Cheers,
Aitor

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





___
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] Fedora 18 with nVidia driver: OSG crashes session

[Jeremy Moles]

On 01/31/2013 04:30 PM, Stuart Mentzer wrote:

Hi Robert,

You were right: the problem was broader than OSG. The fix was to modify 
/etc/X11/xorg.conf so that these 2 lines were in the "Files" section:


Code:
Section "Files"
 ModulePath "/usr/lib64/nvidia/xorg"
 ModulePath "/usr/lib64/xorg/modules"
EndSection


(Sorry I just saw this thread...)

You could also put that little blurb somewhere in 
/usr/share/X11/xorg.conf.d, since a static xorg.conf isn't as flexible.


I should note that I also use Fedora 18 exclusively, and I do it with no 
problems at all. I use two different builds of OSG, one of which uses my 
Intel card/GLES2-only and another which is routed through Bumblebee and 
uses the NVidia "optimus" technology on my T410. All of this works 
flawlessly, and I even get about 3-5 hours of battery life, depending on 
how hard I'm pushing the machine.


Of course, this could have something to do with working for a company 
whose sole purpose is to put Linux on laptops and make them work well, 
but. :)


(Another interesting note: when we install the NVidia drivers here on 
our machines, we don't even run the binary they provide; we just extract 
it into /opt/emperor, touch a few configs to add the appropriate library 
paths, and configure bumblebee to search the right directories; no 
existing RPM files are modified, as it is our policy to avoid futzing 
with the core in any way...)



This comes from http://forums.fedoraforum.org/showthread.php?p=1626150

I hope this helps some other F18 users (until this bug is fixed).

Cheers,
Stuart

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





___
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] Linear gradient color in osgnvpr

[Jeremy Moles]

On 01/17/2013 03:57 AM, Serkan Ozkaymak wrote:

Hi,

Is linear gradient color supported by osgnvpr ?
This is easy to do, but I don't know if I got around to doing it quite 
yet. Hit me up on googletalk if you need to know more.

Thank you!

Cheers,
Serkan

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





___
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] Which GPGPU postprocessing method is best for me?

[Jeremy Moles]

On 01/04/2013 09:33 AM, Ethan Fahy wrote:

Hello all,

I have an osg project that uses shaders to write float32 values representing 
temperatures to my framebuffer texture.  I would like insert a CUDA or OpenCL 
kernel to take those temperature values in the framebuffer and reinterpret them 
as colors based on various sensor effects.

My current understanding is that I may be able to accomplish this in 3 ways:
1.  osgPPU
2.  osgCompute/osgCUDA
3.  write something myself from scratch somehow...
Wang Rui is (I believe) in a Chinese time zone, but he may chime in here 
later today.


He is working on osgFX::EffectsCompositor, which I personally found 
incredibly well-written and easy-to-use.


Check out his code here:

https://github.com/xarray/osgRecipes

I have spent a day or so reading through the documentation and forums for both 
osgPPU and osgCompute but I'm wondering if anybody might have suggestions for 
my particular use case so I optimize my research time.  As always my many 
thanks.

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





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



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

[osg-users] Coursera Classes Coming Up!

[Jeremy Moles]

Hey guys!

You've probably heard by now, but there is a really great up-and-coming 
website/organization/movement called Coursera that I learned about last 
year.


http://www.coursera.org
https://www.coursera.org/user/i/cec974e9434316ce7625ee9df772effe

There are some REALLY great math and graphics classes that start in the 
next few days, and I wanted to see if anyone was going to be taking the 
same classes as myself. Perhaps we could work together over Jabber and 
form a kind of study group. :)


Anyways, hope you all had as great a 2012 as myself! Here's to another 
great one!


P. S. All of our resolutions should be, henceforth, to never use the 
OpenGL FFP ever again!

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

Re: [osg-users] GLES2/Trigonometry Question

[Jeremy Moles]

On 12/07/2012 12:27 PM, Paul Martz wrote:
(Sorry if this shows up twice; I originally posted it Tuesday but it 
has not echoed back to the list. Test emails seem to work, so trying 
again...)


Hi Jeremy -- Since you know the FOV in y (it's 45.0 degrees), you can 
compute the distance to "fit" a bounding sphere with the following code:


double computeInitialDistanceFromFOVY( const osg::BoundingSphere& bs, 
const double fovy )

{
return( bs.radius() / sin( osg::DegreesToRadians( fovy * .5 ) ) );
}

That code comes from the matrix utility library (osgwMx) in the 
osgWorks project, but equivalent code exists in osgGA to compute home 
positions, which you could also use as a reference.

   -Paul



Cool, thanks!

Chris Hanson explained this to me off the lists, as well. It's actually 
REALLY simple trig, but for whatever reason I just haven't ever thought 
of 3D math as anything other than voodoo magic.


Now, of course, it makes perfect sense, and I honestly think I've 
acquired a whole new perspective at solving problems in graphics 
mathmatically. I even went and picked myself up a trig/calc book at B&N 
to worth through over the next few weeks.


On 12/4/2012 7:47 AM, Jeremy Moles wrote:
Hello everyone! I'm writing a bit of code using parts of OSG and pure 
OpenGLES2.
This isn't exactly an OSG question, per se, but there are a lot of 
OpenGL

experts here and this is a great resource. :) Any help is appreciated!

In my particular scene, I do not maintain a matrix representing my 
"camera";
there is a global projection matrix and each Drawable maintains its 
own model
matrix. For this reason, whether pedantically right or wrong, I say 
that my

camera always sits at 0, 0, 0 and looks into a frustum created using the
equivalent of gluPerspective(45, 1, 1, 100).

What I'm looking for is the trigonometric calculation that would 
allow me to
determine either the Z value to translate my scene or the scale to 
apply to my

scene in order to fit the entire thing cleanly into my viewport.

I have both the osg::BoundingBox and osg::BoundingSphere of my scene, 
but since
I'm not using a camera manipulator or view matrix directly, I can't 
simply

reference the code in CameraManipulator.cpp.

Furthermore: I have this working currentls in a VERY TERRIBLE way. :) 
What I do

is use reimplementations of gluProject and gluUnproject to caclulate
screen-to-world and world-to-screen coordinates. I then use those 
values to
figure out how much to scale my scene by, but this feels so wrong 
(and bound to

a known window size) that I know there must be a better way.

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





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



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

[osg-users] GLES2/Trigonometry Question

[Jeremy Moles]

Hello everyone! I'm writing a bit of code using parts of OSG and pure 
OpenGLES2. This isn't exactly an OSG question, per se, but there are a 
lot of OpenGL experts here and this is a great resource. :) Any help is 
appreciated!


In my particular scene, I do not maintain a matrix representing my 
"camera"; there is a global projection matrix and each Drawable 
maintains its own model matrix. For this reason, whether pedantically 
right or wrong, I say that my camera always sits at 0, 0, 0 and looks 
into a frustum created using the equivalent of gluPerspective(45, 1, 1, 
100).


What I'm looking for is the trigonometric calculation that would allow 
me to determine either the Z value to translate my scene or the scale to 
apply to my scene in order to fit the entire thing cleanly into my viewport.


I have both the osg::BoundingBox and osg::BoundingSphere of my scene, 
but since I'm not using a camera manipulator or view matrix directly, I 
can't simply reference the code in CameraManipulator.cpp.


Furthermore: I have this working currentls in a VERY TERRIBLE way. :) 
What I do is use reimplementations of gluProject and gluUnproject to 
caclulate screen-to-world and world-to-screen coordinates. I then use 
those values to figure out how much to scale my scene by, but this feels 
so wrong (and bound to a known window size) that I know there must be a 
better way.


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

Re: [osg-users] Status of Collada Reader (November, 2012)

[Jeremy Moles]

On 11/20/2012 01:50 PM, Jason Daly wrote:

On 11/20/2012 09:50 AM, Jeremy Moles wrote:

Hey guys--anyone using OSG with the Collada reader on Linux? Although I
doubt this is a Linux-centric issue.

I've tried the 2.2 (won't even build), 2.3 and 2.4 (neither of which
work with the OSG code) to no avail. Is there something obvious I'm
missing here?

The wiki indicates I should use the 2.2 DOM, but that won't even build
on its own; something about missing domAsset.h, which doesn't even exist
in the 1.4 tree. It exists in 1.5, but our plugin doesn't work with that
yet.


I don't use it regularly, but I do have OSG compiled with the 2.2 
DOM.  I just tested it (osgviewer on a .dae file), and it still seems 
to be working.


I do remember a little bit of pain in getting the 2.2 DOM to compile, 
but I don't recall the details.  I do remember that I only built the 
"dom" directory (I don't use Cg, so I skipped the fx directory, and I 
didn't care about the viewer or rt features).


For what it's worth, my copy of the 2.2 DOM does have a 
dom/include/1.4/dom/domAsset.h file.



The versions available at the moment do not. I wonder what the deal is... :/

--"J"

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



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

[osg-users] Status of Collada Reader (November, 2012)

[Jeremy Moles]

Hey guys--anyone using OSG with the Collada reader on Linux? Although I 
doubt this is a Linux-centric issue.


I've tried the 2.2 (won't even build), 2.3 and 2.4 (neither of which 
work with the OSG code) to no avail. Is there something obvious I'm 
missing here?


The wiki indicates I should use the 2.2 DOM, but that won't even build 
on its own; something about missing domAsset.h, which doesn't even exist 
in the 1.4 tree. It exists in 1.5, but our plugin doesn't work with that 
yet.


Just looking for some additional info before I give up. :)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OSG + RaspberryPi

[Jeremy Moles]

Has anyone had the chance to play with OSG on the RaspberryPi? I have a 
number of OpenGLES2 examples working using their Broadcom "VideoCore" 
API and I intend on trying to put together a simple 
GraphicsWindowRPi.cpp implementation later today.


I just wanted to quickly ping the lists and see if anyone else had tried 
this and what their experience was.


My intention is to interface with their VideoCore API (which doesn't 
require Xorg) at first. I'm sure in the coming months, with Broadcom 
having recently opensourced their userspace implementations of libGLES 
and whatnot, more appropriate Xorg/DRI driver will likely come into 
being. However, in the meantime, this should be a quick and easy (though 
inputless!) approach...

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

Re: [osg-users] Ideas about a resource system, and deferred rendering framework

[Jeremy Moles]

On Tue, 2012-09-11 at 10:54 +0800, Wang Rui wrote:
> Hi Jeremy,
> 
> Thanks for the tests and feedback. I'm focusing on creating a material
> system which may be a little similar to the Ogre one but will be very
> easy to integrate with OSG scenes. I'd like to also have a benchmark
> including a complete deferred shading pipeline in the near future to
> show others how OSG produces realistic worlds. :-)
> 
> Your requirement could be easiliy implemented with one forward pass
> rendering the scene to a texture, and two deferred passes doing the
> blur work with the texture as input. A final compositing pass will
> make use of the outputs of the blur passes and output to a new
> texture. You can get and use the new texture then in the scene for
> your own purpose instead of direct displaying them on screen. I'd like
> to upload a DOF effect file and an updated example some days later to
> demonstrate how these work.

Hi Wang,

Did you ever get a chance to work up an example showing something like
this? I've been trying to get it to work using a modified blur-x/blur-y
approach from osgPPU, but have had no success.

> Thanks,
> 
> Wang Rui
> 
> 2012/9/11 Jeremy Moles :
> > On Mon, 2012-09-10 at 22:57 +0800, Wang Rui wrote:
> > This looks really cool so far. I'd be really interested to know if it
> > supports the following (and would be willing to create examples if
> > you're willing to help)...
> >
> > Scenario: I want to render an entire subgraph to an FBO texture once,
> > then apply 2 or more completely different shaders in some order, then
> > put the final result into a last texture to be used somewhere in the
> > scene. I'm doing a guassian blur, which typically applies two different
> > shaders for x and y.
> >
> > I have this working in osgPPU, but I think you already have enough to do
> > it here, I just couldn't put the pieces together. :)
> >
> ___
> 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] Check if a Drawable was culled or not

[Jeremy Moles]

On Tue, 2012-09-11 at 20:36 +0200, Janna Terde wrote:
> Hi Jeremy,
> 
> I can cull the RTT camera using its cull mask or node mask however I need to 
> know when should I do it. I would like to cull the camera when the node 
> representing the mirror (Geode) is culled so when it is outside of the 
> viewing frustum. This is what I am trying to do, I've tried to use 
> CullVisitor and isCulled function and also tried to construct the Polytope 
> from main camera but still did not get the correct behavior.   :(

OH RIGHT. Good point, a kind of "chicken-and-egg" problem. :)

Try this, and I'll try it to as soon as I can: create a CullCallback
that calls isCullingActive(); if so, set NodeMask to something wonky.
Attach the CullCallback to your Geode.

(This is just from a cursory look at the API and from experience, I'll
try it soon...)

> So I am wondering if there is something I don't know since it seems to be 
> very common thing to do and should be simple to do. 
> 
> Cheers,
> Janna
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=49946#49946
> 
> 
> 
> 
> 
> ___
> 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] Check if a Drawable was culled or not

[Jeremy Moles]

On Tue, 2012-09-11 at 16:52 +0200, Janna Terde wrote:
> Hi,
> 
> I have a scene containing several mirrors but I would only like to enable RTT 
> camera if the node representing a mirror is visible. I am trying to check  if 
> the specific Drawable was culled or not but so far I was not getting the 
> results I wanted. 
> Before getting into details on how I am trying to do it, I wonder if someone 
> can suggest me a simple way to do such check?

If I'm not mistaken, this is already the default behavior. In fact, I
was under the impression that the "recommended" way to even disable RTT
in the first place was to simply have it automatically culled via it's
NodeMask.

What would you be doing differently in order to enable/disable RTT?

P. S. This is just what "I think." I could be wrong, and hopefully
someone will chime in and prevent me spreading misinformation if I
am. :)

> Thank you very much! :)
> 
> Cheers,
> Janna
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=49931#49931
> 
> 
> 
> 
> 
> ___
> 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] Ideas about a resource system, and deferred rendering framework

[Jeremy Moles]

On Tue, 2012-09-11 at 10:54 +0800, Wang Rui wrote:
> Hi Jeremy,
> 
> Thanks for the tests and feedback. I'm focusing on creating a material
> system which may be a little similar to the Ogre one but will be very
> easy to integrate with OSG scenes. I'd like to also have a benchmark
> including a complete deferred shading pipeline in the near future to
> show others how OSG produces realistic worlds. :-)
> 
> Your requirement could be easiliy implemented with one forward pass
> rendering the scene to a texture, and two deferred passes doing the
> blur work with the texture as input. A final compositing pass will
> make use of the outputs of the blur passes and output to a new
> texture. You can get and use the new texture then in the scene for
> your own purpose instead of direct displaying them on screen. I'd like
> to upload a DOF effect file and an updated example some days later to
> demonstrate how these work.

Are there ever cases, when doing sophisticated layering of rendering
like this, that you'd want to manually "kick off" the EffectCompositor
for just a single frame and update the texture only once? (For example,
by setting the NodeMask to 0xF for one frame, then back to 0x0 when
you're done updating the View).

Is there a term for this kind of approach, and would it make sense to
also support this model of rendering directly or should it be left up to
the user?

> Thanks,
> 
> Wang Rui
> 
> 2012/9/11 Jeremy Moles :
> > On Mon, 2012-09-10 at 22:57 +0800, Wang Rui wrote:
> > This looks really cool so far. I'd be really interested to know if it
> > supports the following (and would be willing to create examples if
> > you're willing to help)...
> >
> > Scenario: I want to render an entire subgraph to an FBO texture once,
> > then apply 2 or more completely different shaders in some order, then
> > put the final result into a last texture to be used somewhere in the
> > scene. I'm doing a guassian blur, which typically applies two different
> > shaders for x and y.
> >
> > I have this working in osgPPU, but I think you already have enough to do
> > it here, I just couldn't put the pieces together. :)
> >
> ___
> 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] Ideas about a resource system, and deferred rendering framework

[Jeremy Moles]

On Mon, 2012-09-10 at 22:57 +0800, Wang Rui wrote:
> Hi all,
> 
> Just to announce that the material system is still in progress and
> I've just made the first version for myself to test and use. An
> optimized version with a complete deferred shading pipeline (XML
> files) will be submitted if it could fit most requirements.
> 
> As to share my current work with anyone who are also interested in
> this idea and implementations, I'd like to attach the source files
> along with this mail instead of submitting it in full fling. If you do
> have better ideas, think the work is misdirected or needs to be fixed
> in some parts, please don't hesitate to tell me. A second version with
> more test files and a detailed XML file introduction will be updated
> soon after some days.

This looks really cool so far. I'd be really interested to know if it
supports the following (and would be willing to create examples if
you're willing to help)...

Scenario: I want to render an entire subgraph to an FBO texture once,
then apply 2 or more completely different shaders in some order, then
put the final result into a last texture to be used somewhere in the
scene. I'm doing a guassian blur, which typically applies two different
shaders for x and y.

I have this working in osgPPU, but I think you already have enough to do
it here, I just couldn't put the pieces together. :)

> Thanks,
> 
> Wang Rui
> 
> 
> 2012/6/21 Wang Rui :
> > Hi Robert, hi all,
> >
> > During the past few days, I was thinking of implementing a resource system,
> > as well as a rendering structure which could support both forward and
> > deferred rendering for OSG. This could help developers design complex
> > materials and effects, test cutting-edge GPU techniques, and implement
> > multi-pass / deferred rendering pipelines with user-friendly interfaces or
> > even a readable script format. Similar work were already done in some game
> > engines like Ogre3D, CryEngine and Unreal, and I now plan to work out
> > something with the same power and can fit our OSG users much better. :-)
> >
> > My initial thoughts are:
> > 1. A resource system records all the resource used in the rendering
> > pipeline, including textures, state attributes, shaders, uniforms, camera
> > parameters, and semantics (not used in GLSL, but very useful IMHO). Resource
> > can be referred by other resource, or obtained from APIs to be altered. It
> > can be recorded in an XML-based format for reading/writing, and external
> > uses.
> > 2. A rendering framework uses one or more techniques, passes, and connect
> > their inputs/outputs for complex render work. It can also be recorded by the
> > resource system and is implemented as a group node in the scene graph, which
> > performs actual forward/deferred rendering work.
> > 3. Some in-built techniques and passes can help implement some complex
> > effects on customized scene quickly. Common ones I planned include HDR,
> > SSDO, godrays, depth of field, motion blur, lensflare, color grading and
> > FXAA. A benchmark could be developed first to show how the framework works.
> > 4. Reader/writers could be developed then to convert DAE, CGFX, or even
> > other game engine scripts into OSG native rendering pipelines, which will
> > greatly help migrations from other engines.
> >
> > The resource system itself is actually abstract and can be extended to
> > contain whole scene information later, so it could be placed in the osgDB
> > library. And the new rendering pipeline, which can totally replace current
> > osgFX functionlities, can be placed in osgFX and rendering resource
> > management will be done here, too.
> >
> > I'm glad to work with others who has interests in such an idea, and hope an
> > initial version could be finished before OSG 3.2. For the first stage I will
> > borrow some code from the osgPostEffects library in my experimental osgXI
> > project, to quickly build the low-level APIs of the framework. But anyone
> > who have better ideas, or could contribute some code or effects will be
> > really appreciated.
> >
> > Cheers,
> >
> > Wang Rui
> >
> ___
> 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] Ideas about a resource system, and deferred rendering framework

[Jeremy Moles]

On Mon, 2012-09-10 at 22:57 +0800, Wang Rui wrote:
> Hi all,
> 
> Just to announce that the material system is still in progress and
> I've just made the first version for myself to test and use. An
> optimized version with a complete deferred shading pipeline (XML
> files) will be submitted if it could fit most requirements.
> 
> As to share my current work with anyone who are also interested in
> this idea and implementations, I'd like to attach the source files
> along with this mail instead of submitting it in full fling. If you do
> have better ideas, think the work is misdirected or needs to be fixed
> in some parts, please don't hesitate to tell me. A second version with
> more test files and a detailed XML file introduction will be updated
> soon after some days.
> 
> Thanks,

I'm testing this out, but you appear to have left noise_tex.jpg out of
the zip. :)

> Wang Rui
> 
> 
> 2012/6/21 Wang Rui :
> > Hi Robert, hi all,
> >
> > During the past few days, I was thinking of implementing a resource system,
> > as well as a rendering structure which could support both forward and
> > deferred rendering for OSG. This could help developers design complex
> > materials and effects, test cutting-edge GPU techniques, and implement
> > multi-pass / deferred rendering pipelines with user-friendly interfaces or
> > even a readable script format. Similar work were already done in some game
> > engines like Ogre3D, CryEngine and Unreal, and I now plan to work out
> > something with the same power and can fit our OSG users much better. :-)
> >
> > My initial thoughts are:
> > 1. A resource system records all the resource used in the rendering
> > pipeline, including textures, state attributes, shaders, uniforms, camera
> > parameters, and semantics (not used in GLSL, but very useful IMHO). Resource
> > can be referred by other resource, or obtained from APIs to be altered. It
> > can be recorded in an XML-based format for reading/writing, and external
> > uses.
> > 2. A rendering framework uses one or more techniques, passes, and connect
> > their inputs/outputs for complex render work. It can also be recorded by the
> > resource system and is implemented as a group node in the scene graph, which
> > performs actual forward/deferred rendering work.
> > 3. Some in-built techniques and passes can help implement some complex
> > effects on customized scene quickly. Common ones I planned include HDR,
> > SSDO, godrays, depth of field, motion blur, lensflare, color grading and
> > FXAA. A benchmark could be developed first to show how the framework works.
> > 4. Reader/writers could be developed then to convert DAE, CGFX, or even
> > other game engine scripts into OSG native rendering pipelines, which will
> > greatly help migrations from other engines.
> >
> > The resource system itself is actually abstract and can be extended to
> > contain whole scene information later, so it could be placed in the osgDB
> > library. And the new rendering pipeline, which can totally replace current
> > osgFX functionlities, can be placed in osgFX and rendering resource
> > management will be done here, too.
> >
> > I'm glad to work with others who has interests in such an idea, and hope an
> > initial version could be finished before OSG 3.2. For the first stage I will
> > borrow some code from the osgPostEffects library in my experimental osgXI
> > project, to quickly build the low-level APIs of the framework. But anyone
> > who have better ideas, or could contribute some code or effects will be
> > really appreciated.
> >
> > Cheers,
> >
> > Wang Rui
> >
> ___
> 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] Looking For An osgPPU RTT Example

[Jeremy Moles]

On Fri, 2012-09-07 at 13:39 +0400, Sergey Polischuk wrote:
> Hi
> 
> If you mean output to texture attached to fbo it works for me without any 
> problems. At the end of pipeline you just create osgPPU::UnitOut with output 
> texture set to your fbo attachment texture. Also IIRC you should add your 
> processor to main scene graph (viewer->getSceneData() ) or to viewer camera 
> even if you processing nested camera output.

I didn't see any methods of UnitOut that allowed this, but I did happen
to find a UnitTexture object (that is used the movie example, I somehow
missed) which I will experiment with.

Thanks for the nudge. :)

> Cheers.
> 
> 07.09.2012, 00:25, "Jeremy Moles" :
> > Hey guys, I'm looking for some osgPPU example code demonstrating setting
> > up an osgPPU pipeline ONLY on an FBO texture. All of the examples in the
> > project currently--at least, as far as I can tell--appear to always use
> > the Viewer's Camera directly, which won't work for my use.
> >
> > Futhermore, all of my own personal attempts to implement this result in
> > some really crazy results; for example, creating a black, null Viewport
> > inside my SceneGraph with no seeming purpose.
> >
> > I haven't seen much traffic from Art Tevs lately, so if there's an
> > alternative to osgPPU, I'd be willing to try that out too.
> >
> > Thanks!
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

[osg-users] Looking For An osgPPU RTT Example

[Jeremy Moles]

Hey guys, I'm looking for some osgPPU example code demonstrating setting
up an osgPPU pipeline ONLY on an FBO texture. All of the examples in the
project currently--at least, as far as I can tell--appear to always use
the Viewer's Camera directly, which won't work for my use.

Futhermore, all of my own personal attempts to implement this result in
some really crazy results; for example, creating a black, null Viewport
inside my SceneGraph with no seeming purpose.

I haven't seen much traffic from Art Tevs lately, so if there's an
alternative to osgPPU, I'd be willing to try that out too.

Thanks!

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

Re: [osg-users] Custom Drawable & GLSL

[Jeremy Moles]

On Tue, 2012-09-04 at 19:21 +0100, Robert Osfield wrote:
> Hi Jeremy,
> 
> It should be possible to do a
> 
> drawImplementation(..)
> {
> 
>   state.apply(stateSetOne);
>   // do stuff
>   state.apply(stateSetTwo);
>  // do more stuff
> 
> }

I've settled on:

drawImplementation() {
state.pushStateSet(ss1);
state.apply();
// do stuff
state.popStateSet();
state.apply()

state.pushStateSet(ss1);
state.apply();
// do more stuff
state.popStateSet();
state.apply()
}

Does this seem like an abomination? :) Just calling state.apply() ALMOST
worked, but there was some state leakage (for example, the shader was
applied to all subsequent fragment processing, regardless of it's
location in the graph).

> I'm not 100% sure what will happen with the progress of draw traversal
> w.r.t how the drawable StateSet if any is applied and then later
> assumed to be applied by other state calls.  I think it will probably
> work out OK though so try it, and if something breaks then considering
> adding an extra state.apply(drawwablesStateSet) or a perhaps a state
> dirty.
> 
> This is something we can workout if required though, try the simplest
> thing first then if need be investigate more complicated routes...
> 
> 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] Custom Drawable & GLSL

[Jeremy Moles]

On Tue, 2012-09-04 at 19:15 -0400, Jean-Sébastien Guay wrote:
> Hi Jeremy,
> 
> In the past I've done similar low-level 2-pass rendering in a Drawable, 
> by doing as Robert suggests. Apply one stateset, draw, apply another, 
> draw again (same or different geometry).
> 
> A Program is just state, so you need to draw something in between 
> setting different Programs. Otherwise setting the first Program has no 
> (visible) effect. I know it sounds obvious but I thought I'd just throw 
> that out there so there's no ambiguity :-)
> 
> Hope this helps,

Hey Paul. :)

It's not simply an issue of setting two similar state attributes in
sequence; the NV_path_rendering API is different enough in that for the
stroke you may want to use a shader and for the fill you may want to
reset the state and use whatever fixed state was available previously,
which is why I've had the issues. HOWEVER, I could just implement
everything as shaders anyways.

What I really seem to need is like a State::save(), State::restore()
kind of thing...

> J-S
> 
> 
> On 04/09/2012 1:23 PM, Jeremy Moles wrote:
> > On Tue, 2012-09-04 at 11:05 -0600, Paul Martz wrote:
> >> Doesn't a Drawable's state get applied prior to the call to
> >> Drawable::drawImplementation()? If so, you could just put the _program in 
> >> your
> >> Drawable's StateSet?
> > I'm working on a nodekit for NV_path_rendering, which takes an "as of
> > yet unseen" approach to rendering; new go OpenGL, at any rate. :)
> >
> > They call it the "Stencil then Cover" approach, and like most 2D vector
> > drawing libraries, there is a notion of both STROKING _and_ FILLING. In
> > order to support arbitrary shading on both the affected stroke fragments
> > and affected fill fragments, I need to be able to potentially set two
> > different shaders during a single drawable drawImplementation.
> >
> > Now, having said that--which I potentially should have mentioned in the
> > first email--does that change any advice you might have? :)
> >
> > (Thanks for the response, btw... good info.)
> >
> >> It's easy to verify that things are happening in the right order using a
> >> debugger with breakpoints set at your drawImplementation() and also at
> >> Program::apply().
> >>
> >> If it doesn't happen as I describe above, then I believe what you're doing 
> >> below
> >> is the most robust, as that code would work with all other rendering in the
> >> scene graph, both shader and non-shader rendering.
> >>
> >> Honestly it's been too long since I played at this level. But I seem to 
> >> recall
> >> that the difference between:
> >>   _program->apply( state );
> >> and
> >>   state->apply( _program.get() );
> >> is that the latter tracks the currently bound program, doesn't bother to 
> >> apply
> >> it if it's already in use, and would probably allow you to remove the call 
> >> to
> >> setLastAppliedProgramObject(0).
> >>  -Paul
> >>
> >>
> >> On 9/4/2012 9:58 AM, Jeremy Moles wrote:
> >>> I am creating a custom Drawable that needs to push a Fragment Shader
> >>> into the current rendering state and then, after a single extension
> >>> call, subsequently remove this shader from the state.
> >>>
> >>> I have some code I noodled through to make this work, but I feel like
> >>> there is probably a better way. It goes something like this:
> >>>
> >>> 
> >>>
> >>> drawImplementaion(RenderInfo&  ri) {
> >>>   State* state = ri.getState();
> >>>   unsigned int contextID = state->getContextID();
> >>>
> >>>   _program.apply(state);
> >>>
> >>>   myExtensions->doMycall();
> >>>
> >>>   GL2Extensions::Get(contextID, true)->glUseProgram(0);
> >>>
> >>>   state->setLastAppliedProgramObject(0);
> >>> }
> >>>
> >>> 
> >>>
> >>> Like I said above, this "works", but I feel like there is probably a
> >>> cleaner way to achieve what I want. Note that _program is a ref_ptr to a
> >>> properly create osg::Program object, since I certainly do NOT want to
> >>> recreate all the goodness it provides. :)
> >>>
> >>> Any API advice?
> >>>
> >>> ___
> >>> osg-users mailing list
> >>> osg-users@lists.openscenegraph.org
> >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >>>
> >>>
> >> ___
> >> osg-users mailing list
> >> osg-users@lists.openscenegraph.org
> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> 
> 


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

Re: [osg-users] Custom Drawable & GLSL

[Jeremy Moles]

On Tue, 2012-09-04 at 11:05 -0600, Paul Martz wrote:
> Doesn't a Drawable's state get applied prior to the call to 
> Drawable::drawImplementation()? If so, you could just put the _program in 
> your 
> Drawable's StateSet?

I'm working on a nodekit for NV_path_rendering, which takes an "as of
yet unseen" approach to rendering; new go OpenGL, at any rate. :)

They call it the "Stencil then Cover" approach, and like most 2D vector
drawing libraries, there is a notion of both STROKING _and_ FILLING. In
order to support arbitrary shading on both the affected stroke fragments
and affected fill fragments, I need to be able to potentially set two
different shaders during a single drawable drawImplementation.

Now, having said that--which I potentially should have mentioned in the
first email--does that change any advice you might have? :)

(Thanks for the response, btw... good info.)

> It's easy to verify that things are happening in the right order using a 
> debugger with breakpoints set at your drawImplementation() and also at 
> Program::apply().
> 
> If it doesn't happen as I describe above, then I believe what you're doing 
> below 
> is the most robust, as that code would work with all other rendering in the 
> scene graph, both shader and non-shader rendering.
> 
> Honestly it's been too long since I played at this level. But I seem to 
> recall 
> that the difference between:
>  _program->apply( state );
> and
>  state->apply( _program.get() );
> is that the latter tracks the currently bound program, doesn't bother to 
> apply 
> it if it's already in use, and would probably allow you to remove the call to 
> setLastAppliedProgramObject(0).
> -Paul
> 
> 
> On 9/4/2012 9:58 AM, Jeremy Moles wrote:
> > I am creating a custom Drawable that needs to push a Fragment Shader
> > into the current rendering state and then, after a single extension
> > call, subsequently remove this shader from the state.
> >
> > I have some code I noodled through to make this work, but I feel like
> > there is probably a better way. It goes something like this:
> >
> > 
> >
> > drawImplementaion(RenderInfo&  ri) {
> > State* state = ri.getState();
> > unsigned int contextID = state->getContextID();
> >
> > _program.apply(state);
> >
> > myExtensions->doMycall();
> >
> > GL2Extensions::Get(contextID, true)->glUseProgram(0);
> >
> > state->setLastAppliedProgramObject(0);
> > }
> >
> > 
> >
> > Like I said above, this "works", but I feel like there is probably a
> > cleaner way to achieve what I want. Note that _program is a ref_ptr to a
> > properly create osg::Program object, since I certainly do NOT want to
> > recreate all the goodness it provides. :)
> >
> > Any API advice?
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

[osg-users] Custom Drawable & GLSL

[Jeremy Moles]

I am creating a custom Drawable that needs to push a Fragment Shader
into the current rendering state and then, after a single extension
call, subsequently remove this shader from the state.

I have some code I noodled through to make this work, but I feel like
there is probably a better way. It goes something like this:



drawImplementaion(RenderInfo& ri) {
State* state = ri.getState();
unsigned int contextID = state->getContextID();

_program.apply(state);

myExtensions->doMycall();

GL2Extensions::Get(contextID, true)->glUseProgram(0);

state->setLastAppliedProgramObject(0);
}



Like I said above, this "works", but I feel like there is probably a
cleaner way to achieve what I want. Note that _program is a ref_ptr to a
properly create osg::Program object, since I certainly do NOT want to
recreate all the goodness it provides. :)

Any API advice?

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

Re: [osg-users] [ANN] osgAndroid: Library for develop OSG applications in Android

[Jeremy Moles]

On Thu, 2012-08-30 at 14:02 +0200, Rafa Gaitan wrote:
> Hi everybody,
> 
> 
> I'm glad to announce osgAndroid (OpenSceneGraph for Android). It
> consists in a set of Java/JNI wrappers of OpenSceneGraph and some
> helper classes to easily develop OSG applications in Android.

Just out of curiosity, does this avoid the need to "enable untrusted
software sources" or whatever it is Android calls it?

> 
> The code repository is hosted in Gitorious:
> 
> 
> https://gitorious.org/osgandroid
> 
> 
> I still don't have a complete documentation, but some
> quick start guidelines can be found here:
> 
> 
> https://gitorious.org/osgandroid/pages/Home
> 
> The osgAndroid project has been initially funded by:
> 
> IRTIC(http://smagris3.uv.es/irtic/)
> AI2(http://www.ai2.upv.es)
> MirageTechnologies S.L.(http://www.mirage-tech.com).
> 
> 
> But we all agreed in open the source code and try to make the life
> easier to all osg developers that want to migrate applications to
> Android. The project was initially developed with AR applications in
> mind, so you will not find too many interaction tools there, and of
> course has some limitations, but you can load and display a model with
> only a few lines of code:
> 
> 
> ... 
> mView = new Viewer(this);
> mView.init(false, 16, 8);
> mView.setSceneData(ReadFile.readNodeFile("/sdcard/axes.ive"));
> mView.setDefaultSettings();
> setContentView(mView);
> ...
> 
> 
> Some usage samples can also be found in the code, such as how to use
> the Android device Camera with an OSG scene with transparent
> background or how to mix osgAndroid and native code in an Android
> Activity, and much more will be added.
> 
> 
> I would also like to announce the project in the community news
> section of the new site (openscenegraph.com), is it possible?
> 
> 
> I really hope this will be useful to the community, and of course feel
> free to contribute!
> 
> 
> Cheers,
> Rafa
> 
> 
> 
> 
> 
> -- 
> Rafael Gaitán Linares
> CTO at Mirage Technologies S.L - http://www.mirage-tech.com
> gvSIG3D Developer - http://gvsig3d.blogspot.com
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

Re: [osg-users] [3rdparty] osgWidget and rotation

[Jeremy Moles]

On Tue, 2012-08-28 at 16:59 +0200, Miguel Lokida wrote:
> So i see what you mean. But how can I declare the position of my widget 
> relative to the parented window ?
> 
> Here's the code I use:
> 
> [code]
> const unsigned int MASK_2D = 0xF000;
> 
> // note: osgViewer::Viewer* ptrViewer;
> // note: osg::ref_ptr _rootScene;
> // note: ptrViewer->setSceneData(_rootScene);
> 
> osgWidget::WindowManager* wm = new osgWidget::WindowManager( 
>   ptrViewer,
>   ptrViewer->width(),
>   ptrViewer->height(),
>   MASK_2D,
>   osgWidget::WindowManager::WM_PICK_DEBUG
>  );
> 
> osgWidget::Window* box = new osgWidget::Box("HBOX", osgWidget::Box::VERTICAL, 
> true);
> 
> osgWidget::Widget * testWidget = new osgWidget::Widget("test", 100.0f, 
> 100.0f);
> testWidget->setColor(1, 0, 0, 1.0);
> box->addWidget(testWidget);
> 
> //box->setAnchorHorizontal(osgWidget::Window::HA_RIGHT);
> //box->setAnchorVertical(osgWidget::Window::VA_TOP);
> 
> box->setVisibilityMode(osgWidget::Window::VM_ENTIRE);
> 
> wm->addChild(box);
> 
> // rotation
> box->setRotate(45.0);
> 
> osg::Group*  group  = new osg::Group();
> osg::Camera* camera = wm->createParentOrthoCamera();
> 
> _rootScene->addChild(camera);
> 
> wm->resizeAllWindows();
>  
> [/code]
> 
> may be I am wrong with this code ?

I've done some testing and you aren't really doing anything wrong here;
it is simply a weakness in osgWidget I never thought of. I'm not sure
how to best proceed, but you have at least two reasonable options:

1) An osgWidget::Window is a MatrixTransform, and an osgWidget::Widget
is just an osg::Geometry. You could attach an
osg::Drawable::UpdateCallback to your widget, but you'd need to do some
fancy calculations to get it to rotate in place. I tried quickly doing
this, but couldn't get the math right in the few minutes I had to test
it... I've attached this code, but you'll need to "fix" it to make it
work.

2) Create one Window for your compass outline and another for your
compass spinner; add the spinner to the outline and call setRotate() on
the spinner window as needed.

In the long run, osgWidget should be rewritten to be more modern and use
my (and utilizing feedback from the community) improved understanding of
OSG in general. Alas, the bills don't stop coming, and the little free
time I have (I do Linux development as my 40+/week) goes to the
occasional contract I can secure or other such activities.

I would really like to go back and fix all the things I know are wrong,
I just need a solid, uninterrupted 2 weeks to do so. :)

> Thanks !
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=49635#49635
> 
> 
> 
> 
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

#include 
#include 
#include 
#include 
#include 

const unsigned int MASK_2D = 0xF000;

class SpinnerCallback: public osg::Drawable::UpdateCallback {
	virtual void update(osg::NodeVisitor* nv, osg::Drawable* drawable) {
		static osg::Matrix::value_type r = 0.0f;
		static double  t = 0.0f;
		
		double time = nv->getFrameStamp()->getSimulationTime();

		if(time - t > 0.1f) {
			r += 1.0f;
			t  = time;

			OSG_WARN << r << std::endl;

			osgWidget::Widget* widget = dynamic_cast(drawable);
			osgWidget::PointArray* points = dynamic_cast(widget->getVertexArray());

			osg::Matrix rotate= osg::Matrix::rotate(osg::DegreesToRadians(r), osg::Vec3(0.0f, 0.0f, 1.0f));
			osg::Matrix translate = osg::Matrix::translate(osg::Vec3(0.0f, 0.0f, 0.0f));

			for(
osgWidget::PointArray::iterator i = points->begin();
i != points->end();
i++
			) {
*i = rotate * translate * *i;
			}
		}
	}
};

int main(int argc, char** argv) {
	osgViewer::Viewer viewer;

	osgWidget::WindowManager* wm = new osgWidget::WindowManager(
		&viewer,
		640.0f,
		480.0f,
		MASK_2D,
		osgWidget::WindowManager::WM_PICK_DEBUG
	);

	osgWidget::Box*outline = new osgWidget::Box("Outline", osgWidget::Box::VERTICAL, true);
	osgWidget::Widget* spinner = new osgWidget::Widget("Spinner", 100.0f, 100.0f);

	spinner->setPadding(100.0f);
	spinner->setColor(1.0f, 0.0f, 0.0f, 1.0f);
	spinner->setUpdateCallback(new SpinnerCallback());

	outline->addWidget(spinner);
	outline->getBackground()->setColor(1.0f, 1.0f, 1.0f, 1.0f);
	outline->attachMoveCallback();

	wm->addChild(outline);

	return osgWidget::createExample(viewer, wm);
}

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

Re: [osg-users] [3rdparty] osgWidget and rotation

[Jeremy Moles]

On Tue, 2012-08-28 at 11:05 +0200, Miguel Lokida wrote:
> Hi,
> 
> I want to use an osgWidget to draw a compass. So, I need to use the rotation. 
> The problem is that the origin of the osgWidget is at the bottom left and not 
> at the center of the widget. 
> 
> How can I specify the center of my widget (since set Origin only move the 
> widget) in order to have a good rotation.

A Widget's origin should be relative to the Window it is parented in.
Rotations should occur properly in that respect, can you provide some
code that isn't behaving properly?

> Thank you!
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=49609#49609
> 
> 
> 
> 
> 
> ___
> 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] Chicken & Egg Problem: BoundingBoxes

[Jeremy Moles]

On Mon, 2012-08-27 at 21:04 +0100, Robert Osfield wrote:
> Hi Jeremy,
> 
> On 27 August 2012 17:34, Jeremy Moles  wrote:
> > You can (and in fact you have to!), but it won't set the dirty flags of
> > the parent Geode, so you're forced to call dirtyBound() on it as well.
> > This can be tough to do because you need to be sure it has already
> > compiled the Paths, which is why I made the initial post.
> 
> Interesting issue...
> 
> The thing to be careful about allow a const dirtyBound() is that it
> opens the door to multi-threading issues where multiple threads could
> call dirty at one time - for instance from multiple cull traversals
> all running at the same time.  There is also the problem that calling
> dirtyBound() would force a computeBound() on the next getBound() call
> which again could present a multi-threading issue where multiple
> threads could potentially be reading and writing from the data
> structures.
> 
> Now... if the drawable can only be managed from a single context or
> from a single cull thread at one time then this multi-threading issue
> wouldn't be an issue, but it's a restriction that is very domain
> specific.
> 
> Rather than relax the core OSG for a niche case might the better
> solution just to cast away constness from your subclass with a note
> that it should just be used on single thread cull. There might be a
> better solution down the line but for now this is route I'd prefer to
> take.

I find myself 100% in agreement and shall proceed thusly! :)

> 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] Camera manipulator velocity and home() calculation affected after scaling nodes

[Jeremy Moles]

On Mon, 2012-08-27 at 15:12 -0400, Judson Weissert wrote:
> On 8/27/2012 2:22 PM, Jeremy Moles wrote:
> > On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote:
> >> Hello,
> >>
> >> I was hoping someone could help me with a camera manipulator/scaling
> >> problem that I have been having.
> >>
> >> I have a scene graph that contains geometry representing a hydraulic
> >> fracture. The fracture length is of the order 1000ft, the height is of
> >> the order 100ft, and the width is of the order .01ft. I am trying to
> >> appy a width exaggeration factor to the model in order to artificially
> >> inflate the geometry along the width axis (in my case it is along the
> >> z-axis). To accomplish this, I call
> >> osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on
> >> the PAT node that I use to orient the fracture in the model. This works
> >> as expected, and the fracture width is exaggerated. However, the camera
> >> manipulator (osgGA::TrackballManipulator) does not return to the same
> >> home position. The larger the scale value, the further the home position
> >> seems to be from the model. Also, the velocity of the camera (model
> >> distance / screen pixel distance) when manipulated via the mouse
> >> increases with the scale value. That is, dragging the mouse an inch on
> >> the screen results in a larger camera manipulation when the scale value
> >> is increased.
> >>
> >> Perhaps I am making some false assumptions regarding how the camera
> >> manipulators and scaling operations interact? Is the scaling operation
> >> messing up a bounding box calculation somewhere? I tried computing then
> >> drawing the bounding box of the root node, but it did not seem to change
> >> for either case. That is, the exaggerated fracture width does not make
> >> the overall volume of the scene any larger (as far as I can tell).
> > I've been working on a custom OrthographicCameraManipulator (and have
> > done FirstPersonShooter and other kinds of CameraManipulators in the
> > past) and I've never seen this behave OTHER than how you're describing.
> >
> > Scaling the PAT will definitely affect the home position of the
> > osgGA::StandardManipulator, so you may end up having to do something
> > like:
> >
> > osgGA::CameraManipulator* cm = viewer.getCameraManipulator();
> >
> > cm->setHomePosition(...);
> >
> > That should also set autoComputeHomePosition to false, so it'll stick.
> >
> > I could, of course, be misunderstanding the question. :)
> 
> Thank you.
> 
> After thinking about what you said, I figured I would revisit my bounding box 
> code. I must have made a mistake the first time around because this time I do 
> get a completely different bounding box for the scene when the scale changes. 
> Therefore, the code that is computing the home position thinks that it needs 
> to view a huge volume, even though most of that volume does not actually 
> contain any drawables.
> 
> Therefore, I think I need to fix the bounds calculation and then I will still 
> be able to rely on the default ComputeHomePosition algorithm. So far I have 
> just relied on the default bounds() calculations.
> 
> Thanks,

A Drawable can have a special ComputeBoundsCallback() (something like
that, I'm on my phone right now and can't look it up), so you could use
that as well...

> Judson
> 


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

Re: [osg-users] Camera manipulator velocity and home() calculation affected after scaling nodes

[Jeremy Moles]

On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote:
> Hello,
> 
> I was hoping someone could help me with a camera manipulator/scaling
> problem that I have been having.
> 
> I have a scene graph that contains geometry representing a hydraulic
> fracture. The fracture length is of the order 1000ft, the height is of
> the order 100ft, and the width is of the order .01ft. I am trying to
> appy a width exaggeration factor to the model in order to artificially
> inflate the geometry along the width axis (in my case it is along the
> z-axis). To accomplish this, I call
> osg::PositionAttitudeTransform::setScale(osg::Vec3d(1.0, 1.0, 100.0)) on
> the PAT node that I use to orient the fracture in the model. This works
> as expected, and the fracture width is exaggerated. However, the camera
> manipulator (osgGA::TrackballManipulator) does not return to the same
> home position. The larger the scale value, the further the home position
> seems to be from the model. Also, the velocity of the camera (model
> distance / screen pixel distance) when manipulated via the mouse
> increases with the scale value. That is, dragging the mouse an inch on
> the screen results in a larger camera manipulation when the scale value
> is increased.
> 
> Perhaps I am making some false assumptions regarding how the camera
> manipulators and scaling operations interact? Is the scaling operation
> messing up a bounding box calculation somewhere? I tried computing then
> drawing the bounding box of the root node, but it did not seem to change
> for either case. That is, the exaggerated fracture width does not make
> the overall volume of the scene any larger (as far as I can tell).

I've been working on a custom OrthographicCameraManipulator (and have
done FirstPersonShooter and other kinds of CameraManipulators in the
past) and I've never seen this behave OTHER than how you're describing.

Scaling the PAT will definitely affect the home position of the
osgGA::StandardManipulator, so you may end up having to do something
like:

osgGA::CameraManipulator* cm = viewer.getCameraManipulator();

cm->setHomePosition(...);

That should also set autoComputeHomePosition to false, so it'll stick.

I could, of course, be misunderstanding the question. :)

> Additional information:
> 
> Lib Version: OpenSceneGraph 3.1.2 (Compiled with VS2010 on Windows 7 64-bit)
> Manipulator: osgGA::TrackballManipulator
> 
> Any hints/tips would be greatly appreciated.
> 
> Thank you,
> 
> Judson Weissert
> ___
> 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] Chicken & Egg Problem: BoundingBoxes

[Jeremy Moles]

On Mon, 2012-08-27 at 17:30 +0100, Robert Osfield wrote:
> Hi Jeremy,
> 
> On 27 August 2012 17:21, Jeremy Moles  wrote:
> > This isn't currently possible because of the dirtyBound() prototypes on
> > Drawable and Node (they are not const). However, if this is an API
> > change you'd be agreeable to, I'd be happy to submit it. :)
> 
> As you have a subclass from Drawable you should be able to set the
> dirty flag directly.

You can (and in fact you have to!), but it won't set the dirty flags of
the parent Geode, so you're forced to call dirtyBound() on it as well.
This can be tough to do because you need to be sure it has already
compiled the Paths, which is why I made the initial post.

> 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] Chicken & Egg Problem: BoundingBoxes

[Jeremy Moles]

On Mon, 2012-08-27 at 16:50 +0100, Robert Osfield wrote:
> Hi Jeremy,
> 
> The OSG uses a compile traversal that is called on the first frame of
> rendering (Renderer.cpp's Renderer::compile() method) and this will
> call your Drawable::compileGLObjects(), this can then set the dirty
> bound so that on the next cull traversal it'll update bounding box
> automatically for you.  The other thing to do would be to estimate the

This isn't currently possible because of the dirtyBound() prototypes on
Drawable and Node (they are not const). However, if this is an API
change you'd be agreeable to, I'd be happy to submit it. :)

> bounding box based on the input parameters to your Drawable, or let
> the use define this or leave it up to the compile method.
>
> Robert.
> 
> On 27 August 2012 16:22, Jeremy Moles  wrote:
> > Hello all!
> >
> > I'm working on a NodeKit (that is coming along nicely, btw) for using
> > the NVidia NV_path_rendering extension with OSG. This new extension has
> > an interesting--and, AFAIK, hitherto unseen--rendering model.
> >
> > When using NV_path_rendering (which I will call NVPR), one must feed
> > path coordinate data into the OpenGL driver and it will "compile" this
> > data for you into resources the graphics context identifies by number.
> > This work fairly well in OSG using the Drawable override of
> > compileGLObjects(), since I am given a valid and active graphics context
> > which I can use to build the renderable objects.
> >
> > (As a side node, for the uninitiated, a "path" in this context is a
> > N-order series of 2D coordinates that you use to draw vectors graphics;
> > for example, fonts. NVPR is an extension that uses your Cuda cores to
> > drastically speed this process up and create incredibly fast and
> > high-quality 2D graphics.)
> >
> > I mentioned earlier that compiling these objects and making them
> > available to OSG (even as displayLists) is straightforward. HOWEVER,
> > there is an issue with regards to properly informing OSG of the bounding
> > boxes of these objects, a kind of "chicken-and-egg" problem. :)
> >
> > Up until now, Drawable objects in OSG have had some kind of 3D geometric
> > data associated with them. This lets the object calculate the bounding
> > box on the CPU as the object is created, and inform the scenegraph
> > almost immediately what to expect with regards to its bounds. In NVPR,
> > we need the GPU to compute these bounds, but it cannot do so until AFTER
> > it has compiled the objects internally. This means it needs a valid
> > graphics context an should ideally do so towards the end of the
> > compileGLObjects method. As before, this is straightforward to execute,
> > but the order of operations here makes things tricky with OSG.
> >
> > Consider the following:
> >
> > osg::Geode*g = new osg::Geode();
> > osgNVPR::Path* p = new osg::PathCommands();
> >
> > p->doStuff();
> >
> > g->addDrawable(p);
> > // DOH! OSG wants to do bounding calculations here, but we
> > // haven't yet compiled or calculated the path internally
> > // until compileGLObjects is called!
> >
> > I've come up with some workarounds, such as calling:
> >
> > viewer.realize();
> > viewer.frame();
> >
> > ...and then manually calling dirtyBound(), but these feels very wrong to
> > me.
> >
> > I wanted to quickly as the OSG community if they had any advice on how I
> > should best approach this problem. Drawble::dirtyBound() isn't a const
> > method, and so can't be easily called from compileGLObjects.
> >
> > Perhaps there may be some way to "pre-compile" these paths with a valid
> > rendering context shortly after creating the Viewer?
> >
> > At any rate, hope everyone has a great week! LABOR DAY EXTENDED WEEKEND!
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

[osg-users] Chicken & Egg Problem: BoundingBoxes

[Jeremy Moles]

Hello all!

I'm working on a NodeKit (that is coming along nicely, btw) for using
the NVidia NV_path_rendering extension with OSG. This new extension has
an interesting--and, AFAIK, hitherto unseen--rendering model.

When using NV_path_rendering (which I will call NVPR), one must feed
path coordinate data into the OpenGL driver and it will "compile" this
data for you into resources the graphics context identifies by number.
This work fairly well in OSG using the Drawable override of
compileGLObjects(), since I am given a valid and active graphics context
which I can use to build the renderable objects.

(As a side node, for the uninitiated, a "path" in this context is a
N-order series of 2D coordinates that you use to draw vectors graphics;
for example, fonts. NVPR is an extension that uses your Cuda cores to
drastically speed this process up and create incredibly fast and
high-quality 2D graphics.)

I mentioned earlier that compiling these objects and making them
available to OSG (even as displayLists) is straightforward. HOWEVER,
there is an issue with regards to properly informing OSG of the bounding
boxes of these objects, a kind of "chicken-and-egg" problem. :)

Up until now, Drawable objects in OSG have had some kind of 3D geometric
data associated with them. This lets the object calculate the bounding
box on the CPU as the object is created, and inform the scenegraph
almost immediately what to expect with regards to its bounds. In NVPR,
we need the GPU to compute these bounds, but it cannot do so until AFTER
it has compiled the objects internally. This means it needs a valid
graphics context an should ideally do so towards the end of the
compileGLObjects method. As before, this is straightforward to execute,
but the order of operations here makes things tricky with OSG.

Consider the following:

osg::Geode*g = new osg::Geode();
osgNVPR::Path* p = new osg::PathCommands();

p->doStuff();

g->addDrawable(p);
// DOH! OSG wants to do bounding calculations here, but we
// haven't yet compiled or calculated the path internally
// until compileGLObjects is called!

I've come up with some workarounds, such as calling:

viewer.realize();
viewer.frame();

...and then manually calling dirtyBound(), but these feels very wrong to
me.

I wanted to quickly as the OSG community if they had any advice on how I
should best approach this problem. Drawble::dirtyBound() isn't a const
method, and so can't be easily called from compileGLObjects.

Perhaps there may be some way to "pre-compile" these paths with a valid
rendering context shortly after creating the Viewer?

At any rate, hope everyone has a great week! LABOR DAY EXTENDED WEEKEND!

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

Re: [osg-users] osgWidget Missing Resources

[Jeremy Moles]

On Thu, 2012-08-23 at 14:02 +0100, Robert Osfield wrote:
> Hi Kim,
> 
> On 24 July 2012 11:59, Kim Bale  wrote:
> > Does anybody have any idea where the missing resources for the osgWidget
> > examples are?
> >
> > I use the latest OpenSceneGraph-Data from the svn but they're not in there.
> >
> > I'm referring specifically to osgwidgetmessagebox.cpp and
> >
> > std::string buttonTheme = "osgWidget/theme-8-shadow.png";
> > std::string borderTheme = "osgWidget/theme-8.png";
> >
> > I think there are others that are missing but I haven't done a thorough
> > search.
> 
> If they aren't in OpenSceneGraph-Data then I don't have them.  Perhaps
> Jeremy Moles might be able to help now he's back coding on the OSG
> again...

I'm going to fix these soon, hang tight. If you need immediate help,
send me something offlist or just hit me up on Googletalk.

> 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] Node Callback never called

[Jeremy Moles]

Is your method declared as const? I always forget that...
On Aug 23, 2012 8:28 AM, "Vincent Bourdier" 
wrote:

> Hi,
>
> I don't think, there are mutiple camera, for HUD, but the graph is
> attached to the main one.
>
> Regards,
>
> Vincent.
>
> Le 23/08/2012 10:28, Sergey Polischuk a écrit :
>
>> Hi
>>
>> iirc update traversals (and may be event traversals too) dont traverse
>> subgraphs under nested cameras. Is it your case?
>>
>> Cheers.
>>
>> 23.08.2012, 11:09, "Vincent Bourdier" :
>>
>>> Hi,
>>>
>>> Nice idea, but there is no other callback antwhere in the code, so i
>>> don't think so.
>>>
>>> thanks,
>>>  Vincent.
>>>
>>> Le 23/08/2012 08:55, Stephan Huber a écrit :
>>>
>>>Hi,

   any chance there's another updatecallback attached to one of the
 geode's
   parents and it is missing  a "traverse(node, nv)" ?

   cheers,
   Stephan

   Am 23.08.12 08:42, schrieb Vincent Bourdier:

>   Hi,
>
>   I'm currently having some troubles in my code that I didn't
> understand.
>   Some help would be very apreciated :
>
>   I have a nodeCallback to animate a shader.
>   I set this callback as nodeCallback on a geode that is displayed, but
>   the callback operator() is never called.
>   I set the same callback as CullCallback on the same geode, now it
> works.
>
>   Maybe this is something very simple, but after a day on this issue
> I'm
>   getting mad.
>
>   Thanks for your help.
>
>   Regards,
>   Vincent.
>
 __**_
>>> osg-users mailing list
>>> osg-users@lists.**openscenegraph.org
>>> http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
>>> openscenegraph.org
>>>
>>
> __**_
> osg-users mailing list
> osg-users@lists.**openscenegraph.org 
> http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
> openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Extensions/State Update Question

[Jeremy Moles]

On Mon, 2012-08-20 at 17:55 -0400, Jean-Sébastien Guay wrote:
> Hi Jeremy, nice to see you back writing graphics code!

I finally have the time again! 

> In the past, when I've needed to have a contextID in a custom Drawable, 
> I've always gotten it from inside my drawable's drawImplementation. IIRC 
> it gets a State pointer and this contains a valid contextID. Same when 
> I've needed to create a custom StateAttribute or something, in its 
> apply() method it gets a State pointer with a valid contextID or 
> something like that.
> 
> So you can have a scheme where you defer doing any initialization until 
> your first Drawable / StateAttribute needs to be traversed for actual 
> rendering, and then you get a valid contextID, do your initialization 
> and further ones will use that since initialization has been done already.
> 
> You need to make sure you consider the case where your Drawable / 
> StateAttribute will be used in multiple contexts. IIRC OSG uses the 
> BufferedValue to store resources associated with a context, and I used 
> the same pattern. Again IIRC, there were some order of initialization 
> issues where I assumed some initialization had been done for a context 
> before drawing but it hadn't, but that just involved a bit of pretty 
> simple debugging to get fixed.
> 
> Hope this helps,

It does. Your use of the word "deferred" is really helpful in this, as
it was a "deferred" approach I was taking and was looking for some
assurance this was an acceptable approach. :)

> J-S
> 
> 
> On 20/08/2012 12:48 PM, Jeremy Moles wrote:
> > On Mon, 2012-08-20 at 10:44 -0600, Paul Martz wrote:
> >> What you seem to be saying is that you want to set some OpenGL state once 
> >> that
> >> applies to all contexts, and not have to set it every frame. AND, you 
> >> don't want
> >> to have to add, then remove, a Camera draw callback just to make this 
> >> happen).
> >> Is that a good synopsis of the issue?
> > It's close; I don't actually mind using a Camera draw callback for this
> > purpose if it's appropriate.
> >
> > A real summarizing question is: under what conditions is it "safe" to
> > query for support of a particular extension? And what is the preferred
> > API for either fetching or being provided the contextID with which to do
> > this?
> >
> >> You could keep a bool buffered_value that tells you whether or not you've 
> >> set
> >> the initial/global state for that particular context. Initially false, 
> >> then set
> >> the global state for a context and flip it to true. Would something like 
> >> that help?
> >>  -Paul
> > Certainly, but I'm still stuck on actually SETTING the state in the
> > first place. :)
> >
> >> On 8/20/2012 10:27 AM, Jeremy Moles wrote:
> >>> Hello everyone! I have a bit of a strange question here, so please bear
> >>> with me. I'll try to be as descriptive as I possibly can, though I'm
> >>> certain I will misuse some terminology.
> >>>
> >>> I am adding support for the NV_path_rendering extension to
> >>> OpenSceneGraph. This extension adds a number of new functions to OpenGL
> >>> when using an NVidia card which take on the form:
> >>>
> >>>   glPath{_function_}NV
> >>>
> >>> http://osgnvpr.googlecode.com
> >>>
> >>> In order to create pointers to these new extension functions, I create
> >>> an Extensions object in OSG using the contextID given to me during the
> >>> compileGLObjects method of my overridden Drawable class. This works
> >>> fine, and the code is running as I expect.
> >>>
> >>> https://code.google.com/p/osgnvpr/source/browse/trunk/src/PathCommands.cpp#45
> >>>
> >>> HOWEVER, this paradigm really only works when I need to call extension
> >>> functions associated with an instance (or instances) of my Drawable.
> >>> There are other functions in the NV_path_rendering API that simply set
> >>> global state, and it is with these functions that I'm having difficulty.
> >>>
> >>> The biggest problem here is that in order to get a pointer to the
> >>> Extensions static object, I need a valid GraphicsContext contextID.
> >>> However, I've tried a number of methods to obtain one of these, but
> >>> every attempt I make actually breaks the entire codebase. I wish I could
> >>> explain it better than that...
> >>

Re: [osg-users] Extensions/State Update Question

[Jeremy Moles]

On Mon, 2012-08-20 at 10:44 -0600, Paul Martz wrote:
> What you seem to be saying is that you want to set some OpenGL state once 
> that 
> applies to all contexts, and not have to set it every frame. AND, you don't 
> want 
> to have to add, then remove, a Camera draw callback just to make this 
> happen). 
> Is that a good synopsis of the issue?

It's close; I don't actually mind using a Camera draw callback for this
purpose if it's appropriate.

A real summarizing question is: under what conditions is it "safe" to
query for support of a particular extension? And what is the preferred
API for either fetching or being provided the contextID with which to do
this?

> You could keep a bool buffered_value that tells you whether or not you've set 
> the initial/global state for that particular context. Initially false, then 
> set 
> the global state for a context and flip it to true. Would something like that 
> help?
> -Paul

Certainly, but I'm still stuck on actually SETTING the state in the
first place. :)

> On 8/20/2012 10:27 AM, Jeremy Moles wrote:
> > Hello everyone! I have a bit of a strange question here, so please bear
> > with me. I'll try to be as descriptive as I possibly can, though I'm
> > certain I will misuse some terminology.
> >
> > I am adding support for the NV_path_rendering extension to
> > OpenSceneGraph. This extension adds a number of new functions to OpenGL
> > when using an NVidia card which take on the form:
> >
> > glPath{_function_}NV
> >
> > http://osgnvpr.googlecode.com
> >
> > In order to create pointers to these new extension functions, I create
> > an Extensions object in OSG using the contextID given to me during the
> > compileGLObjects method of my overridden Drawable class. This works
> > fine, and the code is running as I expect.
> >
> > https://code.google.com/p/osgnvpr/source/browse/trunk/src/PathCommands.cpp#45
> >
> > HOWEVER, this paradigm really only works when I need to call extension
> > functions associated with an instance (or instances) of my Drawable.
> > There are other functions in the NV_path_rendering API that simply set
> > global state, and it is with these functions that I'm having difficulty.
> >
> > The biggest problem here is that in order to get a pointer to the
> > Extensions static object, I need a valid GraphicsContext contextID.
> > However, I've tried a number of methods to obtain one of these, but
> > every attempt I make actually breaks the entire codebase. I wish I could
> > explain it better than that...
> >
> > For example, if I try to use some code like the following:
> >
> > 
> >
> > Windows windows;
> >
> > viewer.getWindows(window);
> >
> > cID = windows[0]->getState()->getContextID();
> >
> > osgNVPR::getNVPRExtensions(cID);
> >
> > -
> >
> > ...then I seem to get an invalid contextID and all subsequent attempts
> > to use that contextID (even by OSG itself) won't work. The entire
> > rendering process seems to be broken in this manner.
> >
> > If instead I create a Camera::DrawCallback object and use the RenderInfo
> > there instead, then everything works fine. However, I feel like I'm
> > grossly misusing a Camera::DrawCallback just to set and unset state...
> >
> > My question is: if I need to set global state like this once, somewhere
> > high in the scenegraph, what is the best way--keeping in mind that I
> > also need a valid contextID in order to access my Extensions functions
> > per-context?
> >
> > Thanks!
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

[osg-users] Extensions/State Update Question

[Jeremy Moles]

Hello everyone! I have a bit of a strange question here, so please bear
with me. I'll try to be as descriptive as I possibly can, though I'm
certain I will misuse some terminology.

I am adding support for the NV_path_rendering extension to
OpenSceneGraph. This extension adds a number of new functions to OpenGL
when using an NVidia card which take on the form:

glPath{_function_}NV

http://osgnvpr.googlecode.com

In order to create pointers to these new extension functions, I create
an Extensions object in OSG using the contextID given to me during the
compileGLObjects method of my overridden Drawable class. This works
fine, and the code is running as I expect.

https://code.google.com/p/osgnvpr/source/browse/trunk/src/PathCommands.cpp#45

HOWEVER, this paradigm really only works when I need to call extension
functions associated with an instance (or instances) of my Drawable.
There are other functions in the NV_path_rendering API that simply set
global state, and it is with these functions that I'm having difficulty.

The biggest problem here is that in order to get a pointer to the
Extensions static object, I need a valid GraphicsContext contextID.
However, I've tried a number of methods to obtain one of these, but
every attempt I make actually breaks the entire codebase. I wish I could
explain it better than that...

For example, if I try to use some code like the following:



Windows windows;

viewer.getWindows(window);

cID = windows[0]->getState()->getContextID();

osgNVPR::getNVPRExtensions(cID);

-

...then I seem to get an invalid contextID and all subsequent attempts
to use that contextID (even by OSG itself) won't work. The entire
rendering process seems to be broken in this manner.

If instead I create a Camera::DrawCallback object and use the RenderInfo
there instead, then everything works fine. However, I feel like I'm
grossly misusing a Camera::DrawCallback just to set and unset state...

My question is: if I need to set global state like this once, somewhere
high in the scenegraph, what is the best way--keeping in mind that I
also need a valid contextID in order to access my Extensions functions
per-context?

Thanks!

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

Re: [osg-users] Compiling/installing OSG and FFmpeg?

[Jeremy Graham]

Well, that fixed one big issue!  Now to figure out another one you mentioned.

Thanks so much for that, J!

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





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

Re: [osg-users] Compiling/installing OSG and FFmpeg?

[Jeremy Graham]

Thanks for the input.  I am a total novice to CMake and pretty new to make 
files in general.  In order to follow your suggestion, would I add a line like 
SET(CMAKE_CXX_FLAGS "-D__STDC_CONSTANT_MACROS") to one of the CMake files?  
Perhaps the one named "CMakeCXXCompiler.cmake"?

I did try issuing a command like, "CXXFLAGS=-D__STDC_CONSTANT_MACROS 
./configure" before typing any commands like make or cmake.  That did not seem 
to resolve the issue, unfortunately.

Jeremy

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





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

Re: [osg-users] Compiling/installing OSG and FFmpeg?

[Jeremy Graham]

Thanks for responding, Alberto.  I updated ffmpeg using the information from 
the Ubuntu Compilation Guide at the ffmpeg website and attempted the 
compilation and install with a fresh start.  It still gave me the same error 
upon halting.  Would you happen to have any other ideas or suggestions?  I've 
included more information about the error this time.


[ 97%] Building CXX obje[ 97%] Building CXX object 
src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/FFmpegDecoderAudio.oct 
src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/FFmpegDecoderAudio.o
In file included from /usr/local/include/libavutil/avutil.h:274:0,
 from /usr/local/include/libavutil/samplefmt.h:22,
 from /usr/local/include/libavcodec/avcodec.h:30,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegHeaders.hpp:12,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegClocks.hpp:10,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.hpp:9,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp:1:
/usr/local/include/libavutil/common.h: In function ‘int32_t 
av_clipl_int32_c(int64_t)’:
/usr/local/include/libavutil/common.h:173:47: error: ‘UINT64_C’ was not 
declared in this scope
In file included from 
/home/jeramboquai/OpenSceneGraph-3.0.1/include/osg/FrameStamp:22:0,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/include/osg/BufferObject:20,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/include/osg/Image:17,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/include/osg/AudioStream:17,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.hpp:12,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp:1:
/usr/include/c++/4.6/ctime: At global scope:
/usr/include/c++/4.6/ctime:62:11: error: ‘::clock_t’ has not been declared
/usr/include/c++/4.6/ctime:63:11: In file included from 
/usr/local/include/libavutil/avutil.h:274:0,
 from /usr/local/include/libavutil/samplefmt.h:22,
 from /usr/local/include/libavcodec/avcodec.h:30,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegHeaders.hpp:12,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegClocks.hpp:10,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.hpp:9,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp:1:
/usr/local/include/libavutil/common.h: In function ‘int32_t 
av_clipl_int32_c(int64_t)’:
/usr/local/include/libavutil/common.h:173:47: error: ‘UINT64_C’ was not 
declared in this scope
In file included from 
/home/jeramboquai/OpenSceneGraph-3.0.1/include/osg/FrameStamp:22:0,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/include/osg/BufferObject:20,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/include/osg/Image:17,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/include/osg/AudioStream:17,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.hpp:12,
 from 
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp:1:
/usr/include/c++/4.6/ctime: At global scope:
/usr/include/c++/4.6/ctime:62:11: error: ‘::clock_t’ has not been declared
/usr/include/c++/4.6/ctime:63:11: error: ‘::time_t’ has not been declared
/usr/include/c++/4.6/ctime:66:11: error: ‘::clock’ has not been declared
/usr/include/c++/4.6/ctime:67:11: error: ‘::difftime’ has not been declared
/usr/include/c++/4.6/ctime:68:11: error: ‘::mktime’ has not been declared
error: ‘::time_t’ has not been declared
/usr/include/c++/4.6/ctime:66:11: error: ‘::clock’ has not been declared
/usr/include/c++/4.6/ctime:67:11: error: ‘::difftime’ has not been declared
/usr/include/c++/4.6/ctime:68:11: error: ‘::mktime’ has not been declared
/usr/include/c++/4.6/ctime:69:11: error: ‘::time’ has not been declared
/usr/include/c++/4.6/ctime:70:11: error: ‘::asctime’ has not been declared
/usr/include/c++/4.6/ctime:71:11: error: ‘::ctime’ has not been declared
/usr/include/c++/4.6/ctime:72:11: error: ‘::gmtime’ has not been declared
/usr/include/c++/4.6/ctime:73:11: error: ‘::localtime’ has not been declared
/usr/include/c++/4.6/ctime:74:11: error: ‘::strftime’ has not been declared
/home/jeramboquai/OpenSceneGraph-3.0.1/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp:
 In function ‘int osgFFmpeg::dec/usr/include/c++/4.6/ctime:69:11: error: 
‘::time’ has not been declared
/usr/include/c++/4.6/ctime:70:11: error: ‘::asctime’ has not been declared
/usr/include/c++/4.6/ctime:71:11: error: ‘::ctime’ has not been declared
/usr/include/c++/4.6/ctime:72:11: er

[osg-users] Compiling/installing OSG and FFmpeg?

[Jeremy Graham]

Hi,

Once upon a time, I think this was mentioned but it has been several years ago 
and I do not know if an actual resolution came out of it, so I thought I'd ask. 
 Does anybody know the source of this error...and more importantly how to 
resolve it?

I am trying to compile and install OSG using the instructions found at the 
GettingStarted page on the OSG site.

I am trying to execute the following commands:
cd OpenSceneGraph
./configure
make
sudo make install

However, on the make command, the process is halted and I get an error message 
like the following:
/home/jeramboquai/OpenSceneGraph/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp: 
In member function ‘size_t osgFFmpeg::FFmpegDecoderAudio::decodeFrame(void*, 
size_t)’:
/home/jeramboquai/OpenSceneGraph/src/osgPlugins/ffmpeg/FFmpegDecoderAudio.cpp:361:48:
 error: ‘INT64_C’ was not declared in this scope
make[2]: *** 
[src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/FFmpegDecoderAudio.o] Error 1
make[1]: *** [src/osgPlugins/ffmpeg/CMakeFiles/osgdb_ffmpeg.dir/all] Error 2
make: *** [all] Error 2

That is the end of the output.  Does anybody know how to resolve this error 
about INT64_C not being declared?  I tried the recommendation of typing 
"CXXFLAGS=-D__STDC_CONSTANT_MACROS ./configure" before make but that did not 
solve the problem.  I'd really appreciate anyone's help.


Thank you!

Cheers,
Jeremy

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





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

Re: [osg-users] Background transparency on iOS

[Jeremy Blatter]

Hi Stephan,
I finally find the time to try your solution, and that works perfectly fine!
The background video is displayed at 30fps independently of the 3D scene, so 
the user experience is much better now :D 

Thanks a lot and merry Christmas !
Jeremy



sth wrote:
> Hi,
> 
> instead of making the opengl-view transparent you can render the
> live-video as a texture inside osg, you'll have to feed the video-image
> into an osg-texture, but it's relatively simple to do.
> 
> If you insist in a transparent opengl view you'll have to hack
> GraphicsWindowIOS.mm, as there's no support for transparent views yet.
> 
> Change eaglLayer.opaque = YES; to eaglLayer.opaque = NO; around line
> 200, and be sure, that your osg-displaysettings /
> GraphicsWindows::Traits require an alpha-channel. (I have not tested
> this approach, ymmv)
> 
> For some background:
> http://stackoverflow.com/questions/1394934/iphone-layering-a-transparent-opengl-view-on-top-of-a-uiview
> 
> HTH,
> Stephan
> 
> Am 26.11.11 21:36, schrieb Jeremy Blatter:
> 
> > I'm developing an augmented reality application for iPad. I'm using 
> > OpenSceneGraph to render the 3D objects over the camera view.
> > My code is based on the view_test iPhone example given with the sources on 
> > Github, so we can discuss my problem from this exemple.
> > 
> > I wish to set the background of the OSG Viewer transparent, so we can see 
> > the UIView behind (which contains the iPad camera preview layer in my 
> > application, that works well).
> > To be clear, say that in the view_test exemple, I change the background 
> > color of the view in FlipsideViewController.mm
> > 
> > 
> > Code:
> > - (void)viewDidLoad {
> > ...
> > self.view.backgroundColor = [UIColor redColor];
> > ...
> > }
> > 
> > 
> > 
> > Then, I wish to see this red color as background for my 3D scene (the box) 
> > instead of the default blue background.
> > My intuition was to change the clearColor to black with the alpha channel 
> > set to 0 :
> > 
> > 
> > Code:
> > _viewer->getCamera()->setClearColor(osg::vec4(0.0f, 0.0f, 0.0f, 0.0f));
> > 
> > 
> > 
> > The background is black as expected, but the alpha value is not considered 
> > (as if it was always 1.0f).
> > Any ideas?
> > 
> 
> ___
> osg-users mailing list
> 
> 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=44451#44451





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

Re: [osg-users] Background transparency on iOS

[Jeremy Blatter]

Hi Stephan!

Thank you for your answer.

Until now, I render the video in a texture as you suggest and that works well. 
The problem is that my 3D scene is quite complex (for the iPad ;) ) so the 
framerate is not so good... Thus I came up with this idea in order to display 
directly the video preview layer at 30 fps. I think we can tolerate if the 
rendering of the scene is not perfectly smooth, as long as the video behind is.

Anyway I will try your suggestion as soon as possible. Be sure I'll give you 
some feedback then!

Best,
Jeremy

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





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

[osg-users] Background transparency on iOS

[Jeremy Blatter]

Hi,

I'm developing an augmented reality application for iPad. I'm using 
OpenSceneGraph to render the 3D objects over the camera view.
My code is based on the view_test iPhone example given with the sources on 
Github, so we can discuss my problem from this exemple.

I wish to set the background of the OSG Viewer transparent, so we can see the 
UIView behind (which contains the iPad camera preview layer in my application, 
that works well).
To be clear, say that in the view_test exemple, I change the background color 
of the view in FlipsideViewController.mm


Code:
- (void)viewDidLoad {
...
self.view.backgroundColor = [UIColor redColor];
...
}

 

Then, I wish to see this red color as background for my 3D scene (the box) 
instead of the default blue background.
My intuition was to change the clearColor to black with the alpha channel set 
to 0 :


Code:
_viewer->getCamera()->setClearColor(osg::vec4(0.0f, 0.0f, 0.0f, 0.0f));



The background is black as expected, but the alpha value is not considered (as 
if it was always 1.0f).
Any ideas?

Thanks!

Cheers,
Jeremy

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





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

Re: [osg-users] [3rdparty] Using OSGWidgets with OSGArt

[Jeremy Moles]

On Sun, 2011-10-30 at 09:09 +0100, Stefanos Kougiou wrote:
> Hi,
> 
> I am building an application using OSGARt and I recently tried to use the 
> example: osgwidgetlabel   to show some static labels on the viewer.
> 
> I followed the procedure as in the example and the labels were visible on the 
> screen. The problem is that my testcube vanished as if the tracker could not 
> recognize it on the webcam stream.
> 
> I found out that the camera was the problem, specifically the setup.
> 
> To enable the widgets I created a window manager and added the labels. Then I 
> used the code from the function createOrthoCamera.
> 
> osg::Camera* camera = new osg::Camera();
> 
> camera->getOrCreateStateSet()->setMode(
> GL_LIGHTING,
> osg::StateAttribute::PROTECTED | osg::StateAttribute::OFF
> );
> 
> camera->setProjectionMatrix(osg::Matrix::ortho2D(0.0, width, 0.0f, 
> height));
> camera->setReferenceFrame(osg::Transform::ABSOLUTE_RF);
> camera->setViewMatrix(osg::Matrix::identity());
> camera->setClearMask(GL_DEPTH_BUFFER_BIT);
> camera->setRenderOrder(osg::Camera::POST_RENDER);
> 
> After the creation of the camera I used the standard procedure of OSGart, 
> meaning I added the tracker and the video stream.
> 
> camera -> addChild(arTransform.get());
> camera -> addChild(videoBackground.get());
> 
> I know that the camera creation in OSGart must be done through the 
> calibration object  -> osgART::Calibration 
> 
> so I think it is normal that the OrthoCamera Settings cannot function 
> correctly. 
> 
> Is there a way to make something like this to work?Does anyone know if there 
> is any documentation on the osgWidget objects? Any help would be appreciated. 

How many total cameras are in your scene? Geometry/Geodes in osgWidget
are no different than any other part of OSG, so you just need to make
sure all of your objects expect to be viewed the same way.

I've never used osgArt, so I can't really comment more beyond that... if
the two kits are using different setups though, just try to keep them in
sync.

> Thank you for your time!
> Stefanos
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=43632#43632
> 
> 
> 
> 
> 
> ___
> 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] Simulation Loop in osgWidget

[Jeremy Moles]

On Tue, 2011-10-11 at 04:08 +0200, dan marshal wrote:
> Very sorry!
> 
> If I create a window using:
> 
>  osgViewer::Viewer viewer;
>  osgWidget::WindowManager* wm = new osgWidget::WindowManager(
> &viewer,
> WINDOW_WIDTH,
> WINDOW_HEIGHT,
> MASK_2D
> );
> ..
> .viewer.home();
> 
> I get a viewer object inside a window.
> ===
> However if I change
> 
> viewer.home();
> 
> to
>   while(!viewer.done())
>   {
>   viewer.frame();
>   }
> 
> I lose the osgWidget:WindowManager window and the viewer object now takes 
> over the entire screen.
> 
> I would like to keep my window but be able to add additional code inside the 
> viewer simulation loop.
> 
> How can I use the osgWidget::Window and be able to add calls to the 
> simulation loop?
> 
> Thank you again,

Hmm, I'm still not sure what's going on. Can you provide me some example
code? I tried this here on my end and saw no issues... (Linux, Fedora 15
64bit)

> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=43310#43310
> 
> 
> 
> 
> 
> ___
> 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] Rendering From First Person

[Jeremy Moles]

On Sun, 2011-10-09 at 04:53 +0200, Rishabh Taneja wrote:
> Hi Jeremy,
> 
> I am a newbie in osg. I am working on a project to build a virtual 
> environment.After trying a lot, I am not able to create first person 
> experience in my environment. Can you help me out in this regard.

Sure, do you have any sample code? What OS are you on? I may be able to
provide a very simple example...

> ... 
> 
> Thank you!
> 
> Cheers,
> Rishabh
>  (ryshabtaneja@gmail)
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=43276#43276
> 
> 
> 
> 
> 
> ___
> 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] osgWidget complex widgets

[Jeremy Moles]

On Tue, 2011-10-11 at 17:32 +0100, James Turner wrote:
> Hi,
> 
> I'm experimenting with replacing an existing widget set with versions based 
> on osg::Widget. I hope to create most items by composition, eg a scrollbar as 
> two end buttons, plus a 'track' and 'thumb', each an osgWidget::Frame or 
> similar, arranged in a layout. I was wondering if anyone had any open-source 
> examples of this to share? I need to create many standard widgets (such as 
> scrollbars, spinboxes, sliders), and unfortunately text-editing widgets as 
> well. The osgWidget demos give me everything I strictly *need*, but seeing 
> what other people have done would make me more comfortable I'm on a good path 
> :)

I really, really, really wish I could help the community more with this
sort of thing. I've wanted to do more osgWidget development for a long
time, but the bills must be paid. :(

And, unfortunately, my "real" job has absolutely nothing to do with
graphics programming, so I have very little time to work with OSG. Maybe
one day that will change, but in the interim you're always welcome to
add me on Googletalk and bug me there (cubic...@gmail.com)

Best of luck...

> Regards,
> James
> 
> ___
> 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] Simulation Loop in osgWidget

[Jeremy Moles]

On Mon, 2011-10-10 at 17:25 +0200, dan marshal wrote:
> Hi,
> 
> I am using osgWidget to run osg inside a window frame.

Can you clarify what you mean by this? osgWidget is an OSG nodekit, I'm
not entirely sure what to derive from this statement (which makes the
rest of the e-mail impossible to understand).

Thanks!

> It works fine when I use
> 
> viewer.home();
> 
> No problem.
> 
> However, if I use:
> 
>   while(!viewer.done())
>   {
>   viewer.frame();
>   }
> to get access to the simulation loop, the widget window is lost and osg is 
> again using the full screen.
> 
> How can I use osgWidget and program inside the simulation loop?
> 
> Thank you
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=43302#43302
> 
> 
> 
> 
> 
> ___
> 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] [ANN] New OSG book on the way, and new plan of OSG recipes

[Jeremy Moles]

On Thu, 2011-09-29 at 23:02 +0800, Wang Rui wrote:
> Hi Jeremy,
> 
> 2011/9/29 Jeremy Moles :
> >
> > BTW: It's a shame you can't add GUI stuff to your upcoming book. The
> > current osgWidget is just... not enough. :)
> >

How long do I have then to clean things up? :)

> Oh, in fact I'm think of introducing osgWidget in the 9th or the last
> chapter. Chapter 9 'Integrating with GUI' should meet its standing.
> :-)
> 
> >
> > I think Robert has looked before, but he may have decided (at least back
> > then) not to. The code has changed a lot since then, so perhaps another
> > look (later, when there's "more at stake") might be good. :)
> >
> 
> I just found that in the ReaderWriterPDF source code there is already
> one CairoImage class. So we had better implement a specialized Cairo
> plugin for reuse in the Flash plugin if it can be merged  in future.

There is, but osgCairo adds Serializer support, premultiply, and a
number of utility functions... I honestly don't imagine Robert having an
aversion to adding it eventually, there just needs to be a powerfully
convincing reason. :)

> Wang Rui
> ___
> 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] [ANN] New OSG book on the way, and new plan of OSG recipes

[Jeremy Moles]

On Thu, 2011-09-29 at 22:39 +0800, Wang Rui wrote:
> Hi Jeremy,
> 
> We have already done an initial flash integration (including osgFlash
> abstract layer and plugins) in osgXI using GameSWF (public domain).
> But the ActionScript support is poor. Another two implementations done
> by my partner are based on ScaleForm (commercial) and COM (Windows
> only).

It was ScaleForm that inspired me to start osgWidget wwaayy back as a
building block for getting that same kind of functionality in OSG. :)

BTW: It's a shame you can't add GUI stuff to your upcoming book. The
current osgWidget is just... not enough. :)

> At present I'm working on a new integration of OSG and Vektrix. The
> latter can support AS3, and the license is MIT. The result can be
> outputted to Cairo first and then to an osgCairo image object for
> rendering, so I'm also wondering if osgCairo can be merged as a plugin
> of core OSG and then the Flash support can be added without requiring
> extra dependence.

I think Robert has looked before, but he may have decided (at least back
then) not to. The code has changed a lot since then, so perhaps another
look (later, when there's "more at stake") might be good. :)

> Wang Rui
> 
> 
> 2011/9/29 Jeremy Moles :
> > On Thu, 2011-09-29 at 20:48 +0800, Wang Rui wrote:
> >> Hi Alessandro,
> >>
> >> I'd like to list the titles of all recipes finished until now as below.
> >>
> >> Thanks for the support. :-)
> >>
> >> Wang Rui
> >>
> >> ---
> >>
> >> [Chapter 1]
> >> Checking  out the latest version of OSG.
> >> Configure Configuring CMake options.
> >> Building plug-ins to support common file externsions.
> >> Compile Compiling and package packaging OSG on different platforms.
> >> Compile Compiling and use using OSG on mobile devices.
> >> Compile Compiling and use using dynamic and static libraries.
> >> Generate Generating the API documentation.
> >> Create Creating your own project using Cmake
> >>
> >> [Chapter 2]
> >> Using smart and observer pointers
> >> Sharing and cloning objects
> >> Computing the world bounding box of any node
> >> Creating a running car
> >> Mirroring the scene graph
> >> Designing a breadth-first node visitor
> >> Implementing a background image node
> >> Making your node always face to screen
> >> Using draw callbacks to execute NVIDIA Cg functions
> >> Implementing a compass node
> >>
> >> [Chapter 3]
> >> Creating a polygon with borderlines
> >> Extruding a 2D shape to 3D
> >> Drawing a NURBS surface
> >> Drawing a dynamic clock on the screen
> >> Drawing a ribbon following a model
> >> Selecting and highlighting a model
> >> Selecting a triangle face of the model
> >> Selecting a point of the model
> >> Using vertex displacement mapping in shaders
> >> Using the draw instanced extension
> >>
> >> [Chapter 4]
> >> Setting up views on multiple screens
> >> Using slave cameras to simulate a power-wall
> >> Using depth partition to display huge scene
> >> Implementing the radar map
> >> Showing the top, front and side views of a model
> >> Manipulating the top, front and side views
> >> Following a moving model
> >> Using manipulator to follow models
> >> Designing a 2D camera manipulator
> >> Manipulating the view with joysticks
> >>
> >> [Chapter 5]
> >> Opening and closing the door
> >> Playing a movie in the 3D world
> >> Designing scrolling texts
> >> Implementing a morph geometry
> >> Fading in and out
> >> Animating a flight on fire
> >> Dynamically lighting within shaders
> >> Creating a simple 'Galaxian' game
> >> Building a skeleton system
> >> Skinning a skeleton system
> >> Letting the physics engine be
> >>
> >> [Chapter 6]
> >> Using the bump mapping technique
> >> Simulating the view-dependent shadow
> >> Implementing transparency with multiple passes
> >> Reading and displaying the depth buffer
> >> Implementing the night vision effect
> >> Implementing the depth-of-field effect
> >> Designing a skybox with the cubemap
> >> Creating simple water effect
> >> Creating a piece of cloud
> >> Customizing the state attribute
> >> Using MRT to create the G-buffer
> >> Completing the deferred shading algor

Re: [osg-users] Rendering From First Person

[Jeremy Moles]

On Wed, 2011-09-28 at 11:37 -0600, Paul Martz wrote:
> On 9/28/2011 9:22 AM, Jean-Sébastien Guay wrote:
> > Hi Jeremy,
> >
> >> My question is how do I render these objects? Should I treat them
> >> specially (for example, adding them in a post render camera) or should I
> >> simply position them properly to be rendered in the main frame? I'm
> >> looking for some "gotchas" from other people who have done something
> >> similar.
> >
> > I'd render them as a separate camera, simply because they're very close to 
> > the 
> > eye and so might affect your depth range and precision pretty drastically. 
> > If 
> > you render them as a separate camera, you'll then have a main camera with a 
> > z 
> > range starting at over 1m (probably the ground will be the closest object 
> > most 
> > of the time) and a post-render camera with a very small near distance but a 
> > very close far distance too, so that's ideal. You can even keep automatic 
> > near-far calculation on for both, and it will likely work really well. 
> 
> I agree with J-S. If you use ABSOLUTE_RF and an identity view matrix, you 
> should 
> be able to draw these scene elements directly in eye space (you're looking 
> down 
> the -z axis with +y up). In OSG parlance, it's effectively a "HUD".
> 
> In OpenGL, the pattern looks like: push the modelview matrix, set it to 
> identity, draw, then pop. Whenever  rendering calls for this OpenGL pattern, 
> in 
> OSG you should immediately think "Camera".
> -Paul

Rendering directly into the framebuffer from a 2nd camera (like a HUD,
as you said) turned out to really simplify things, but it does--of
course--change how I need to handle lighting. Since the gun never
technically moves (though it appears to because of the first camera)
I'll have to come up with a way of updating this second camera with the
proper lighting variables...

> ___
> 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] [ANN] New OSG book on the way, and new plan of OSG recipes

[Jeremy Moles]

On Thu, 2011-09-29 at 20:48 +0800, Wang Rui wrote:
> Hi Alessandro,
> 
> I'd like to list the titles of all recipes finished until now as below.
> 
> Thanks for the support. :-)
> 
> Wang Rui
> 
> ---
> 
> [Chapter 1]
> Checking  out the latest version of OSG.
> Configure Configuring CMake options.
> Building plug-ins to support common file externsions.
> Compile Compiling and package packaging OSG on different platforms.
> Compile Compiling and use using OSG on mobile devices.
> Compile Compiling and use using dynamic and static libraries.
> Generate Generating the API documentation.
> Create Creating your own project using Cmake
> 
> [Chapter 2]
> Using smart and observer pointers
> Sharing and cloning objects
> Computing the world bounding box of any node
> Creating a running car
> Mirroring the scene graph
> Designing a breadth-first node visitor
> Implementing a background image node
> Making your node always face to screen
> Using draw callbacks to execute NVIDIA Cg functions
> Implementing a compass node
> 
> [Chapter 3]
> Creating a polygon with borderlines
> Extruding a 2D shape to 3D
> Drawing a NURBS surface
> Drawing a dynamic clock on the screen
> Drawing a ribbon following a model
> Selecting and highlighting a model
> Selecting a triangle face of the model
> Selecting a point of the model
> Using vertex displacement mapping in shaders
> Using the draw instanced extension
> 
> [Chapter 4]
> Setting up views on multiple screens
> Using slave cameras to simulate a power-wall
> Using depth partition to display huge scene
> Implementing the radar map
> Showing the top, front and side views of a model
> Manipulating the top, front and side views
> Following a moving model
> Using manipulator to follow models
> Designing a 2D camera manipulator
> Manipulating the view with joysticks
> 
> [Chapter 5]
> Opening and closing the door
> Playing a movie in the 3D world
> Designing scrolling texts
> Implementing a morph geometry
> Fading in and out
> Animating a flight on fire
> Dynamically lighting within shaders
> Creating a simple 'Galaxian' game
> Building a skeleton system
> Skinning a skeleton system
> Letting the physics engine be
> 
> [Chapter 6]
> Using the bump mapping technique
> Simulating the view-dependent shadow
> Implementing transparency with multiple passes
> Reading and displaying the depth buffer
> Implementing the night vision effect
> Implementing the depth-of-field effect
> Designing a skybox with the cubemap
> Creating simple water effect
> Creating a piece of cloud
> Customizing the state attribute
> Using MRT to create the G-buffer
> Completing the deferred shading algorithm
> 
> [Chapter 7]
> Preparing the VPB (VirtualPlanetBuilder) tool
> Generating small terrain database
> Generating terrain database on the earth
> Working with multiple imagery and elevation data
> Patching existing terrain database with newer data
> Building NVTT support for device-independent generation
> Using SSH to implement cluster generation
> Configuring and loading terrain from the Internet
> Playing with osgEarth: another way to visualize the world
> Use osgEarth to display VPB generated database

A lot of those look really cool; quite exciting! 

You're working on Flash support in OSG? Are there licensing issues?

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


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

[osg-users] Rendering From First Person

[Jeremy Moles]

Hey guys, looking for some quick design advice before I start hacking
something that I'd end up scrapping.

I've written a pretty traditional FPS camera; game-like movement and
strafing, sprinting, mouse viewing by warping the pointer to the center
of the screen, axis inversion, etc. All the stuff you might find in a
game like Call of Duty or similar. When this is all done, I'll probably
submit the camera (its a child of osgGA::StandardManipulator) as a new
FirstPersonManipulator...

Now I'm looking to add some facilities for attaching objects to the
scene relative to the viewing eye. For example: a weapon and a mesh
representing the viewer's arms.

My question is how do I render these objects? Should I treat them
specially (for example, adding them in a post render camera) or should I
simply position them properly to be rendered in the main frame? I'm
looking for some "gotchas" from other people who have done something
similar.

Thanks!

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

Re: [osg-users] osgexport for blender?

[Jeremy Moles]

On Sun, 2011-09-25 at 03:23 +0200, Damyon Wiese wrote:
> Hi Jeremy,
> 
> Just thought I would post to clarify the post about my exporter (This one: 
> https://code.google.com/p/blender-osgexport-25/).
> 
> I originally tried to update Cedrics exporter for blender 2.5 and got some 
> way but realised that I couldn't follow it well enough to do it without 
> introducing a heap of subtle bugs. So I started fresh and wrote that new 
> exporter you found - but my intent was just to write a proof of concept that 
> Cedric could use when he came to update his exporter - I agree that having 2 
> exporters is not the way to go and that Cedric knows more than anyone about 
> osgAnimation so his exporter should be the way forward. 
> 
> I let Cedric know about my exporter off list and have been giving him updates 
> on the progress so that he can pinch bits from it when he gets to updating 
> his code to support animation. The reason I didn't announce this exporter 
> anywhere (but google found it obviously) is that I don't want to create this 
> confusion. 
> 
> That said - until Cedric has finished his updates if someone uses my exporter 
> and finds a bug, post it in the google code project and I'll be happy to look 
> at it.
> 
> Regards, Damyon

Ah, very cool. I tried to do the adaptation myself a few nights back,
but ran into the same issue you did: the larger, original exporter has
become (and perhaps necessarily so) quite large.

At least you're writing code though, not like me sitting on the
sidelines. :)

> ... 
> 
> Thank you!
> 
> Cheers,
> Damyon
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42994#42994
> 
> 
> 
> 
> 
> ___
> 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] osgexport for blender?

[Jeremy Moles]

On Fri, 2011-09-23 at 17:36 +0200, Alberto Luaces wrote:
> Jeremy Moles writes:
> 
> > Some history: Alberto wrote the first osgexport.py.
> 
> Hi Jeremy,
> 
> just a clarification: I didn't wrote anything :) As far as I know, the
> original osgexport.py script belongs to Rubén López.

CRAP, you're right. Sorry. It was your thread I was responding to and
somehow I transposed that. It WAS Ruben, sorry. :)


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

Re: [osg-users] osgexport for blender?

[Jeremy Moles]

On Fri, 2011-09-23 at 16:38 +0200, Alberto Luaces wrote:
> "Benjamin Gehmlich" writes:
> 
> > Hi Alberto,
> > thanks for your answer, but there is a Problem with blender.
> >
> >
> > When I want to add  the osgExport file ("Install Add-On"), there happens 
> > nothing.
> >
> > What I have done
> > 1.) put the osg folder in blender-2.59/2.59/scripts/addons
> > 2.) the osgExport.py in blender-2.59
> > 3.) started Blender -> User Preferences -> Install Add-On
> > 4.) then chose osgExport.py
> >
> > By the other versions I used, after this I saw an entry.
> >
> > Is there a mistake?
> >
> > The other versions worked good for normaly exports, but when I chose 
> > "Armatur" by the mesh as parent it did not export.
> > Therefore I used the Modifier Armatur and i could export as osg but the 
> > mesh was not correct.
> 
> Benjamin,
> 
> I don't fully understand how you are installing the add-on, but you have
> to take into consideration that the plugin doesn't only need
> osgExport.py, but the `osg' directory as well. Also, start Blender from
> the command line in order to check if the script is not found by your
> Python installation.

The state of the Blender export(s) requires some explanation...

Some history: Alberto wrote the first osgexport.py. A few years later,
Cedric and myself came along and improved (?) it, in a very general
sense. Another year later, Cedric wrote animtk, which eventually became
osgAnimation, and added support for that as well into the exporter.

Then, along came Blender 2.5. It drastically changed the way data is
represented and enumerated in Python internally. Cedric adapted the Mesh
exports easily enough, but the Animation exporting remains
non-functional. You can find all of this code here (git):

https://github.com/cedricpinson/osgexport.git

HOWEVER, another exporter has come into light. I'm not sure WHY this
individual chose to start over (rather than add to the existing
exporter), I do not know. The code base has become quite large however,
so perhaps that is the reason. There are also comments in the source to
the "main" exporter that he actually did work on it at some point. His
code DOES support animation export, but it isn't as robust as the
original in other ways. You can find that code here (git):

https://code.google.com/p/blender-osgexport-25/

To be completely honest, the state of all of this is a total mess. We
now have 2 exporters, each possessing features the other lacks, and
neither of which are (anymore) particularly clean or usable code bases.

I've talked with Cedric about the future of the "original" exporter, and
it certainly hasn't been forgotten, but he is an extremely, EXTREMELY
busy person and it may be a while before anything happens.

I also tried adapting the code from Wiese's exporter myself, but I can't
follow either of the exporters anymore, so no luck there...


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

Re: [osg-users] Motion Blur (or "What is Post Processing?")

[Jeremy Moles]

On Mon, 2011-09-19 at 12:52 -0600, Paul Martz wrote:
> On 9/19/2011 11:16 AM, Jeremy Moles wrote:
> > I can't help but wonder how to best do something like this in OSG. :)
> 
> The general solution -- OSG or whatever -- is to render your scene into one 
> or 
> more textures. Then draw a fullscreen quad to display the final image, but 
> use a 
> shader that uses your texture(s) as input to achieve the desired rendering 
> effect. Depending on the effect or effects you want, you might need to draw 
> multiple fullscreen quads with multiple different shaders, often using the 
> rendered output of the previous quad as an input texture to the next. With a 
> post-render pipeline such as this, you can create several visual effects, 
> including depth of field, motion (or other) blur, glow, heat distortion, 
> deferred lighting application, etc etc.
> -Paul

Thanks Paul--I was certainly aware of this in the general sense, but
sought some confirmation. :)

What you've described is essentially what osgPPU does (or can do), yes?

And as far as performance is concerned: how often is this rendering
paradigm used in high-fps applications? Often articles simply state
"post-process the default frame buffer" which leads me to believe there
are (possibly lesser) alternatives? Even so, how would subsequent
shaders have access to the former color if it wasn't stored in a texture
somewhere, so really, RTT seems to be the ONLY way (which is what
prompted this message).

Thanks for the info...

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


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

[osg-users] Motion Blur (or "What is Post Processing?")

[Jeremy Moles]

Hello all. I spent the weekend relaxing (the first in many), and had the
chance to play a few video games I've been getting behind on. It wasn't
long, however, before I saw something I wanted to implement myself,
which led me to this post. :)

In a large number of FPS/3PS shooters these days there is this concept
of a "sprint"; i.e., the character can--usually for a short period of
time--double or triple their movement speed. The unique aspect, however,
is that in many modern games (especially those using the Unreal engine),
they apply a very visually pleasing motion blur to the scene as well.

I began researching this, and found an article in a book called "Game
Engine Gems 1" which describes this effect by creating pre and post
processing shaders, the first of which creates an "acceleration buffer"
and the second of which applies the blur to the frame buffer using this
data. If I'm not mistaken (though I don't fully understand the algorithm
yet) it will even blur objects in the viewers peripheral more than those
directly in front. Killer stuff.

I can't help but wonder how to best do something like this in OSG. :)

I've never used osgPPU, but I know at its core it simplifies the process
of using post processing. In a general sense though, when an article
refers to some of "post processing" shader on the normal frame buffer,
how does one go about implementing this in OSG? Do I create a
screen-aligned quad and set the shader to run on it in a POST_RENDER
camera?

How would you guys approach a problem like this? (Note: this question is
purely academic; it's just the latest thing bouncing around in my brain
as I try and fall asleep... :))


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

Re: [osg-users] osgPango text always black (even the examples)

[Jeremy Moles]

On Sat, 2011-09-17 at 01:46 +0200, Trystan Larey-Williams wrote:
> Hi all,
> 
> I've used osgPango successfully in the past on a different system, but am 
> facing a strange problem now. All text renders black including in all the 
> out-of-box examples (osgpangoanimation, etc), regardless of what the color is 
> set to in the markup. Anyone else run into this? My system/version info is 
> below.
> 
> Fedora 15 / Gnome3 with proprietary nvidia drivers (280.13)
> osg version: 3.0.0
> osgPango and osgCairo 1.0.0 tag versions
> pango 1.28.4
> cairo 1.10.2
> 
> I've tried updating to the latest versions of osgPango/Cairo as well, no 
> difference.
> 
> Thank you!

You are encountering a driver bug. :(

You'll need the very latest OSG (with Robert's patch from last week to
change the variable naming from "foo[0]" to "foo" when appropriate).

> Cheers,
> Trystan
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42841#42841
> 
> 
> 
> 
> 
> ___
> 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] NVidia 275-series Driver Bug

[Jeremy Moles]

On Thu, 2011-09-15 at 12:00 +0100, Robert Osfield wrote:
> Hi All,
> 
> I'm note yet clear on exactly where the problems are stemming form
> with the NVidia 275+ drivers but with the assumption that the
> glGetActiveUniform is appending a [..] and the the matching
> glGetUniformLocation can handle the name without the [..] appended
> I've written some code to do the trimming off of the [..].  I've
> tested this with an artificially append [0] and it works fine, but
> haven't yet tested against the problem drivers.  My code looks like:
> 
> _extensions->glGetActiveUniform( _glProgramHandle,
> i, maxLen, 0, &size, &type, name );
> 
> int pos = strlen(name);
> if (pos>0 && name[pos-1]==']')
> {
> // need to trim [..] from end of name as some drivers
> append this causing problems with look up.
> --pos;
> while(pos>0 && name[pos]!='[') { --pos; }
> name[pos] = 0;
> }
> 
> GLint loc = _extensions->glGetUniformLocation(
> _glProgramHandle, name );
> 
> I have also attached the modified Program.cpp.  Could users that have
> seen the driver issue test out this proposed version of Program.cpp?
> If things work fine I'll check it into svn/trunk.

This continues to resolve the problem for me on 280+, so I must assume
it also works on 275 (the issue existed on both).

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


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

[osg-users] Google+

[Jeremy Moles]

Who needs an invite? :) I've got 150...

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

Re: [osg-users] Color grid overlay question/help

[Jeremy Moles]

On Tue, 2011-09-13 at 15:35 +0200, Kevin DeMott wrote:
> So I'm pretty close to getting this working using the osghud example code. 
> 
> The problem I'm having now is that color grid on the left side of the screen 
> is not visible at the start of the application. I traced this problem down to 
> the fact that during creation the window size is larger than what the initial 
> displayed window size is. So if I manually make the window larger then the 
> color grid is visible.
> 
> I fixed this problem by adding my own ResizedCallback to the GraphicsContext 
> the hud camera is using. The ResizedCallback then updates the 
> ProjectionMatrix to the dimensions of the new window size. This seems to work 
> fine for anything that is aligned with the left side of the screen. I'm now 
> working on adding another object to the hud in the upper right hand corner of 
> the screen.
> 
> To do this I create the my object and then apply a PositionAttitudeTransform 
> matrix to the root node of my new object. The positional vector is based on: 
> x = width of window minus width of new object, y = height of window minus 
> height of new object.
> 
> The result is that initially the object is not viewable until I manually 
> resize the window with the mouse to make the viewing area larger. I'm 
> thinking that I'm running into pretty much the same problem I had before I 
> added the ResizedCallback, which is that the window size at creation time is 
> larger than that at display time. So I'm basically placing the image beyond 
> the viewable area initially.
> 
> It seems I could solve this problem by updating the PositionAttitudeTransform 
> matrix in my ResizedCallback to take into account the new window width and 
> height. However, that seems like it is going to get really tedious as more 
> and more things are added to the hud and is not the correct approach I should 
> be using.
> 
> Can anyone recommend any alternative approaches to this problem? 

Is the source to this application available?

> Thanks
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42692#42692
> 
> 
> 
> 
> 
> ___
> 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] Skipping nodes in serialization

[Jeremy Moles]

On Sat, 2011-09-03 at 13:01 +0200, Joel Graff wrote:
> Hi,
> 
> I have a graph that I serialize with a simple call to osgDB::writeNodeFile(), 
> but it contains a node that is auto-generated when the application starts.  
> Is there a way to exclude that node from serialization?  I'm familiar with 
> the setNodeMask() / setTraversalMask() mechanism used in visitor classes, but 
> wasn't finding something similiar for serialization - nothing jumped out at 
> me in the ReaderWriter docs, anyway.

It is really mind-boggling-ly easy to write a serializer wrapper. Here,
I'll show you (this file is generally called LibraryWrapper.cpp):

--

#include 
#include 

extern "C" void wrapper_serializer_library_myLibrary(void) {
}

REGISTER_OBJECT_WRAPPER(
myLibrary_Object,
new myLibrary::Object(),
myLibrary::Object,
"osg::Object osg::MatrixTransform myLibrary::Object"
) {
}

-

As long as your object can be built after construction this will be a
suitable workaround. If you want to actually serialize members, well,
that's also incredibly easy (depending on what type of data they are).

You can find some examples here:

http://code.google.com/p/osgpango/source/browse/#svn%2Ftrunk%2Fsrc%
2Fserializers

...or all throughout the code in $OSG/src/osgWrappers/serializers/

> ... 
> 
> Thank you!
> 
> Cheers,
> Joel
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42403#42403
> 
> 
> 
> 
> 
> ___
> 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] iOS: wireframe

[Jeremy Moles]

On Fri, 2011-09-02 at 18:11 +0200, Alessandro Terenzi wrote:
> Ok and thanks for your help.

I think I might finish my own personal solid+wireframe GLSL example here
in a few minutes. Would this be of use to you? (It is derived from this
example:

http://www2.imm.dtu.dk/~jab/Wireframe/



> Cheers.
> Alessandro
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42387#42387
> 
> 
> 
> 
> 
> ___
> 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] Unable to load osgdb_tiff plugin on CentOS 5.6

[Jeremy Moles]

On Fri, 2011-09-02 at 13:17 -0400, Cary, Karl A. wrote:
> I developed something that uses tiffs as textures and developed it in
> CentoS 5.5 and everything works just fine. The installation of OSG on
> the system was actually built on a CentOS 5.6 machine and then rpm’d
> and installed on the 5.5 system. When I try to run the code on 5.6, I
> get that it cannot load the tiff plugin. We are able to use other
> plugins just fine though. Does anyone have any idea where to begin
> looking? I am extremely rushed as this has to be working today and I
> head out tonight for a week long vacation.

You're probably just missing the libtiff RPM on the new machine, or some
similar library.

Run your program like:

OSG_NOTIFY_LEVEL=DEBUG ./my_binary

...and see if you can track it down.

> ___
> 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] I made the libRocket GUI library usable with OSG

[Jeremy Moles]

On Sat, 2011-08-27 at 07:09 +0200, Martin Scheffler wrote:
> Hi Jeremy,
> 
> I hope I haven't discouraged you from continuing development on osgWidget! A 
> "native" osg gui would have a lot of advantages over an external library. The 
> main reason I did not consider osg widget was the lack of documentation, so 
> maybe you can invest some time in that...

It won't at all. I just need to find the time, or at least the funding
so I can MAKE time. :)

The next version will be much better, as I've learned exponentially
since then...

> About the missing CMake variables: Are you using the "advanced" mode in 
> cmake-gui? The libRocket variables are marked as advanced, I have not yet hd 
> time to find out how to mark them as non-advanced.

Whoops. Got it...

> Cheers,
> Martin
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42272#42272
> 
> 
> 
> 
> 
> ___
> 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] I made the libRocket GUI library usable with OSG

[Jeremy Moles]

On Fri, 2011-08-26 at 06:38 +0200, Martin Scheffler wrote:
> Hi all,
> 
> On a long train ride yesterday I had the chance to work on my osg 
> implementation of a libRocket interface. You can download the code from the 
> attachment.
> 
> 
> 
> libRocket is a nice little GUI library that seems to be well thought through 
> and cleanly coded. There is an html-like format for writing GUIs. I have not 
> yet fully explored the library, but now that I can use it in OSG I surely 
> will.
> 
> What it can do at this point:
> * Create fullscreen GUIs
> * Create in-scene GUIs
> * Mouse and keyboard events are transformed to GUI coordinates and forwarded 
> to libRocket system
> 
> That's all, and I think that is all that is needed.
> I don't think I will wrap any other libRocket functionality as it is all 
> accessible.
> 
> The included example shows two GUIs. One is full screen, the other is 
> in-scene and can be rotated with the default osgViewer mouse manipulator.
> 
> If anyone is interested in this I can put it on source control somewhere. 
> Please give me feedback on what is missing or what can be improved!

Having made osgWidget all those years ago it really makes me sad when I
see stuff like this, but the bottom line is osgWidget simply isn't good
enough. I've wanted to, for a long, long, time, go back and make it
better. :)

HOWEVER, having said that, this is actually a great little library. Not
bad at all, the design seems very solid! I think if you figure out the
issues with cleaning up, it could become quite popular in the OSG
community.

BTW: I can't actually get it to compile yet (though I can run the Rocket
examples just fine); CMake won't find/define LIBROCKET_* variables...

> Cheers,
> Martin
> [/img]
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42250#42250
> 
> 
> 
> ___
> 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] ANN: osgNVPR (NVidia Path Rendering)

[Jeremy Moles]

On Wed, 2011-08-24 at 06:43 +0200, Mark Kilgard wrote:
> Jeremy,
> 
> Very cool to see this OpenSceneGraph support for NV_path_rendering.

And even cooler to get an @nvidia.com response. :)

> I hope you'll explore the ability to mix 3D and path rendering within a 
> depth-buffered perspective scene as discussed in the "Mixing Path Rendering 
> and 3D" whitepaper.
> 
> Any CUDA-capable NVIDIA GPU under Windows or Linux can use NV_path_rendering 
> with Release 275 drivers or later.
> 
> A few suggestions for your osgNVPR::Path object:
> 
> *  Consider having the "_colors" be a path "paint" object.  Solid color (what 
> you have now) is one paint style, but linear gradient color, radial gradient 
> color, and image paint are others common to path rendering standards.  (See 
> the nvpr_svg SDK example to see how simple the shaders are for linear and 
> radial gradients.)
> 
> *  Eventually you could have "paint" shaders where you can use arbitrary 
> assembly, Cg, or GLSL shaders to paint your paths during the cover operation. 
>  Environment mapped or bump mapped paths are possibilities.
> 
> *  Have separate fill and stroke paint.  Sometimes you want the stroking to 
> happen "before" the filling (such as for matting text rendering) but usually 
> the stroking is an outline around the path drawn over the filled version of 
> the path.  Have an option for either.  "null" paint would skip the filling or 
> stroking.
> 
> *  Have methods to set stroking styles (end caps, join style, dash pattern, 
> dash caps, and stroke width).
> 
> *  Be able to initialize a path from an actual string of text and a font name 
> (and font style).  This way someone can create a osgNVPR::Path for "Hello 
> world" in Arial or whatever.
> 
> *  Have a mode to say whether mixing with depth testing should be done.
> 
> *  Provide an option to "cache" the drawing commands for a path object in a 
> display list.  All the NV_path_rendering commands are display-listable.  
> Because the NVIDIA OpenGL driver is dual-core enabled, this allows you to 
> draw a path with a single glCallList command relayed over to the driver 
> thread on another core.  This gives your app thread more CPU cycles.
> 
> *  You should be able to support "picking" support with the 
> glIsPointInFillPathNV and glIsPointInStrokePathNV queries.  Since you have 
> the bounding box queried already, it makes sense to test against the bounding 
> box first before doing the (more expensive) glIsPointInFillPathNV query.
> 
> I look forward to seeing how this develops.

Really good suggestions, all stuff I'd like to do...

Unfortunately, I did most of what is currently in osgNVPR over a weekend
in a attempt to see if there was any interest in funding for such a
NodeKit in OSG. As of yet, there has been none, so development will be
on hold (for now).

> - Mark
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42207#42207
> 
> 
> 
> 
> 
> ___
> 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] Custom Vertex Attributes & Binding

[Jeremy Moles]

On Tue, 2011-08-23 at 22:27 +0200, Tony Horrobin wrote:
> Hi Jeremy,
> 
> The glsl attachments have been squashed - could you attach them as .txt, 
> please?
> 
> I believe you have to bind shader vertex attributes as PER_VERTEX as opposed 
> to colours and normals which can be PER_PRIMITIVE.
> Then copy the line that calls push_back() on gridCoordinates so you have 4 
> calls and it should work.
> 
> I had to add:
> setVertexArray(gridPositions);
> 
> to get anything at all on the screen ( otherwise there are no primitives ).

OH WAIT, if you weren't using the shaders, then on wonder. :) So,
scratch my first response.

As far as your binding speculation is concerned: you are probably right.
I was just hoping I could avoid some repetitive memory use for the
heightfields this way.

> Cheers,
> 
> -Tony
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42202#42202
> 
> 
> 
> 
> 
> ___
> 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] Custom Vertex Attributes & Binding

[Jeremy Moles]

On Tue, 2011-08-23 at 22:27 +0200, Tony Horrobin wrote:
> Hi Jeremy,
> 
> The glsl attachments have been squashed - could you attach them as .txt, 
> please?
> 
> I believe you have to bind shader vertex attributes as PER_VERTEX as opposed 
> to colours and normals which can be PER_PRIMITIVE.
> Then copy the line that calls push_back() on gridCoordinates so you have 4 
> calls and it should work.
> 
> I had to add:
> setVertexArray(gridPositions);

You shouldn't have to call this at all. Something is still wrong if you
need to. :( Drats...

> to get anything at all on the screen ( otherwise there are no primitives ).
>
> Cheers,
> 
> -Tony
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42202#42202
> 
> 
> 
> 
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 


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

[osg-users] Custom Vertex Attributes & Binding

[Jeremy Moles]

Hello everyone.

I am using custom vertex attributes but running into a strange issue. I
do not seem to be able to use:

BIND_PER_PRIMITIVE

..when using custom vertex attributes. Is this a known limitation, or is
it likely a bug/me doing something wrong? I have attached a simple
example of this failure; if you uncomment "GridCoordinates", nothing is
rendered at all (nor do I receive any information via OSG_NOTIFY).

If you keep this commented out, the grid renders.

Curious...
#include 
#include 
#include 
#include 
#include 

class Grid: public osg::Geometry {
public:
	enum {
		GRID_POSITION   = 6,
		GRID_COORDINATE = 7
	};

	Grid(const osg::Vec2s& size, const osg::Vec2& gridSize = osg::Vec2(1.0f, 1.0f)):
	_size (size),
	_gridSize (gridSize) {
		setUseDisplayList(false);
	}

	bool allocate() {
		osg::Program* program = new osg::Program();
		osg::Shader*  vert= osg::Shader::readShaderFile(osg::Shader::VERTEX, "vert.glsl");
		osg::Shader*  frag= osg::Shader::readShaderFile(osg::Shader::FRAGMENT, "frag.glsl");
		// osg::Uniform* texture = new osg::Uniform(osg::Uniform::SAMPLER_2D, "Texture");
		
		program->addShader(vert);
		program->addShader(frag);
		program->addBindAttribLocation("GridPosition", GRID_POSITION);
		program->addBindAttribLocation("GridCoordinate", GRID_COORDINATE);

		osg::Vec4Array* gridPositions   = new osg::Vec4Array();
		osg::Vec2Array* gridCoordinates = new osg::Vec2Array();

		for(short x = 0; x < _size.x(); x++) {
			for(short y = 0; y < _size.y(); y++) {
osg::Vec4 bl(x, y, 0.0f, 0.0f);
osg::Vec4 br(x + _gridSize.x(), y, 0.0f, 1.0f);
osg::Vec4 ur(x + _gridSize.x(), y + _gridSize.y(), 0.0f, 2.0f);
osg::Vec4 ul(x, y + _gridSize.y(), 0.0f, 3.0f);

gridPositions->push_back(bl);
gridPositions->push_back(br);
gridPositions->push_back(ur);
gridPositions->push_back(ul);

gridCoordinates->push_back(osg::Vec2(x, y));
			}
		}

		// GridPosition
		setVertexAttribArray(GRID_POSITION, gridPositions);
		setVertexAttribBinding(GRID_POSITION, osg::Geometry::BIND_PER_VERTEX);

		/*
		// GridCoordinates
		setVertexAttribArray(GRID_COORDINATE, gridCoordinates);
		setVertexAttribBinding(GRID_COORDINATE, osg::Geometry::BIND_PER_PRIMITIVE);
		u*/

		// Finish seting up the Geometry...
		addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::QUADS, 0, _size.x() * _size.y() * 4));

		// texture->set(0);

		osg::StateSet* state = getOrCreateStateSet();

		state->setAttributeAndModes(program);
		// state->addUniform(texture);

		return true;
	}

	virtual osg::BoundingBox computeBound() const {
		return osg::BoundingBox(
			osg::Vec3(0.0f, 0.0f, 0.0f),
			osg::Vec3(_size.x() * _gridSize.x(), _size.y() * _gridSize.y(), 0.0f)
		);
	}

private:
	osg::Vec2s _size;
	osg::Vec2  _gridSize;
};

int main(int argc, char** argv) {
	osgViewer::Viewer viewer;

	Grid* grid = new Grid(osg::Vec2s(10, 10));

	grid->allocate();

	osg::Geode* geode = new osg::Geode();

	geode->addDrawable(grid);

	viewer.setSceneData(geode);
	viewer.addEventHandler(new osgViewer::StatsHandler());

	return viewer.run();
}

varying float color;

void main() {
gl_FragColor = vec4(color, color, color, 1.0);
}

in vec4 GridPosition;
in vec2 GridCoordinate;

varying float color;

void main() {
color = GridPosition.w / 3.0;

gl_Position = gl_ModelViewProjectionMatrix * vec4(GridPosition.xyz, 
1.0);
}

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

Re: [osg-users] osgWidget Callbacks

[Jeremy Moles]

On Fri, 2011-08-19 at 16:36 +0200, Daniel Cámpora wrote:
> Hello :),
> 
> I'm working my way on osgWidgets, and I have come into using callbacks for 
> them.
> 
> The way for adding callbacks on them is by means of the method 
> "osgWidget::EventInterface::addCallback", but I didn't find any way to remove 
> a callback after it's been added.
> 
> After reading some code definitions, I found out callbacks are stored in a 
> std::list, and they are defined in the private scope, so therefore I have 
> virtually no way of sorting this out.
> 
> Is there any workaround for this?

This is simply an oversight. Submit a patch for this and I'm certain it
will be accepted.

> Thank you!
> 
> Cheers,
> Daniel
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42135#42135
> 
> 
> 
> 
> 
> ___
> 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] osgWidget::Label::setLabel() does not update the size

[Jeremy Moles]

On Fri, 2011-08-19 at 15:31 +0200, Daniel Cámpora wrote:
> Hi,
> 
> I had the same problem and ended up overriding the _calculateSize method as 
> you are doing.
> 
> However, I don't think this is an error of the bounding box. What happens 
> internally is that the text has a width and height according to the first 
> text that we fit in, and it's only updated IF the text occupies more space, 
> shall it be width or heigth.
> 
> On the other hand, I think it's not a good approach to remove completely the 
> if statement, because that would imply the size of the box is always going to 
> be that one of the text's. Eg. suppose you want a bigger container with a 
> background color specified by user's width and height.
> 
> I went for two booleans, "_userWidth" and "_userHeight" which are set 
> whenever the user wants to define a custom width or height (in the setters 
> and adders). With this, the _calculateSize looks like this:
> 
> 
> Code:
> void EnhancedWidgetText::_calculateSize(const osgWidget::XYCoord& size){
>   if(!_userWidth || getWidth() < size.x())
>   inherited::setWidth(size.x());
> 
>   if(!_userHeight || getHeight() < size.y())
>   inherited::setHeight(size.y());
> }
> 
> 
> 
> If someone is interested I can provide the implementation.
> 
> Btw, among other things, you'll find out the padding is not supported in 
> canvas widgets. An addition could be added in this direction, maybe.

Honoring Widget sizing hints is the job of each Window (and could mean
different things). Canvas is truly free-form, so it doesn't even look at
any of that. :)

> Cheers,
> 
> Daniel
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42132#42132
> 
> 
> 
> 
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 


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

Re: [osg-users] osg::Image Serialization

[Jeremy Moles]

On Wed, 2011-08-17 at 08:48 +0800, Wang Rui wrote:
> Hi Jeremy and Robert,
> 
> In fact the osg::Image class can be derived and it is possible to
> write serializers for the subclasses. In
> osgWrappers/serializers/osg/ImageStream.cpp you will find an example
> which has no difference from other serializers. I'm not sure if this
> could work for osgCairo images, but I think a subclass that doesn't
> change osg::Image's basic functionalities can work fine with
> serializers at present.

I'm not entirely sure this is accurate; if you look at osgimagesequence
example, it lets you write the file out to disk:

osgimagesequence -o foo.osgt

...but that file isn't readable by OSG. In fact, I had no trouble ever
writing my custom Image to disk, only reading it back in.

However, the serializer backend is very complex (or rather, quite
abstracted away in macros), and so I've found it difficult to track down
where exactly to investigate...

> After reviewing the source code, I think it also possible to replace
> the readImage() and writeImage() in Input/OutputStream classes with an
> Image serializer, too. I can't remember why I use special
> reader/writer functions to handle images. Maybe it is only a
> plagiarism of old osgDB::Input/Output class' methods. :-P

Perhaps this is where I should look then. :)

> Cheers,
> 
> Wang Rui
> 
> 
> 2011/8/17 Jeremy Moles :
> > Hello everyone; this is probably a question only a few people could
> > possibly, answer (Robert, Wang), but here goes:
> >
> > I have created a derived osg::Image class (osgCairo::Image), and this
> > has worked just fine for the last few years. However, I want to add
> > strong serialization support for my nodekits, and I'm finding
> > customizing an Images behavior in the serialization code is quite
> > difficult.
> >
> > Images are treated as special kinds of Objects, so any custom behavior
> > you might add confuses the base serializers, and there doesn't appear to
> > be any way to avoid this.
> >
> > My question is: should the serialization backend be modified to support
> > osg::Image subclasses, or should programmers be encouraged NOT to derive
> > from osg::Image directly and instead create "contains-a" objects
> > instead?
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 


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

Re: [osg-users] osg::Image Serialization

[Jeremy Moles]

On Tue, 2011-08-16 at 12:42 -0400, Jeremy Moles wrote:
> Hello everyone; this is probably a question only a few people could
> possibly, answer (Robert, Wang), but here goes:
> 
> I have created a derived osg::Image class (osgCairo::Image), and this
> has worked just fine for the last few years. However, I want to add
> strong serialization support for my nodekits, and I'm finding
> customizing an Images behavior in the serialization code is quite
> difficult.
> 
> Images are treated as special kinds of Objects, so any custom behavior
> you might add confuses the base serializers, and there doesn't appear to
> be any way to avoid this.
> 
> My question is: should the serialization backend be modified to support
> osg::Image subclasses, or should programmers be encouraged NOT to derive
> from osg::Image directly and instead create "contains-a" objects
> instead?

As an addendum, this may simply be a misuse on my part.

Perhaps if someone is deriving from osg::Image, that person should also
consider creating a custom image "type" and, thus, writing an osgPlugin
for their image type to do the various kinds of extra stuff they need to
do.

For example, in osgCairo, though I may actually be using PNG data, I
could create a ".cairo" file type which will force my custom loader
instead of the default loader (which will allow me to do things like
pre-multiply the alpha, which Cairo expects internally).

Just thinking out loud here. :)

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


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

[osg-users] osg::Image Serialization

[Jeremy Moles]

Hello everyone; this is probably a question only a few people could
possibly, answer (Robert, Wang), but here goes:

I have created a derived osg::Image class (osgCairo::Image), and this
has worked just fine for the last few years. However, I want to add
strong serialization support for my nodekits, and I'm finding
customizing an Images behavior in the serialization code is quite
difficult.

Images are treated as special kinds of Objects, so any custom behavior
you might add confuses the base serializers, and there doesn't appear to
be any way to avoid this.

My question is: should the serialization backend be modified to support
osg::Image subclasses, or should programmers be encouraged NOT to derive
from osg::Image directly and instead create "contains-a" objects
instead?

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

Re: [osg-users] osgWidget::Label::setLabel() does not update the size

[Jeremy Moles]

On Fri, 2011-08-12 at 11:09 +0200, Yue Zijian wrote:
> [code]
> #include 
> #include 
> #include 
> 
> const unsigned int MASK_2D = 0xF000;
> 
> 
> int main(int argc, char** argv) {
> osgViewer::Viewer viewer;
> 
> osgWidget::WindowManager* wm = new osgWidget::WindowManager(
> &viewer,
> 1280.0f,
> 1024.0f,
> MASK_2D,
> osgWidget::WindowManager::WM_PICK_DEBUG
> );
> 
> osgWidget::Canvas* canvas = new osgWidget::Canvas("canvas");
> 
> osgWidget::Label* label = new osgWidget::Label( "label_test", "test" );
> 
> label->setFontColor( 1.0f, 0.0f, 0.0f, 1.0f );
> 
> canvas->addWidget( label, 0.0f, 0.0f );
> 
> canvas->resize();
> 
> wm->addChild(canvas);
> 
> return osgWidget::createExample(viewer, wm);
> }
> [/code]
> 
> the canvas bg grows taller after the window size changed.

This is probably the bug where the bounding box of the Text isn't
proper; what version of OSG are you using?

> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=42017#42017
> 
> 
> 
> 
> 
> ___
> 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] Serialization Question (Proto Constructors)

[Jeremy Moles]

On Thu, 2011-08-11 at 08:16 +0800, Wang Rui wrote:
> Hi Jeremy,
> 
> Yes. The serializers at present don't support constructor with
> arguments. It is welcome if you and anyone else could provide the
> functionality. :-)

I'll see if I can do it...

BTW: Working with the new serializer interfaces has been a breeze; it's
really great stuff! I might make a small example showing how to do it
for others to get up to speed. The 'osguserdata' examples gives some
hints, but really people will want to know how to use
{Input,Output}Stream.{write,read}Object(), what the serializer macros
do, etc.

It's been quite easy though, and I'm definitely not using it a "simple"
way. :)

> Wang Rui
> 
> 
> 2011/8/11 Jeremy Moles :
> > This question is for anyone who has used the new serialization interface
> > introduced by Wang Rui in 2010 (osgWrappers/serializers).
> >
> > Is it possible to pass arguments to the object's constructor? The 2nd
> > argument to the REGISTER_ macro lets you define the protocol for object
> > creation, but the arguments cannot (as far as I can tell) be
> > dynamic--and certainly not values from the serialization stream--right?
> >
> > Please correct me if I'm wrong... :)
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 


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

[osg-users] Serialization Question (Proto Constructors)

[Jeremy Moles]

This question is for anyone who has used the new serialization interface
introduced by Wang Rui in 2010 (osgWrappers/serializers).

Is it possible to pass arguments to the object's constructor? The 2nd
argument to the REGISTER_ macro lets you define the protocol for object
creation, but the arguments cannot (as far as I can tell) be
dynamic--and certainly not values from the serialization stream--right?

Please correct me if I'm wrong... :)

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