[osg-users] Caustics for UnderWater Effect by GLSL
Hi All, I have found a good Thesis(2007) about creation UnderWater effects with using OpenSceneGraph and GLSL and I want to share with you. It was developed by Philippe APERY from University of HULL. You can download this thesis from http://apery.tesseract.fr/thesis.pdf Best Regards. Umit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setLODScale affecting near far planes?
Hi all again, Robert: for you last question; yes, I have near/far culling enabled and the near/far setting is compute_near_far_using_bounding_volume. If the near far modification that is taking place should be very small, somehow I am still getting quite significant jumps because some objects near the camera get culled when I would not like that to happen. When I enable culling for near/far planes, it seems like osg takes into account my preferred near/far planes and is NOT auto-computing. It does do some re computation as I change the LODScale. Why does this happen? Paul: Do you get the same behavior when viewing your database in osgviewer and hitting the * and / keys? -Paul Sorry Paul, but it is hard for me to say, because with osgviewer I only notice the terrain loosing or gaining detail, but since I am unable to dump the camera information in osgviewer I cannot compare it to my application's printouts of near far planes, but thanks for the advice. -Jose On Sat, September 20, 2008 1:53 am, Robert Osfield wrote: Hi Jose, The LODScale does not affect the near/far planes and certainly won't affect near/far plane culling if enabled. If you have compute near/far planes on the camera enabled then LODScale might change the depth range a little as different children of LOD gets selected, but generally this would be very small.Could it be that you have enabled near/far plane culling by not disabled the compute of the near/far? Both settings are on the camera. Robert. On Fri, Sep 19, 2008 at 11:01 PM, Joseanibal Colon Ramos [EMAIL PROTECTED] wrote: Hi all, I am getting this rather weird effect when playing with the setLODScale values in my application. I have a large pagedLOD terrain, with near/far planes culling mode enabled for my camera, and I am looking at a certain direction in the scene. I added osg's lod scale handler so that I can modify the value interactively (with the * and / keys, just like in osgviewer) and it turns out that as I change that value, and I dump my application's debug information, I notice the the near/far planes do not remain constant, although I am not moving around the scene and I am always looking in the same direction. This causes problems because the clipping planes change as a result of changing the LOD scale and my non-LOD objects beyond the planes get culled. I don't think that the clipping planes should change at all if I am not moving my camera. I should still see the objects that are within a constant near/far distance, and I should only observe different level of detail on the LOD objects as I change the scale. What am I missing here? I am using osg.2.6.0 on a 64bit intel linux machine. Thanks, -Jose ___ 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] Compile error in OSG trunk rev 8909
Hi,
I am having trouble compiling OSG trunk after doing svn update:
% svn update
At revision 8909.
...
[ 14%] Building CXX object src/osgDB/CMakeFiles/osgDB.dir/FileUtils.o
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp: In
function `void appendInstallationLibraryFilePaths(osgDB::FilePathList)':
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: expected primary-expression before '/' token
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `usr' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `local' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `lib64' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `osgPlugins' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:24:
too many decimal points in number
make[2]: *** [src/osgDB/CMakeFiles/osgDB.dir/FileUtils.o] Error 1
make[1]: *** [src/osgDB/CMakeFiles/osgDB.dir/all] Error 2
make: *** [all] Error 2
Exit 2
The problem seems to be that the string contained by
OSG_DEFAULT_LIBRARY_PATH is not limited by quotation marks:
static void appendInstallationLibraryFilePaths(osgDB::FilePathList
filepath)
{
#ifdef OSG_DEFAULT_LIBRARY_PATH
// Append the install prefix path to the library search path if
configured
filepath.push_back(OSG_DEFAULT_LIBRARY_PATH); Line 371
#endif
}
Best regards,
John
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Foggy headed bog
Hi All, I've come down with a bad cold over the weekend, and am find it difficult to read/concentrate so I'm going to take it easy till my cold starts getting better and I can work more productively. I'll be doing a bit of tinkering, but mailing list wise I'm going to keep a low profile as jumping between lots of different topics is something my brain can't function to do right now. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compile error in OSG trunk rev 8909
Hi again,
The compile error seems to be due to faulty CXX_FLAG settings in the
flags.make files created by cmake:
% grep OSG_DEFAULT_LIBRARY_PATH flags.make
CXX_FLAGS = -O3 -DNDEBUG
-I/home/john/external.el4/OpenSceneGraph/build_trunk_release/include
-I/home/john/external.el4/OpenSceneGraph/trunk/include
-DOSG_DEBUG_POSTFIX='d'
-DOSG_DEFAULT_LIBRARY_PATH=/usr/local/lib64/osgPlugins-2.7.3
OSG_DEFAULT_LIBRARY_PATH should probably have been set to:
-DOSG_DEFAULT_LIBRARY_PATH='/usr/local/lib64/osgPlugins-2.7.3'
(i.e. missing single quotes.) I hope someone can tell me how to fiks
this problem:)
Best regards,
John
John Vidar Larring wrote:
Hi,
I am having trouble compiling OSG trunk after doing svn update:
% svn update
At revision 8909.
...
[ 14%] Building CXX object src/osgDB/CMakeFiles/osgDB.dir/FileUtils.o
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp: In
function `void appendInstallationLibraryFilePaths(osgDB::FilePathList)':
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: expected primary-expression before '/' token
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `usr' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `local' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `lib64' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `osgPlugins' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:24:
too many decimal points in number
make[2]: *** [src/osgDB/CMakeFiles/osgDB.dir/FileUtils.o] Error 1
make[1]: *** [src/osgDB/CMakeFiles/osgDB.dir/all] Error 2
make: *** [all] Error 2
Exit 2
The problem seems to be that the string contained by
OSG_DEFAULT_LIBRARY_PATH is not limited by quotation marks:
static void appendInstallationLibraryFilePaths(osgDB::FilePathList
filepath)
{
#ifdef OSG_DEFAULT_LIBRARY_PATH
// Append the install prefix path to the library search path if
configured
filepath.push_back(OSG_DEFAULT_LIBRARY_PATH); Line 371
#endif
}
Best regards,
John
--
Best regards,
John
WeatherOne
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compile error in OSG trunk rev 8909
Hi again,
Sorry for creating all this traffic communicating with myself, but
here's the fix to get OSG trunk rev 8909 to compile (I'll send a zip
file to osg-submission):
% svn diff CMakeLists.txt
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 8909)
+++ CMakeLists.txt (working copy)
@@ -534,7 +534,7 @@
# Add a default plugin search path component
IF (DYNAMIC_OPENSCENEGRAPH)
-
ADD_DEFINITIONS(-DOSG_DEFAULT_LIBRARY_PATH=${CMAKE_INSTALL_PREFIX}/lib${LIB_POSTFIX}/${OSG_PLUGINS})
+
ADD_DEFINITIONS(-DOSG_DEFAULT_LIBRARY_PATH='${CMAKE_INSTALL_PREFIX}/lib${LIB_POSTFIX}/${OSG_PLUGINS}')
ENDIF(DYNAMIC_OPENSCENEGRAPH)
INCLUDE(OsgMacroUtils)
Best regards,
John
John Vidar Larring wrote:
Hi again,
The compile error seems to be due to faulty CXX_FLAG settings in the
flags.make files created by cmake:
% grep OSG_DEFAULT_LIBRARY_PATH flags.make
CXX_FLAGS = -O3 -DNDEBUG
-I/home/john/external.el4/OpenSceneGraph/build_trunk_release/include
-I/home/john/external.el4/OpenSceneGraph/trunk/include
-DOSG_DEBUG_POSTFIX='d'
-DOSG_DEFAULT_LIBRARY_PATH=/usr/local/lib64/osgPlugins-2.7.3
OSG_DEFAULT_LIBRARY_PATH should probably have been set to:
-DOSG_DEFAULT_LIBRARY_PATH='/usr/local/lib64/osgPlugins-2.7.3'
(i.e. missing single quotes.) I hope someone can tell me how to fiks
this problem:)
Best regards,
John
John Vidar Larring wrote:
Hi,
I am having trouble compiling OSG trunk after doing svn update:
% svn update
At revision 8909.
...
[ 14%] Building CXX object src/osgDB/CMakeFiles/osgDB.dir/FileUtils.o
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:
In function `void
appendInstallationLibraryFilePaths(osgDB::FilePathList)':
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: expected primary-expression before '/' token
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `usr' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `local' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `lib64' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `osgPlugins' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:24:
too many decimal points in number
make[2]: *** [src/osgDB/CMakeFiles/osgDB.dir/FileUtils.o] Error 1
make[1]: *** [src/osgDB/CMakeFiles/osgDB.dir/all] Error 2
make: *** [all] Error 2
Exit 2
The problem seems to be that the string contained by
OSG_DEFAULT_LIBRARY_PATH is not limited by quotation marks:
static void appendInstallationLibraryFilePaths(osgDB::FilePathList
filepath)
{
#ifdef OSG_DEFAULT_LIBRARY_PATH
// Append the install prefix path to the library search path if
configured
filepath.push_back(OSG_DEFAULT_LIBRARY_PATH); Line 371
#endif
}
Best regards,
John
--
Best regards,
John
WeatherOne
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compile error in OSG trunk rev 8909
There is another compile error with this revision on osgParticle :
ModularEmitter.obj : error LNK2019: unresolved external symbol
__declspec(dllimport) public: class std::vectorclass osg::Matrixd,class
std::allocatorclass osg::Matrixd __thiscall
osg::Drawable::getWorldMatrices(class osg::Node const *)const
([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@osg@
@[EMAIL PROTECTED]@osg@@@std@@@std@@[EMAIL PROTECTED]@@Z) referenced in function
protected: virtual void __thiscall
osgParticle::ModularEmitter::emit(double) ([EMAIL PROTECTED]
@osgParticle@@[EMAIL PROTECTED])
OpenSceneGraph\lib\Debug\..\..\bin\osg47-osgParticled.dll : fatal error
LNK1120: 1 unresolved externals
The function osg::Drawable::getWorldMatrices seems to be declared into the
header file but not into the cpp file.
On Mon, Sep 22, 2008 at 11:37 AM, John Vidar Larring
[EMAIL PROTECTED]wrote:
Hi again,
Sorry for creating all this traffic communicating with myself, but here's
the fix to get OSG trunk rev 8909 to compile (I'll send a zip file to
osg-submission):
% svn diff CMakeLists.txt
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 8909)
+++ CMakeLists.txt (working copy)
@@ -534,7 +534,7 @@
# Add a default plugin search path component
IF (DYNAMIC_OPENSCENEGRAPH)
-
ADD_DEFINITIONS(-DOSG_DEFAULT_LIBRARY_PATH=${CMAKE_INSTALL_PREFIX}/lib${LIB_POSTFIX}/${OSG_PLUGINS})
+
ADD_DEFINITIONS(-DOSG_DEFAULT_LIBRARY_PATH='${CMAKE_INSTALL_PREFIX}/lib${LIB_POSTFIX}/${OSG_PLUGINS}')
ENDIF(DYNAMIC_OPENSCENEGRAPH)
INCLUDE(OsgMacroUtils)
Best regards,
John
John Vidar Larring wrote:
Hi again,
The compile error seems to be due to faulty CXX_FLAG settings in the
flags.make files created by cmake:
% grep OSG_DEFAULT_LIBRARY_PATH flags.make
CXX_FLAGS = -O3 -DNDEBUG
-I/home/john/external.el4/OpenSceneGraph/build_trunk_release/include
-I/home/john/external.el4/OpenSceneGraph/trunk/include
-DOSG_DEBUG_POSTFIX='d'
-DOSG_DEFAULT_LIBRARY_PATH=/usr/local/lib64/osgPlugins-2.7.3
OSG_DEFAULT_LIBRARY_PATH should probably have been set to:
-DOSG_DEFAULT_LIBRARY_PATH='/usr/local/lib64/osgPlugins-2.7.3'
(i.e. missing single quotes.) I hope someone can tell me how to fiks this
problem:)
Best regards,
John
John Vidar Larring wrote:
Hi,
I am having trouble compiling OSG trunk after doing svn update:
% svn update
At revision 8909.
...
[ 14%] Building CXX object src/osgDB/CMakeFiles/osgDB.dir/FileUtils.o
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp: In
function `void appendInstallationLibraryFilePaths(osgDB::FilePathList)':
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: expected primary-expression before '/' token
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `usr' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `local' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `lib64' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `osgPlugins' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:24:
too many decimal points in number
make[2]: *** [src/osgDB/CMakeFiles/osgDB.dir/FileUtils.o] Error 1
make[1]: *** [src/osgDB/CMakeFiles/osgDB.dir/all] Error 2
make: *** [all] Error 2
Exit 2
The problem seems to be that the string contained by
OSG_DEFAULT_LIBRARY_PATH is not limited by quotation marks:
static void appendInstallationLibraryFilePaths(osgDB::FilePathList
filepath)
{
#ifdef OSG_DEFAULT_LIBRARY_PATH
// Append the install prefix path to the library search path if
configured
filepath.push_back(OSG_DEFAULT_LIBRARY_PATH); Line 371
#endif
}
Best regards,
John
--
Best regards,
John
WeatherOne
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Serge Lages
http://www.tharsis-software.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compile error in OSG trunk rev 8909
Hi Serge,
The getWorldMatrices() method is implementated and checked into svn.
http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osg/Drawable.cpp?rev=8880
Check your local to make sure that it's checked out Drawable.cpp properly.
Robert.
On Mon, Sep 22, 2008 at 11:00 AM, Serge Lages [EMAIL PROTECTED] wrote:
There is another compile error with this revision on osgParticle :
ModularEmitter.obj : error LNK2019: unresolved external symbol
__declspec(dllimport) public: class std::vectorclass osg::Matrixd,class
std::allocatorclass osg::Matrixd __thiscall
osg::Drawable::getWorldMatrices(class osg::Node const *)const
([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@osg@@[EMAIL
PROTECTED]@osg@@@std@@@std@@[EMAIL PROTECTED]@@Z)
referenced in function protected: virtual void __thiscall
osgParticle::ModularEmitter::emit(double)
([EMAIL PROTECTED]@osgParticle@@[EMAIL PROTECTED])
OpenSceneGraph\lib\Debug\..\..\bin\osg47-osgParticled.dll : fatal error
LNK1120: 1 unresolved externals
The function osg::Drawable::getWorldMatrices seems to be declared into the
header file but not into the cpp file.
On Mon, Sep 22, 2008 at 11:37 AM, John Vidar Larring [EMAIL PROTECTED]
wrote:
Hi again,
Sorry for creating all this traffic communicating with myself, but here's
the fix to get OSG trunk rev 8909 to compile (I'll send a zip file to
osg-submission):
% svn diff CMakeLists.txt
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 8909)
+++ CMakeLists.txt (working copy)
@@ -534,7 +534,7 @@
# Add a default plugin search path component
IF (DYNAMIC_OPENSCENEGRAPH)
-
ADD_DEFINITIONS(-DOSG_DEFAULT_LIBRARY_PATH=${CMAKE_INSTALL_PREFIX}/lib${LIB_POSTFIX}/${OSG_PLUGINS})
+
ADD_DEFINITIONS(-DOSG_DEFAULT_LIBRARY_PATH='${CMAKE_INSTALL_PREFIX}/lib${LIB_POSTFIX}/${OSG_PLUGINS}')
ENDIF(DYNAMIC_OPENSCENEGRAPH)
INCLUDE(OsgMacroUtils)
Best regards,
John
John Vidar Larring wrote:
Hi again,
The compile error seems to be due to faulty CXX_FLAG settings in the
flags.make files created by cmake:
% grep OSG_DEFAULT_LIBRARY_PATH flags.make
CXX_FLAGS = -O3 -DNDEBUG
-I/home/john/external.el4/OpenSceneGraph/build_trunk_release/include
-I/home/john/external.el4/OpenSceneGraph/trunk/include
-DOSG_DEBUG_POSTFIX='d'
-DOSG_DEFAULT_LIBRARY_PATH=/usr/local/lib64/osgPlugins-2.7.3
OSG_DEFAULT_LIBRARY_PATH should probably have been set to:
-DOSG_DEFAULT_LIBRARY_PATH='/usr/local/lib64/osgPlugins-2.7.3'
(i.e. missing single quotes.) I hope someone can tell me how to fiks this
problem:)
Best regards,
John
John Vidar Larring wrote:
Hi,
I am having trouble compiling OSG trunk after doing svn update:
% svn update
At revision 8909.
...
[ 14%] Building CXX object src/osgDB/CMakeFiles/osgDB.dir/FileUtils.o
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp: In
function `void appendInstallationLibraryFilePaths(osgDB::FilePathList)':
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: expected primary-expression before '/' token
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `usr' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `local' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `lib64' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `osgPlugins' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:24:
too many decimal points in number
make[2]: *** [src/osgDB/CMakeFiles/osgDB.dir/FileUtils.o] Error 1
make[1]: *** [src/osgDB/CMakeFiles/osgDB.dir/all] Error 2
make: *** [all] Error 2
Exit 2
The problem seems to be that the string contained by
OSG_DEFAULT_LIBRARY_PATH is not limited by quotation marks:
static void appendInstallationLibraryFilePaths(osgDB::FilePathList
filepath)
{
#ifdef OSG_DEFAULT_LIBRARY_PATH
// Append the install prefix path to the library search path if
configured
filepath.push_back(OSG_DEFAULT_LIBRARY_PATH); Line 371
#endif
}
Best regards,
John
--
Best regards,
John
WeatherOne
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Serge Lages
http://www.tharsis-software.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
Re: [osg-users] Compile error in OSG trunk rev 8909
Sorry for the noise Robert, an update has fixed it.
On Mon, Sep 22, 2008 at 12:50 PM, Robert Osfield
[EMAIL PROTECTED]wrote:
Hi Serge,
The getWorldMatrices() method is implementated and checked into svn.
http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osg/Drawable.cpp?rev=8880
Check your local to make sure that it's checked out Drawable.cpp properly.
Robert.
On Mon, Sep 22, 2008 at 11:00 AM, Serge Lages [EMAIL PROTECTED]
wrote:
There is another compile error with this revision on osgParticle :
ModularEmitter.obj : error LNK2019: unresolved external symbol
__declspec(dllimport) public: class std::vectorclass osg::Matrixd,class
std::allocatorclass osg::Matrixd __thiscall
osg::Drawable::getWorldMatrices(class osg::Node const *)const
([EMAIL PROTECTED]@osg@@[EMAIL PROTECTED]@osg@
@[EMAIL PROTECTED]@osg@@@std@@@std@@[EMAIL PROTECTED]@@Z)
referenced in function protected: virtual void __thiscall
osgParticle::ModularEmitter::emit(double)
([EMAIL PROTECTED]@osgParticle@@[EMAIL PROTECTED])
OpenSceneGraph\lib\Debug\..\..\bin\osg47-osgParticled.dll : fatal error
LNK1120: 1 unresolved externals
The function osg::Drawable::getWorldMatrices seems to be declared into
the
header file but not into the cpp file.
On Mon, Sep 22, 2008 at 11:37 AM, John Vidar Larring
[EMAIL PROTECTED]
wrote:
Hi again,
Sorry for creating all this traffic communicating with myself, but
here's
the fix to get OSG trunk rev 8909 to compile (I'll send a zip file to
osg-submission):
% svn diff CMakeLists.txt
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 8909)
+++ CMakeLists.txt (working copy)
@@ -534,7 +534,7 @@
# Add a default plugin search path component
IF (DYNAMIC_OPENSCENEGRAPH)
-
ADD_DEFINITIONS(-DOSG_DEFAULT_LIBRARY_PATH=${CMAKE_INSTALL_PREFIX}/lib${LIB_POSTFIX}/${OSG_PLUGINS})
+
ADD_DEFINITIONS(-DOSG_DEFAULT_LIBRARY_PATH='${CMAKE_INSTALL_PREFIX}/lib${LIB_POSTFIX}/${OSG_PLUGINS}')
ENDIF(DYNAMIC_OPENSCENEGRAPH)
INCLUDE(OsgMacroUtils)
Best regards,
John
John Vidar Larring wrote:
Hi again,
The compile error seems to be due to faulty CXX_FLAG settings in the
flags.make files created by cmake:
% grep OSG_DEFAULT_LIBRARY_PATH flags.make
CXX_FLAGS = -O3 -DNDEBUG
-I/home/john/external.el4/OpenSceneGraph/build_trunk_release/include
-I/home/john/external.el4/OpenSceneGraph/trunk/include
-DOSG_DEBUG_POSTFIX='d'
-DOSG_DEFAULT_LIBRARY_PATH=/usr/local/lib64/osgPlugins-2.7.3
OSG_DEFAULT_LIBRARY_PATH should probably have been set to:
-DOSG_DEFAULT_LIBRARY_PATH='/usr/local/lib64/osgPlugins-2.7.3'
(i.e. missing single quotes.) I hope someone can tell me how to fiks
this
problem:)
Best regards,
John
John Vidar Larring wrote:
Hi,
I am having trouble compiling OSG trunk after doing svn update:
% svn update
At revision 8909.
...
[ 14%] Building CXX object src/osgDB/CMakeFiles/osgDB.dir/FileUtils.o
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:
In
function `void
appendInstallationLibraryFilePaths(osgDB::FilePathList)':
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: expected primary-expression before '/' token
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `usr' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `local' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `lib64' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:
error: `osgPlugins' was not declared in this scope
/home/john/external.el4/OpenSceneGraph/trunk/src/osgDB/FileUtils.cpp:371:24:
too many decimal points in number
make[2]: *** [src/osgDB/CMakeFiles/osgDB.dir/FileUtils.o] Error 1
make[1]: *** [src/osgDB/CMakeFiles/osgDB.dir/all] Error 2
make: *** [all] Error 2
Exit 2
The problem seems to be that the string contained by
OSG_DEFAULT_LIBRARY_PATH is not limited by quotation marks:
static void appendInstallationLibraryFilePaths(osgDB::FilePathList
filepath)
{
#ifdef OSG_DEFAULT_LIBRARY_PATH
// Append the install prefix path to the library search path if
configured
filepath.push_back(OSG_DEFAULT_LIBRARY_PATH); Line 371
#endif
}
Best regards,
John
--
Best regards,
John
WeatherOne
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Serge Lages
[osg-users] Spatial View SVI autosteroscopic display support.
I am currently looking at the feasibility of adding support for SVI
autostereoscopic display in OSG.
Does anyone know anything about this?
So far, I have been looking at an SDK that provides an OpenGL based API and
examples for driving the display.
I have also been looking at the different ways OSG implements stereo modes
with a view to seeing where might be the best place to perform the interlace
function required to support the SVI display.
I noticed that the WOWVX support is done by creating two slave cameras that
render to textures, then combining the textures and wowvx headers using a
pixel shader. So, at first, that seemed a good pattern to try and follow,
but on reflection it's difficult for me to see how to use the SVI API in
this way (even though internally I suspect something similar is going on).
I seem to be floundering a bit., so I wondered if I can trouble anyone on
the list to take a quick look at the attached OpenGL example code from the
SVILaceOGL SDK and make any suggestions about how and where the best place
to try and use the API from within OSG (or from an OSG application).
Of course, if I'm successful with the integration, I'll be happy to share
the result with the OSG community. ;-)
Cheers.
Chris.
/**
\file
SVILaceOgl Example 1
Initialize an interlacer.
Set an arbitary stereo mode and
provide anaglyph red cyan stereo
\author klaus.kesseleratspatialview.com
\author dietrich.johnatspatialview.com
\author (c) http://www.spatialview.com
*/
#include SVILaceOgl.h
#include OglCameras.h
#include vector
#include string
#include iostream
#include GL/glut.h
using namespace SVI;
using namespace SVI::OglCameras;
//==
namespace{
int g_rotation = 0;
int g_rotation_increment = 1;
struct IlaceData{
IlaceOgl::IlaceHandle interlacer;
std::vectorGLuint textures;
unsigned int texWidth;
unsigned int texHeight;
};
IlaceData g_data;
} // anonymous Namespace
//==
void cbDisplay();
void cbResize(int w, int h);
void cbIdle(void);
void cbTimer(int );
void cbKey(unsigned char k, int , int );
//==
// init Glut window
void initGlut(int *argc, char *argv[])
{
//Init window position and size:
int windowX = 100;
int windowY = 100;
int windowWidth = 680;
int windowHeight = 480;
glutInit(argc, argv);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH);
glutInitWindowSize(windowWidth, windowHeight);
glutInitWindowPosition(windowX, windowY);
glutCreateWindow(argv[0]);
//call backs
glutDisplayFunc(cbDisplay);
glutReshapeFunc(cbResize);
glutIdleFunc(cbIdle);
glutTimerFunc(1/360, cbTimer, 0);
glutKeyboardFunc(cbKey);
}
//==
// create the interlacer
bool ilaceInit(){
// Check for OpenGL extensions, we need
if (!IlaceOgl::checkHardware())
{
std::cout Interlacing support is not available. Missing OpenGL
extensions: std::endl;
std::cout IlaceOgl::getMissingExt();
return false;
}
// Create an interlacer
g_data.interlacer=IlaceOgl::createInstance();
// Test for failure:
if (!g_data.interlacer)
{
std::cout Failure, can not create interlacer std::endl;
return false;
}
// Set an arbitrary Stereo Mode:
IlaceOgl::setCurrentStereoMode(g_data.interlacer,AnaglyphRedCyan);
// Query the number of camera views, we need for the stereo mode:
int camCount = IlaceOgl::getCameraCount(g_data.interlacer);
int windowWidth = glutGet(GLUT_WINDOW_WIDTH );
int windowHeight = glutGet(GLUT_WINDOW_HEIGHT);
//initialize input textures
g_data.textures.resize(camCount);
g_data.texWidth = windowWidth;
g_data.texHeight = windowHeight;
// use a helper function from IlaceOgl to request texture id's and
initialize the texture:
IlaceOgl::provideTextures(g_data.textures[0],camCount,g_data.texWidth,g_data.texHeight);
IlaceOgl::setTextures(g_data.interlacer, g_data.textures[0], camCount);
int screenX = 0; // Here we use 0,0 for x,y for the first display, but we should know
int screenY = 0; // the position of the display, if we use a second one.
int screenWidth = glutGet(GLUT_SCREEN_WIDTH);
int screenHeight = glutGet(GLUT_SCREEN_HEIGHT);
IlaceOgl::setScreen(g_data.interlacer, screenX, screenY, screenWidth,
screenHeight);
return true;
}
Re: [osg-users] setLODScale affecting near far planes?
Hi all again, Robert: for you last question; yes, I have near/far culling enabled and the near/far setting is compute_near_far_using_bounding_volume. If the near far modification that is taking place should be very small, somehow I am still getting quite significant jumps because some objects near the camera get culled when I would not like that to happen. When I enable culling for near/far planes, it seems like osg takes into account my preferred near/far planes and is NOT auto-computing. It does do some re computation as I change the LODScale. Why does this happen? You have said on multiple occasions that you are enabling near/far culling -- What exactly do you mean by that? Near/far culling is always enabled in OSG and OpenGL, so I'm curious to know what function call you are making that you believe is enabling near/far culling. Paul: Do you get the same behavior when viewing your database in osgviewer and hitting the * and / keys? -Paul Sorry Paul, but it is hard for me to say, because with osgviewer I only notice the terrain loosing or gaining detail, but since I am unable to dump the camera information in osgviewer I cannot compare it to my application's printouts of near far planes, but thanks for the advice. If you don't get the dame behavior in osgviewer, then most likely this is a bug in your own application somewhere, and not a problem in OSG. You can dump the osgviewer camera information by editing the osgviewer source. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Ref_ptr question : argument and return
Hi all,
I read that all the objects that inherit from Referenced need to be in a
ref_ptr.
Ok that sounds good , but :
In this case I don't know if I need to put the ref_prt in argument or if
only the ptr is needed.
bool VisualEffects::setTransparency(string name, float alpha){
osg::ref_ptrosg::Node node = getNode(name);
return VisualEffects::setTransparency(node.get(), alpha); //node ? or
node.get() ?
}
If call the second function without ref_prt,
I just need to understand if it can make an error, and if it depends on the
code on setTransparency(node, alpha), based on a ref_prt or not... (imagine
I don't know)
thanks a lot,
Regards,
Vincent
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setLODScale affecting near far planes?
Culling IS done against the near and far clip, this is standard
operating procedure of OGL and OSG
Gordon
__
Gordon Tomlinson
Product Manager 3D
Email : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651
Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival
- Master Tambo Tetsura
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Smeenk,
R.J.M. (Roland)
Sent: Monday, September 22, 2008 11:36 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] setLODScale affecting near far planes?
Paul,
As far as I know default OSG culling is only done against the sides and
not against the near and far plane.
See:
enum MaskValues
{
NO_CULLING = 0x0,
VIEW_FRUSTUM_SIDES_CULLING = 0x1,
NEAR_PLANE_CULLING = 0x2,
FAR_PLANE_CULLING = 0x4,
VIEW_FRUSTUM_CULLING= VIEW_FRUSTUM_SIDES_CULLING|
NEAR_PLANE_CULLING|
FAR_PLANE_CULLING,
SMALL_FEATURE_CULLING = 0x8,
SHADOW_OCCLUSION_CULLING= 0x10,
DEFAULT_CULLING = VIEW_FRUSTUM_SIDES_CULLING|
SMALL_FEATURE_CULLING|
SHADOW_OCCLUSION_CULLING,
ENABLE_ALL_CULLING = VIEW_FRUSTUM_CULLING|
SMALL_FEATURE_CULLING|
SHADOW_OCCLUSION_CULLING
};
--
Roland
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Martz
Sent: maandag 22 september 2008 16:46
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] setLODScale affecting near far planes?
Hi all again,
Robert: for you last question; yes, I have near/far culling enabled
and the near/far setting is
compute_near_far_using_bounding_volume. If
the near far modification that is taking place should be
very small,
somehow I am still getting quite significant jumps because some
objects near the camera get culled when I would not like that to
happen. When I enable culling for near/far planes, it seems
like osg
takes into account my preferred near/far planes and is NOT
auto-computing. It does do some re computation as I change the
LODScale. Why does this happen?
You have said on multiple occasions that you are enabling near/far
culling
-- What exactly do you mean by that? Near/far culling is always
enabled in OSG and OpenGL, so I'm curious to know what function call
you are making that you believe is enabling near/far culling.
Paul:
Do you get the same behavior when viewing your database in
osgviewer
and hitting the * and / keys?
-Paul
Sorry Paul, but it is hard for me to say, because with osgviewer I
only notice the terrain loosing or gaining detail, but since I am
unable to dump the camera information in osgviewer I cannot
compare it
to my application's printouts of near far planes, but
thanks for the
advice.
If you don't get the dame behavior in osgviewer, then most likely this
is a bug in your own application somewhere, and not a problem in OSG.
You can dump the osgviewer camera information by editing the osgviewer
source.
-Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org
This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/disclaimer/email.html
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setLODScale affecting near far planes?
Tomlinson, Gordon wrote on Monday, September 22, 2008 10:45 AM:
Culling IS done against the near and far clip, this is standard
operating procedure of OGL and OSG
To be precise, OSG only culls based on the sides of the frustum by
default (as Roland says); OGL does the near and far plane culling (based
on OSG calculations of what those planes should be). You can configure
OSG to do its own near and far plane culling in addition, though.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Smeenk,
R.J.M. (Roland)
Sent: Monday, September 22, 2008 11:36 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] setLODScale affecting near far planes?
Paul,
As far as I know default OSG culling is only done against the sides
and
not against the near and far plane.
See:
enum MaskValues
{
NO_CULLING = 0x0,
VIEW_FRUSTUM_SIDES_CULLING = 0x1,
NEAR_PLANE_CULLING = 0x2,
FAR_PLANE_CULLING = 0x4,
VIEW_FRUSTUM_CULLING= VIEW_FRUSTUM_SIDES_CULLING|
NEAR_PLANE_CULLING|
FAR_PLANE_CULLING,
SMALL_FEATURE_CULLING = 0x8,
SHADOW_OCCLUSION_CULLING= 0x10,
DEFAULT_CULLING = VIEW_FRUSTUM_SIDES_CULLING|
SMALL_FEATURE_CULLING|
SHADOW_OCCLUSION_CULLING,
ENABLE_ALL_CULLING = VIEW_FRUSTUM_CULLING|
SMALL_FEATURE_CULLING|
SHADOW_OCCLUSION_CULLING
};
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Martz
Sent: maandag 22 september 2008 16:46
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] setLODScale affecting near far planes?
Hi all again,
Robert: for you last question; yes, I have near/far culling enabled
and the near/far setting is
compute_near_far_using_bounding_volume. If
the near far modification that is taking place should be very small,
somehow I am still getting quite significant jumps because some
objects near the camera get culled when I would not like that to
happen. When I enable culling for near/far planes, it seems like osg
takes into account my preferred near/far planes and is NOT
auto-computing. It does do some re computation as I change the
LODScale. Why does this happen?
You have said on multiple occasions that you are enabling near/far
culling
-- What exactly do you mean by that? Near/far culling is always
enabled in OSG and OpenGL, so I'm curious to know what function call
you are making that you believe is enabling near/far culling.
Paul:
Do you get the same behavior when viewing your database in
osgviewer and
hitting the * and / keys? -Paul
Sorry Paul, but it is hard for me to say, because with osgviewer I
only notice the terrain loosing or gaining detail, but since I am
unable to dump the camera information in osgviewer I cannot compare
it
to my application's printouts of near far planes, but thanks for the
advice.
If you don't get the dame behavior in osgviewer, then most likely
this
is a bug in your own application somewhere, and not a problem in OSG.
You can dump the osgviewer camera information by editing the
osgviewer
source.
-Paul
--
Bryan Thrall
FlightSafety International
[EMAIL PROTECTED]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setLODScale affecting near far planes?
On Mon, Sep 22, 2008 at 4:45 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: Culling IS done against the near and far clip, this is standard operating procedure of OGL and OSG FYI, Roland is correct, the OSG just does culling on sides of the frustum by default. OpenGL does no culling, is just does near and far *clipping*. The OSG of course doesn't change this so will do near/far clipping and the only way to switch this off is to disable GL_DEPTH_TEST. It would seem that Paul and Gordon have confused the clipping and culling a little. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setLODScale affecting near far planes?
FYI, Roland is correct, the OSG just does culling on sides of the frustum by default. OpenGL does no culling, is just does near and far *clipping*. The OSG of course doesn't change this so will do near/far clipping and the only way to switch this off is to disable GL_DEPTH_TEST. Even that won't work; DEPTH_TEST is a fragment op, and clipping against the clip planes is done before rasterization. It would seem that Paul and Gordon have confused the clipping and culling a little. Yes, I thought the original poster was talking about enabling OpenGL near/far clipping (probably because I have seen so many newbies ask how to disable this in the OpenGL forums and newsgroups). Clearly, the original poster said culling... My mistake, and thanks to all for the clarification. Back to the original issue: So, you see this problem when you enable OSG culling for near/far. What happens if you leave this disabled (as osgviewer does)? -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shared VertexBufferObject question
I did some reading about VBOs on the NVidia developer site and it turns
out that the glBindBuffer() call is not the one that I should worry
about. The white paper I read said that limiting the number of calls to
glVertexPointer() was the proper way to optimize the use of VBOs.
So I noticed that there was some commented out code in include/State
that appeared to be for the purpose of preventing redundant calls to
glVertexPointer() - see below:
inline void setVertexPointer( GLint size, GLenum type,
GLsizei stride, const GLvoid *ptr
)
{
(only showing relevant parts of code)
//if (_vertexArray._pointer!=ptr || _vertexArray._dirty)
{
_vertexArray._pointer=ptr;
glVertexPointer( size, type, stride, ptr );
}
_vertexArray._dirty = false;
}
Seems like if the commented out IF statement was not commented out then
I could have multiple Geometry nodes share a vertex buffer object and a
vertex array and only require one call to glVertexPointer(). Wouldn't
that be more efficient?
Alex
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Saturday, September 20, 2008 1:56 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] shared VertexBufferObject question
Hi Alex,
The unbind is done to prevent state leakage. One could potentially
using lazy state updating on VBO state by placing more controls into
osg::State, but this would require all Drawables to be careful about
what they assume is current state. It's possible but it's quite a bit
of work.
Robert.
On Sat, Sep 20, 2008 at 12:42 AM, Pecoraro, Alexander N
[EMAIL PROTECTED] wrote:
I want to create a VertexBufferObject that is shared by several
Geometry
nodes so that the number of calls to glBindBuffer() are decreased, but
I
noticed that on lines 1561 - 1567 of Geometry.cpp there is some code
that
automatically unbinds the vertex buffer object effectively forcing
each
Geometry node to rebind the VBO each time. Why does it do this? Isn't
this
preventing a shared VBO from being used in the most efficient way
possible?
Thanks.
Alex
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Spatial View SVI autosteroscopic display support.
Hi Chris. I spent quite some time on doing just what you are planning to do - getting an OpenSceneGraph-application to work with a Spatial View display. In the end I was successful. I don't know at the moment if I can provide you with any code but of course I can tell you how I am doing it. I have no idea if this is the best way but it works quite well. I use 5 RTT-cameras to save the five views in textures that later become input for the interlacer. You can position these 5 cameras using the SVI camera API or calculate the view and projection matrixes yourself. You then let the SVI interlacer render the result from the 5 textures. Everytime the master camera (the main osg camera) changes you also have to recalculate the matrixes of your slave cameras. The important part is that you take care on when you do call the API functions. You have to do this in a part of your program where the OpenGL context was set accordingly by OSG. You can use a PostRender-CameraCallback for this. See the osgteapot-example for some code on how to do this. Good luck. Schon gehört? Bei WEB.DE gibt' s viele kostenlose Spiele: http://games.entertainment.web.de/de/entertainment/games/free/index.html ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] strange ShadowMap behavior
I am seeing strange shadow artifacts on my model when I use a ShadowMap. The artifacts get worse as I increase the size of my ground plane. You can see the artifacts get progressively worse in these images: http://www.benaxelrod.com/temp/3x3.png http://www.benaxelrod.com/temp/5x5.png http://www.benaxelrod.com/temp/7x7.png http://www.benaxelrod.com/temp/10x10.png - this is the desired size of ground plane http://www.benaxelrod.com/temp/12x12.png You can see strange gradients on the humanoid's hands and feet. And the shadow gets more and more pixilated. I am using OSG 2.6 on Debian Etch with a NVidia 7300 LE graphics card. This is how I configure the ShadowMap: shadowmap-setTextureSize(osg::Vec2s(1024, 1024)); shadowmap-setPolygonOffset(osg::Vec2(1.1f, 4.0f)); Do I need to tune these parameters? If so, how? Are there more parameters I need? And what do these parameters control exactly? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] strange ShadowMap behavior
Hello Ben, I am seeing strange shadow artifacts on my model when I use a ShadowMap. These are not strange, they're quite expected when using a straight shadow mapping algorithm. It's simply shadow map aliasing. See this page: http://www.openscenegraph.org/projects/osg/wiki/Support/ProgrammingGuide/osgShadow for some details. In a nutshell, since osgShadow::ShadowMap uses the whole scene bounds and fits that to the shadow map texture, as your scene becomes bigger your shadows will become more and more pixelated, and will match the geometry less. Classic workarounds are: * increasing the shadow texture resolution (most cards today can render to 2048x2048 or 4096x4096 without too much trouble) but this is limited as even with the highest resolution your card supports, you can make a terrain that will make shadows very pixelated... * marking your terrain so that it does not cast shadows, which means that it won't be used in the shadow texture, and so the bounding volume that the texture must fit will (probably) be smaller. This also breaks down if 1) you want your terrain to cast shadows (not a problem for a plane, but for mountains, you might want to see their shadow too) 2) you have other objects everywhere in your scene (and not in a very localized area) A new technique called Light-Space Perspective Shadow Maps (LiSPSM) will soon be integrated into OSG. This is a view-dependent shadow technique, so the shadow map texture will fit the intersection of the scene volume and the viewing volume, so you aren't wasting resolution in parts of the scene where you don't even see if there are shadows or not... This massively improves the situation, and will be a great tool for people who want to integrate shadows to their applications. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to apply shadows to a scene with differ ent shaders- Part 2
Thanks Wojtek, that was what I needed to hear. Currently I'm filtering the shadows (similar to the soft shadow shaders i imagine) by averaging 9 texture samples. This gives decent results but in the event that more precision is needed, storing a custom texture matrix in a uniform sounds good. Michael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] openGL extensions
I would like to detect if the user has the appropriate openGL extensions in order to do shadowing. However, when I do: glGetString(GL_VERSION) glGetString(GL_EXTENSIONS) They return null. How can I get a list of the available extensions? Is there an easy way to get this info from OSG? Also, how do I know which extensions I need for the different shadow techniques? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Opengl extensions
Yes these will work But you can only do OpenGL calls in a process that has a valid Opengl context in the case of OSG the is the draw thread We do ours in the first call to draw in a draw callback, Search the archives for more info if you require more in-depth answer __ Gordon Tomlinson mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] IM: mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.vis-sim.com/ www.vis-sim.com http://www.gordontomlinson.com/ www.gordontomlinson.com __ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Axelrod Sent: Monday, September 22, 2008 6:28 PM To: OpenSceneGraph Users Subject: [osg-users] openGL extensions I would like to detect if the user has the appropriate openGL extensions in order to do shadowing. However, when I do: glGetString(GL_VERSION) glGetString(GL_EXTENSIONS) They return null. How can I get a list of the available extensions? Is there an easy way to get this info from OSG? Also, how do I know which extensions I need for the different shadow techniques? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] openGL extensions
Hi Ben, I would like to detect if the user has the appropriate openGL extensions in order to do shadowing. However, when I do: glGetString(GL_VERSION) glGetString(GL_EXTENSIONS) They return null. How can I get a list of the available extensions? Is there an easy way to get this info from OSG? For the first part of your question, they return NULL if they were called from a thread that does not have a graphics context. The safest way to do this is to create a camera predraw/postdraw/finaldraw callback or a node cull callback or a drawable draw callback. In each of these points you will have a graphics context. What I generally do is assume support is present and start the viewer with a detection callback attached (camera predraw callback on the main camera) which will check extensions and then remove itself from the camera. Then after the first frame, if I see that some feature is not supported, I disable the relevant options. There are other valid strategies of course. As for detecting actual extensions, instead of calling glGetString(GL_EXTENSIONS) and parsing it yourself, you can use #include osg/GLExtensions #include osg/GL2Extensions osg::isGLExtensionSupported(contextID, extensionName) Also, how do I know which extensions I need for the different shadow techniques? I'm personally not sure which extensions are required for all of them, perhaps someone else will know (it might be good to add that info to the osgShadow page on the wiki). I can tell you what I test for in the case of osgShadow::ShadowMap: _shadowsSupported = osg::isGLExtensionSupported(contextID, GL_EXT_framebuffer_object) (osg::isGLExtensionSupported(contextID, GL_ARB_fragment_program) || osg::isGLExtensionSupported(contextID, GL_EXT_fragment_program)) (osg::isGLExtensionSupported(contextID, GL_ARB_fragment_program_shadow) || osg::isGLExtensionSupported(contextID, GL_EXT_fragment_program_shadow)); Not sure if that's totally correct, but in most cases where shadow maps were not supported (they fell back to software and so were extremely slow) it was the first (GL_EXT_framebuffer_object) which was not supported. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ImageStream current frame
thanks for the clarification about ImageStream Robert.
If I understand right ImageStream buffers the frames in a PixelBufferObject
and switches the frames in the compileBuffer() function. So if I could get
feedback from this function then I could determine the frame count. Possibly
the _compiledList[contextID] variable might help with this.
Am I on the right track? Can you offer any advice?
Richard
Hi *Richard*,
These methods are virtual methods, and ImageStream is a base class...
that implementations subclass from, so the fact a header doesn't
implement something doesn't say anything about the actual
implementations that are meant to implement it.
Secondly the getReferenceTime() and TimeMultiplier are an time offset
and multiple, that is used by the ImageStream implementations to
compute the current time, and not the current time of the movie.
The actual time of the movie is something that would have to added to
ImageStream and its implementations, it should be possible to do this,
something like a getMovieTime().
Robert.
On Fri, Sep 19, 2008 at 6:52 AM, *Richard* Baron *Penman*
richardbp+...http://groups.google.com/groups/unlock?_done=/group/osg-users/browse_thread/thread/bde4593fbcf2f787/c30a4b7745126399%3Flnk%3Dgst%26q%3Drichard%2Bpenmanmsg=00cb577c06825440
@gmail.com wrote:
hello,
I would like to display what percentage of a video has been played. I'm
using the ImageStream class and I thought getReferenceTime() or
getTimeMultiplier() might help me, but they always return 0.
Examining the header file I found this:
72 virtual double getLength() const { return 0.0; }
73
74 virtual void setReferenceTime(double) {}
75 virtual double getReferenceTime() const { return 0.0; }
76
77 virtual void setTimeMultiplier(double) {}
78 virtual double getTimeMultiplier() const { return 0.0; }
So it seems this functionality is not ready yet. Does anyone have an
alternative way to determine the current playing video frame?
regards,
*Richard*
___
osg-users mailing list
osg-us...http://groups.google.com/groups/unlock?_done=/group/osg-users/browse_thread/thread/bde4593fbcf2f787/c30a4b7745126399%3Flnk%3Dgst%26q%3Drichard%2Bpenmanmsg=00cb577c06825440
@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph...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
