Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi Fred, sorry, I don't have time at the moment to check your code. I just remember from past experience and bug reports to NVidia that OSG does not reuse FBOs for new cameras, so it's quite possible one can run out with the video driver complaining/crashing. The limits were also different for Windows vs Linux. At the time Robert created osgmemorytest app to show the problem to NVidia. What does this do on your machine? osgmemorytest --fbo 1024x768 cheers jp On 18/05/11 09:59, Fred Smith wrote: Hi, Here is a repro of the slave camera problem (the original problem, not the bounding box stuff). Increase the number of testRTTCamera() iterations to see the problem better. It seems there is something wrong with respects to how GL objects are released, as the program is stuck after a large number of iterations. Cheers, Fred Attached file: modified osggeometry.cpp source code. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39493#39493 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. 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] how can I get the main camera's rotation angle relative to x, y, z axis
Hi: I am a beginner of OSG. I have a problem about how can I get the main camera's rotation relative to x,y,z axis. I can get the view matrix by osg::Matrix matrix = viewer-camera()-getViewMatrix(),after I get the view matrix,there is only one member function getRotate which returns the quat but not the rotation angle relative to x,y,z axis. Is there any way to get rotaton angle relative to x,y,z axis from quat? ms yang ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi J.P., I'll try running osgmemorytest, but I don't have the problem with OSG 2.9.10. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39526#39526 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performace issue with nVidia 400 series
dglenn wrote: Jason Daly wrote: On 05/18/2011 05:14 AM, Fred Smith wrote: Hi, The only problem that I personally heard about is about the slow transfer speed to/from GPU memory on Fermi cards. DMA transfers are said to be slower than on GTX 2xx hardware. I haven't seen anything related to computing. I think it's specifically GPU-host memory transfers that are slow. The other direction is OK, as is the computation speed. The thread on the OpenGL forums has the details, and someone posted a small program that does timing tests and illustrates the issue pretty well. http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflatNumber=284065page=1 --J I looked at the link you gave and downloaded the program that was the (the 4th revision of it) and tried on my GTX 460 and an old 8800 GT and compared it to the results that was posted and something does not add up with the test program! Most people there compare GTX2xx hardware and Fermi hardware. You are comparing G80 and Fermi hardware. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39527#39527 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
OK, missed that it's a recent regression. jp On 19/05/11 09:26, Fred Smith wrote: Hi J.P., I'll try running osgmemorytest, but I don't have the problem with OSG 2.9.10. Cheers, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39526#39526 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. 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] osgexport for blender?
ok , keep us updated -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39529#39529 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Farshid,
I gave it a try, the description lines are there. I just see a minor issue: you
did not add the MaterialData.{h,cpp} to Cmake.
About the results, looks like what is there is fine! I'll do more testing in
the next days, trying to use the definitions in my shaders as well, and let you
know.
One more thing. it looks like you now have code to handle the normal maps also.
But I think there is still no way to know if you were using a bump or a normal
map for the Bump channel. While in Max there is a clear distinction (different
texture types there), the exporter does not distinguish them. Look at this
example:
# osgmaxexp material data
NameTestMat
Map Diffuse 0 1 images\\casaterr_02.tga
Map Specular Level 1 1 images\\testRefMap.tga
Map Bump2 0.5 images\\casaterr_01norm.tga
# osgmaxexp material data
NameTestMat2
Map Bump0 0.3 images\\casaterr_01norm.tga
The testMat2 is using the tx directly as a bitmap, while TestMap first has a
NormalMap texture, then the bitmap. In the output they look totally equivalent
though. Looking at the code, it seems that you treat them as separate cases:
so, what about adding an extra field at the end of TestMap to indicate it's a
normal map? The field could actually be even smarter and indicate the active
texture space (tangent, screen, ...).
Great work anyway, really thanks for this.
Luca
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39530#39530
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.9.10 on iOS
Hi, Am 19.05.11 06:52, schrieb Büsra Gülten: But the error target specifies product type 'com.apple.product-type.tool', but there´s no such product type for the 'iphonesimulator' platform. is still existing in my own Project in Xcode 3.2.6. Could you please look at my CMakeCache.txt in attached file? disable the building of examples via BUILD_OSG_EXAMPLES:BOOL=OFF HTH, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Earth using VPB
Hi, Who can tell me how to make a earth with terrain(DEM) and Satellite-Image using VPB as Google Earth？ Sorry for my poor English. Thank you ! Good Luck! Cheers GuiYe___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performace issue with nVidia 400 series
Hi, David, 4xx series slow specifically on readback from framebuffer\FBO to texture\PBO\host memory (in GL, dunno about cuda\opencl). That is what all people talking about. If you dont use this features much you will have no problems whatsoever. Cheers, Sergey. 19.05.2011, 03:27, David Glenn david.e.glenn@navy.mil: Jason Daly wrote: On 05/18/2011 05:14 AM, Fred Smith wrote: Hi, The only problem that I personally heard about is about the slow transfer speed to/from GPU memory on Fermi cards. DMA transfers are said to be slower than on GTX 2xx hardware. I haven't seen anything related to computing. I think it's specifically GPU-host memory transfers that are slow. The other direction is OK, as is the computation speed. The thread on the OpenGL forums has the details, and someone posted a small program that does timing tests and illustrates the issue pretty well. http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflatNumber=284065page=1 --J I looked at the link you gave and downloaded the program that was the (the 4th revision of it) and tried on my GTX 460 and an old 8800 GT and compared it to the results that was posted and something does not add up with the test program! Before I learned of all of this, I ran some other tests using a stress program and gDEBugger and found that the GTX 460 was much faster than 8800 GT (about 10 times faster under stress). I also tested it on most of my high end terrain and it ran much faster (about the biggest texture based thing I have) even though I don't have figures for it yet. I'm not saying that there is not a problem, but I'm a bit confused when one test I do contadicted by another and that the numbers for that other test and the conclusion seem spect to me! D Glenn D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39519#39519 ___ 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] Error in example?
Hi, John Error log looks like shader uses vertex texture fetch, and you should use texture2DLod instead of texture2D, because in vertex shader GPU doesn't know which mipmap to use. It has no way to compute the lambda factor. You need to choose the mipmap in the VS yourself. So either there are error in shader or fragment shader loads as vertex shader. At first try to change texture2D(... , ... ) to texture2DLod(..., ..., 0), that should solve problem. Cheers, Sergey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39534#39534 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] osg with QT how to?
Hi, thanks for the reply, I solved the problem. For all of you who struggle, here is how I did this: I downloaded the QTSDK, installed it in C:\ Set environment variables: QTDIR to C:\QtSDK\Desktop\Qt\4.7.3 QMAKESPEC to win32-g++ Since I wanted to work with Microsoft Visual Studio 2008 I added C:\QtSDK\Desktop\Qt\4.7.3\msvc2008\bin to the Path environment variable Updated Microsoft Visual Studio 2008 to SP1, downloaded this update from Microsoft (important, because without Visual Studio SP1 I got linker crashes when compiling osg) - I checked out OpenSceneGraph from the repository - Also checked out the OpenSceneGraph Data (on the website under downloads - SVN) Both into C:\Projects\ I also downloaded the 3rdParty_VC9sp1_x86_x64_V5.7z , just used the x82 Version and packed it all into C:\Projects\3rdParty (next to the OpenSceneGraph Repositories, and made sure the folders for x86 (like bin, include, lib were directly in the 3rdParty folder). Then I ran CMake over my C:\Projects\OpenSceneGraph and created the build folder C:\Projects\OpenSceneGraph\build. Made sure - that the CMake install Path was set to C:\Program_Files(x86)\OpenSceneGraph. - that CMake found the 3rdParty folder and many libraries (ofc. not all of them) - that I checked build OSG examples - that CMake found the QT executable and I checked build QT examples Then I hit generate. I set some environment variables: OSG_FILE_PATH to C:\Projekte\OpenSceneGraph-Data OSG_DIR to C:\Program Files (x86)\OpenSceneGraph added C:\Projekte\3rdParty\bin;C:\Program Files (x86)\OpenSceneGraph\bin to the Path environment variable I opened the .sln file in C:\OpenSceneGraph\build with Visual Studio. Set it to Debug and compiled it (ALL BUILD). The after around 20 min it was finished and i right clicked the INSTALL target and told Visual Studio to build that (which just copies the right files into my CMake install path (C:\Program_Files(x86)\OpenSceneGraph). Then I set Visual Studio to Release and did ALL BUILD again. After 20 min again, it was finished and again i did the INSTALL target. And oh my gosh I was finally done and now it works Thank you! Cheers, jin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39535#39535 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CPU usage - qt application
hybr wrote: Hi, Gianni Ambrosio It can be the case that in old drivers vsync were disabled, and in new ones its enabled by default. OK, it seems I got the point but I have some questions. Basically the monitor refresh rate is 60Hz but the timer to update the widget was 10 milliseconds (just like in the OSG example!). That means I was forcing a refresh of 100HZ, useless since my monitor is set to 60Hz. So I set the update timer to 17 milliseconds (~60Hz) and it works fine. Looking around the forum I realized, as suggested, that the problem is related to vsync. But if I understand correctly when vsync is enabled it should work without extra CPU usage even if the timer is set to 100Hz on a monitor with 60HZ. Is that correct? Moreover getSyncToVBlank() returns true so I guess the vsync is enabled. If that's correct I don't understand why sometimes the app gets a full cpu (without moving anything). Now a question about setSyncToVBlank(). If I call it I get a not implemented message. That's because GraphicsWindowQt inherits from GraphicsWindow. But why GraphicsWindowQt derives from GraphicsWindow? Both GraphicsWindowWin32 and GraphicsWindowX11 implements setSyncToVBlank(). Is there a way to have a GraphicsWindowQt and setSyncToVBlank() implemented? One more question about get/setSyncToVBlank(). If I get 'true' from the getter, does that mean the vsync is enabled in the gfx card driver or just an option of OSG? Thanks Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39536#39536 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VBO incosistencies between 2.8 and 2.912
Hi, I recently upgraded my code base to 2.912 (Linux, GTX 280) , unfortunately my GPU morphing code stopped working. I use VBO, GLSL and vertex attributes to copy the changing morph shapes and do the interpolation on the GPU. After searching for the problem I found that when I declared a geometry as VBO // Disable Display lists and setup Vertex Buffer Objects geom-setUseDisplayList (false); geom-setUseVertexBufferObjects(true); osg::VertexBufferObject* df = geom-getOrCreateVertexBufferObject(); df-setUsage (GL_STREAM_DRAW); the subsequent commands during the update which changed the vertexArray had no effect and produced random triangles on the screen. geom-setVertexArray(vcoords); Because of the many morph shapes, I have many vertex arrays preallocated and pass them to the geometry based on a time. I do not copy assign to the vertex array of the geometry for speed reasons. As I said in the 2.8 version everything worked fine. When change the code to issued a dirty on the vertex arrays vcoords-dirty() the shape morphed correctly but the color, normal, texcoord arrays (which do not morph) did not show up correctly. Has anyone any idea what changed between the 2.8-2.912 versions. I was under the impression that issuing a setVertexArray command calls dirty() at least on the geometry array. Is it therefore mandatory to issue a dirty() call for all arrays (color, normal, texcoords) assigned to the geometry? Please note then when I disable the VBO usage, a single dirty() call on the vertexarray works and the other arrays show up normal. Thank you in advance Dimi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO incosistencies between 2.8 and 2.912
Hi Dimi, The buffer object support in the OSG has been revamped and in theory should be robust and flexible... but like all code there is a chance for regressions so wide spread testing it neccessary. Whether in this instance there is an actual bug, or just a different behaviour I can't say as I haven't tested your code. As a quick test I would suggest calling dirty on each array your modiy. Robert. On Thu, May 19, 2011 at 1:37 PM, dimi christop dimi_chris...@yahoo.com wrote: Hi, I recently upgraded my code base to 2.912 (Linux, GTX 280) , unfortunately my GPU morphing code stopped working. I use VBO, GLSL and vertex attributes to copy the changing morph shapes and do the interpolation on the GPU. After searching for the problem I found that when I declared a geometry as VBO // Disable Display lists and setup Vertex Buffer Objects geom-setUseDisplayList (false); geom-setUseVertexBufferObjects(true); osg::VertexBufferObject* df = geom-getOrCreateVertexBufferObject(); df-setUsage (GL_STREAM_DRAW); the subsequent commands during the update which changed the vertexArray had no effect and produced random triangles on the screen. geom-setVertexArray(vcoords); Because of the many morph shapes, I have many vertex arrays preallocated and pass them to the geometry based on a time. I do not copy assign to the vertex array of the geometry for speed reasons. As I said in the 2.8 version everything worked fine. When change the code to issued a dirty on the vertex arrays vcoords-dirty() the shape morphed correctly but the color, normal, texcoord arrays (which do not morph) did not show up correctly. Has anyone any idea what changed between the 2.8-2.912 versions. I was under the impression that issuing a setVertexArray command calls dirty() at least on the geometry array. Is it therefore mandatory to issue a dirty() call for all arrays (color, normal, texcoords) assigned to the geometry? Please note then when I disable the VBO usage, a single dirty() call on the vertexarray works and the other arrays show up normal. Thank you in advance Dimi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi guys, Cool that this is done, I'll check it out soon and try reading the files back in our engine. Thanks a lot for your work! 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] [vpb] model placing using osgdem
Hi, I just tried to add 3d models to the terrain by adding -m modelname option. But Icouldn't see the object in the terrain. What exactly -m option will do. My object is also in the same coordinate. Why the option doesn't work. Thank you! Cheers, Vijeesh -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39542#39542 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO incosistencies between 2.8 and 2.912
Hi Robert, this is exactly what I did, I called dirty on the vertexArray which is passed each frame to the geometry using geom-setVertexArray(vcoords); vcoords-dirty(); The problem was that, it screws up all other attached geometry arrays like (colors, normals, texcoords) which do not change This behavior does not occur when the geometry is not specified as VBO or in 2.8. I can try to call dirty on all arrays whether they change or not, but it does not seem logical. I attach a small example which show the problem (along with the makefile). The example changes vertexArrays of a VBO geometry (a cube) at runtime using 2 different vertexArrays. You should see a pulsating colored, textured cube if it runs fine. Commenting/Uncommenting the dirty calls make, or disabling the VBO makes it clear. Dimi - Original Message From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thu, May 19, 2011 3:52:06 PM Subject: Re: [osg-users] VBO incosistencies between 2.8 and 2.912 Hi Dimi, The buffer object support in the OSG has been revamped and in theory should be robust and flexible... but like all code there is a chance for regressions so wide spread testing it neccessary. Whether in this instance there is an actual bug, or just a different behaviour I can't say as I haven't tested your code. As a quick test I would suggest calling dirty on each array your modiy. Robert. On Thu, May 19, 2011 at 1:37 PM, dimi christop dimi_chris...@yahoo.com wrote: Hi, I recently upgraded my code base to 2.912 (Linux, GTX 280) , unfortunately my GPU morphing code stopped working. I use VBO, GLSL and vertex attributes to copy the changing morph shapes and do the interpolation on the GPU. After searching for the problem I found that when I declared a geometry as VBO // Disable Display lists and setup Vertex Buffer Objects geom-setUseDisplayList (false); geom-setUseVertexBufferObjects(true); osg::VertexBufferObject* df = geom-getOrCreateVertexBufferObject(); df-setUsage (GL_STREAM_DRAW); the subsequent commands during the update which changed the vertexArray had no effect and produced random triangles on the screen. geom-setVertexArray(vcoords); Because of the many morph shapes, I have many vertex arrays preallocated and pass them to the geometry based on a time. I do not copy assign to the vertex array of the geometry for speed reasons. As I said in the 2.8 version everything worked fine. When change the code to issued a dirty on the vertex arrays vcoords-dirty() the shape morphed correctly but the color, normal, texcoord arrays (which do not morph) did not show up correctly. Has anyone any idea what changed between the 2.8-2.912 versions. I was under the impression that issuing a setVertexArray command calls dirty() at least on the geometry array. Is it therefore mandatory to issue a dirty() call for all arrays (color, normal, texcoords) assigned to the geometry? Please note then when I disable the VBO usage, a single dirty() call on the vertexarray works and the other arrays show up normal. Thank you in advance Dimi ___ 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 osggpumorph.cpp Description: Binary data GNUmakefile Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO incosistencies between 2.8 and 2.912
Hi Dimi, Thanks for example. I won't be able to look at the issue this week, but if I don't follow up next week please send me a reminder. Robert. On Thu, May 19, 2011 at 2:21 PM, dimi christop dimi_chris...@yahoo.com wrote: Hi Robert, this is exactly what I did, I called dirty on the vertexArray which is passed each frame to the geometry using geom-setVertexArray(vcoords); vcoords-dirty(); The problem was that, it screws up all other attached geometry arrays like (colors, normals, texcoords) which do not change This behavior does not occur when the geometry is not specified as VBO or in 2.8. I can try to call dirty on all arrays whether they change or not, but it does not seem logical. I attach a small example which show the problem (along with the makefile). The example changes vertexArrays of a VBO geometry (a cube) at runtime using 2 different vertexArrays. You should see a pulsating colored, textured cube if it runs fine. Commenting/Uncommenting the dirty calls make, or disabling the VBO makes it clear. Dimi - Original Message From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thu, May 19, 2011 3:52:06 PM Subject: Re: [osg-users] VBO incosistencies between 2.8 and 2.912 Hi Dimi, The buffer object support in the OSG has been revamped and in theory should be robust and flexible... but like all code there is a chance for regressions so wide spread testing it neccessary. Whether in this instance there is an actual bug, or just a different behaviour I can't say as I haven't tested your code. As a quick test I would suggest calling dirty on each array your modiy. Robert. On Thu, May 19, 2011 at 1:37 PM, dimi christop dimi_chris...@yahoo.com wrote: Hi, I recently upgraded my code base to 2.912 (Linux, GTX 280) , unfortunately my GPU morphing code stopped working. I use VBO, GLSL and vertex attributes to copy the changing morph shapes and do the interpolation on the GPU. After searching for the problem I found that when I declared a geometry as VBO // Disable Display lists and setup Vertex Buffer Objects geom-setUseDisplayList (false); geom-setUseVertexBufferObjects(true); osg::VertexBufferObject* df = geom-getOrCreateVertexBufferObject(); df-setUsage (GL_STREAM_DRAW); the subsequent commands during the update which changed the vertexArray had no effect and produced random triangles on the screen. geom-setVertexArray(vcoords); Because of the many morph shapes, I have many vertex arrays preallocated and pass them to the geometry based on a time. I do not copy assign to the vertex array of the geometry for speed reasons. As I said in the 2.8 version everything worked fine. When change the code to issued a dirty on the vertex arrays vcoords-dirty() the shape morphed correctly but the color, normal, texcoord arrays (which do not morph) did not show up correctly. Has anyone any idea what changed between the 2.8-2.912 versions. I was under the impression that issuing a setVertexArray command calls dirty() at least on the geometry array. Is it therefore mandatory to issue a dirty() call for all arrays (color, normal, texcoords) assigned to the geometry? Please note then when I disable the VBO usage, a single dirty() call on the vertexarray works and the other arrays show up normal. Thank you in advance Dimi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::Timer::tick Calls in OSG
I know this is probably in the noise but I was profiling my code and noticed many calls per frame to clock_gettime(). I traced this back to OSG (I'm using OSG 2.9.12 but it is probably true for other version). I counted about 245 calls to clock_gettime() per frame with each clock_gettime() call taking around 0.2 microseconds. This means that around 49 microseconds per frame are spent fetching the current time. In looking at the code, it looks like most (if not all) of the calls are from osg::Timer::tick() and used for debugging information which is only reported for various debugging notify levels, however, the timing calculation is reported no matter what the notify level is. Again, I know this might be in the noise, but for my project, I need to conserve every CPU cycle I can. Paul P. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39545#39545 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] model placing using osgdem
On 5/19/2011 7:14 AM, Vijeesh Theningaledathil wrote: Hi, I just tried to add 3d models to the terrain by adding -m modelname option. But Icouldn't see the object in the terrain. What exactly -m option will do. My object is also in the same coordinate. Why the option doesn't work. I don't recall that that option is implemented. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO incosistencies between 2.8 and 2.912
Will do thanks - Original Message From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thu, May 19, 2011 4:39:29 PM Subject: Re: [osg-users] VBO incosistencies between 2.8 and 2.912 Hi Dimi, Thanks for example. I won't be able to look at the issue this week, but if I don't follow up next week please send me a reminder. Robert. On Thu, May 19, 2011 at 2:21 PM, dimi christop dimi_chris...@yahoo.com wrote: Hi Robert, this is exactly what I did, I called dirty on the vertexArray which is passed each frame to the geometry using geom-setVertexArray(vcoords); vcoords-dirty(); The problem was that, it screws up all other attached geometry arrays like (colors, normals, texcoords) which do not change This behavior does not occur when the geometry is not specified as VBO or in 2.8. I can try to call dirty on all arrays whether they change or not, but it does not seem logical. I attach a small example which show the problem (along with the makefile). The example changes vertexArrays of a VBO geometry (a cube) at runtime using 2 different vertexArrays. You should see a pulsating colored, textured cube if it runs fine. Commenting/Uncommenting the dirty calls make, or disabling the VBO makes it clear. Dimi - Original Message From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thu, May 19, 2011 3:52:06 PM Subject: Re: [osg-users] VBO incosistencies between 2.8 and 2.912 Hi Dimi, The buffer object support in the OSG has been revamped and in theory should be robust and flexible... but like all code there is a chance for regressions so wide spread testing it neccessary. Whether in this instance there is an actual bug, or just a different behaviour I can't say as I haven't tested your code. As a quick test I would suggest calling dirty on each array your modiy. Robert. On Thu, May 19, 2011 at 1:37 PM, dimi christop dimi_chris...@yahoo.com wrote: Hi, I recently upgraded my code base to 2.912 (Linux, GTX 280) , unfortunately my GPU morphing code stopped working. I use VBO, GLSL and vertex attributes to copy the changing morph shapes and do the interpolation on the GPU. After searching for the problem I found that when I declared a geometry as VBO // Disable Display lists and setup Vertex Buffer Objects geom-setUseDisplayList (false); geom-setUseVertexBufferObjects(true); osg::VertexBufferObject* df = geom-getOrCreateVertexBufferObject(); df-setUsage (GL_STREAM_DRAW); the subsequent commands during the update which changed the vertexArray had no effect and produced random triangles on the screen. geom-setVertexArray(vcoords); Because of the many morph shapes, I have many vertex arrays preallocated and pass them to the geometry based on a time. I do not copy assign to the vertex array of the geometry for speed reasons. As I said in the 2.8 version everything worked fine. When change the code to issued a dirty on the vertex arrays vcoords-dirty() the shape morphed correctly but the color, normal, texcoord arrays (which do not morph) did not show up correctly. Has anyone any idea what changed between the 2.8-2.912 versions. I was under the impression that issuing a setVertexArray command calls dirty() at least on the geometry array. Is it therefore mandatory to issue a dirty() call for all arrays (color, normal, texcoords) assigned to the geometry? Please note then when I disable the VBO usage, a single dirty() call on the vertexarray works and the other arrays show up normal. Thank you in advance Dimi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Earth using VPB
Hi GuiYe, Once you get VPB built some examples of how to run osgdem are at: http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/osgdem You can also take a look at osgEarth (http://osgearth.org/) which is an on demand terrain rendering toolkit for OpenSceneGraph. Good luck! Jason 2011/5/19 GuiYe guiy...@163.com: Hi, Who can tell me how to make a earth with terrain(DEM) and Satellite-Image using VPB as Google Earth？ Sorry for my poor English. Thank you ! Good Luck! Cheers GuiYe ___ 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] Searching for help on including osgEarth in FlightGear
Hi. I am developing Vostok-1 for OSG based FlightGear flight simulator and have a lot of problems with it. Current FlightGear terrain engine could not provide high speed/altitude flights, due to too complex Earth tiles implementation. As You can see on pictures, there in no visible Earth surface, only blue fog, and still it loads a lot of something, drop fps, hangs, and even can drop out. There is option to include in FlightGear other OSG based GPL project code, osgEarth which seems to be not so complex, and then automatically switch between engines on some speed/altitude. I had asked FlightGear developers to help me, but it seems what no one of them interested in space flight now to somehow improve current terrain engine. Me personally is not competent enough to do so. Is there someone interested in solving that task? It would give a lot of OSG understanding for developer by, maybe, not so big efforts. With best regards, Slavutinsky Victor -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39548#39548 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how can I get the main camera's rotation angle relative to x, y, z axis
On 5/19/2011 1:15 AM, ms yang wrote: Hi: I am a beginner of OSG. I have a problem about how can I get the main camera's rotation relative to x,y,z axis. I can get the view matrix by osg::Matrix matrix = viewer-camera()-getViewMatrix(),after I get the view matrix,there is only one member function getRotate which returns the quat but not the rotation angle relative to x,y,z axis. Get the view matrix lookat components: osg;;vec3 eye, at, up; view-getLookAt( eye, at, up ); Then get the normalized view direction: osg::Vec3 viewDir = at - eye; viewDir.normalize(); Then use linear algebra and trigonometry: The dot product of two unit vectors is the cosine of the angle between the two vectors. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Move image in texture
Hi, I have the following problem: I've got a (for example, 1024x1024px) Image and each animation cycle I need (in a smaller texture) a slightly different part of this Image. e.g. 1. Pass: x1 = 0, x2 = 64, y = 0, y2 = 64 2. Pass: x1 = 0, x2 = 64, y = 1, y2 = 65 3. Pass: x1 = 0, x2 = 64, y = 2, y 2 = 66 Could I somehow use copyTexImage2D (State state, int x, int y, int width, int height) but with my 1024px Texture as Source? E.g targetImage.copyTexImage2D(sourceImage,0,y,64,y+64) Or is there another way to go? Thank you and please excuse my bad english. Cheers, Marc -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39554#39554 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGExp: CMake build
Thank you Laurens. On Thu, May 19, 2011 at 7:58 AM, Laurens Voerman l.voer...@rug.nl wrote: Hi Farshid, attached are updated CMakelist.txt files for Helpers OsgExp A fix for missing header files and an update with the added files (svn rev 199) Regards, Laurens. ___ 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] Error in example?
Hi, Ooops, possibly messed up my earlier reply; apologies if this is a double post At any rate, OS is linux-2.6.23, CPUs are 64-bit AMD and Intel multi-core, and graphic boards are Nvidia GEForce 8 and 9 series, Moving to GTX 460s after we get these shaders working Quick comment, it would appear the example shader code in OSG 2.8.3 and 2.8.4 is a few years old. what version of GLSL does it support? running flightgear 2.0 and 2.2 which use shaders and the basic shader example code works, so all that seems to be in order. My assumption ( after some reading and research ) is that the texture info is not being passed to the frament shader. Just wondering if others have been able to run these examples as is? And is there a more appropriate place to post this type of problem; perhaps a users or developers group or is this the best place? ... Thank you! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39557#39557 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Move image in texture
On 5/19/2011 9:19 AM, Marc Wahl wrote: I've got a (for example, 1024x1024px) Image and each animation cycle I need (in a smaller texture) a slightly different part of this Image. Maybe I'm missing something but wouldn't it be better to store one large texture image and just change your vertex texture coordinates to view a different part of this image as needed? Reloading a texture is slow compared to reloading new vertex texcoords. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking at OSGExp and maya2osg (3dsmax and Maya export plugins)
Hi Luca,
On Thu, May 19, 2011 at 12:59 AM, Luca Vezzadini
luca.vezzad...@gmail.comwrote:
I gave it a try, the description lines are there. I just see a minor issue:
you did not add the MaterialData.{h,cpp} to Cmake.
About the results, looks like what is there is fine! I'll do more testing
in the next days, trying to use the definitions in my shaders as well, and
let you know.
Laurens just submitted a patch that fixes the Cmake issue.
The testMat2 is using the tx directly as a bitmap, while TestMap first has
a NormalMap texture, then the bitmap. In the output they look totally
equivalent though. Looking at the code, it seems that you treat them as
separate cases: so, what about adding an extra field at the end of TestMap
to indicate it's a normal map? The field could actually be even smarter and
indicate the active texture space (tangent, screen, ...).
My intention was to add more keywords that would describe each map in more
detail, depending on the texture type. In your example, I could add the
following line to provide more information regarding the bump map on unit 2:
Normal unit amount method
Normal 2 1.0 Tangent
This let's you know that the bitmap type on unit 2 is a normal map with the
specified settings. I could eventually add keywords to provide additional
info for Mix maps and Reflection maps.
Does this sound reasonable to you?
Cheers,
Farshid
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGExp: CMake build
Thanks for pointing that out, should be fixed now.
Cheers,
Farshid
On Thu, May 19, 2011 at 8:59 AM, Laurens Voerman l.voer...@rug.nl wrote:
Hi Farshid,
sorry to bother you again, I think you are not even using the cmake files.
The CMakeLists I send you for osgExp is not correct, the line
${HEADER_PATH}/MaterialData.cpp is wrong, should refer to the .h
Regards, Laurens.
On 5/19/2011 5:44 PM, Farshid Lashkari wrote:
Thank you Laurens.
On Thu, May 19, 2011 at 7:58 AM, Laurens Voerman l.voer...@rug.nl
mailto:l.voer...@rug.nl wrote:
Hi Farshid,
attached are updated CMakelist.txt files for Helpers OsgExp
A fix for missing header files and an update with the added files
(svn rev 199)
Regards, Laurens.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performace issue with nVidia 400 series
hybr wrote: Hi, David, 4xx series slow specifically on readback from framebuffer\FBO to texture\PBO\host memory (in GL, dunno about cuda\opencl). That is what all people talking about. If you dont use this features much you will have no problems whatsoever. Cheers, Sergey. 19.05.2011, 03:27, David Glenn : Jason Daly wrote: On 05/18/2011 05:14 AM, Fred Smith wrote: Hi, The only problem that I personally heard about is about the slow transfer speed to/from GPU memory on Fermi cards. DMA transfers are said to be slower than on GTX 2xx hardware. I haven't seen anything related to computing. I think it's specifically GPU-host memory transfers that are slow. The other direction is OK, as is the computation speed. The thread on the OpenGL forums has the details, and someone posted a small program that does timing tests and illustrates the issue pretty well. http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflatNumber=284065page=1 --J I looked at the link you gave and downloaded the program that was the (the 4th revision of it) and tried on my GTX 460 and an old 8800 GT and compared it to the results that was posted and something does not add up with the test program! Before I learned of all of this, I ran some other tests using a stress program and gDEBugger and found that the GTX 460 was much faster than 8800 GT (about 10 times faster under stress). I also tested it on most of my high end terrain and it ran much faster (about the biggest texture based thing I have) even though I don't have figures for it yet. I'm not saying that there is not a problem, but I'm a bit confused when one test I do contadicted by another and that the numbers for that other test and the conclusion seem spect to me! D Glenn D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39519#39519 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Well I'm using a far chunk of terrain that is very texture based and I haven't seen any issues. Maybe I'm making a mistake getting the 460's and sould try the GTX 280. D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39561#39561 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGExp: CMake build
Thanks.
On 5/19/2011 6:06 PM, Farshid Lashkari wrote:
Thanks for pointing that out, should be fixed now.
Cheers,
Farshid
On Thu, May 19, 2011 at 8:59 AM, Laurens Voerman l.voer...@rug.nl
mailto:l.voer...@rug.nl wrote:
Hi Farshid,
sorry to bother you again, I think you are not even using the cmake
files. The CMakeLists I send you for osgExp is not correct, the line
${HEADER_PATH}/MaterialData.cpp is wrong, should refer to the .h
Regards, Laurens.
On 5/19/2011 5:44 PM, Farshid Lashkari wrote:
Thank you Laurens.
On Thu, May 19, 2011 at 7:58 AM, Laurens Voerman
l.voer...@rug.nl mailto:l.voer...@rug.nl
mailto:l.voer...@rug.nl mailto:l.voer...@rug.nl wrote:
Hi Farshid,
attached are updated CMakelist.txt files for Helpers OsgExp
A fix for missing header files and an update with the added
files
(svn rev 199)
Regards, Laurens.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Move image in texture
Yes, that was also my first approach, but I need a resulting Texture2D. I'm working with an external painting lib, which requires a Texture2D as a brush. I'm painting tire tracks and the used painter draws on each animation cycle. Therefore i use the tire rotation to calculate the current tire track (normalbump map). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39565#39565 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CPU usage - qt application
In the meanwhile I found a way to get the screen refresh rate to use as default
in the timer. I don't know if there is something helpful in the OSG libs but
since nobody answers ... here is the code:
DEVMODE lpDevMode;
memset(lpDevMode, 0, sizeof(DEVMODE));
lpDevMode.dmSize = sizeof(DEVMODE);
lpDevMode.dmDriverExtra = 0;
if(EnumDisplaySettings(NULL, ENUM_CURRENT_SETTINGS, lpDevMode) != 0)
{
rate = lpDevMode.dmDisplayFrequency;
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39566#39566
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crashing when calling viewer-done()
Hello Robert,
I may be a couple of days late, but I have a suggestion to solve your
crashing problem. Instead of s dynamically allocated viewer use a
static object.
osgViewer::Viewer viewer;
...
//don't want this: viewer = new osgViewer::Viewer();
...
viewer.realize();
int iter = 0;
while( !viewer.done() )
{
coutiter: iterendl;
iter++;
viewer.frame();
}
return 0;
}
-Don Leich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] osg with QT how to?
Greetings to Jin and fellow OSG/Qt users. Jin, I am glad that you got your setup working. I am unsure of the specific differences between g++ and Visual C++, but I would recommend that you be careful using win32-g++ as your QMAKESPEC when using Visual Studio anything as your build environment, unless you have found a way to use g++ as your compiler/linker within the Visual Studio IDE (in which case, you can probably ignore everything I say below). Using g++ as your compiler/linker within the Visual Studio IDE is completely outside my experience (I do not know if such a thing is even possible). Generally, I have found that http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio is a good place to start for Visual Studio specific instructions for building OSG. Just make sure that you use the correct 3rd party dependencies (it looks like you are using the correct ones). From the error message I read in what I think is your original post, it looks like you may not have added OSG's bin directory and/or the 3rd party bin directory to your path before trying build the example that uses OSG with Qt. If you are using the CMake GUI, use the advanced view to make sure that all the CMake settings are correct before trying to generate project files for the examples; you may have to manually make changes to some of the settings; I am unfamiliar with configuring CMake from the command line. At the time when you saw the error, had you already successfully installed Qt and OSG in the desired debug and release builds? Are you using debug Qt libraries with debug OSG libraries, and release Qt libraries with release OSG libraries? With Visual C++, you can not mix debug binaries with release binaries. I notice in what I think is your original post that you do not mention g++. How did you determine that win32-g++ was the QMAKESPEC you needed? Did you build Qt with a g++ compiler/linker? Are you using an already built Qt SDK? As daunting as it may seem, if you are using a Qt SDK that was not already built with Visual Studio 2008, you may want to consider building Qt from source code yourself. Qt has pretty good instructions on how to do that specific to the version of Qt you want to use. I would start with http://qt.nokia.com/, and follow the links to the version of Qt you want to use with OSG. If I followed the thread correctly, you specifically mentioned VS2008 on Windows 7. Does Qt not offer a Visual Studio 2008 QMAKESPEC? If so, I would recommend using that, unless you are using a version of Qt SDK already built with g++; in that case, you should also consider building OSG with the same type of setup as that used to build the Qt SDK. I do not think that g++ binaries are compatible with Visual C++ binaries. I hope this helps. In any event, good luck in your work with OSG and Qt. D.J. On Thu, May 19, 2011 at 5:28 AM, jin tongo scat...@googlemail.com wrote: Hi, thanks for the reply, I solved the problem. For all of you who struggle, here is how I did this: I downloaded the QTSDK, installed it in C:\ Set environment variables: QTDIR to C:\QtSDK\Desktop\Qt\4.7.3 QMAKESPEC to win32-g++ Since I wanted to work with Microsoft Visual Studio 2008 I added C:\QtSDK\Desktop\Qt\4.7.3\msvc2008\bin to the Path environment variable Updated Microsoft Visual Studio 2008 to SP1, downloaded this update from Microsoft (important, because without Visual Studio SP1 I got linker crashes when compiling osg) - I checked out OpenSceneGraph from the repository - Also checked out the OpenSceneGraph Data (on the website under downloads - SVN) Both into C:\Projects\ I also downloaded the 3rdParty_VC9sp1_x86_x64_V5.7z , just used the x82 Version and packed it all into C:\Projects\3rdParty (next to the OpenSceneGraph Repositories, and made sure the folders for x86 (like bin, include, lib were directly in the 3rdParty folder). Then I ran CMake over my C:\Projects\OpenSceneGraph and created the build folder C:\Projects\OpenSceneGraph\build. Made sure - that the CMake install Path was set to C:\Program_Files(x86)\OpenSceneGraph. - that CMake found the 3rdParty folder and many libraries (ofc. not all of them) - that I checked build OSG examples - that CMake found the QT executable and I checked build QT examples Then I hit generate. I set some environment variables: OSG_FILE_PATH to C:\Projekte\OpenSceneGraph-Data OSG_DIR to C:\Program Files (x86)\OpenSceneGraph added C:\Projekte\3rdParty\bin;C:\Program Files (x86)\OpenSceneGraph\bin to the Path environment variable I opened the .sln file in C:\OpenSceneGraph\build with Visual Studio. Set it to Debug and compiled it (ALL BUILD). The after around 20 min it was finished and i right clicked the INSTALL target and told Visual Studio to build that (which just copies the right files into my CMake install path (C:\Program_Files(x86)\OpenSceneGraph). Then I set Visual Studio to Release and did ALL BUILD again.
Re: [osg-users] Performace issue with nVidia 400 series
On 05/19/2011 12:07 PM, David Glenn wrote Well I'm using a far chunk of terrain that is very texture based and I haven't seen any issues. Maybe I'm making a mistake getting the 460's and sould try the GTX 280. By texture-based do you mean you're reading the texture image from the GPU back into your application, or you're just using the texture data on the GPU for rendering. Unless you're reading the texture data back from the GPU (glReadPixels(), glGetTextureImage(), PBO in READ mode), you won't see the problem. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performace issue with nVidia 400 series
Jason Daly wrote: On 05/19/2011 12:07 PM, David Glenn wrote Well I'm using a far chunk of terrain that is very texture based and I haven't seen any issues. Maybe I'm making a mistake getting the 460's and sould try the GTX 280. By texture-based do you mean you're reading the texture image from the GPU back into your application, or you're just using the texture data on the GPU for rendering. Unless you're reading the texture data back from the GPU (glReadPixels(), glGetTextureImage(), PBO in READ mode), you won't see the problem. --J ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Not unless OSG is doing that at some point! I'm not adding any drawables or changing much of the OSG code at this point. At least not yet! Grin! The only other stuff that I found that GTX460 have some issues with some of the AMD base motherboard stuff that can jam performance of the card, to the point that some textures might not appear in some OGL based games – exp: Mafia 2. But you might have already heard of that! D Glenn D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39571#39571 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow vs reflection vs cull visitor
Hello ! I hope you don't mind I address you directly for this question, but as you implemented the view-dependent shadow techniques, you are best placed to answer it. Well... we will see if I will be able to help here. I am currently investigating a problem that seems to be caused by the ordering of RTT passes. I have a scene that uses osgOcean and osgShadow, and the shadow INSIDE the refraction (which is an RTT effect) is late compared to the shadows OUTSIDE the refraction (i.e. above the water level). What I mean by late is that the shadow moves away from the casting object if I move the eye around, but stops moving and is in the right place as soon as I stop moving the eye. So the refraction pass seems to be happening before the shadow pass. I understand. I know this problem well from my experience. The nodes are ordered like this: root ShadowedScene OceanScene the scene And in the OceanScene traverse() method, there is a check if the current camera is the shadow pass camera or analysis camera (for DrawBounds techniques) and just do a regular traversal in that case. My expectation was that the first traversal of the OceanScene would be the shadow pass, then the main pass, and so when we do the refraction RTT (during the main pass), the shadow map would already be correct for the current frame. [..] So the main pass is done (culled) before the shadow pass. I can understand that the bounds calculation needs to cull the shadow receiving scene first, or else we won't know where the shadow map should lie. However, I wonder how this even works. Culling order does not need to be the same as Rendering order. Rendering order is defined by PRE_RENDER / POST_RENDER / NESTED_RENDER camera flag. Cull visitor on the other hand simply traverses the scene tree in first encountered/first processed order. My understanding is that when the cull visitor traverses a scene graph, it accumulates the drawables and state into a list. It does this in the order it visits notes, and might reorder based on state or other criteria (distance to camera for the transparent bin, for example). Sorting is done in Draw stage as far as I know. So given the code above, how does the cullShadowCastingScene() manage to place the drawables for the shadow pass before the ones for the main pass, even though the cullShadowReceivingScene() (culling the main pass) is before? Each camera has render order flag and associated RenderStage+RenderBin set. Cull visitor simply fills these render stage bins and state graphs without checking which will be rendered first. They are waiting for Draw phase to be rendered and they are then drawn in order defined by cameras. Main question here I believe is how to ensure that PRE_RENDER cameras will render in certain desired order. And honestly I don't know definite answer to this question. My tests with analysis shadow cameras seem to suggest that first traversed by cull visitor will be rendered first. For DrawBounds method order of culling is 1: scene / 2: analysis / 3: shadow. Scene has standard order (i am not sure but suppose its NESTED) and analysis and shadow are PRE_RENDER. So if analysis comes before shadow (which I made sure it does) it means that first PRE_RENDER camera traversed by cull visitor will be drawn first. I think for osgOcean's refraction pass to contain correct shadows, I would need to do something similar, i.e. place the drawables for that pass after the shadow pass, but before the main pass, in the render list. I'm actually surprised that's not what happens already, since the sequence should be: cullShadowReceivingScene() -- eventually calls OceanScene::traverse() -- does cull for refraction RTT camera -- then does cull for main pass cullShadowCastingScene() -- does shadow pass, somehow placing results before main pass, which for all it knows should contain the refraction pass And the above order of cull visits explains the effect. I assume refraction RTT camera is PRE_RENDER cam like analisys and shadow. So its rendered first because its culled first. You would need to put refraction cull after cullShadowCastingScene() to be sure it will get rendered at the right moment, I guess. Thanks in advance, You are welcome, but I doubt I helped ;-) Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow vs reflection vs cull visitor
Hi Wojtek, Well... we will see if I will be able to help here. Yes, I am sure you will! :-) Each camera has render order flag and associated RenderStage+RenderBin set. Ah yes, I had forgotten about the render order number (integer to order more finely between PRE_RENDER cameras and so on). Perhaps that's the answer here? And I checked, the main pass camera is POST_RENDER with a _renderOrderNum of 0. And the above order of cull visits explains the effect. I assume refraction RTT camera is PRE_RENDER cam like analisys and shadow. So its rendered first because its culled first. You would need to put refraction cull after cullShadowCastingScene() to be sure it will get rendered at the right moment, I guess. You're my hero! I just set the refraction camera as PRE_RENDER, but with a number higher than the shadow pass and analysis cameras (I chose 1 since the shadow pass camera is PRE_RENDER 0), and it now happens before the main pass (since that is POST_RENDER 0), but after the shadow and analysis passes! Thanks a million, I owe you yet another beer. Though I kind of hate hard-coding the render order in osgOcean, since the shadow pass could be any render order number imaginable and it won't necessarily work then, but at least now it works with the default shadow technique. I think we might need a render passes manager in OSG that would work out the order of all passes in all libraries whether they know about each other or not... I know, wishful thinking :-) Thanks again, 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] osgText::Text character spacing
Hi Robert, On Wed, May 18, 2011 at/14:18:05/, Robert Osfield wrote: Could you create a small example that prints the a set of different fonts at different sizes against quad the same hight as the font for reference. Running this against OSG-2.8.x and OSG-2.9.15+/svn/trunk will reveal a bit more what is happening w.r.t sizing. Ok, I'll try to prepare something here. I'm also curious how the effect looks with different fonts. / Even if the font size is correct now, one could still consider it a/ / regression./ I believe we've fixed bugs in osgText and the sizes should now be more realiable and consitent across different font types and means of rendering. Breaking code that relied upon the original bugs is a tricky area, to call fixing a bug a regression is not really appropriate. Yes, I know that osgText is improved and a bug is fixed now, so regression probably wasn't the right word to use in the context of osg (I apologize). Just meant that the behaviour of an existing feature in the osg library is about to change in between released versions - and in the context of an application using it, this may lead to issues of osgText looking differently or (as in our case) also being unreadable - which potentially triggers loads of issues for existing applications. Some libraries/products try to avoid such issues - even at costs - but I know things like this can also cause huge hassle. I guess you might be able come up with a workaround to apply the the txf plugin, perhaps as post process scaling. I'd probably need to find someone knowing more about osg to do that. Currently I'm also trying to find out/estimate how many of our aircraft are affected. Not sure how we'll proceed eventually. Do you have a date for the FlightGear release? Just announced today: we're aiming to branch the next release in mid-July, with the final release planned for mid-August. Any osg 3.0 estimates? cheers, Thorsten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow vs reflection vs cull visitor
On 5/19/2011 2:07 PM, Wojciech Lewandowski wrote: [..] So the main pass is done (culled) before the shadow pass. I can understand that the bounds calculation needs to cull the shadow receiving scene first, or else we won't know where the shadow map should lie. However, I wonder how this even works. Culling order does not need to be the same as Rendering order. Rendering order is defined by PRE_RENDER / POST_RENDER / NESTED_RENDER camera flag. Cull visitor on the other hand simply traverses the scene tree in first encountered/first processed order. If you have multiple sibling Cameras with the same render order, their draw order is determined by their order in the scene graph (or by the CullVisitor, in other words). The CullVisitor is assembling a graph of RenderBins. RenderStage derives from RenderBin. Each Camera keeps a cache of RenderStages indexed by CullVisitor address. Every time the CullVisitor encounters a Camera node (and the order isn't NESTED_RENDER), it inserts the Camera's RenderStage for that CullVisitor into the render graph. Your Viewer object and/or SceneView has an implicit root Camera, and its corresponding RenderStage is the root node of the render graph. If that root Camera has two PRE_RENDER Camera children, child 0 and child 1, then the child 0 Camera RenderStage gets added to the root Camera RenderStage's list of pre-render stages first, and the child 1 Camera RenderStage goes into that list second. During draw, RenderStage::draw() is called on the list of pre-render stages in the order they appear in the list -- in this case, the same order they were encountered by the CullVisitor. All of the root Camera RenderStage's pre-render children are drawn before ::draw() gets called on the root Camera RenderStage. I hope that helps. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenGL version parsing broken
Hi Robert, et al, we're having an issue caused by this changeset: http://www.openscenegraph.org/projects/osg/changeset/12303 Particularly the change in parsing GL_SHADING_LANGUAGE_VERSION broke certain GL/shader features on many systems (all our clouds are gone with osg = r12303). Cross-posting from our devel-list: On Wednesday, 18.05.2011, 22:45 Csaba Halász wrote: Turns out 12303 is the cause for the constant sunshine ;) Specifically, the GLSL version parsing has been broken: Original code: _glslLanguageVersion = asciiToFloat( langVerStr ); New code: _glslLanguageVersion = ( asciiToFloat( glslvs.substr( glslvs.find( GLSL +5 ) ).c_str() ) ); The version string for me here is simply 3.30 (using fglrx 11.4), so the old code works but the new one doesn't. Incidentally, the GL version parsing doesn't work either, because version string is 3.3.10666 Compatibility Profile Context and the code (both the old and the new) expect a decimal number before the space. Thanks to Csaba for debugging into this issue. I also see the issue on my system. So, obviously the new code for parsing the GL version strings doesn't work for all systems. Could you please have a look? cheers, Thorsten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow vs reflection vs cull visitor
Hi, I am glad you could solve it. I was not aware of _renderOrderNum index. So thanks, I have learned important new stuff today ;-) I guess you had to override either Ocean or LispSM techniuque already. So you may set _renderOrderNum in overriden code. Depending on which one you overrode, I believe you may either set 1 for Refraction camera or -1 for Analysis and Shadow cams. Cheers, Wojtek Hi Wojtek, Well... we will see if I will be able to help here. Yes, I am sure you will! :-) Each camera has render order flag and associated RenderStage+RenderBin set. Ah yes, I had forgotten about the render order number (integer to order more finely between PRE_RENDER cameras and so on). Perhaps that's the answer here? And I checked, the main pass camera is POST_RENDER with a _renderOrderNum of 0. And the above order of cull visits explains the effect. I assume refraction RTT camera is PRE_RENDER cam like analisys and shadow. So its rendered first because its culled first. You would need to put refraction cull after cullShadowCastingScene() to be sure it will get rendered at the right moment, I guess. You're my hero! I just set the refraction camera as PRE_RENDER, but with a number higher than the shadow pass and analysis cameras (I chose 1 since the shadow pass camera is PRE_RENDER 0), and it now happens before the main pass (since that is POST_RENDER 0), but after the shadow and analysis passes! Thanks a million, I owe you yet another beer. Though I kind of hate hard-coding the render order in osgOcean, since the shadow pass could be any render order number imaginable and it won't necessarily work then, but at least now it works with the default shadow technique. I think we might need a render passes manager in OSG that would work out the order of all passes in all libraries whether they know about each other or not... I know, wishful thinking :-) Thanks again, 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
[osg-users] Problems Building OSG (Make: Protocol error)
Hi there. I was hardly trying to build OSG on my virtual machine with OpenSuSE 11.2 installed on it. I did the following steps: 1. downloaded the sources of OSG 2.8.4. 2. unzipped them 3. ran the configure script from within the folder I attached the output of the configure script. 4. Finally I ran make and this one threw an error of which really cannot find a solution for. Firstmake builds 6 CXX-Objects and then i get the following error: Linking CXX shared library ../../../lib/libOpenThreads.so CMake Error: cmake_symlink_library: System Error: Protocol error CMake Error: cmake_symlink_library: System Error: Protocol error make[2]: *** [lib/libOpenThreads.so.2.4.0] Fehler 1 make[1]: *** [src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/all] Fehler 2 make: *** [all] Fehler 2 What the hell does Protocol error mean in this context and how can I get rid of it? Hopefully that you can help me, Patrick -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for include files CMAKE_HAVE_PTHREAD_H -- Looking for include files CMAKE_HAVE_PTHREAD_H - found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found -- Looking for shmat -- Looking for shmat - found -- Looking for IceConnectionNumber in ICE -- Looking for IceConnectionNumber in ICE - found -- Found X11: /usr/lib/libX11.so -- checking for module 'libxml-2.0' -- package 'libxml-2.0' not found -- Could NOT find LibXml2 (missing: LIBXML2_LIBRARIES LIBXML2_INCLUDE_DIR) -- Could NOT find CURL (missing: CURL_LIBRARY CURL_INCLUDE_DIR) -- checking for module 'xulrunner-xpcom=1.8.9' -- package 'xulrunner-xpcom=1.8.9' not found -- checking for module 'xulrunner-js' -- package 'xulrunner-js' not found -- checking for module 'xulrunner-nspr' -- package 'xulrunner-nspr' not found -- checking for module 'xulrunner-nss' -- package 'xulrunner-nss' not found -- checking for module 'gtk+-2.0' -- found gtk+-2.0, version 2.18.1 -- checking for module 'gtkglext-x11-1.0' -- package 'gtkglext-x11-1.0' not found -- checking for module 'librsvg-2.0' -- package 'librsvg-2.0' not found -- checking for module 'cairo' -- found cairo, version 1.8.8
Re: [osg-users] Shadow vs reflection vs cull visitor
On 5/19/2011 2:51 PM, Paul Martz wrote: On 5/19/2011 2:07 PM, Wojciech Lewandowski wrote: [..] So the main pass is done (culled) before the shadow pass. I can understand that the bounds calculation needs to cull the shadow receiving scene first, or else we won't know where the shadow map should lie. However, I wonder how this even works. Culling order does not need to be the same as Rendering order. Rendering order is defined by PRE_RENDER / POST_RENDER / NESTED_RENDER camera flag. Cull visitor on the other hand simply traverses the scene tree in first encountered/first processed order. If you have multiple sibling Cameras with the same render order, their draw order is determined by their order in the scene graph (or by the CullVisitor, in other words). Scratch that statement, in light of the render order num discussion in this thread. :-) On the other hand, if the render order number is *also* the same... -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow vs reflection vs cull visitor
Hi Wojtek, Just a quick follow-up on this: I guess you had to override either Ocean or LispSM techniuque already. I was wondering, if I ever need to override LispSM's ViewData class, how would I go about it? I guess I need to override the *ShadowMap class as well so that it instantiates my new derived ViewData class instead of the default one in the *ShadowMap class itself? I think you've said this before but it's been a while and I can't find it in the archives. Thanks, 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] Shadow vs reflection vs cull visitor
Hi Wojtek, I guess you had to override either Ocean or LispSM techniuque already. So you may set _renderOrderNum in overriden code. Depending on which one you overrode, I believe you may either set 1 for Refraction camera or -1 for Analysis and Shadow cams. Actually I'm working on osgOcean a lot lately (and I'm co-developer on it so I have commit access). So this is going straight into the osgOcean code. Since the default shadow techniques in OSG all use PRE_RENDER #0 for their shadow pass cameras, it's a safe change to set the refraction one (and other PRE_RENDER passes in osgOcean) to PRE_RENDER #1. Thanks for your help, 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] Shadow vs reflection vs cull visitor
Hi Paul, On the other hand, if the render order number is *also* the same... Thanks for going over the basics again for me, I knew all that but for some reason had completely forgotten about the render order number (_renderOrderNum)... So yeah, the RenderStages are ordered in order of _renderOrder (PRE_RENDER before NESTED_RENDER before POST_RENDER), if 2 cameras have the same _renderOrder they are ordered by _renderOrderNum, and if they have the same _renderOrder AND _renderOrderNum they are ordered in the order they were traversed by the CullVisitor (their order in the graph). That explains both why the shadow pass renders before the main pass in StandardShadowMap::ViewData::cull(), and why I was getting the results I was getting for the shadows in the refraction, as Wojtek said: cullShadowReceivingScene() (main pass camera is POST_RENDER #0) .. eventually goes into OceanScene::traverse() .. eventually culls refraction camera (PRE_RENDER #0) cullShadowCastingScene() (shadow pass camera is PRE_RENDER #0) So the order of rendering of the cameras (or RenderStages to be more correct) was: refraction (PRE_RENDER #0 traversed before shadow pass camera) shadow pass (PRE_RENDER #0 traversed after refraction camera) main pass (POST_RENDER #0) which explains why the refraction was using the shadow map from the previous frame, the shadow map for this frame wasn't rendered yet. I knew the error was ordering of the passes, I just didn't know why the order was wrong. So I'm explaining this as much for myself as for others. Now I've set the refraction pass _renderOrderNum to 1 (it could be any number 0 so it occurs after the shadow pass) and everything is fine. Thanks Wojtek and Paul for reminding me of lots of little things, and filling in gaps in my knowledge, thanks to you I was able to fix this bug and my users are happy once again :-) 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] how can I get the main camera's rotation angle relative to x, y, z axis
Hi : I tried what paul's suggestion but I do not get the correct result.Following are some tests what I do: //rotate 30 degrees around x axis,45 degrees around y axis,60 degrees around z axis osg::Quat quat(0.52359876f,osg::Vec3f(1.0f,0.0f,0.0f), 0.785398f,osg::Vec3f(0.0f,1.0f,0.0f), 1.0471975f,osg::Vec3f(0.0f,0.0f,1.0f)); osg::Matrix matrix; matrix.makeRotate(quat); osg::Vec3f eye,center,up; matrix.getLookAt(eye,center,up); osg::Vec3f forward = center - eye; double len = forward.length(); double x = forward._v[0]/len;//0.7071066 double y = forward._v[1]/len;//-0.35355 double z = forward._v[2]/len;//-0.6123725 osg::ref_ptrosg::MatrixTransform rotate = new osg::MatrixTransform; rotate-setMatrix(osg::Matrix::rotate(0.52359876f,osg::Vec3(1.0f,0.0f,0.0f),0.785398f,osg::Vec3(0.0f,1.0f,0.0f),1.0471975f,osg::Vec3(0.0f,0.0f,1.0f))* osg::Matrix::translate(0.0f,0.0f,0.0f)); osg::Matrix mt = rotate-getMatrix(); mt.getLookAt(eye,center,up); forward = center - eye; len = forward.length(); x = forward._v[0]/len;//0.7071066 y = forward._v[1]/len;//-0.35355 z = forward._v[2]/len;//-0.6123725 Ater I get the cosine value of each axis, the I try to get arcos value and find it is not the initial value what I setted.I do not konw what is wrong. ms yang ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Move image in texture
my code:
bool GraphicSceneClass::RSetTexturePosition(std::string ObjectName,
float dx, float dy, unsigned int UnitNumber)
{
//Находим объект
osg::ref_ptrFindNamedNodeVisitor fnnv = new
FindNamedNodeVisitor(ObjectName);
root-accept(*fnnv.get());
//Если такой объект есть, ищем анимацию
if (!fnnv-_foundNodes.empty())
{
if (fnnv-_foundNodes.size()1) std::cout Warning: Duplicate
names - ObjectName std::endl;
osg::ref_ptrFindGeometryVisitor zzz = new
FindGeometryVisitor();
fnnv-_foundNodes.front().get()-accept (*zzz.get());
//Если геометрия найдена
if (!zzz-geom.get())
{
std::cout geometry NOT found;
//delete zzz;
//delete fnnv;
return false;
}
//MOVE TEXTURE COORDINATES
!1
osg::ref_ptrosg::Vec2Array vertices2 =
dynamic_castosg::Vec2Array*
(zzz-geom-getTexCoordArray(UnitNumber)) ;
for (unsigned int u =0 ; u vertices2-size(); u++)
{
vertices2-at(u).x() += dx;
vertices2-at(u).y() += dy;
}
//Чистим мусор
//delete zzz;
}
else
{
std::cout Find objects in Root - FALSE! ObjectName
std::endl;
//delete fnnv;
return false;
}
//Чистим мусор
//delete fnnv;
return true;
}
2011/5/20 Marc Wahl osgfo...@tevs.eu:
Yes, that was also my first approach, but I need a resulting Texture2D.
I'm working with an external painting lib, which requires a Texture2D as a
brush.
I'm painting tire tracks and the used painter draws on each animation cycle.
Therefore i use the tire rotation to calculate the current tire track
(normalbump map).
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39565#39565
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Maxim Gammer
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
