Re: [osg-users] OSG Collada plugin
Hi Jean-Sebastien, thank you for your response. It is possible that I am missing something, but it seems that every library is in debug mode. I have checked with Dependency Walker the libs and I have all the debug dependencies in the folder. I have exported one single cube with Blender, just to check that there are no problems with textures and the same problem is happening. If I try to run the application from command line instead of from Visual Studio, this is the error that I find: HEAP CORRUPTION DETECTED: after Normal block (#37612) at 0x0047CF58. CRT detected that the application wrote to memory after end of heap buffer. And I have seen that the messages in the command line goes a bit further than in VS: ReaderWriterDAE( OSG/box.dae ) URI loaded: OSG/box.dae Adding parent0039C498 Adding parent0039C498 Maybe those lines can be helpful to see where the problem is... Héctor -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: martes, 23 de agosto de 2011 15:35 To: OpenSceneGraph Users Subject: Re: [osg-users] OSG Collada plugin Hi Héctor, I am having some problems to load collada files into my project. I have used the collada dom lib (libcollada14dom21) to build the plugin. The line that is throwing the breakpoint is: osg::ref_ptrosg::Node model = osgDB::readNodeFile(modelFilePath); This line will be loading the collada plugin, as well as the collada DOM DLLs and others the plugin depends on. So if that line is making your app crash, I would suspect the common gotcha about linking debug and release together (or in general, different runtimes). So check your compile settings and make sure all your libs and DLLs (even the collada ones and its dependencies) are differentiated between debug and release, and that they all match in the linker settings. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.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] [osgPlugins] could not find plugin to read objects from file
Hi, I cant seem to load png image when running OSG on iOS. Im using osg version from github-stmh-osg. (somehow I cant post url). The error message on Xcode console was: Warning: Could not find plugin to read objects from file grid.png Please kindly advice. Thank you! Cheers, William -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42209#42209 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] could not find plugin to read objects from file
Ah pardon me. I managed to answer my own question (I was about to give up before realizing this),.. I forgot that I commented out USE_OSGPLUGIN(imageio) in osgPlugins.h, and also, forgot to link ImageIO.framework to the target.. Cheers, William -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42210#42210 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Uniform array naming problem
Hi Robert, I encountered the same problem (Win7 64 Bit, nVidia current driver 280.26), while it does not occur on older versions (like 266.58). The solution of McKay Davis (http://forum.openscenegraph.org/viewtopic.php?t=1828) works around this. Code: // Strip [0] from uniform array name to work around driver bugs const int len = strlen(name); if (len = 3 name[len-1] == ']') name[len-3] = 0; Apparently uniform arrays are not used so widely, hence there are just few complaints about this. Anyway, I would support McKay and Glenn. I understand your reluctance to support particular platforms / drivers, but in this case the fix would be still according to the standard to query the location of the array without brackets. So no need to change it back for future drivers, as far as I can see. Thank you! Cheers, Tassilo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42211#42211 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Is the Z-Buffer linear or non-linear?
Hello,
I am completely confused about the Z-Buffer. I thought it is non-linear but now
I read a lot in forums and now I am not sure about that. The reason about this
question is I want render linear depth values into a texture. I think, I can do
it with this shader:
varying float depth;
uniform float near;
uniform float far;
void main(void)
{
vec4 viewPos = gl_ModelViewMatrix * gl_Vertex;
depth = (-viewPos.z-near)/(far-near);
gl_Position = ftransform();
};
varying float depth;
void main(void)
{
gl_FragDepth = depth;
}
But the poor think is all other shader will be overwritten.
Now I use this:
_rendertarget-setInternalFormat(GL_DEPTH_COMPONENT);
_cam-setClearMask(GL_DEPTH_BUFFER_BIT);
_cam-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
_cam-attach(osg::Camera::DEPTH_BUFFER, _rendertarget);
_cam-setRenderOrder(::osg::Camera::PRE_RENDER, 0);
But this is nonlinear, isn't it?
I hope someone can help me about this.
Thanke you very much.
Martin
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
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
Hi Jeremy, To clarify, I used a couple of trivial shaders instead of the missing ones and in order to get any output I had to add the vertices. If I set GRID_POSITION=0 the additional call is not required. This is covered in the glVertexAttrib man page. I am using osg with the fixed pipeline available. Cheers, Tony -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42213#42213 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG VRML plugin
Hi Keith, thank you for your response. I am trying to compile the version of OpenVRML that you say (0.17.12), but I am still having some problems to compile it. I get some errors, for example: 1c:\projects\openvrml-0.17.12\src\libopenvrml\openvrml\node.h(198): error C2668: 'boost::bind' : ambiguous call to overloaded function 1 c:\program files (x86)\boost\boost_1_46_1\boost\bind\bind.hpp(1480): could be 'boost::_bi::bind_tR,F,L boost::bindopenvrml::node_interface_matches_field,boost::argI,std::string (F,A1,A2)' 1 with 1 [ 1 R=boost::_bi::unspecified, 1 F=openvrml::node_interface_matches_field, 1 L=boost::_bi::list2boost::arg1,boost::_bi::valuestd::string, 1 I=1, 1 A1=boost::arg1, 1 A2=std::string 1 ] 1 c:\program files (x86)\microsoft visual studio 10.0\vc\include\xxbind1(334): or 'std::tr1::_Bind_fty_Fty,_Ret,_BindN std::tr1::bindopenvrml::node_interface_matches_field,boost::argI,std::str ing(_Fty,_Arg0,_Arg1)' [found using argument-dependent lookup] 1 with 1 [ 1 _Fty=openvrml::node_interface_matches_field, 1 _Ret=std::tr1::_Notforced, 1 _BindN=std::tr1::_Bind2std::tr1::_Callable_objopenvrml::node_interface_mat ches_field,false,boost::arg1,std::string, 1 I=1, 1 _Arg0=boost::arg1, 1 _Arg1=std::string 1 ] 1 while trying to match the argument list '(openvrml::node_interface_matches_field, boost::argI, const std::string)' 1 with 1 [ 1 I=1 1 ] If I change the code in node.h bind(node_interface_matches_field(), _1, id)); for: boost::bind(node_interface_matches_field(), _1, id)); then I get several errors of this kind: 1c:\projects\openvrml-0.17.12\src\libopenvrml\openvrml\node_impl_util.h(449 ): error C2899: typename cannot be used outside a template declaration Do you know how to solve those problems? I have found your instructions but I cannot follow them without openvrml library. Cheers Héctor -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Keith Parkins Sent: martes, 23 de agosto de 2011 16:44 To: OpenSceneGraph Users Subject: Re: [osg-users] OSG VRML plugin Hi Héctor, The Readme file in the src folder for the vrml plugin states that it requires a minimum of OpenVRML 0.17.12 and Boost 1.38. I built the plugin with OpenVRML 0.17.12 and Boost 1.46.1. If you look through the list archives, you will find a post of mine from last spring that explains how to modify the CmakeLists.txt file in order to enable compilation on a Windows platform. You just need to remove the references to the antlr and regex libraries as they are obsolete in openvrml after ~0.17. You also need to define a macro when you are compiling a program with the new openvrml library stating how you are going to link (see openvrml-config.h for details). You will choose either -DOPENVRML_USE_DLL or -DOPENVRML_USE_LIB depending on whether you are linking with the dynamic or static library. Hopefully that'll be all you need to do to get it to build. I haven't tried the 0.18.x libraries, so your problem may be just a problem with a change of the API between 0.17 and 0.18. -K On Tue, 23 Aug 2011, Héctor Martínez wrote: I have forgotten to mention that as that was an old version of openvrml, I have tried with the 0.18.8 version of openvrml, but it seems to have changed a lot and I am not able to compile it. It seems to be a problem with the boost library (I am using the 1.46.1 version of boost). Does anybody know which versions of openvrml and boost I need for OSG 3.0.0? Héctor From: Héctor Martínez [mailto:hector.marti...@sensetrix.com] Sent: martes, 23 de agosto de 2011 12:25 To: osg-users@lists.openscenegraph.org Subject: OSG VRML plugin Hello everyone, I am trying to compile VMRL plugin for OSG, but I am not succeeding at all. I have followed those instructions: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpeci fics/V isualStudio/VisualStudioPlugins http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecif ics/Vi sualStudio/VisualStudioPlugins and I was able to compile openvrml, so now I have the antlr.lib, openvrml.lib and the regex.lib files. I have configured cmake to build the VRML plugin and everything OK. When I load the OSG solution in Visual Studio, I am able to compile everything but the VRML plugin. This is the output I get: 2ClCompile: 2 IndexedFaceSet.cpp 2..\..\..\..\src\osgPlugins\vrml\IndexedFaceSet.cpp(23): error C2064: 2term does not evaluate to a function taking 0 arguments 2..\..\..\..\src\osgPlugins\vrml\IndexedFaceSet.cpp(23): error C2228: 2left of '.id' must have class/struct/union 2..\..\..\..\src\osgPlugins\vrml\IndexedFaceSet.cpp(25): error
Re: [osg-users] osgAndroidExampleGLES1 crashed
hi jorge, i am sorry if i am asking very basic question. I don't know how and where to use these macros. i am not able to load .tff, .png file also on device. one thing i understood from your pervious mail that i need to use these macros. The macro are: *USE_OSGPLUGIN*(name_plugin) *USE_DOTOSGWRAPPER_LIBRARY*(name_deprecated) *USE_SERIALIZER_WRAPPER_LIBRARY*(name_serializer) I can see that in /usr/local/obj/local/armeabi all the libraries i.e libjpeg.a etc are there, but how to ;load it at which part of my application i have to use these macros? sorry if my question is too basic; Please help, Anurag i build plugins made these changes in cmake(through cmake-gui); few entries of my CMakeCache.txt are shown below. //Path to a file. CURL_DIR:PATH=/home/anurag/Complete-build/OpenSceneGraph-3.0.0/3rdparty/curl/ //Path to a file. CURL_INCLUDE_DIR:PATH=/usr/include //on if curl is a static lib CURL_IS_STATIC:BOOL=ON //Path to a library. CURL_LIBRARY:FILEPATH=/usr/lib/libcurl.so //Path to a file. FREETYPE_DIR:PATH=/home/anurag/Complete-build/OpenSceneGraph-3.0.0/3rdparty/freetype/ //Path to a file. FREETYPE_INCLUDE_DIR_freetype2:PATH=/usr/include/freetype2 //Path to a file. FREETYPE_INCLUDE_DIR_ft2build:PATH=/usr/include //Path to a library. FREETYPE_LIBRARY:FILEPATH=/usr/lib/libfreetype.so //Path to a file. GDAL_DIR:PATH=/home/anurag/Complete-build/OpenSceneGraph-3.0.0/3rdparty/gdal/ //Path to a file. GDAL_INCLUDE_DIR:PATH=/usr/include/gdal //Path to a library. GDAL_LIBRARY:FILEPATH=/usr/lib/libgdal1.6.0.so //Path to a file. GIFLIB_INCLUDE_DIR:PATH=/usr/include //Path to a library. GIFLIB_LIBRARY:FILEPATH=/usr/lib/libgif.so //Path to a file. JPEG_INCLUDE_DIR:PATH=/usr/include //Path to a library. JPEG_LIBRARY:FILEPATH=/usr/lib/libjpeg.so //Value Computed by CMake OSG_PLUGINS_MASTER_BINARY_DIR:STATIC=/home/anurag/Complete-build/OpenSceneGraph-3.0.0/build-source/src/osgPlugins //Value Computed by CMake OSG_PLUGINS_MASTER_SOURCE_DIR:STATIC=/home/anurag/Complete-build/OpenSceneGraph-3.0.0/src/osgPlugins //Set to ON to have OpenSceneGraph search the configured install // directory for plugins. OSG_PLUGIN_SEARCH_INSTALL_DIR_FOR_PLUGINS:BOOL=ON //Path to a file. PNG_INCLUDE_DIR:PATH=/home/anurag/Complete-build/OpenSceneGraph-3.0.0/3rdparty/libpng/ //Path to a library. PNG_LIBRARY:FILEPATH=/usr/lib/libpng.so //Path to a file. PNG_PNG_INCLUDE_DIR:PATH=/usr/include //Path to a file. TIFF_INCLUDE_DIR:PATH=/usr/include //Path to a library. TIFF_LIBRARY:FILEPATH=/usr/lib/libtiff.so ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAndroidExampleGLES1 crashed
Wow xD why did you redefine all that stuff? Just execute a regular build of OSG and latter an installation an it will copy al the files and libraries to the installation directory! xD It's defined to use the libraries if he founds them at that point. Now about using on your final build *USE_OSGPLUGIN*(name) if you look the osdb_plugins you'll see that they all have the same name except for the latest part, that's the real name you have to use in the macro. BUT! that's not all, you also need to include the plugin and the library dependece in the Android.mk of your program.following the dependance (first library second plugin that uses that library) My usual way of writting it's on the bottom of the list add the third party stuff and the first in the list the plugin. If you look well the -losg you'll figure out. Dependencies are from bottom to top And once more time I really DISAGREE with installing osg for Android in the usr directory, there's a -DINSTALL_PREFIX (or something like that) that can be used to define your destination directory. (I have two independant builds for example in $HOME/osgAndroidGLES1 and $HOME/osgAndroidGLES2) 2011/8/24 anurag mairal mairal2...@gmail.com question. I don't know how and where to use these macros. i am not able to load .tff, .png file also on device. one thing i understood from your pervious mail that i need to use these macros. The macro are: *USE_OSGPLUGIN*(name_plugin) *USE_DOTOSGWRAPPER_LIBRARY*(n ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is the Z-Buffer linear or non-linear?
Hello,
I think I got it. Correct me if I am wrong, if I use an orthogonal projection I
get linear Z-Buffer values. If I use a perspective projection I get non-linear
values.
The Z-Buffer value (z') of a perspective projection is:
z' = (far + near) / (far - near) + 1/z ((-2 * far * near)/(far-near))
The Z-Buffer value (z') of a orthogonal projection is:
z' = 2 * ((z-near)/(far-near))-1
So, I use a orthogonal projection therefore I get a linear Z-Buffer.
I hope that is right.
Cheers
Martin
Original-Nachricht
Datum: Wed, 24 Aug 2011 10:01:23 +0200
Von: Martin Großer grosser.mar...@gmx.de
An: osg-users@lists.openscenegraph.org
Betreff: [osg-users] Is the Z-Buffer linear or non-linear?
Hello,
I am completely confused about the Z-Buffer. I thought it is non-linear
but now I read a lot in forums and now I am not sure about that. The reason
about this question is I want render linear depth values into a texture. I
think, I can do it with this shader:
varying float depth;
uniform float near;
uniform float far;
void main(void)
{
vec4 viewPos = gl_ModelViewMatrix * gl_Vertex;
depth = (-viewPos.z-near)/(far-near);
gl_Position = ftransform();
};
varying float depth;
void main(void)
{
gl_FragDepth = depth;
}
But the poor think is all other shader will be overwritten.
Now I use this:
_rendertarget-setInternalFormat(GL_DEPTH_COMPONENT);
_cam-setClearMask(GL_DEPTH_BUFFER_BIT);
_cam-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
_cam-attach(osg::Camera::DEPTH_BUFFER, _rendertarget);
_cam-setRenderOrder(::osg::Camera::PRE_RENDER, 0);
But this is nonlinear, isn't it?
I hope someone can help me about this.
Thanke you very much.
Martin
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.8.3 3.0.1 view dependent shadow clippingplane
Hi All, I now have enough of the new ViewDependentShadowMap technique implemented for members of the community to start testing it out on their own data. From the testing I've done so far it looks to be signifcantly faster and produces more consistently high quality results than any of the other techniques we have had so far. The algorithm isn't based on any one paper, but one could say it in similar to perspective/light space perspective shadow maps but I abdoned the maths behind these approaches as I just couldn't get them to work reliably enough over a wide range of data. The new technique isn't finished yet, it's certainly far enough along for others to start testing and to report back results. The new technique isn't compatible with depth partitioning yet, and while it does handle spot lights it do so avoiding tackling the perspective transform in light space. My hope with the shdow implementation is that it'll be robust and flexible enough to replace all the old shadow techniques. The new techhnique also lays down the framework for future support of mltiple shadow maps such as with cascaded or parallel split shadow maps, as well handling multiple lights+shadows. If we can get it working robust enough I'll removal all the old techniques and enable us to have a lighter weight osgShadow library. All the changes are now checked into svn/trunk. To test use the --vdsm option in osgshadow, or use the new osgShadow::ViewDepedentShadowMap technique class in place of your existing shadow technique used in your application. Please let me know how you get on. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is the Z-Buffer linear or non-linear?
Hi
The z-buffer is not linear ( in my experience) its weighted to give higher
resolution closer to the near clip plane
See
http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
Gordon Tomlinson
3D Technical Product Manager
Overwatch®
An Operating Unit of Textron Systems
__
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martin Großer
Sent: Wednesday, August 24, 2011 7:58 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Is the Z-Buffer linear or non-linear?
Hello,
I think I got it. Correct me if I am wrong, if I use an orthogonal projection I
get linear Z-Buffer values. If I use a perspective projection I get non-linear
values.
The Z-Buffer value (z') of a perspective projection is:
z' = (far + near) / (far - near) + 1/z ((-2 * far * near)/(far-near))
The Z-Buffer value (z') of a orthogonal projection is:
z' = 2 * ((z-near)/(far-near))-1
So, I use a orthogonal projection therefore I get a linear Z-Buffer.
I hope that is right.
Cheers
Martin
Original-Nachricht
Datum: Wed, 24 Aug 2011 10:01:23 +0200
Von: Martin Großer grosser.mar...@gmx.de
An: osg-users@lists.openscenegraph.org
Betreff: [osg-users] Is the Z-Buffer linear or non-linear?
Hello,
I am completely confused about the Z-Buffer. I thought it is non-linear
but now I read a lot in forums and now I am not sure about that. The reason
about this question is I want render linear depth values into a texture. I
think, I can do it with this shader:
varying float depth;
uniform float near;
uniform float far;
void main(void)
{
vec4 viewPos = gl_ModelViewMatrix * gl_Vertex;
depth = (-viewPos.z-near)/(far-near);
gl_Position = ftransform();
};
varying float depth;
void main(void)
{
gl_FragDepth = depth;
}
But the poor think is all other shader will be overwritten.
Now I use this:
_rendertarget-setInternalFormat(GL_DEPTH_COMPONENT);
_cam-setClearMask(GL_DEPTH_BUFFER_BIT);
_cam-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
_cam-attach(osg::Camera::DEPTH_BUFFER, _rendertarget);
_cam-setRenderOrder(::osg::Camera::PRE_RENDER, 0);
But this is nonlinear, isn't it?
I hope someone can help me about this.
Thanke you very much.
Martin
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
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 2.8.3 3.0.1 view dependent shadowclippingplane
Hi, Great news ! Will this new technique handle multitexturing ? That was one of the problems in older osgShadow techniques: the shadow shaders used void setBaseTextureUnit( unsigned int unit ) with a single texture unit and then void searchAndReplaceShaderSource was rewriting over the base shader. In particular, using osgShadows in conjunction with osgEarth was a nightmare Luc De : Robert Osfield robert.osfi...@gmail.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 08/24/2011 04:17 PM Objet : Re: [osg-users] OSG 2.8.3 3.0.1 view dependent shadow clippingplane Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi All, I now have enough of the new ViewDependentShadowMap technique implemented for members of the community to start testing it out on their own data. From the testing I've done so far it looks to be signifcantly faster and produces more consistently high quality results than any of the other techniques we have had so far. The algorithm isn't based on any one paper, but one could say it in similar to perspective/light space perspective shadow maps but I abdoned the maths behind these approaches as I just couldn't get them to work reliably enough over a wide range of data. The new technique isn't finished yet, it's certainly far enough along for others to start testing and to report back results. The new technique isn't compatible with depth partitioning yet, and while it does handle spot lights it do so avoiding tackling the perspective transform in light space. My hope with the shdow implementation is that it'll be robust and flexible enough to replace all the old shadow techniques. The new techhnique also lays down the framework for future support of mltiple shadow maps such as with cascaded or parallel split shadow maps, as well handling multiple lights+shadows. If we can get it working robust enough I'll removal all the old techniques and enable us to have a lighter weight osgShadow library. All the changes are now checked into svn/trunk. To test use the --vdsm option in osgshadow, or use the new osgShadow::ViewDepedentShadowMap technique class in place of your existing shadow technique used in your application. Please let me know how you get on. 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] [vpb] vector layer made by osgGIS take too much cpu usage
Hi, ... Here is the vector model ,25mb， nothing special。please just osgviewer it. I am a little supraise no one had this problem before,I think it's common for a globle world GIS system. Thank you! Cheers, Lv -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42221#42221 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.8.3 3.0.1 view dependent shadowclippingplane
Hi Luc, On Wed, Aug 24, 2011 at 3:30 PM, Luc Frauciel luc.frauc...@star-apic.comwrote: Will this new technique handle multitexturing ? That was one of the problems in older osgShadow techniques: the shadow shaders used void setBaseTextureUnit( unsigned intunit ) with a single texture unit and then voidsearchAndReplaceShaderSource was rewriting over the base shader. In particular, using osgShadows in conjunction with osgEarth was a nightmare The current implementation is hardwired to place the shadow maps on texture unit 1. I will be making to user definable. I'll use a uniform is used to specify the texture unit is being used rather than using the searchAndReplaceShaderSource approach by some of the previous shadow techniques. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Acquiring the world matrix of a DoF node
Greetings, everyone. I figured out what I was doing wrong, and I thought I would post my answer here for posterity. The short answer is: everything is working the way it is supposed to. Nothing to see here. Move along. =) Long answer: The PUT matrix is essentially the inverse of the DoF node's origin. The descendant geometry is not defined relative to the DoF's origin, as is the case with other types of transforms. Instead, the PUT matrix will transform all descendant geometry such that it becomes relative to the DoF's origin. For example. If you have a DoF whose origin is at 0,0,10 (lets leave rotations out of this, for simplicity sake), and you have a geode with a single vertex that is one meter above it (z=up in this example), you may expect (as with other transforms) that the DoF would have a position of 0,0,10 and the vertex would have a position of 0,0,1. However, this is not how it works. Instead, the DoF has a PUT matrix of 0,0,-10 and the vert has a position of 0,0,11. If you transform this vert by the PUT matrix, it becomes 0,0,1 (its DoF-relative position!). At this point, you can apply the DoF position/rotation offsets (if any). Then, you need to transform it back, using the inverse PUT matrix. So let's say that the DoF in our example has a 45degree y-rotation. Here's what happens. The PUT matrix transforms out vert to 0,0,1. Then, we apply the 45-degree rotation, making it 0.7071, 0, 0.7071. Then, the inverse matrix is applied, making the final position 0.7071, 0, 10.7071. Voila. So, the final matrix of a DoF transform is: PUTMatrix * rotationPositionOffsetsMatrix * InvPUTMatrix ...which is exactly what DoFTranform::localToWorld does (which is called by Node::getWorldTransforms). So, naturally, if there are no rotation or position offsets in the DoF (i.e., they are all 0), then the final matrix is going to be identity. But that's okay, because your geometry is not defined relative to the DoF's origin (i.e. its inverse PUT). If you have a chain of DoFs, the final matrix of each (as calculated above) can be concatenated just like any other matrix, and the math works out (I had to see this for myself on the whiteboard before I believed it ... tough to visualize). So, again, long-story-short, it will all work out if you just let it do its thing. If you question it too much, you'll end up on a long journey to reinvent the wheel, as I did. =) Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42223#42223 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is the Z-Buffer linear or non-linear?
The transform below for the orthogonal projection is indeed linear, mapping
[n,f] to [-1,1] in linear fashion.
If you want to linearize depth with a perspective projection (i.e. survive the
perspective divide between the vertex and fragment shader), here's a way to do
that. The example uses HLSL but it gets the point across...
http://www.mvps.org/directx/articles/linear_z/linearz.htm
Another interesting discussion related to linear depth using W-buffers can be
found at
http://www.mvps.org/directx/articles/using_w-buffers.htm
Just make sure you have support for W buffers...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martin Großer
Sent: Wednesday, August 24, 2011 5:58 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Is the Z-Buffer linear or non-linear?
Hello,
I think I got it. Correct me if I am wrong, if I use an orthogonal projection I
get linear Z-Buffer values. If I use a perspective projection I get non-linear
values.
The Z-Buffer value (z') of a perspective projection is:
z' = (far + near) / (far - near) + 1/z ((-2 * far * near)/(far-near))
The Z-Buffer value (z') of a orthogonal projection is:
z' = 2 * ((z-near)/(far-near))-1
So, I use a orthogonal projection therefore I get a linear Z-Buffer.
I hope that is right.
Cheers
Martin
Original-Nachricht
Datum: Wed, 24 Aug 2011 10:01:23 +0200
Von: Martin Großer grosser.mar...@gmx.de
An: osg-users@lists.openscenegraph.org
Betreff: [osg-users] Is the Z-Buffer linear or non-linear?
Hello,
I am completely confused about the Z-Buffer. I thought it is non-linear
but now I read a lot in forums and now I am not sure about that. The reason
about this question is I want render linear depth values into a texture. I
think, I can do it with this shader:
varying float depth;
uniform float near;
uniform float far;
void main(void)
{
vec4 viewPos = gl_ModelViewMatrix * gl_Vertex;
depth = (-viewPos.z-near)/(far-near);
gl_Position = ftransform();
};
varying float depth;
void main(void)
{
gl_FragDepth = depth;
}
But the poor think is all other shader will be overwritten.
Now I use this:
_rendertarget-setInternalFormat(GL_DEPTH_COMPONENT);
_cam-setClearMask(GL_DEPTH_BUFFER_BIT);
_cam-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
_cam-attach(osg::Camera::DEPTH_BUFFER, _rendertarget);
_cam-setRenderOrder(::osg::Camera::PRE_RENDER, 0);
But this is nonlinear, isn't it?
I hope someone can help me about this.
Thanke you very much.
Martin
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
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] [osgOcean] Syncronizing waves across multiple monitors
Heya, I know that I can initialize the water with the same random seed. However, there does not seem to be a way to synchronize the timing of the waves. Does anyone know if this is possible? If not, I have coded a solution. It's a bit of a hack, but I would be happy to clean it up and submit it as a possible future update. I would prefer to use the canonical source code, rather than my own version of it, and so if the feature doesn't exist, canonizing my changes would be the next best option. =) Hahaha. Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42225#42225 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: osgNVPR (NVidia Path Rendering)
Jeremy, Very cool to see this OpenSceneGraph support for NV_path_rendering. 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. - 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] Linking error : QT + OSG
Hi, I'm trying compile sgd with Qt in QtCreator. I have the following erros: error: undefined reference to `_imp___ZN9osgViewer6ViewerC1Ev' error: undefined reference to `_imp___ZN3osg5GroupC1Ev' Qt Version: Qt 4.7.3 for Desktop - MSV2008 (Qt SDK) Tool chain: Microsoft Visual C++ Compiler 9.0 (x86) OpenSceneGraph-3.0.0 Can anyone help me? Thank you! Cheers, Diego -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42204#42204 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.8.3 3.0.1 view dependent shadowclippingplane
Hi Luc, On Wed, Aug 24, 2011 at 4:03 PM, Robert Osfield robert.osfi...@gmail.com wrote: The current implementation is hardwired to place the shadow maps on texture unit 1. I will be making to user definable. I'll use a uniform is used to specify the texture unit is being used rather than using the searchAndReplaceShaderSource approach by some of the previous shadow techniques. I have now cheked in support for user defined setting of the shadow map texture unit via ViewDependentShadowMap::setBaseShadowTextureUnit(uint); The shader supplied by this technique doesn't implement any handling of multi-texturing itself so it'll be up to the user to provide their own shaders to do this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Drawing a simple sphere...
Hi,
I'm quite new to OSG, and I don't get why my (very (very)) simple code crashes :
[main.cpp]
#include osg/Shape
#include osg/ShapeDrawable
#include osg/Geode
#include osgViewer/Viewer
int main(int argc, char *argv[]) {
osg::Group* root = new osg::Group;
osg::Geode* geode = new osg::Geode();
geode-addDrawable(new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0.,0.,0.), 1.)));
root-addChild( geode );
osgViewer::Viewer viewer;
viewer.setSceneData( root );
viewer.realize();
while( !viewer.done() )
viewer.frame();
return 0;
}
I run :
g++ -c main.cpp
and then
g++ -o sphere main.o -losg -losgViewer
So far, everything goes well. Then, when I type :
./sphere
the app crashes without displaying any sphere, and yielding :
Bus error: 10
But when I want to display a .3ds mesh, it works perfectly well.
I am under Mac OS X Lion (10.7), and I compiled OSG myself.
What's wrong? ;(
Please help
Thank you
Yann___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.8.3 3.0.1 view dependent shadowclippingplane
Hi Robert, Luc, The shader supplied by this technique doesn't implement any handling of multi-texturing itself so it'll be up to the user to provide their own shaders to do this. As a side note Luc, nothing forced you to use the ShadowMap's own shaders and searchAndReplace... functionality. You could simply replace the shaders, define your own uniforms for sampler name - texture unit mapping, and do multi-texturing that way. That's what we did. No shader provided by a library can be 100% flexible and support all use cases (at least until shader composition is done). The shaders in the older shadow techniques were no exception, but luckily you could replace them. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Syncronizing waves across multiple monitors
Hi Frank, I know that I can initialize the water with the same random seed. However, there does not seem to be a way to synchronize the timing of the waves. Does anyone know if this is possible? If not, I have coded a solution. It's a bit of a hack, but I would be happy to clean it up and submit it as a possible future update. I have not had a look at your code, but what exactly is the problem you're trying to solve? I have not had any problems with synchronizing the waves across multiple monitors on a single machine (they are synchronized by default, since the update traversal will be run only once no matter how many cameras are rendering your scene). Where I have had to modify things in the past is to synchronize the waves across multiple machines. For this, there is the FFTOceanTechnique::OceanAnimationCallback, in which you can override the operator() method to query some application-specified simulation time (which is broadcast to all machines, so at the same time it will be the same value on all machines) and then call update() with that time value. That way, the wave animation will be at the same frame on all machines. If what you're doing solves a different problem, then I'll have a look when I come back from vacation... Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Syncronizing waves across multiple monitors
Hello, Yes, you are right. I neglected to mention that these monitors are hooked up to separate machines. =) Your suggestion is much cleaner than my solution, and has the added benefit of not having to be checked into the central repository. I will give that a try. Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42230#42230 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
