Re: [osg-users] deferred shading in osg
Wang, thanks for the pointers! Nick On Mon, Aug 5, 2013 at 3:41 AM, Wang Rui wangra...@gmail.com wrote: Hi Nick, You may want to have a look at the osgeffectcompositor example in the osgRecipes project, which is an initial deferred shading framework for OSG. Also there is the osgPPU project that can do the same work for you, I think. Wang Rui 2013/8/5 Trajce Nikolov NICK trajce.nikolov.n...@gmail.com Hi Community, has anyone has done some work on this and willing to share hints, snippets ? Thanks a lot! Nick -- 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 -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] shader composing related link
Hi All, just to share, searching for shader composing stumbled across https://github.com/tlorach/nvFX https://developer.nvidia.com/sites/default/files/akamai/gamedev/docs/nvFX%20A%20New%20Shader-Effect%20Framework.pdf it is open sourced so maybe it might be of some interest to look at. Best regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shader composing related link
On 5.8.2013 15:23, Sergey Kurdakov wrote: en sourced so maybe it might be of some interest to look at. Best regards Sergey Very Interesting indeed. One more thing is needed though, the osg implementation of the nvFX interfaces (currently implemented for GL, D3D, CUDA and OPTIX) . On the other hand, Wang Rui's effect compositor looks cleaner, more osg-ish and maybe easier to extend... In any case, a decent effect framework is needed now more then ever. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OpenFlight - Palette Records prevent using of ReaderWriter Callback
Hi Robert,
Sorry for reviving this old thread.
But I stumbled across the exact same problem, and solving this issue
with the FindFileCallback is a real PITA.
I tried the patch Katharina provided (there is still a typo in here, but
nevertheless, it solves the issue.)
The problem with the FindFileCallback is that it simply gives you no
context. In my compiler I need to distinguish files that are referenced
inside the openflight from those which are searched from other sources
(e.g. looking up additional textures based on a name scheme).
With the the ReadFileCallback it is much easier to maintain such context.
So I second Katharinas idea.
Implementation-wise I'd provide an option to support calling the
readfile even if no valid path was found through the FindFileCallback
and leave the default option to the old behavior.
Would that be exectable?
cheers
Sebastian
HI Katharina,
In the svn/trunk version of the OSG I added support for overriding the
find file operation using an osgDB::FindFileCallback, that you attach
to the osgDB::Registry or an osgDB::Options object. Perhaps this
would be the best way for you to intercept and do something special
when texture files are not found.
Cheers,
Robert.
On Mon, Sep 21, 2009 at 1:49 PM, Katharina Plugge
katharina.plu...@web.de wrote:
Hello,
the OpenFlight-Plugin prevents reacting on missing Textures via a
ReadFileCallback, because osgDB::readRefImageFile (called by function
readTexture) is not called if the file does not exist. Would be great if this
could be changed.
A fix could look like this (file PaletteRecords.cpp, line 436):
Code:
virtual void readRecord(RecordInputStream in, Document document)
{
if (document.getTexturePoolParent())
// Using parent's texture pool -- ignore this record.
return;
int maxLength = (document.version() VERSION_14) ? 80 : 200;
std::string filename = in.readString(maxLength);
int32 index = in.readInt32(-1);
/*int32 x =*/ in.readInt32();
/*int32 y =*/ in.readInt32();
osg::StateSet* stateset = NULL;
// Need full path for unique key in local texture cache.
std::string pathname =
osgDB::findDataFile(filename,document.getOptions());
if (pathname.empty())
{
// allow the aplication to react on missing texture via
ReadFileCallback
stateset = readTexture(filename,document);
if( !stateset)
{
osg::notify(osg::WARN) Can't find texture ( index )
filename std::endl;
return;
}
}
else
{
// Is texture in local cache?
osg::StateSet* stateset =
flt::Registry::instance()-getTextureFromLocalCache(pathname);
}
// Read file if not in cache.
if (!stateset)
{
stateset = readTexture(pathname,document);
// Add to texture cache.
flt::Registry::instance()-addTextureToLocalCache(pathname,stateset);
}
// Add to texture pool.
TexturePool* tp = document.getOrCreateTexturePool();
(*tp)[index] = stateset;
}
Thank you!
Greetings,
Katharina[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=17525#17525
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::notify crash, not thread safe
Hi Robert, I tested against the svn 3.2 and trunk branches today on Linux and get the same results with the test program I posted. ./ThreadedNotify 48 1000 2 2 Segmentation fault ./ThreadedNotify 48 1000 2 2 *** glibc detected *** ./ThreadedNotify: free(): invalid pointer: 0x00d81500 *** Segmentation fault ./ThreadedNotify 48 1000 2 2 *** glibc detected *** ./ThreadedNotify: double free or corruption (!prev): 0x0189b500 *** Segmentation fault On Sun, Aug 04, 2013 at 11:48:56AM +, Robert Osfield wrote: Hi David, There were various changes to osg::Notify during the 3.1.x dev cycle. Could you try out OSG-3.2 and see how you get on. Robert. On 2 August 2013 22:54, David Fries da...@fries.net wrote: I spent a few days tracking down a crash I was having generally when a terrapage terrain was paging. This is using OSG 3.1, when I finally caught the corruption I found that both the DatabasePager thread and the Draw thread were calling OSG_NOTIFY. I wrote up a test that does little more than start up a bunch of threads and print messages and found it too crashes. I am testing on both Linux x86-64 gcc 4.7.2, and Windows 7 Visual Studio 10 and both crash, though it crashes much quicker on Windows. It will crash pretty quickly with the default (no arguments) on Windows. The following arguments are working for me to crash on Linux on a 12 core (24 with hyperthreading), x86-64 system. ./ThreadedNotify 48 1000 2 2 It has been pointed out that cout/cerr are thread safe, so it should be possible to make osg::notify thread safe as well. In this program it helps when I reduce the notification level, at least with the low number of messages being printed it seems to be unlikely. -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/ ___ 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 -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OpenFlight - Palette Records prevent using of ReaderWriter Callback
Hi Robert,
I'm preparing a submission right now. Don't hold your breath ...
Hi Sebastien,
I don't really have any strong opinions, nor a submission which to
review. If you send a full modified file into osg-submissions I can
review it and give you a more informed decions.
Cheers,
Robert.
On 5 August 2013 15:40, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de wrote:
Hi Robert,
Sorry for reviving this old thread.
But I stumbled across the exact same problem, and solving this issue with
the FindFileCallback is a real PITA.
I tried the patch Katharina provided (there is still a typo in here, but
nevertheless, it solves the issue.)
The problem with the FindFileCallback is that it simply gives you no
context. In my compiler I need to distinguish files that are referenced
inside the openflight from those which are searched from other sources (e.g.
looking up additional textures based on a name scheme).
With the the ReadFileCallback it is much easier to maintain such context.
So I second Katharinas idea.
Implementation-wise I'd provide an option to support calling the readfile
even if no valid path was found through the FindFileCallback and leave the
default option to the old behavior.
Would that be exectable?
cheers
Sebastian
HI Katharina,
In the svn/trunk version of the OSG I added support for overriding the
find file operation using an osgDB::FindFileCallback, that you attach
to the osgDB::Registry or an osgDB::Options object. Perhaps this
would be the best way for you to intercept and do something special
when texture files are not found.
Cheers,
Robert.
On Mon, Sep 21, 2009 at 1:49 PM, Katharina Plugge
katharina.plu...@web.de wrote:
Hello,
the OpenFlight-Plugin prevents reacting on missing Textures via a
ReadFileCallback, because osgDB::readRefImageFile (called by function
readTexture) is not called if the file does not exist. Would be great if
this could be changed.
A fix could look like this (file PaletteRecords.cpp, line 436):
Code:
virtual void readRecord(RecordInputStream in, Document document)
{
if (document.getTexturePoolParent())
// Using parent's texture pool -- ignore this record.
return;
int maxLength = (document.version() VERSION_14) ? 80 : 200;
std::string filename = in.readString(maxLength);
int32 index = in.readInt32(-1);
/*int32 x =*/ in.readInt32();
/*int32 y =*/ in.readInt32();
osg::StateSet* stateset = NULL;
// Need full path for unique key in local texture cache.
std::string pathname =
osgDB::findDataFile(filename,document.getOptions());
if (pathname.empty())
{
// allow the aplication to react on missing texture via
ReadFileCallback
stateset = readTexture(filename,document);
if( !stateset)
{
osg::notify(osg::WARN) Can't find texture ( index
) filename std::endl;
return;
}
}
else
{
// Is texture in local cache?
osg::StateSet* stateset =
flt::Registry::instance()-getTextureFromLocalCache(pathname);
}
// Read file if not in cache.
if (!stateset)
{
stateset = readTexture(pathname,document);
// Add to texture cache.
flt::Registry::instance()-addTextureToLocalCache(pathname,stateset);
}
// Add to texture pool.
TexturePool* tp = document.getOrCreateTexturePool();
(*tp)[index] = stateset;
}
Thank you!
Greetings,
Katharina[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=17525#17525
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::notify crash, not thread safe
HI David, I have my brain focused on some big topics today without much scope with thinking other complicated areas so won't dive into this one right now. I recall a discussion about thread safety of Notify from last year with a user who was heavily using notification in a multi-threaded environement and found issues like yourself, I don't know if they are the same though,I don't recall the details. He may of submitted changes or proposed some, but if they had been straight forward and without a performance compromise I would have merged them. It might be searching the archives on osg-users and osg-submissions to look at the discussions, it might help. I did merge some changes w.r.t threading though: r13094 | robert | 2012-06-22 16:21:08 + (Fri, 22 Jun 2012) | 2 lines Restructed the way that the global notify variables are initialized to avoid problems with multi-threaded initialization of these variables. This is at start up though. As for the assumptions that cerr and cout are thread safe, normally I'd stick with this assumption, but I'm not sure it's always the case across all compilers etc. Robert. On 5 August 2013 16:10, David Fries da...@fries.net wrote: Hi Robert, I tested against the svn 3.2 and trunk branches today on Linux and get the same results with the test program I posted. ./ThreadedNotify 48 1000 2 2 Segmentation fault ./ThreadedNotify 48 1000 2 2 *** glibc detected *** ./ThreadedNotify: free(): invalid pointer: 0x00d81500 *** Segmentation fault ./ThreadedNotify 48 1000 2 2 *** glibc detected *** ./ThreadedNotify: double free or corruption (!prev): 0x0189b500 *** Segmentation fault On Sun, Aug 04, 2013 at 11:48:56AM +, Robert Osfield wrote: Hi David, There were various changes to osg::Notify during the 3.1.x dev cycle. Could you try out OSG-3.2 and see how you get on. Robert. On 2 August 2013 22:54, David Fries da...@fries.net wrote: I spent a few days tracking down a crash I was having generally when a terrapage terrain was paging. This is using OSG 3.1, when I finally caught the corruption I found that both the DatabasePager thread and the Draw thread were calling OSG_NOTIFY. I wrote up a test that does little more than start up a bunch of threads and print messages and found it too crashes. I am testing on both Linux x86-64 gcc 4.7.2, and Windows 7 Visual Studio 10 and both crash, though it crashes much quicker on Windows. It will crash pretty quickly with the default (no arguments) on Windows. The following arguments are working for me to crash on Linux on a 12 core (24 with hyperthreading), x86-64 system. ./ThreadedNotify 48 1000 2 2 It has been pointed out that cout/cerr are thread safe, so it should be possible to make osg::notify thread safe as well. In this program it helps when I reduce the notification level, at least with the low number of messages being printed it seems to be unlikely. -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/ ___ 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 -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OpenFlight - Palette Records prevent using of ReaderWriter Callback
Hi Sebastien,
I don't really have any strong opinions, nor a submission which to
review. If you send a full modified file into osg-submissions I can
review it and give you a more informed decions.
Cheers,
Robert.
On 5 August 2013 15:40, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de wrote:
Hi Robert,
Sorry for reviving this old thread.
But I stumbled across the exact same problem, and solving this issue with
the FindFileCallback is a real PITA.
I tried the patch Katharina provided (there is still a typo in here, but
nevertheless, it solves the issue.)
The problem with the FindFileCallback is that it simply gives you no
context. In my compiler I need to distinguish files that are referenced
inside the openflight from those which are searched from other sources (e.g.
looking up additional textures based on a name scheme).
With the the ReadFileCallback it is much easier to maintain such context.
So I second Katharinas idea.
Implementation-wise I'd provide an option to support calling the readfile
even if no valid path was found through the FindFileCallback and leave the
default option to the old behavior.
Would that be exectable?
cheers
Sebastian
HI Katharina,
In the svn/trunk version of the OSG I added support for overriding the
find file operation using an osgDB::FindFileCallback, that you attach
to the osgDB::Registry or an osgDB::Options object. Perhaps this
would be the best way for you to intercept and do something special
when texture files are not found.
Cheers,
Robert.
On Mon, Sep 21, 2009 at 1:49 PM, Katharina Plugge
katharina.plu...@web.de wrote:
Hello,
the OpenFlight-Plugin prevents reacting on missing Textures via a
ReadFileCallback, because osgDB::readRefImageFile (called by function
readTexture) is not called if the file does not exist. Would be great if
this could be changed.
A fix could look like this (file PaletteRecords.cpp, line 436):
Code:
virtual void readRecord(RecordInputStream in, Document document)
{
if (document.getTexturePoolParent())
// Using parent's texture pool -- ignore this record.
return;
int maxLength = (document.version() VERSION_14) ? 80 : 200;
std::string filename = in.readString(maxLength);
int32 index = in.readInt32(-1);
/*int32 x =*/ in.readInt32();
/*int32 y =*/ in.readInt32();
osg::StateSet* stateset = NULL;
// Need full path for unique key in local texture cache.
std::string pathname =
osgDB::findDataFile(filename,document.getOptions());
if (pathname.empty())
{
// allow the aplication to react on missing texture via
ReadFileCallback
stateset = readTexture(filename,document);
if( !stateset)
{
osg::notify(osg::WARN) Can't find texture ( index
) filename std::endl;
return;
}
}
else
{
// Is texture in local cache?
osg::StateSet* stateset =
flt::Registry::instance()-getTextureFromLocalCache(pathname);
}
// Read file if not in cache.
if (!stateset)
{
stateset = readTexture(pathname,document);
// Add to texture cache.
flt::Registry::instance()-addTextureToLocalCache(pathname,stateset);
}
// Add to texture pool.
TexturePool* tp = document.getOrCreateTexturePool();
(*tp)[index] = stateset;
}
Thank you!
Greetings,
Katharina[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=17525#17525
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::notify crash, not thread safe
On Mon, Aug 05, 2013 at 04:34:17PM +, Robert Osfield wrote: HI David, I have my brain focused on some big topics today without much scope with thinking other complicated areas so won't dive into this one right now. I recall a discussion about thread safety of Notify from last year with a user who was heavily using notification in a multi-threaded environement and found issues like yourself, I don't know if they are the same though,I don't recall the details. He may of submitted changes or proposed some, but if they had been straight forward and without a performance compromise I would have merged them. It might be searching the archives on osg-users and osg-submissions to look at the discussions, it might help. I did merge some changes w.r.t threading though: Date: Nov 28 06:08:02 2011 From: George Bekos bekos...@live.com Subject: [osg-users] Custom osg::NotifyHandler problems and multi-threading It sounded like the same issue, no changes were posted on the thread. It sounded to me to show an example that reproduced it on Linux which is what I posted. For now we'll just make sure are logging levels are set low so we don't have much chance of hitting it. r13094 | robert | 2012-06-22 16:21:08 + (Fri, 22 Jun 2012) | 2 lines Restructed the way that the global notify variables are initialized to avoid problems with multi-threaded initialization of these variables. This is at start up though. As for the assumptions that cerr and cout are thread safe, normally I'd stick with this assumption, but I'm not sure it's always the case across all compilers etc. Robert. On 5 August 2013 16:10, David Fries da...@fries.net wrote: Hi Robert, I tested against the svn 3.2 and trunk branches today on Linux and get the same results with the test program I posted. ./ThreadedNotify 48 1000 2 2 Segmentation fault ./ThreadedNotify 48 1000 2 2 *** glibc detected *** ./ThreadedNotify: free(): invalid pointer: 0x00d81500 *** Segmentation fault ./ThreadedNotify 48 1000 2 2 *** glibc detected *** ./ThreadedNotify: double free or corruption (!prev): 0x0189b500 *** Segmentation fault On Sun, Aug 04, 2013 at 11:48:56AM +, Robert Osfield wrote: Hi David, There were various changes to osg::Notify during the 3.1.x dev cycle. Could you try out OSG-3.2 and see how you get on. Robert. On 2 August 2013 22:54, David Fries da...@fries.net wrote: I spent a few days tracking down a crash I was having generally when a terrapage terrain was paging. This is using OSG 3.1, when I finally caught the corruption I found that both the DatabasePager thread and the Draw thread were calling OSG_NOTIFY. I wrote up a test that does little more than start up a bunch of threads and print messages and found it too crashes. I am testing on both Linux x86-64 gcc 4.7.2, and Windows 7 Visual Studio 10 and both crash, though it crashes much quicker on Windows. It will crash pretty quickly with the default (no arguments) on Windows. The following arguments are working for me to crash on Linux on a 12 core (24 with hyperthreading), x86-64 system. ./ThreadedNotify 48 1000 2 2 It has been pointed out that cout/cerr are thread safe, so it should be possible to make osg::notify thread safe as well. In this program it helps when I reduce the notification level, at least with the low number of messages being printed it seems to be unlikely. -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/ ___ 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 -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/ ___ 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 -- David Fries da...@fries.netPGP pub CB1EE8F0 http://fries.net/~david/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
