Re: [osg-users] OSG gathering during my visit to Virginia in December
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
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
[osg-users] Pruning content
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] Pruning content
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 <jswig...@gmail.com> 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
Re: [osg-users] osgDB::FileCache for network sources
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 <robert.osfi...@gmail.com> 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 <jswig...@gmail.com> 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
Re: [osg-users] osgDB::FileCache for network sources
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 <robert.osfi...@gmail.com> wrote: > On 11 December 2015 at 11:33, Jeremy <jswig...@gmail.com> 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
[osg-users] osgDB::FileCache for network sources
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] (no subject)
I am having this problem with OSG 3.3.3 and Qt5 and MSVC2013 Commenting out the #define GL_ARB_vertex_buffer_object in osg/BufferObject does indeed allow it to compile. On Sun, Feb 1, 2015 at 10:56 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Phileppe, I presume Qt5.4 is define the various GL values in it's headers as well as the OSG. You could try changing the include order of the Qt and OSG headers to see if that can resolve the issue. I don't have Qt5.4 on my system to test against so I'll have to defer to you to see if you can find a solution. If you do just let me know the changes required and we can then discuss how to tweak the OSG or it's Qt usage to avoid the issues. Robert. On 31 January 2015 at 22:03, philippe renon philippe_re...@yahoo.fr wrote: I am also seeing this warnings multiple times: [ 92%] Building CXX object src/applications/osgearth_package_qt/CMakeFiles/application_osgearth_package_qt.dir/package_qt.cpp.obj In file included from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgQt/GraphicsWindowQt:17, from d:/Projects/OpenPilot/3rdparty/osgearth/src/osgEarthQt/ViewerWidget:26, from d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:26: d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:2431:0: warning: GL_SHADER_STORAGE_BARRIER_BIT redefined #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000 ^ In file included from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLExtensions:18:0, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/BufferObject:19, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Array:46, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/Shape:21, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/KdTree:17, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/Registry:21, from D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osgDB/FileUtils:17, from d:\Projects\OpenPilot\3rdparty\osgearth\src\applications\osgearth_package_qt\package_qt.cpp:21: D:/Projects/OpenPilot/build/3rdparty/install/osg-3.3.3-mingw491_32-qt-5.4.0/include/osg/GLDefines:496:0: note: this is the location of the previous definition #define GL_SHADER_STORAGE_BARRIER_BIT 0x2000 ^ PS : sorry for the missing email object. Le Samedi 31 janvier 2015 21h44, philippe renon philippe_re...@yahoo.fr a écrit : Hi, Compilation of osg 3.2.1 against Qt 5.4.0 (mingw) was working perfectly fine. After switching to 3.3.3 we are seeing this compilation error : In file included from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopengl.h:123:0, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/qgl.h:39, from d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtOpenGL/QGLWidget:1, from d:/Projects/OpenPilot/3rdparty/osg/include/osgQt/GraphicsWindowQt:17, from d:\Projects\OpenPilot\3rdparty\osg\examples\osgviewerQt\osgviewerQt.cpp:12: d:/Projects/OpenPilotTools/qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h:10653:130: error: 'GLintptrARB' has not been declared typedef void (APIENTRYP PFNGLBINDVIDEOCAPTURESTREAMBUFFERNVPROC) (GLuint video_capture_slot, GLuint stream, GLenum frame_region, GLintptrARB offset); The issue comes from a conflict between osg/include/osg/BufferObject and qt-5.4.0/5.4/mingw491_32/include/QtGui/qopenglext.h within the section starting with: #ifndef GL_ARB_vertex_buffer_object #define GL_ARB_vertex_buffer_object I beleive that this issue was introduced by openscenegraph/osg https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c [image: image] https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c openscenegraph/osg https://github.com/openscenegraph/osg/commit/2c9d3671404583e797e9fdd5cc7687985c1bdf3b#diff-9e6bea70325f4962c2d5c856e6e5001c osg - OpenSceneGraph git mirror Afficher sur github.com
Re: [osg-users] Node/Object Serialization
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 jswig...@gmail.com 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 robert.osfi...@gmail.com 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 jswig...@gmail.com 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] Node/Object Serialization
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 robert.osfi...@gmail.com 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 jswig...@gmail.com 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
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
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 robert.osfi...@gmail.com
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 jswig...@gmail.com 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
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 ?
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
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 cubic...@gmail.com 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
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
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
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
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::listosg::observer_ptrCallback 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 osg::ref_ptr Callback 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?
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] changing a osgWidget::Box position
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] osgWidget Frame borders
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] Fedora 18 with nVidia driver: OSG crashes session
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
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?
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!
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
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 BN
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
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] Status of Collada Reader (November, 2012)
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
Re: [osg-users] Status of Collada Reader (November, 2012)
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] OSG + RaspberryPi
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
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 cubic...@gmail.com: 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
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 cubic...@gmail.com: 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
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] Check if a Drawable was culled or not
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] Ideas about a resource system, and deferred rendering framework
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 wangra...@gmail.com: 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
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 wangra...@gmail.com: 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
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 cubic...@gmail.com: 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
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
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
[osg-users] Custom Drawable GLSL
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] Custom Drawable GLSL
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
Re: [osg-users] Custom Drawable GLSL
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] [ANN] osgAndroid: Library for develop OSG applications in Android
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
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] [3rdparty] osgWidget and rotation
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_ptrosg::Group _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 osg/io_utils
#include osgDB/ReadFile
#include osgWidget/Util
#include osgWidget/WindowManager
#include osgWidget/Box
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_castosgWidget::Widget*(drawable);
osgWidget::PointArray* points = dynamic_castosgWidget::PointArray*(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
[osg-users] Chicken Egg Problem: BoundingBoxes
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] Chicken Egg Problem: BoundingBoxes
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 cubic...@gmail.com 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
Re: [osg-users] Chicken Egg Problem: BoundingBoxes
On Mon, 2012-08-27 at 17:30 +0100, Robert Osfield wrote: Hi Jeremy, On 27 August 2012 17:21, Jeremy Moles cubic...@gmail.com 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] Camera manipulator velocity and home() calculation affected after scaling nodes
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] Camera manipulator velocity and home() calculation affected after scaling nodes
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] Chicken Egg Problem: BoundingBoxes
On Mon, 2012-08-27 at 21:04 +0100, Robert Osfield wrote: Hi Jeremy, On 27 August 2012 17:34, Jeremy Moles cubic...@gmail.com 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] Node Callback never called
Is your method declared as const? I always forget that... On Aug 23, 2012 8:28 AM, Vincent Bourdier vincent.bourd...@gmail.com 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 vincent.bourd...@gmail.com: 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.orgosg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __**_ osg-users mailing list osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget Missing Resources
On Thu, 2012-08-23 at 14:02 +0100, Robert Osfield wrote: Hi Kim, On 24 July 2012 11:59, Kim Bale kcb...@googlemail.com 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] Extensions/State Update Question
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...
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] Extensions/State Update Question
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] Extensions/State Update Question
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
Re: [osg-users] Background transparency on iOS
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
[osg-users] Background transparency on iOS
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] Background transparency on iOS
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
Re: [osg-users] [3rdparty] Using OSGWidgets with OSGArt
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] Rendering From First Person
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] Simulation Loop in osgWidget
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] osgWidget complex widgets
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
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
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
Re: [osg-users] Rendering From First Person
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
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 jer...@emperorlinux.com: 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
Re: [osg-users] [ANN] New OSG book on the way, and new plan of OSG recipes
On Thu, 2011-09-29 at 23:02 +0800, Wang Rui wrote: Hi Jeremy, 2011/9/29 Jeremy Moles jer...@emperorlinux.com: 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
[osg-users] Rendering From First Person
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?
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?
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] osgexport for blender?
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] osgPango text always black (even the examples)
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
[osg-users] Motion Blur (or What is Post Processing?)
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] Motion Blur (or What is Post Processing?)
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
Re: [osg-users] NVidia 275-series Driver Bug
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 (pos0 name[pos-1]==']')
{
// need to trim [..] from end of name as some drivers
append this causing problems with look up.
--pos;
while(pos0 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
Re: [osg-users] Color grid overlay question/help
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
[osg-users] Google+
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] Skipping nodes in serialization
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 osgDB/Registry
#include osgDB/ObjectWrapper
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] Unable to load osgdb_tiff plugin on CentOS 5.6
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] iOS: wireframe
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] I made the libRocket GUI library usable with OSG
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
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)
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
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
Re: [osg-users] Custom Vertex Attributes Binding
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
[osg-users] Custom Vertex Attributes Binding
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 osg/Geometry
#include osg/Geode
#include osg/PrimitiveSet
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
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::Label::setLabel() does not update the size
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] osgWidget Callbacks
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] osg::Image Serialization
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 jer...@emperorlinux.com: 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
[osg-users] osg::Image Serialization
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] osg::Image Serialization
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
Re: [osg-users] osgWidget::Label::setLabel() does not update the size
On Fri, 2011-08-12 at 11:09 +0200, Yue Zijian wrote:
[code]
#include osgWidget/Util
#include osgWidget/WindowManager
#include osgWidget/Canvas
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] blender2.5 exporter
On Wed, 2011-08-10 at 14:21 +0200, Cedric Pinson wrote: Hi, just to talk about the blender 2.5 exporter. The plugin is on github https://github.com/cedricpinson/osgexport I fixed a few things and optimized model. I setup unittest too. Sadly the exporter does not support animation yet. It should come in a near futur. Woot! 2.5 is (IMO) the best version of Blender to date, so this is awesome. What are the complications with 2.5 and animation? Has the internal animation mechanism been totally redesigned, or is it just getting at the old data in a new Python interface? if you want to report bug/improve it everything is on github. Cheers, Cedric ___ 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] Timers for OSG Application
On Wed, 2011-08-10 at 12:35 +0200, Ankur Gandhi wrote: Dear All, I am making a scene graph in OSG and things are going great. Extensive support is available in forums and tutorials of OSG. Thanks a lot for that. I have one doubt. It may not be related to OSG but may be related general application development based on OSG. To update my scenegraph periodically, I want to use timer. I want a particular function to be called every few seconds or so. In GTK, I used to use g_timeout_add() function. However I believe OSG doesn't use g_main_loop() inside its render API. is it correct? No, it doesn't. Can some one tell me equivalent API for g_timeout_add() for OSG based application? or is there any other way to implement timer callback in OSG? There must be at least 200 different ways to do this. :) If it's just one Node you want updated, then create a NodeCallback object and fetch the elapsed time from: NodeVisitor-getFrameStamp()-getSimulationTime() If you want to visit your entire scenegraph instead, have this Node create a NodeVisitor and let it visit the subgraph. You could also replace your call to viewer.run() with manual calls to realize/frame/etc., but I still recommend the first method. :) Thanks in advance! Cheers, Ankur -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41972#41972 ___ 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)
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
Re: [osg-users] Serialization Question (Proto Constructors)
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 jer...@emperorlinux.com:
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
Re: [osg-users] Camera returns NULL viewport on Windows but not Linux
On Tue, 2011-08-09 at 22:05 +0200, Paul Leopard wrote: I have some code I have inherited that was developed on Linux. I am trying to get a Windows version of it to run but there is an inconsistency that I am unable to explain. Perhaps someone here has seen this issue before ... Anyway, the problem is that on Windows (OSG v2.9.9 and v3.0.0) I get a NULL viewport pointer with the following (pseudocode) call to getViewport() : Code: osg::ArgumentParser arguments(argc,argv); osgViewer::Viewer viewer(arguments); viewer.addEventHandler(...); osg::Group* root = new osg::Group; root-addChild( ... ); viewer.frame(); Try viewer.realize() here instead; not sure it'll change anything, but it's worth a shot. osg::Camera* camera = viewer.getCamera(); assert(camera!=NULL); // Ok osg::Viewport* pViewPort = camera-getViewport(); assert(pViewPort !=NULL); // FAILS! NULL POINTER On Linux the pointer is valid, on Windows it is always NULL. Am I missing something here or has anyone else had this issue? Thanks! Paul -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41955#41955 ___ 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)
On Fri, 2011-08-05 at 10:11 -0500, Michael Weiblen wrote: heh, first osgVRPN, now osgNVPR :-) That said, this is quite an interesting extension. -- mew Hmm, perhaps osgNVPath would be better. :) On Thu, Aug 4, 2011 at 2:23 PM, Jeremy Moles jer...@emperorlinux.com wrote: NVidia recently added an extension to their 275+ series of drivers called GL_NV_path_rendering. This turns path (sometimes called vector graphics) rendering into first class drawables in OpenGL. Honestly, it's one of the coolest things I've seen in a while, and naturally--given my interest in OpenGL UIs--I began researching it and putting together a NodeKit for OSG. You can find it (in its infancy) here: http://osgnvpr.googlecode.com Run the example thusly: # osgnvprviewer # osgnvprviewer --perspective ..and notice how that no matter what the resolution, scale, or projection, the objects are rendered clear and crisp. There is also support for glyphs inside of GL_NV_path_rendering, so I will very soon be adding support for this style of text rendering into osgPango (and possible, osgText::TextNode). I've only just begun exploring this, and I'm mainly sending this e-mail to see if there is any professional interest in seeing this NodeKit mature in a timely fashion. I don't know if this is outside the allowable etiquette of the lists, but in full disclosure I'm looking to fill some free time by seeking funding for development of by those who would not only use these features but could benefit from being able to influence their development and pace! If this is inappropriate for the lists, just let me know and I'll be sure and keep my peddling to a minimum from here on out. :) At any rate, I'll continue to work on osgNVPR regardless, alongside devleopment of osgCairo/Pango/Widget and the recent TextNode submission. (Can you see a pattern here? All OSG interface development tools...) Some notes: - NV_path_rendering introduces a new kind of rendering style for its path objects. This doesn't map 1:1 to any existing usage of osg::Drawable, though I am able to hijack the compileGLObjects() method to get what I need. :) - BoundingBoxes are calculated with an extension call, but in order to use the extension I need a contextID (provided via either a State object or RenderInfo object). Unfortunately, these are difficult to get to at times, so CameraManipulators cannot properly determine a home position unless the Path has been compiled. ___ 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
