Re: [osg-users] Shadow is not updated with the light
Hi Summit, Your problems suggest that the light casting shaodws is not found during cull traversal. See & debug method: const osg::Light* StandardShadowMap::ViewData::selectLight ( osg::Vec4 & lightPos, osg::Vec3 & lightDir ) This it the place in he code where light passed to technique is compared with lights active in the scene. If your light is found shadow casting projection is built. There is no magic in this method. So if it does not work, it means shadow casting light ptr has changed in the meantime. Cheers, Wojtek -Oryginalna wiadomość- From: Martin Scheffler Sent: Monday, May 16, 2011 8:32 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Shadow is not updated with the light Hi Sumit, mayb you have to update the light direction vector instead of the light position? I think the LISP shadow ignores light position and only uses light direction. Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39385#39385 ___ 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] DDS with DXT1 with and without alpha
Hi Robert,
I hope I do not spread misinformation, as I am not fully sure nor I know
exact details but I believe that logic for finding if DXT1 pixels are
transparent, should first check the order of entries in chunk( 4x4pixels)
micropallete. And if its ascending then chunk may not contain alpha pixels
and if its descending chunk may contain such pixels and then we should look
for proper alpha pixel index. That information comes from top of my head,
I cannot at the moment delve deeper and look into verifying this but thats
what I remember I read somewhere...
Cheers,
Wojtek Lewandowski
-Oryginalna wiadomość-
From: Robert Osfield
Sent: Thursday, April 14, 2011 1:03 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] DDS with DXT1 with and without alpha
Hi All,
I have now implemented the various options I suggested in my previous
post, and for now have opted to default to DXT1 RGB pixle format for
DXT1 files, unless the alpha bit in the dds header is set, then it
will choose DXT1 RGBA pixel format. The OSG's DDS plugin does set the
alpha bit when writting out DXT1 RGBA images, but other 3rd party
tools such as nvcompress do not, so for these 3rd party generated
images the dds plugin will now read all these DXT1 files as RGB.
These changes are now checked into svn/trunk.
You can list the new options using:
osgconv --format dds
Which will output:
Plugin osgPlugins-2.9.12/osgdb_dds.so
{
ReaderWriter : DDS Image Reader/Writer
{
features : readObject readImage writeObject writeImage
extensions : .ddsDDS image format
options: dds_dxt1_detect_rgbaFor DXT1 encode images
set the pixel format according to presence of transparent pixels
options: dds_dxt1_rgbSet the pixel format of
DXT1 encoded images to be RGB variant of DXT1
options: dds_dxt1_rgba Set the pixel format of
DXT1 encoded images to be RGBA variant of DXT1
options: dds_flipFlip the image about the
horizontl axis
}
}
To get the old automatic detection of DXT1 RGB vs RGBA you'll need to
use the "dds_dxt1_detect_rgba" option string.
I've gone for the default what I feel is probably most approrpiate,
but am aware I don't regularily use DXT1 compressed data coming in
from 3rd party sources in my work, so you own art parth routes may be
quite different. Please chip in.
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] ViewDependentShadow massive flickering problems
Hi, Ramy Sorry for late response (Excuse: Terribly Busy). Truth is I do not have much to suggest in your case. I have tried with J-S to investigate the problem of massive flicker when non zero MinLightMargin was used. This is the observation I got then: When View (shadow receiving) volume clipped by maxFarPlane gets much smaller than volume casting shadows (made by extruding first volume by MinLightMargin ) lispsm algortim can get really badly conditioned numerically. In such worst case Lispsm can produce projection matrix which has almost 180 deg of FOV. Such matrix does not only loose lots of mathematical precison, but also makes use of only a small fraction of shadow texture for shadowed view and this cause the flicker. But you metnioned that you use small minlightmargin value, so this may be a different problem. You may also notice similar problems with duelling frusta case and all techniques are vulnerable to this case producing worse results. Besides, LispSM may be not particularly well suited for walking / driving sim. If thats the type of your app you probably should consider PSSM. Some day I will maybe contribute TrapezoidalShadowMap (but its not going to happen in next few months I am afraid). Tsm may be better suited for low moving camera than LispSM but it will still be far from perfect PSSM is usually considered to be most universal technique with reasonably controllable shadow quality. However, I did not used this technique myself so I cannot delve into its details. Cheers, Wojtek Lewandowski From: Ramy Gowigati Sent: Tuesday, March 15, 2011 8:13 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] ViewDependentShadow massive flickering problems Hi, Sorry guys, I know this thread hasn't been active for quite sometime, but I am also using LightSpacePerspectiveShadowMapVB and im getting flickering and artifacts. To be honest I kinda got lost in the replies as to how to fix the flickering and artifacts. I also have a large outdoor scene and used LightSPSM for my shadows. Shadows on some buildings are stable, but on others it flickers very fast. my scene is almost 1Km x 1Km more or less. I set the near light distance to something small and far distance to some distance beyond the camera, but not too far in the distance (since its a big scene). Reading the thread topic I knew this was my problem also, but I am lost in the replies. Any clarifications please? If it helps I'm using OSG 2.8.3. Thank you! Cheers, Ramy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37634#37634 ___ 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] StandardShadowMap and Render To Texture
View Dependent Shadow techniques don't work with nested cameras. They work with RTT Slave cameras though. Cheers, Wojtek -Original Message- From: "Martin Großer" Sent: Wednesday, February 16, 2011 4:44 PM To: OpenSceneGraph Users Subject: Re: [osg-users] StandardShadowMap and Render To Texture OK, you are right, but that is not my problem. I don't want the shadow texture, which need the DEPTH_BUFFER. I want the "final" rendering in my texture. The basic graph looks like this: ROOT | rtt_cam (the result has no shadows) | shadowedScene (with StandardShadowMap) | camera (is also a render to texture camera) I hope it is better explanation of my problem. Cheers Martin Original-Nachricht Datum: Wed, 16 Feb 2011 16:19:09 +0100 Von: "Wojciech Lewandowski" An: osg-users@lists.openscenegraph.org Betreff: Re: [osg-users] StandardShadowMap and Render To Texture Maybe your problem is related to the fact that Shadow maps are usually stored in DEPTH_BUFFER (not COLOR_BUFFER). Wojtek Lewandowski -Original Message- From: "Martin Großer" Sent: Wednesday, February 16, 2011 3:47 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] StandardShadowMap and Render To Texture Hello, Every day a new problem. :-) Ok, so my Render To Texture works, but my shadows are not visible in the texture (rendertarget). My Settings: rtt_cam->setRenderOrder(::osg::Camera::PRE_RENDER, 0); rtt_cam->setRenderTargetImplementation( osg::Camera::FRAME_BUFFER_OBJECT ); rtt_cam->attach(::osg::Camera::COLOR_BUFFER, rtt_tex, 0, 0); Is the Problem the pre rendering? Because the standard shadow map has also a pre render camera. I am not sure which camera do the first rendering. Or is it another Problem? Cheers Martin -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StandardShadowMap and Render To Texture
Maybe your problem is related to the fact that Shadow maps are usually stored in DEPTH_BUFFER (not COLOR_BUFFER). Wojtek Lewandowski -Original Message- From: "Martin Großer" Sent: Wednesday, February 16, 2011 3:47 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] StandardShadowMap and Render To Texture Hello, Every day a new problem. :-) Ok, so my Render To Texture works, but my shadows are not visible in the texture (rendertarget). My Settings: rtt_cam->setRenderOrder(::osg::Camera::PRE_RENDER, 0); rtt_cam->setRenderTargetImplementation( osg::Camera::FRAME_BUFFER_OBJECT ); rtt_cam->attach(::osg::Camera::COLOR_BUFFER, rtt_tex, 0, 0); Is the Problem the pre rendering? Because the standard shadow map has also a pre render camera. I am not sure which camera do the first rendering. Or is it another Problem? Cheers Martin -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Main frame buffer corruption when using a slave camerato POST_RENDER to a FBO
Hi Roger, Did you try to run addSlave & removeSlave wrapped in stopThreading / startThreading call ? We recently learned in similar case like yours (postrender HUD), that its really needed if slave is added/removed after realize. Without this Update traversal was entering the graph while Cull/Draw traversals were active in other thread. Wojtek -Oryginalna wiadomość- From: Roger James Sent: Saturday, February 12, 2011 1:19 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Main frame buffer corruption when using a slave camerato POST_RENDER to a FBO Hi, I am seeing a a strange corruption of the main frame buffer when I use a slave camera to render to a frame buffer object and set the camera render order to POST_RENDER. The camera is set up like this. Code: pCamera->setClearColor(pViewer->getCamera()->getClearColor()); pCamera->setViewport(0, 0, Width, Height); pCamera->setRenderOrder(osg::Camera::POST_RENDER); pCamera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT, osg::Camera::FRAME_BUFFER); pCamera->setComputeNearFarMode(osg::Camera::DO_NOT_COMPUTE_NEAR_FAR); pCamera->attach(osg::Camera::COLOR_BUFFER, pImage.get()); pCamera->setGraphicsContext(pViewer->getCamera()->getGraphicsContext()); // pViewer->stopThreading(); It seems to work without this, but Robert says it is needed, maybe it is not always needed for simple setups pViewer->addSlave(pCamera.get()); pViewer->frame(); pViewer->removeSlave(pViewer->findSlaveIndexForCamera(pCamera.get())); // pViewer->startThreading(); Immediately aftere this code has executed and before the next frame the the main frame buffer scene has had a white half circle painted over it in approximately the top third of the viewport. If I don't remove the slave camera and allow it to render in following frames the white half circle still dissappears on the following frames. I can fix this by setting the slave camera to PRE_RENDER in this case. But I am really puzzled by this behaviour. Does anyone have any idea on what is happening here? Why should a camera that has been set to render to a FBO be causing things to be drawn in the real frame buffer? Roger -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36577#36577 ___ 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] Some question about osgShadow... can someone helpme?
Axel,
I am on Windows but imho CMakeLists.txt should contain osgShadow among
REQUIRED osg libs. See the example below:
#
cmake_minimum_required (VERSION 2.6)
set( APP_NAME my_applet )
project (${APP_NAME})
set( CMAKE_DEBUG_POSTFIX "d" )
find_package (OpenGL REQUIRED)
find_package (OpenSceneGraph REQUIRED osgDB osgViewer osgShadow osgText
osgGA osgUtil )
include_directories (${OPENSCENEGRAPH_INCLUDE_DIR})
file(GLOB shader_files shaders/*.glsl shaders/*.frag shaders/*.vert
data/*.glsl data/*.frag data/*.vert)
file(GLOB cpp_files *.cpp src/*.cpp)
file(GLOB h_files *.h src/*.h)
source_group("Shader Files" FILES ${shader_files} )
add_executable(${APP_NAME} ${cpp_files} ${h_files} ${shader_files} )
# CMAKE_DEBUG_POSTFIX works only for libs. Lets make executable suffixed
also.
set_target_properties( ${APP_NAME} PROPERTIES DEBUG_POSTFIX
${CMAKE_DEBUG_POSTFIX} )
target_link_libraries( ${APP_NAME} ${OPENSCENEGRAPH_LIBRARIES} )
target_link_libraries( ${APP_NAME} ${OPENGL_LIBRARY} )
#
Cheers,
Wojtek
-Original Message-
From: Axel Spirtaat
Sent: Wednesday, February 02, 2011 4:47 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Some question about osgShadow... can someone
helpme?
Hi Wojtek,
thank you for reply and suggestions.
Wojciech Lewandowski wrote:
Axel,
Messages suggest that Linker cannot find symbols. Looks to me as missing
osgShadow lib in your make file.
I was supposing this, and of course I need to change the make file.
Unfortunatelly, to create the make file I used the cmake, and my
CMakeLists.txt contains the several lines of 4 CMakeLists.txt
(openScenegraph 2.3.3, bullet physics 2.76, osgWorks and osgBullet). I
checked the OpenSceneGraph's one, but seems that I haven't forgotten
anything... seems.
I also inclueded all #include main.cpp (the osgshadow app works properly). However, I enclose my
CMakeLists.txt file if you have some second... or can you suggest me any
other solution to solve this?
Wojciech Lewandowski wrote:
Axel,
For the small scene like yours simplest ShadowMap technique should be
sufficient. I am recomending it because, extending this technique to
support
multiple lights will be easiest thing to do. Its still advanced stuff but
probably not that complex as extending other techniques. Basically you
would
need to multiply resources associated with shadows/light sources. So
instead
of single resource of each type, you will need array of shadow cameras,
shadow textures, shadow texgens indexed by light ids.
Your modifications will mostly override ShadowMap::cull method. All
technique important work is done there. You will need to take most of the
code from this method (except first part traversing scene for main view
where shadows are applied) and put it into the loop iterating on all your
lightsources rendering neccessary shadows with their cameras and applying
proper texgens. And thats generally all whats needed in a shortcut.
Hopefully when you do this you will learn enough to hack other
techniques...
These suggestions are really precious to me. I hope to solve the make
problem to try my scene with one light and then try to implement your
suggestions with multiple lights.
Thank you again
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=36276#36276
Attachments:
http://forum.openscenegraph.org//files/cmakelists_162.txt
___
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] Some question about osgShadow... can someone helpme?
Axel, Messages suggest that Linker cannot find symbols. Looks to me as missing osgShadow lib in your make file. For the small scene like yours simplest ShadowMap technique should be sufficient. I am recomending it because, extending this technique to support multiple lights will be easiest thing to do. Its still advanced stuff but probably not that complex as extending other techniques. Basically you would need to multiply resources associated with shadows/light sources. So instead of single resource of each type, you will need array of shadow cameras, shadow textures, shadow texgens indexed by light ids. Your modifications will mostly override ShadowMap::cull method. All technique important work is done there. You will need to take most of the code from this method (except first part traversing scene for main view where shadows are applied) and put it into the loop iterating on all your lightsources rendering neccessary shadows with their cameras and applying proper texgens. And thats generally all whats needed in a shortcut. Hopefully when you do this you will learn enough to hack other techniques... Cheers, Wojtek -Original Message- From: Axel Spirtaat Sent: Wednesday, February 02, 2011 9:53 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Some question about osgShadow... can someone helpme? Hi Steven, thanks for reply. I tryed to add shadows on my scene copying the osgShadow demo example. When I clean&build the project, the make returns an error... I don't understand why. Can you help me? Here is the code I added to my project: Code: int ReceivesShadowTraversalMask = 0x1; int CastsShadowTraversalMask = 0x2; osg::ref_ptr shadowedScene = new osgShadow::ShadowedScene; shadowedScene->setReceivesShadowTraversalMask(ReceivesShadowTraversalMask); shadowedScene->setCastsShadowTraversalMask(CastsShadowTraversalMask); osg::ref_ptr st = new osgShadow::StandardShadowMap; shadowedScene->setShadowTechnique(st.get()); shadowedScene->addChild(root); viewer.setSceneData(shadowedScene.get()); I alo removed a light, and added the one to shadoewScene and set a model to cast and receive shadows... The make error is the following: Linking CXX executable ../bin/Room CMakeFiles/Room.dir/main.cpp.o: In function `main': main.cpp:(.text+0x621): undefined reference to `osgShadow::ShadowedScene::ShadowedScene(osgShadow::ShadowTechnique*)' main.cpp:(.text+0x698): undefined reference to `osgShadow::StandardShadowMap::StandardShadowMap()' main.cpp:(.text+0x6d0): undefined reference to `osgShadow::ShadowedScene::setShadowTechnique(osgShadow::ShadowTechnique*)' collect2: ld returned 1 exit status make[2]: *** [bin/Room] Error 1 make[1]: *** [src/CMakeFiles/Room.dir/all] Error 2 make: *** [all] Error 2 I tryed to change ShadowTEcnhique but I obtain the same issue... :( -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36255#36255 ___ 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] Converting DrawArrays(TRIANGLE_STRIP)to DrawElements(TRIANGLES)
Hi Guys, You probably know this but if not it may be other option for you. One can define restart index that works as terminator for triangle/quad strips (check GL_NV_primitive_restart extension) . So in practice multiple triangle strips can be separated by restart indices and put into one physical PrimitiveSet. Other option doing the same is adding 2 degenerated triangles (2 extra indices or vertices) linking end of prior strip with start of next strip. And you can use this trick on older boards in the same way as primitive terminator. Cheers, Wojtek -Oryginalna wiadomość- From: Jean-Sébastien Guay Sent: Friday, January 28, 2011 4:44 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Converting DrawArrays(TRIANGLE_STRIP)to DrawElements(TRIANGLES) Hi Tim, If I understand correctly how the sky dome mesh is constructed, there was a lot of duplication of vertices in the triangle strip arrays, and this has been carried forward into your indexed mesh approach. The INDEX_MESH optimizer would remove these duplicates. The order of the triangles in the output of INDEX_MESH should be the same as the input order, but it might be tricky to pick corresponding triangles out of the new mesh. Since this is such a regular mesh, the vertex cache optimizers would make a small difference; however, you would totally lose the order of the mesh. Incidentally, I tried running the INDEX_MESH optimizer on the created subgraph (at the end of the constructor in the file I attached in my previous post) but it would crash in MyTriangleOperator::operator() - it goes out of bounds on the _remapIndices list. The other two optimizers also go out of bounds in similar ways. Here's a modified Sphere.cpp with the code from the MeshOptimizers simply copied into it (for simplicity of testing) if you want to have a look. I'm still not sure the order of the mesh is really important. I said that before because it would have explained why the strips were arranged like that, but I'm not sure now. So if I could get the INDEX_MESH optimizer not to crash, I think using that and the other two (post/pre transform) would probably work well. I could test it and see at least. What was the actual performance difference? With only the skydome in the scene, Draw went from about 0.45 to 0.4 on my i7 920 + GTX 260. However it made the number of batches (draw calls) go way down, of course - replacing 768 draw calls by 16 is good, but I guess we could do better. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizing scene structure and geometry
Hi Guys, Its really interesting observation about this 3 ms bind time. I suspect this might be a shadow map. 3 ms could be actually a time needed for shadow map rendering stage to finish ... If you are desperate you may consider building the database used only for shadow casting (and using proper Casts & Receives node masks to select it). Such database can be stripped from allmost all textures (only translucent textures are needed) and many other state attribs. Then it can be probably optimized till it hurts. Allmost all geometry can be probably put into single indexed triangle set. If you got coplanar geometry - some of it can be removed. Of course such stripping the DB may be a challenge, but I believe J-S have done this already ;-)... Wojtek Lewandowski -Oryginalna wiadomość- From: Ramy Gowigati Sent: Friday, January 28, 2011 4:38 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Optimizing scene structure and geometry Hi, I am in the same stage now, optimizing a shadowed scene that is 1.5M triangles big (according to the stats). I did several optimizations, but still no where near what I am targeting for. Its the same, large outdoor scene, but in my case everything is fairly static. And the camera navigates around and in some areas the camera can see pretty much all the scene, and that is where the performance plummets pretty fast! I tried to minimize the StateSets in my models when I load them. I simply grouped together the geometry that use a common StateSets. That helped in terms of StateSet changes and FPS time (I can't find my stats that I wrote down back then at the moment). Also we created LODs on the high res models, that cut down a lot of tri's, but still not the performance we want. Something useful I found was to place an OcclusionQuery node on my models and hide them out when they are being occluded by another building or a small part of them is not shown. But recently (and the most interesting to me so far), I tried out the nVidia nSight tool. I ran my application and it gave me a detailed analysis of the OpenGL calls and the min, max and agv. timing they took. So I discovered one of the glBindTexture commands took over 3 milliseconds! That was the highest since the average was somewhere around 0.5-0.7. Did anybody by any chance use nSight and saw how useful it is in the optimizing process? I will play around more on this tool and see what I can do. I hope these suggestions would help if you haven't already tried them. Always looking for new optimization techniques :D Cheers, Ramy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36116#36116 ___ 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] MinimalShadowMap and specular
Hi Cyril,
Good shoot ;-). You got me. Its the bug, vertex and fragment shaders are
inconsistent ;-) StandardShadowMap Vertex shader produces specular term on
SecondaryColor but fragment shader expects specular added to primary color
and assumes gl_Color contains both diffuse and specular.
See attached modified StandardShadowMap.cpp. I hope it will do better
speculars ;-) But I have no time nor model at hand to test it now, so if you
are anxious you are going to be the first user. Let me know how the tests
passsed.
It also contains alternative set of shaders that does not use vertex
shaders. This alternative shaders can be activated with setting
FRAGMENT_SHADERS_ONLY to 1. They will work correctly only if 1 light is
active.
I will send this to submissions lists soon but not today as I need to test
it first
Cheers,
Wojtek
-Original Message-
From: Cyril Bondue
Sent: Wednesday, January 26, 2011 7:25 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] MinimalShadowMap and specular
Hello,
I'm using MinimalShadowMap in an application and I would like to display
objects with their specular value. But whenever I use a sub class of
StandardShadowMap my objects appear totally "matte finish".
If I use ShadowMap my objects are well rendered with specular so the problem
comes from MinimapShadowMap I guess. I looked in the code but wasn't able to
find anything that could solve my problem. Is there something I'm missing?
Here is my code for light parameters and shadow :
Code:
//light
_light->setAmbient(osg::Vec4(0.35, 0.35, 0.35, 1.0f));
_light->setDiffuse(osg::Vec4(0.65, 0.65, 0.65, 1.0f));
_light->setSpecular(osg::Vec4(1.0f,1.0f,1.0f,1.0f));
_light->setPosition(osg::Vec4(30, 30, 170, 1));
//shadows
osg::ref_ptr sm = new
osgShadow::MinimalShadowMap();
sm->setTextureSize(osg::Vec2s(2048, 2048));
sm->setLight(_light);
_sceneRoot->setShadowTechnique(sm.get());
I'm using Windows 7 pro 32 bits, with an ATI X1950XT card and the lastest
drivers. I got the same result using osg 2.8.3 or 2.9.7.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35998#35998
Attachments:
http://forum.openscenegraph.org//files/specular_nospecular_480.jpg
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified
under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*
* ViewDependentShadow codes Copyright (C) 2008 Wojciech Lewandowski
* Thanks to to my company http://www.ai.com.pl for allowing me free this
work.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
using namespace osgShadow;
#define DISPLAY_SHADOW_TEXEL_TO_PIXEL_ERROR 0
#define FRAGMENT_SHADERS_ONLY 0
StandardShadowMap::StandardShadowMap():
BaseClass(),
_polygonOffsetFactor( 1.1f ),
_polygonOffsetUnits( 4.0f ),
_textureSize( 1024, 1024 ),
_baseTextureUnit( 0 ),
_shadowTextureUnit( 1 ),
_baseTextureCoordIndex( 0 ),
_shadowTextureCoordIndex( 1 )
{
#if FRAGMENT_SHADERS_ONLY
_mainFragmentShader = new osg::Shader( osg::Shader::FRAGMENT,
" // following expressions are auto modified - do not change them:
\n"
" // gl_TexCoord[0] 0 - can be subsituted with other index
\n"
"
\n"
"float DynamicShadow( );
\n"
"
\n"
"uniform sampler2D baseTexture;
\n"
"
\n"
"void main(void)
\n"
"{
\n"
" vec4 colorAmbientEmissive =
gl_FrontLightModelProduct.sceneColor;
\n"
" // Add ambient from Light of index = 0
\n"
" colorAmbientEmissive += gl_FrontLightProduct[0].ambient;
\n"
" float shadow = DynamicShadow();
\n"
" color *= mix( colorAmbientEmissive, gl_Color, shadow );
\n"
" color.rgb += gl_SecondaryColor.rgb * shadow;
\n"
#if DISPLAY_SHADOW_TEXEL_TO_PIXEL_ERROR
" color.xy = abs( dFdy( gl_TexCoord[1].xy / gl_TexCoord[1].w ) )*
1024.0; \n"
" color.z = color.y; \n"
" color.x = color.z
Re: [osg-users] Optimizing scene structure and geometry
Hi J-S, [..] My next step is eliminating textures that repeat, to even further improve texture atlas generation. This will again lead to some graphical artifacts unfortunately... I did the test of removing almost all statesets after scene load. The result was that most of the time, the frame rate was close to or at 60. In the worst case scenario (whole scene visible, which is also what I'm giving you stats for since the beginning) it went to about 50 fps in our simulator, so it's not just statesets that are a problem. I think I really need to lower statesets and primitivesets in combination to be able to get good results. I agree. I must admit I have lied to you (unintentionally;-) when I said that our frmerate increase was due to statesets removal. I checked the code and we later run optimizer again meging meshes. I also checked the toolset on my new PC and speed increase does not seem to be that high on GF 280 GTX (150%) as it used to on GF 8800 (200%). I'll also look at decreasing the cull time, since in practice that should pay off in double (because of the shadow pass) and even quadruple or more sometimes (ocean can have reflection turned on, for now we've turned it off; also we often have extra picture-in-picture view(s) to render in addition to the main view). I think I may have hint for you. Check if ComputeBoundsVisitor is used MinimalShadowMap::computeShadowReceivingCoarseBounds(). If it does it will add to overall cull time. With complex scenes it may take some time. Its only used to compute rough bounds of the scene so in many occasions it can be computed once or replaced with constant Bounding box. Yo may need to overwrite technique and the above method for this, though. Cheers, Wojtek -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizing scene structure and geometry
Hi J-S, No, we use the ViewBounds type. and I forgot to mention in my arguments to reproducing the results in the osgshadow example that I also used ViewBounds. Sorry about that, seems even with my very long post I was still missing some specifics :-) Command line for osgshadow was not indicating this. Default is DrawBounds and I assumed you use this. One problem unfortunately is that some textures could not be included in the atlases (because they are set to REPEAT), and sometimes not only textures change, but also some render state such as cull face (some fences made with a single polygon set to render both sides, for example). I'll have to get our artist to model these kinds of things as boxes, and replace the textures set to REPEAT. Yeah, but if we can remove texture state attributes we may usually get rid of majority of StateSets and end up with really small number of unique StateSets created by combinations of remaining attributes. Textures cannot be always put into Texture atlasses thats why we finally built Texture2DArray. Btw I just noticed you mentioned that you can send your DB for others to check. If you want you may send it to me, I may try to run the same tool on your DB and report what I got. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizing scene structure and geometry
J-S, You have not mentioned which lispsm is used but if thats DrawBounds (flavour) it does 2 extra cull & render passes. Shadow map pass is preceeded with depth buffer render pass used to compute DrawBounds. I should also mention that this computation is made using ReadPixels and scanning the picture on CPU. But picture is small (64x64) and I once did tests on performance penalty for ReadPixels at GF 8800, and they not seemed to be a bottleneck. I turned off reading after first succesful ReadPixels and framerate did not changed. But I guess this situation may change with different GPUs. Our DBs are also made from small batches. My observations were that not only the size of primitive sets but small state attribute changes between them were hitting hard as well. I once did an experiment. We had a DB that was suffering from small batches problem. I have built Texture Atlases, then put all the scene Textures into single Texture2DArray (yes it was huge). Then I removed Statesets and created only one StateSet at scene root with Shaders to use Texture2DArray I built. I think I have not done anything to primitve sets they were the same as before only StateSets were gone. And framerate went up 2 times. Cheers, Wojtek -Oryginalna wiadomość- From: Jean-Sébastien Guay Sent: Friday, January 21, 2011 10:13 PM To: OpenSceneGraph Users Subject: [osg-users] Optimizing scene structure and geometry Hi all, I thought I had a pretty firm grasp on what to optimize given a certain set of scene stats, but I've optimized what I can and I'm still getting little improvement in results. So I'll explain my situation here and hope you guys have some good suggestions. Sorry if this is a long message, but I prefer to give all the relevant data now rather than get asked later. The whole scene is about a 200m x 200m square (apart from the ocean and skydome but these are not significant, I have removed them and confirmed that the situation is the same). The worst case viewpoint is a flying view where the whole scene could be visible at once. So I need to balance culling cost with draw cost, since in some views we will see only part of the scene (so we should be able to cull away at least part of what's not visible) and in the flying view everything is visible so we shouldn't waste too much time doing cull tests which we know will not cull anything. The other thing is that there are a lot of dynamic objects, so there are a lot of transforms. But I can't change this, it's part of our simulation. So, after doing some optimization (removing redundant groups, building texture atlases where possible, merging geodes and geometry, generating triangle strips, most of which I did with the osgUtil::Optimizer), I get the following stats, which I'll talk about a bit later: Scene stats: StateSets 1345 Groups 392 Transforms 672 Geodes 992 Geometry 992 Vertices139859 Primitives 87444 Camera stats: State graphs 1282 Drawables 2151 PrimitiveSets 73953 Triangles 3538 Tri. Strips 211091 Tri. Fans16 Quads 11526 Quad Strips 534 Total primitives 226705 And, both in our simulator and in osgViewer, for the same scene and same viewpoint, I get: FPS: ~35 Cull: 5.4ms Draw: 19ms GPU: 19ms This is on a pretty good machine: Core i7 920, GeForce GTX 260. First of all, the stats above tell me that the "Primitives" part of the scene stats refers to primitive sets, not just primitives... Since the camera stats tell me there are over 226000 primitives in the current view. As you can see, the number of primitiveSets is very high. If I understand correctly, each PrimitiveSet will result in an OpenGL draw call, and since my draw time is what's high now, I would want to reduce that (since I'm currently at about 3 primitives per primitiveSet on average). If I remove triangle strip generation from the optimizer options, the stats become: Scene stats: StateSets 1345 Groups 392 Transforms 672 Geodes 992 Geometry 992 Vertices190392 Primitives 51197 Camera stats: State graphs 1254 Drawables 2117 PrimitiveSets 4899 Triangles 17122 Tri. Strips 191 Tri. Fans 7212 Quads106464 Quad Strips 534 Total primitives 131523 This indicates to me that the tristrip visitor in the optimizer does a pretty bad job. I looked at an .osg dump, and it seems to generate a separate strip for each quad (so one strip for 4 vertices) which is ridiculous... But that's a subject for another day. When I disabled the tristripper, you can see a massive decrease in the number of primitiveSets (and even in the number of primitives), however there was no significant change in the frame rate and timings. I don't understand this. I would have expected, with more primitives per primitiveSet (I'm now at about 26 prims per primSet on average, as opposed to around 3 before) and
Re: [osg-users] multiple tex gen modes in a single scene
Brad, It really sounds like texgen stage conflict. You can use up to 8 texgens concurently (stages 0..7). PositionalStates (including TexGens) are apllied at start of render stage and not changed during rendering. So if there are more then one texgen on particular stage, only one will be used (I am not sure which will win the race). If you are sure, texgens are applied on unique stages, check if your shaders use the correct texgen indices. Wojtek -Oryginalna wiadomość- From: Christiansen, Brad Sent: Friday, January 21, 2011 9:29 AM To: OpenSceneGraph Users Subject: Re: [osg-users] multiple tex gen modes in a single scene Hi, I have a small amount of extra info to add, which confuses me even more. Revisting all my code I discovered that my overlays actualy use two eye linear tex gens (one for close items, one for distant ones, a bit like the parralel split shadow maps) with different matrices and different units. These work fine in isolation, but don't work when I add in the third shadow tex gen. The code that adds the tex gens to the positional state container is almost identical. I am now very confused as to why I can use two tex gens for my overlays but it wont work with shadows added. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Christiansen, Brad Sent: Friday, 21 January 2011 3:47 PM To: OpenSceneGraph Users Subject: Re: [osg-users] multiple tex gen modes in a single scene Hi Robert, I am currently adding shadows to my scene (which is going well) but in doing so I have hit this issue. I already use an eye linear tex gen in my scene to render overlays (very similar code to the osgSim::OverlayNode). I don't think it would be possible for me to split the renderering accross two different RenderStages as the two tex gens are used from within the same shader to render my terrain (one for applying shadows and the other for applying overlays). I have had a look at the PositionalStateContainer class and I do not understand why the issue exists. The tex gens use different texture units and as such there matrices are stored and applied seperately. However the result I am seeing is one of the two always 'wins' and its matrix is applied to both tex gens. This is an issue I will need to resolve so I am hoping you could provide some more guidance as to what would be the best solution. Cheers, Brad -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, 13 January 2011 6:27 PM To: OpenSceneGraph Users Subject: Re: [osg-users] multiple tex gen modes in a single scene Hi Paul, Eye linear glTexGen is positional state, i.e. it's value depends on the current modelview matrix, so has to be treated by the OSG like other positional state like glLight and glClipPlane. All positional state has to be positioned by a positional state node, and for glTexGen this is TexGenNode. During the cull traversal the OSG collects the positional state and binds the TexGen/Light/ClipPlane to modelview matrix at that point in traversal, this binding is done via the PositionalStateContainer, and there is one of these per RenderStage. During the draw traversal the positional state is then applied prior to the traversal of the RenderStage, and fixes each positional state in the appropriate place. While this technique doesn't properly fix the state as required, it does limit you to one position, per stage, you can't have two eye line tex gens/lights/clip planes applied on two separate subgraphs. Object linear TexGen isn't positional state so can be applied in the normal way and you have multiple of these per stage without problem. To have multiple Eye linear TexGen/TexGenNode's you'll need to break the scene up into multiple RenderStage and use the clear mask set to 0 on the subsequent stages so that each stage overlays correctly on the previous one. Other approaches are to write a custom TexGen that you push/pop a custom modelview matrix. I'm afraid both approaches are rather hacky. Robert. On Thu, Jan 13, 2011 at 2:28 AM, Paul Martz wrote: Hi all -- Has anyone ever successfully used multiple TexGen modes (say, EYE_LINEAR and OBJECT_LINEAR) on different objects in the same scene? What is the recommended way to do this in OSG? The TexGenNode has a pointer to a TexGen, and the TexGen has the mode. I assume I should create two TexGens, one OBJECT_LINEAR and one EYE_LINEAR, and two TexGenNodes to reference them, and add the two TexGenNodes to the scene graph. Then, I assume I should attach the same two TexGens as StateAttributes to different Node's StateSets as needed. I am running into some issues with this. If it sounds like I'm doing everything right, I'll post a small example that fails, or dig into the OSG code. More than likely, I'm doing someth
Re: [osg-users] Shadows in OSG
Hi Linda, Its large and advanced topic. Various techniques work in different way. I simply do not have the time to explain it. Besides, I follow the rule to not respond in much more words than question asked (hint). If you are interested in Shadow Mapping I may recomend starting from osgShadow::ShadowMap implementation. See ShadowMap::cull method. Its the place where all the relevant code is located. However be warned, that to fully understand it one needs to understand how OSG culling and rendering backend works so its really stuff for advanced developers. Wojtek -Oryginalna wiadomość- From: Linda Lee Sent: Monday, January 17, 2011 2:42 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Shadows in OSG Hi, How about learning the way OSG structures the shadow code. I found it difficult understanding how OSG manage shadow. Could anyone briefly explain the shadow codes in OSG or is there any way I could learn more on them? Thank you! Cheers, Linda -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35694#35694 ___ 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] Shadows in OSG
I suggest this presentaton to learn basics: http://developer.nvidia.com/object/cedec_shadowmap.html and then this page offers enough reading for months ;-): http://developer.nvidia.com/object/doc_shadows.html Wojtek Lewandowski -Oryginalna wiadomość- From: Linda Lee Sent: Monday, January 17, 2011 4:51 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Shadows in OSG Hi everyone, I am trying to learn to the detail implementation of shadowing in OSG and maybe to develop my own shadow technique. Could anyone give some advices on where I should get started or if there is any online resources that I could start learning with? Thank you! Cheers, Linda -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35673#35673 ___ 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] different rendering states for different passes?
Hi Peter, For situation like yours I would recommend overwriting osgShadow::LightSpacePerspectiveShadowMapVB and its internal ViewData class. Internal ViewData contains all the resources you need including shadowCamera. You may then add your own uniform or change any states used for shadow map prerender or final render. See StandardShadowMap::ViewData::init method to learn what states are set by these ShadowTechniques. Btw, if you look there you, will notice that shadow prerender pass overrides any program with fixed pipeline NULL program. So unless you set you shaders with PROTECTED attribute you may not need the uniform. I think we already wrote about overriding ViewDependentShadowTechniques in the past. If you look carefully you would find posts with neccessary example code. Cheers, Wojtek -Oryginalna wiadomość- From: Peter Amstutz Sent: Thursday, January 13, 2011 4:48 PM To: OpenSceneGraph Users Subject: [osg-users] different rendering states for different passes? Hello all, I have a bit of a knotty problem and was hoping for some advice. I am using OSG 2.8.3. I am using osgShadow::LightSpacePerspectiveShadowMapVB, which renders the scene in two passes; the prerender stage renders the shadow map, the main state renders the scene. My understanding is that the behavior of the two passes is controlled by setting different shader programs at the scene root, which sets the default shader program for the whole scene. However, I am also using shader programs at some of my leaf nodes. I would like it to accept shadows, so it needs to read the shadowTexture uniform. However, this uniform is only available on the main drawing pass, not the prerender pass (since the purpose of the prerender pass is to generate the shadow texture). The problem I am encountering is the fact that my shader program does not have a way to distinguish between executing the prerender pass and the main pass, and attempts to read the (non-existent) shadowTexture uniform in the prerender pass, which causes a GL error and results in the node not showing up at all. I know the solution is to use different shaders for different passes, but I haven't figured out the right way to set up OSG to do this at the leaf. Can anyone point me in the right direction? -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ 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] BIND_PER_PRIMITIVE broken?
Hi Jason & Sukender, Hmm... Maybe we could make this even more absurd ;-) Lets consider this: if you propose to use OpenGL Primitive interpretation then N GL_TRIANGLES or N GL_QUADS in one PrimitveSet should be also rather interpreted as one Primitive. Am I right ? Shouldn't we get rid of osg::PrimitiveSet name and replace it with osg::Primitive class then ? (I am not serious ;-) I actually like current OSG primitive semantics and OSG bindings more than GL primitive semantics. But thats just my taste, discussion on what Primitive should be seems rather unproductive to me, and I avoided using this word before. Besides, I am not native speaker so I would rather shut my mouth and don't talk more about this Silent Cheers, Wojtek Lewandowski -Original Message- From: Sukender Sent: Monday, January 10, 2011 5:06 PM To: OpenSceneGraph Users Subject: Re: [osg-users] BIND_PER_PRIMITIVE broken? Yes, Jason. This is why I proposed to have a BIND_PER_ELEMENT, which would do "per triangle/quad" (since OpenGL says a strip is a primitive). Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - "Jason Daly" a écrit : On 01/10/2011 03:46 AM, Wojciech Lewandowski wrote: > Hi, Sukender, > > I think we fully agree both on whats a 'Primitive' and binding > interpretations. I don't think we agree at all... man glBegin NAME glBegin, glEnd - delimit the vertices of a primitive or a group of like primitives C SPECIFICATION void glBegin( GLenum mode ) PARAMETERS mode Specifies the primitive or primitives that will be created from vertices presented between glBegin and the subsequent glEnd. Ten symbolic constants are accepted:GL_POINTS, GL_LINES, GL_LINE_STRIP, GL_LINE_LOOP, GL_TRIANGLES, GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN, GL_QUADS, GL_QUAD_STRIP, and GL_POLYGON. glDrawArrays also refers to the "mode" parameter as specifying "what kind of primitives to render." From what I've read (I just went and did a cursory check), the OpenGL spec agrees with what the man pages. I really don't think we should be redefining what a primitive is, we should stick with OpenGL's terms. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Frederic,
it is my understanding that OpenGL can only do BIND_PER_VERTEX natively.
There is no such thing as a face normal or color. There is only linear
interpolation between values at vertices. So when you share vertex data
in a primitive, you can only share also normal, color and other
attributes.
Interpolation is done when you have GL_SMOOTH shade model. If shade model is
GL_FLAT you can have per face binding. See OpenGL help on glShadeModel
function.
Wojtek
- "Sukender" a écrit :
Hi all,
Interesting discusssion. I didn't guess that it wouyld bring so much
comments!
Well this cannot be a regression as I'm implementing it! I just need
to make it work "the old style" way.
However, I would expect that a primitive is one of {point, line,
triangle, quad}, even id OpenGL says a strip is also a primitive (is
there a naming issue there? Should we have something like "elements",
"primitive" and "primitive set"???). So, for me, PER_PRIMITIVE is a
binding for them, and PER_PRIMITIVE_SET is a binding for a "bunch" of
them :
TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN : primitive = one triangle /
primitive set = all triangles
QUADS, QUAD_STRIP : primitive = one quad / primitive set = all quads
Once again, that's only my point of view.
Actually, OpenGL can do this binding (even if it's slow), so why not
supporting it if it's not that difficult? Should we name it
differently?
Thank you all for your comments and ideas.
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- "Jason Daly" a écrit :
> On 1/8/2011 6:19 AM, Robert Osfield wrote:
> > Hi All,
> >
> > Perhaps we should be asking the question what was the behavior
> prior
> > to the refactor to I did for GL3/OpenGLES support. Sukender did
> your
> > Geometry work previously? Is this a regression or just a
behaviour
> > that you weren't expecting?
>
> Good question!
>
> ---
>
> Somehow I missed Wojtek's post, so I'll reply to that here:
>
> >> glBegin(GL_TRIANGLE)/glEnd() code with 2 triangles and one
normal.
> It will
> >> be correct OpenGL code. Would you say that two triangles
correspond
> to one
> >> OSG primitive or two OSG primitves in this case ? And if you do
not
> pass
> >> normal before second triangle, OpenGL will use last normal passed
> (ie the
> >> one from first triangle):
> >>
> >> glBegin(GL_TRIANGLE);
> >> glNormal3f(...);
> >> glVertex3f(...); //1
> >> glVertex3f(...); //2
> >> glVertex3f(...); //3
> >> // no normal and its no error !
> >> glVertex3f(...); //4
> >> glVertex3f(...); //5
> >> glVertex3f(...); //6
> >> glEnd();
>
> It's two primitives. Yes, you can use the same normal for two
> separate
> triangles, but that doesn't mean it's not two primitives. Actually
> your
> code is slightly incorrect, the glBegin() line should read:
>
> glBegin(GL_TRIANGLES);
>
> I'm not pointing this out just to be pedantic. It's evidence to
> support
> my position that it's actually two primitives (i.e.: two triangles)
> in
> that case :-)
>
>
> >> In the same way OpenGL assumes that last passed normal is used
for
> the
> >> triangle in triangle strip. Triangle Srip is just another method
of
> passing
> >> vertices to OpenGL and each triangle may have its own unique
> normals/colors.
> >> If you don't agree, just do a reverse test: see if below would
> render both
> >> triangles with the same color or different colors. They will
> differ, and
> >> this is also correct OpenGL code:
> >>
> >> glShadeModel( GL_FLAT );
> >> glBegin(GL_TRIANGLE_STRIP);
> >> glColor4f( 1, 0, 0, 1 ); // RED
> >> glVertex3f(0, 0, 0);
> >> glVertex3f(0, 1, 0);
> >> glVertex3f(1, 0, 0);
> >> glColor4f( 0, 1, 0, 1 ); // GREEN
> >> glVertex3f(1, 1, 0);
> >> glEnd();
>
> Yes, I mentioned that in my previous post. It doesn't take away
from
>
> the fact that the triangle strip is considered a single primitive.
>
> I actually wonder what the colors would look like here. Did you
> actually run this code? My guess would be that the final vertex is
> green, but the final triangle would blend from red to green across
its
>
> surface, because its two other vertices were red (as specified in
the
>
> code). I could be wrong (I haven't run the code myself), but
that's
>
> what I would expect. Even if you consider each triangle in the
strip
> a
> different "primitive", you still couldn't get a set of completely
red
>
> triangles, followed by a completely green triangle, which is what
the
> OP
> is looking for.
>
> >> Last argument is actually a postulate for OSG clarity. We have
> >> BIND_PER_PRIMITIVE_SET flag. Shouldn't this flag be rather used
for
> the
> >> situation where we want to one normal / one color etc for all
> triangles in
> >> tristrip ?
>
> If I understand you correctly, then yes. BIND_PER_PRIMITIVE in the
> case
> of triangle strips should mean the same normal/color for each entire
> triangle strip (that's how Performer used to treat it as well). If
I
>
>
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Sukender,
What for ? If we agreed on Primitive meaning a single Triangle from
TriangleStrip then we don't need to change the enums. Current binding
smenatics are valid:
PER_PRIMIITIVE means per triangle
PER_PRIMITIVE_SET means per triangle strip
and of course
PER_VERTEX means per vertex
OVERALL means the same attrib (normal/color) for all primitive sets in
geometry.
Why change that ?
Wojtek
-Original Message-
From: Sukender
Sent: Monday, January 10, 2011 9:59 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Wojtek,
Allright. So what about changing the terms we use? Say BIND_PER_SHAPE /
BIND_PER_PRIMITIVE, or BIND_PER_ELEMENT / BIND_PER_PRIMITIVE?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
----- "Wojciech Lewandowski" a écrit :
Hi, Sukender,
I think we fully agree both on whats a 'Primitive' and binding
interpretations. I actually like your interpretation of primitive
term.
Primitive is always a Triangle and Triangles, TriangleFans and
TriangleStrips are just a methods of passing vertices. But I avoided
using
word Primitive because I had the feeling that it can have slightly
different
semantics in OpenGL docs and different in Performer docs and different
in
OSG.
Wojtek
-Original Message-
From: Sukender
Sent: Monday, January 10, 2011 9:22 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi all,
Interesting discusssion. I didn't guess that it wouyld bring so much
comments!
Well this cannot be a regression as I'm implementing it! I just need
to make
it work "the old style" way.
However, I would expect that a primitive is one of {point, line,
triangle,
quad}, even id OpenGL says a strip is also a primitive (is there a
naming
issue there? Should we have something like "elements", "primitive" and
"primitive set"???). So, for me, PER_PRIMITIVE is a binding for them,
and
PER_PRIMITIVE_SET is a binding for a "bunch" of them :
TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN : primitive = one triangle /
primitive set = all triangles
QUADS, QUAD_STRIP : primitive = one quad / primitive set = all quads
Once again, that's only my point of view.
Actually, OpenGL can do this binding (even if it's slow), so why not
supporting it if it's not that difficult? Should we name it
differently?
Thank you all for your comments and ideas.
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- "Jason Daly" a écrit :
> On 1/8/2011 6:19 AM, Robert Osfield wrote:
> > Hi All,
> >
> > Perhaps we should be asking the question what was the behavior
> prior
> > to the refactor to I did for GL3/OpenGLES support. Sukender did
> your
> > Geometry work previously? Is this a regression or just a
behaviour
> > that you weren't expecting?
>
> Good question!
>
> ---
>
> Somehow I missed Wojtek's post, so I'll reply to that here:
>
> >> glBegin(GL_TRIANGLE)/glEnd() code with 2 triangles and one
normal.
> It will
> >> be correct OpenGL code. Would you say that two triangles
correspond
> to one
> >> OSG primitive or two OSG primitves in this case ? And if you do
not
> pass
> >> normal before second triangle, OpenGL will use last normal passed
> (ie the
> >> one from first triangle):
> >>
> >> glBegin(GL_TRIANGLE);
> >> glNormal3f(...);
> >> glVertex3f(...); //1
> >> glVertex3f(...); //2
> >> glVertex3f(...); //3
> >> // no normal and its no error !
> >> glVertex3f(...); //4
> >> glVertex3f(...); //5
> >> glVertex3f(...); //6
> >> glEnd();
>
> It's two primitives. Yes, you can use the same normal for two
> separate
> triangles, but that doesn't mean it's not two primitives. Actually
> your
> code is slightly incorrect, the glBegin() line should read:
>
> glBegin(GL_TRIANGLES);
>
> I'm not pointing this out just to be pedantic. It's evidence to
> support
> my position that it's actually two primitives (i.e.: two triangles)
> in
> that case :-)
>
>
> >> In the same way OpenGL assumes that last passed normal is used
for
> the
> >> triangle in triangle strip. Triangle Srip is just another method
of
> passing
> >> vertices to OpenGL and each triangle may have its own unique
> normals/colors.
> >> If you don't agree, just do a reverse test: see if below would
> render both
> >> triangles with the same color or different colors. They will
> differ, and
> >> this is also correct OpenGL code:
> >>
> >> glShadeModel( GL_FLA
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi, Sukender,
I think we fully agree both on whats a 'Primitive' and binding
interpretations. I actually like your interpretation of primitive term.
Primitive is always a Triangle and Triangles, TriangleFans and
TriangleStrips are just a methods of passing vertices. But I avoided using
word Primitive because I had the feeling that it can have slightly different
semantics in OpenGL docs and different in Performer docs and different in
OSG.
Wojtek
-Original Message-
From: Sukender
Sent: Monday, January 10, 2011 9:22 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi all,
Interesting discusssion. I didn't guess that it wouyld bring so much
comments!
Well this cannot be a regression as I'm implementing it! I just need to make
it work "the old style" way.
However, I would expect that a primitive is one of {point, line, triangle,
quad}, even id OpenGL says a strip is also a primitive (is there a naming
issue there? Should we have something like "elements", "primitive" and
"primitive set"???). So, for me, PER_PRIMITIVE is a binding for them, and
PER_PRIMITIVE_SET is a binding for a "bunch" of them :
TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN : primitive = one triangle /
primitive set = all triangles
QUADS, QUAD_STRIP : primitive = one quad / primitive set = all quads
Once again, that's only my point of view.
Actually, OpenGL can do this binding (even if it's slow), so why not
supporting it if it's not that difficult? Should we name it differently?
Thank you all for your comments and ideas.
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- "Jason Daly" a écrit :
On 1/8/2011 6:19 AM, Robert Osfield wrote:
> Hi All,
>
> Perhaps we should be asking the question what was the behavior
prior
> to the refactor to I did for GL3/OpenGLES support. Sukender did
your
> Geometry work previously? Is this a regression or just a behaviour
> that you weren't expecting?
Good question!
---
Somehow I missed Wojtek's post, so I'll reply to that here:
>> glBegin(GL_TRIANGLE)/glEnd() code with 2 triangles and one normal.
It will
>> be correct OpenGL code. Would you say that two triangles correspond
to one
>> OSG primitive or two OSG primitves in this case ? And if you do not
pass
>> normal before second triangle, OpenGL will use last normal passed
(ie the
>> one from first triangle):
>>
>> glBegin(GL_TRIANGLE);
>> glNormal3f(...);
>> glVertex3f(...); //1
>> glVertex3f(...); //2
>> glVertex3f(...); //3
>> // no normal and its no error !
>> glVertex3f(...); //4
>> glVertex3f(...); //5
>> glVertex3f(...); //6
>> glEnd();
It's two primitives. Yes, you can use the same normal for two
separate
triangles, but that doesn't mean it's not two primitives. Actually
your
code is slightly incorrect, the glBegin() line should read:
glBegin(GL_TRIANGLES);
I'm not pointing this out just to be pedantic. It's evidence to
support
my position that it's actually two primitives (i.e.: two triangles)
in
that case :-)
>> In the same way OpenGL assumes that last passed normal is used for
the
>> triangle in triangle strip. Triangle Srip is just another method of
passing
>> vertices to OpenGL and each triangle may have its own unique
normals/colors.
>> If you don't agree, just do a reverse test: see if below would
render both
>> triangles with the same color or different colors. They will
differ, and
>> this is also correct OpenGL code:
>>
>> glShadeModel( GL_FLAT );
>> glBegin(GL_TRIANGLE_STRIP);
>> glColor4f( 1, 0, 0, 1 ); // RED
>> glVertex3f(0, 0, 0);
>> glVertex3f(0, 1, 0);
>> glVertex3f(1, 0, 0);
>> glColor4f( 0, 1, 0, 1 ); // GREEN
>> glVertex3f(1, 1, 0);
>> glEnd();
Yes, I mentioned that in my previous post. It doesn't take away from
the fact that the triangle strip is considered a single primitive.
I actually wonder what the colors would look like here. Did you
actually run this code? My guess would be that the final vertex is
green, but the final triangle would blend from red to green across its
surface, because its two other vertices were red (as specified in the
code). I could be wrong (I haven't run the code myself), but that's
what I would expect. Even if you consider each triangle in the strip
a
different "primitive", you still couldn't get a set of completely red
triangles, followed by a completely green triangle, which is what the
OP
is looking for.
>> Last argument is actually a postulate for OSG clarity. We have
>> BIND_PER_PRIMITIVE_SET flag. Shouldn't this flag be rather used for
the
>> situation where we want to one normal / one color etc for all
triangles in
>> tristrip ?
If I understand you correctly, then yes. BIND_PER_PRIMITIVE in the
case
of triangle strips should mean the same normal/color for each entire
triangle strip (that's how Performer used to treat it as well). If I
remember correctly, the OP was looking to get different normals for
eac
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Robert, Jason, I am lazy guy, and I agree with both of you, its only neccessary to make it backward compatibile ;-) However, for purely academic reasons I will respond to Jason. But don't treat my post as call for revolution. Its just my opinion how PER_VERTEX, PER_PRIMITIVE, PER_PRIMITIVE_SET should be resolved for Triangle strips. But, I will state it again, if it was differently done before, then lets keep it as it used to be. Now lets get to our academic discussion: In Jason's post BIND_PER_PRIMITIVE does the same as BIND_PER_PRIMITIVE_SET for Triangle strips. Note that if this was correct behaviour then TriangleStrips with BIND_PER_PRIMITIVE binding could use fast paths. Instead, IMHO thats how these bindings should be translated to glBegin/glEnd OpenGL code: // Color BIND_PER_VERTEX : N vertices, N colors glBegin(GL_TRIANGLE_STRIP); glColor4f( ... ); // set color for each vertex glVertex3f( ... ); glColor4f( ... ); glVertex3f( ... ); ... glColor4f( ... ); glVertex3f( ... ); glEnd(); // Color BIND_PER_PRIMITIVE : N vertices, N-2 colors glBegin(GL_TRIANGLE_STRIP); glVertex3f( ... ); // two verts without colors glVertex3f( ... ); glColor4f( ... ); // starting from third vertex, we pass color for each provoking vertex of triangle glVertex3f( ... ); glColor4f( ... ); glVertex3f( ... ); ... glColor4f( ... ); glVertex3f( ... ); glEnd(); // Color BIND_PER_PRIMITIVE_SET : N vertices, 1 color glColor4f( ... ); // set color once glBegin(GL_TRIANGLE_STRIP); glVertex3f( ... ); // no need for colors glVertex3f( ... ); ... glVertex3f( ... ); glEnd(); With above interpretation, only PER_PRIMITIVE binding cannot be done with fast paths DrawArrays. So general recommendation to avoid BIND_PER_PRIMITIVE as slow path trigger, still makes sense. Second: I would not treat Performer as ultimate reference for resolving all doubts. Performer did not offer PER_PRIMITIVE_SET binding and also had additional PFGS_FLAT_LINESTRIPS, PFGS_FLAT_TRISTRIPS in addition to classic PFGS_LINESTRIPS, PFGS_TRISTRIPS we have in OSG. I actually wonder what the colors would look like here. Did you actually run this code? My guess would be that the final vertex is green, but the final triangle would blend from red to green across its surface, because its two other vertices were red (as specified in the code). I could be wrong (I haven't run the code myself), but that's what I would expect. Even if you consider each triangle in the strip a different "primitive", you still couldn't get a set of completely red triangles, followed by a completely green triangle, which is what the OP is looking for. I ran it and yes you can. I guess, thats what PFGS_FLAT_TRISTRIPS was doing in Performer. With flat shading (activated in example), one triangle is red and second is green. With smooth shading second triangle is colored wtih red -> green gradient. Last argument is actually a postulate for OSG clarity. We have BIND_PER_PRIMITIVE_SET flag. Shouldn't this flag be rather used for the situation where we want to one normal / one color etc for all triangles in tristrip ? If I understand you correctly, then yes. BIND_PER_PRIMITIVE in the case of triangle strips should mean the same normal/color for each entire triangle strip (that's how Performer used to treat it as well). If I remember correctly, the OP was looking to get different normals for each triangle in the strip (to produce a faceted appearance, I think). I don't believe this is possible even in pure OpenGL. The only way to do it is to use distinct triangles for primitives. Well... what you write sounds like you don't agree with me, because I postulate that that BIND_PER_PRIMITIVE should differ from BIND_PER_PRIMITIVE_SET and BIND_PER_VERTEX. And yes I will say that again, its possible to make faceted apperance with triangle strips in OpenGL. Thats was my point in my first post and thats what this short example I posted was doing. Btw good point about GL_TRIANGLES instead of GL_TRIANGLE ;-) Highest Regards ;-) Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi, Jason I generally agree with your post that binding per primitive is a scene graph thing, but I would disagree with such BIND_PER_PRIMITIVE interpretation: BIND_PER_PRIMITIVE is a scene graph thing, it has nothing to do with pure OpenGL. All BIND_PER_PRIMITIVE means is this: glBegin(GL_TRIANGLE_STRIP); glNormal3f(...); glVertex3f(...); glVertex3f(...); ... glVertex3f(...); glEnd(); OpenGL argument against your example: you may also write similar glBegin(GL_TRIANGLE)/glEnd() code with 2 triangles and one normal. It will be correct OpenGL code. Would you say that two triangles correspond to one OSG primitive or two OSG primitves in this case ? And if you do not pass normal before second triangle, OpenGL will use last normal passed (ie the one from first triangle): glBegin(GL_TRIANGLE); glNormal3f(...); glVertex3f(...); //1 glVertex3f(...); //2 glVertex3f(...); //3 // no normal and its no error ! glVertex3f(...); //4 glVertex3f(...); //5 glVertex3f(...); //6 glEnd(); In the same way OpenGL assumes that last passed normal is used for the triangle in triangle strip. Triangle Srip is just another method of passing vertices to OpenGL and each triangle may have its own unique normals/colors. If you don't agree, just do a reverse test: see if below would render both triangles with the same color or different colors. They will differ, and this is also correct OpenGL code: glShadeModel( GL_FLAT ); glBegin(GL_TRIANGLE_STRIP); glColor4f( 1, 0, 0, 1 ); // RED glVertex3f(0, 0, 0); glVertex3f(0, 1, 0); glVertex3f(1, 0, 0); glColor4f( 0, 1, 0, 1 ); // GREEN glVertex3f(1, 1, 0); glEnd(); Last argument is actually a postulate for OSG clarity. We have BIND_PER_PRIMITIVE_SET flag. Shouldn't this flag be rather used for the situation where we want to one normal / one color etc for all triangles in tristrip ? Wojtek Lewandowski ___ 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] DYNAMIC drawables, StateSets, and rendering
Hi Tim, > I've recently been looking hard at the "rendering backend" i.e., RenderStage, > RenderBin, etc. and the rendering traversal in osgViewer::ViewerBase. I was > surprised to find that the State dynamic object count, and the dynamic object > callback that triggers the end of the dynamic barrier, only considers the > data variance of the RenderLeaf drawables. It doesn't seem to account at all > for dynamic StateSet and StateAttribute objects. Is this the intended > behavior? I had always thought that dynamic StateAttribute objects were > protected by the dynamic object barrier. I remember I was doing similar research some time ago. I believe StateAttibutes affect dynamic barrier indirectly. Dynamic StateGraphs (ie those including dynamic StateAttributes) propagate their _dynamic value to associated render leafs. See StateGraph::addLeaf method. Sounds like you still investigate multiple monitor performance loss ? I am also very interested in your results Cheers, Wojtek ___ 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] osgShadow clipping shadows cast from off-camera objects
Hi Peter, Try using MinLightMargin parameter. May help somtimes. Look at the attached picture for its meaning. Cheers, Wojtek Lewandowski -Oryginalna wiadomość- From: Peter Amstutz Sent: Wednesday, January 05, 2011 7:37 PM To: OpenSceneGraph Users Subject: [osg-users] osgShadow clipping shadows cast from off-camera objects Hello all, I am trying to add dynamic shadows to my scene and so far osgShadow::LightSpacePerspectiveShadowMapVB seems to produce the best results [*]. Unfortunately, one problem I am encountering is that shadows cast by geometry located to the side or behind the camera get clipped, leading to a number of artifacts. For example, standing outside a building with the "sun" to your back, the shadow map correctly projects the outline of a doorway onto the floor. However, once the camera enters the building, the wall is clipped and this causes the entire room to be illuminated. This is a very noticeable and undesirable effect. How can I mitigate this problem? [*] I had high hopes for PSSM based on reading about the technique but so far neither osg 2.8.3 nor 2.9.10 produce correct results for me. Thanks! -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ 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] StandardShadowMap effect
Hi Linda, I tried using cow.osg and have similar problem. I tried download the driver from AMD website but the latest version they have is 10.12 and it seems to keep crashing after installed. Do you think there is any work around using the ATI card like change the mapping method for the shadow texture? Or should I keep to find another device or simply abandon this machine? Does osgshadow (without command line params ) crash ? If it does you may check if --SingleThreaded --window 10 10 800 600 options help. They do sometimes. You may also try looking at earlier driver versions. I would check 10.8 and/or 10.9. I believe that with 10.9 or 10.10 ATI introduced OpenGL 4.0 support and this was a chance to break some stuff if it was not broken yet. We still mainly use NVidia cards for OpenGL development and occasionaly switch to ATI to check if the code works there. AMD/ATI improved their OpenGL drivers recently but its clearly still not the same quality as on NVidia. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StandardShadowMap effect
Hi Linda, I tried using ShadowMap and the effect is the same. How do I check if my model is using texture coordinates on the same stage as shadow map (1 by default)? I tried using ShadowTexture and the effect is okay. Does osgshadow example look correct (using shadow map and default scene with rotating shapes) ? Does it look correct when you load different model. ? If they do, then your model could be the cause. Try converting your model to .osg format with osgconv utility. Then load produced .osg file into text editor and look for 'textureUnit 1' sections. If you find one then it means your model does use the same stage as shadow map. But it seems that of all Shadow effects, only Shadow Texture seems to work on my machine. I am using ATI Mobility Radeon HD 4330. Is that an issue? That could be the reason. Older ATI drivers were flipping shadow map texture. Install most recent Catalyst drivers you can find. I have old Radeon X1250 in my laptop. Last Catalyst available for this board are rev 10.2. And they seem to work correctly with shadow maps, but earlier revisions were a disaster. I am sure you will find fresher release than 10.2 for your board. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StandardShadowMap effect
Hi Linda, Looks like shadow map was rendered using different projection than the texture projection which is applied by shadow texgen. This is most probably a result of texgen unit conflict. Does your model use texture coordinates on the same stage as shadow map (1 by default) ? But that issue could be also caused by other factors (old ATI drivers, texture matrix settings etc) so it would be best it you could prepare a test case and post it on forum. You may also try ShadowMap which should give you very similar results to StandardShadowMap and see if the issue is present there. ShadowMap does not use Vertex shaders so if your issue is caused by something in Vertex setup phase it may not appear in ShadowMap. Cheers, Wojtek Lewandowski -Oryginalna wiadomość- From: Linda Lee Sent: Monday, December 27, 2010 2:02 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] StandardShadowMap effect Hi, I tried using StandardShadowMap but however, have strange result as attached. Could anyone give some clue as what went wrong? Thank you! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35176#35176 Attachments: http://forum.openscenegraph.org//files/shadow_213.jpg ___ 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] Cutting geometry out of a scene
Hi Kevin, I don't know if this can be useful for you or not, but you may look at osgSim::CustomPolytope or its remote derivative osgShadow::ConvexPolyhedron. These classes supoport tranformation and cut with other polytopes. Both classes keep reference points for each of the polytope faces. These points basically represent polygons on each of planes of convex polytope. Both classes don't keep other attributes beyound x,y,z vertex coords but it would be straightforward to extend their storage and methods so that they keep more than 3 coordinates per reference point. Cheers, Wojtek Lewandowski -Original Message- From: Paul Martz Sent: Sunday, December 19, 2010 8:41 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Cutting geometry out of a scene On 12/19/2010 12:01 PM, Kevin Bentley wrote: Hi, I'm writing an app that essentially needs to 'cut' some geometry and its textures from a scene, to create a new model. Currently I'm using a PolytopeIntersector to find the faces I'm interested in. The next step is that I need to clip those faces to the boundaries of the Polytope I used to find the intersection. I also need to add some vertices to some of the faces to slightly change the shape. I've been looking at some libraries for geometry operations. I want to preserve the texture mapping if I divide the faces up, and I haven't found a library that I can use to divide the faces and preserve the texture mapping (creating new texture coordinates for the new verts). What I'm wondering is if there is something in OSG already I should be looking at as an example of this type of problem, or if anyone has any hints as to the best way to approach this. I sometimes find myself going down a path to solve a problem the hard way in OSG, then later I find out there's some existing feature I should have used to make life easier. Any tips are very much appreciated! I don't know of an existing OSG-compatible tool for this, but it shouldn't be difficult to implement. Clipping a triangle against a plane is fairly trivial and it sounds like you've already solved that. Use linear interpolation to derive the new texture coordinate; that's what OpenGL does when it clips primitives. -Paul ___ 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] VertexBufferObject usage very slow...
Since you wrote you use gDebugger, please check if glDrawElements index buffers are taken from CPU or GPU memory. If its CPU mem then all should be clear... Wojtek Lewandowski -Original Message- From: Sean Spicer Sent: Friday, December 17, 2010 7:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] VertexBufferObject usage very slow... Robert, Some more data... Looks like we're drawing approx 100K tri-strips every frame. The glDrawElements call is the culprit...though I'm still baffled by why it is so much slower with VBOs than in immediate mode. Perhaps the drawing isn't sorted by VBO so that all of the triangles drawn from each VBO are draw in single bind call ? sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Dec 17, 2010 at 11:37 AM, Sean Spicer wrote: Hi Robert, We are not updating the data frame-to-frame, which is why this is so baffling. I'm working through the issue with gDebugger now - if you don't have any suggestions off the top of your head, then I'll start digging and report back what I find, since I don't have time try and duplicate the issue outside our app. cheers, sean _ Sean Spicer Aqumin (www.aqumin.com) Office+1.713.781.2121 Mobile...+1.713.447.2706 Fax...+1.713.781.2123 On Fri, Dec 17, 2010 at 2:36 AM, Robert Osfield wrote: reproduces the problem you are seeing? ___ 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] osgCal does not build - where is PerContextProgram::getUniformLocation( string ) method ?
YFTFM ? Where ? When ? WL
-Oryginalna wiadomość-
From: Ulrich Hertlein
Sent: Wednesday, December 08, 2010 10:42 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgCal does not build - where is
PerContextProgram::getUniformLocation( string ) method ?
On 9/12/10 0:11 , Robert Osfield wrote:
Do you think it makes sense to add following extra method to
PerContextProgram ?
inline GLint getUniformLocation( const std::string & name )
{
return getUniformLocation( osg::Uniform::getNameId( name ) );
}
For backwards compatibility purposes I have no objection to adding
this method and the above implementation into the OSG. Feel free to
implement, test, *document it*, and post the change to osg-submissions.
FTFY. ;-)
/ulrich
___
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] osgCal does not build - where is PerContextProgram::getUniformLocation( string ) method ?
Thanks Mourad,
That solves my problem. I saw this method used inside the code but did not
notice it is static so I thought it can be used only when we know the uniform
ptr.
Do you think it makes sense to add following extra method to PerContextProgram ?
inline GLint getUniformLocation( const std::string & name )
{
return getUniformLocation( osg::Uniform::getNameId( name ) );
}
Cheers,
Wojtek
From: Mourad Boufarguine
Sent: Wednesday, December 08, 2010 12:47 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgCal does not build - where is
PerContextProgram::getUniformLocation( string ) method ?
Hi Wojciech,
This change was introduced in rev 11952. This new static function in
osg/Uniform should help you to get the (unsigned int) id out of the (string)
name :
static unsigned int getNameID(const std::string& name);
Mourad
2010/12/8 Wojciech Lewandowski
Hi Guys,
The title says it all. We use osgCal and it does not compile anymore.
Compiler does not find Program::PerContextProgram::getUniformLocation( const
std::string & ) while compiling HardwareMesh.cpp. Problem appeared with trunk
change revision 11942:
Where
Program::PerContextProgram::getUniformLocation( const std::string & )
was replaced with:
Program:: PerContextProgram::getUniformLocation( unsigned int )
I tried to look at modified PerContextProgram to figure out how to get
uniform location knowing only uniform name but I was not able to come up with
reasonable idea. Can anyone help me ?
Ideally we could possible retrofit PerProgramContext with a method that would
accept string name ? It does not mean reverting all the code that was changed
recently I would only want to have another version of
PerContextProgram::getUniformLocation( int ) with string parameter so that
osgCall still compile.
Cheers,
Wojtek Lewandowski
___
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] osgCal does not build - where is PerContextProgram::getUniformLocation( string ) method ?
Hi Guys, The title says it all. We use osgCal and it does not compile anymore. Compiler does not find Program::PerContextProgram::getUniformLocation( const std::string & ) while compiling HardwareMesh.cpp. Problem appeared with trunk change revision 11942: Where Program::PerContextProgram::getUniformLocation( const std::string & ) was replaced with: Program:: PerContextProgram::getUniformLocation( unsigned int ) I tried to look at modified PerContextProgram to figure out how to get uniform location knowing only uniform name but I was not able to come up with reasonable idea. Can anyone help me ? Ideally we could possible retrofit PerProgramContext with a method that would accept string name ? It does not mean reverting all the code that was changed recently I would only want to have another version of PerContextProgram::getUniformLocation( int ) with string parameter so that osgCall still compile. Cheers, Wojtek Lewandowski___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.9.10 dev release
Hi, I tried to build static OSG from Trunk on Windows today (VS 2008 Express) even though I turned off the check marks by DYNAMIC_OPENSCENEGRAPH and DYNAMIC_OPENTHREADS, I had issues with static OpenThreads Release config. It was correctly built by librarian into a static lib (not a DLL). However, OT project did not set OT_LIBRARY_STATIC define but was using OPENTHREADS_EXPORTS definition. This of course caused missing function linker errors because OpenThread methods were not static but exported as if in DLL. I did not test Debug becaue I was short on time. So there is a chance the same may happen in Debug config. Cheers, Wojtek Lewandowski -Oryginalna wiadomość- From: Robert Osfield Sent: Tuesday, December 07, 2010 9:52 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Please test svn/trunk in prep for 2.9.10 dev release Hi Peter, Could you post the whole modified file to osg-users so I can review the change whilst avoiding the chance of mis-interpreting your suggestion. Cheers, Robert. On Tue, Dec 7, 2010 at 8:29 PM, Peter Wrobrl wrote: Hi, Issues with osgWidget My System: Widows 7 x64, VS2010 Building for x64 osgWidget couldn't build ( Input.cpp ) due to: 'inserter' : is not a member of 'std' fixed that with #include iterator Cheers, ParticlePeter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34590#34590 ___ 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] Getting light-space depth of main pass fragment
Hi Yes, that explains it. And it works, thanks a lot. Just to confirm, since both MinimalDrawBoundsShadowMap and MinimalCullBoundsShadowMap call MinimalShadowMap::frameShadowCastingCamera() and don't do anything to the camera's matrices after that, it should be safe for all variants to update the uniform in that method? I tried it in DrawBounds and it seems OK, but I just want to be sure since I don't yet know the code that well. I would expect DrawBounds may not work when others do. Thats because last update of matrices in DrawBounds is actually done in almost hackish way in the middle of render stage, I would expect that your uniform may not get updated then. But if you got DrawBounds to work, other should work as well. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting light-space depth of main pass fragment
Hi J-S, The whole idea of optimal shadow map is implemented in a series of shadow camera projection adjustments. I saw you set up your ShadowCameraTransform uniform in StandardShadowMap::aimShadowCasting camera. This is initial setting of shadow cam matrices. MinimalShadowMap and derived techniques further refine these based on bounds computed in their specific way. This refinement may happen more than once in frameShadowCastingCamera method. So you should update ShadowCameraTransform inside these methods. This explains your observations that projection you read differs from projection used in practice. Cheers, Wojtek -Original Message- From: Jean-Sébastien Guay Sent: Wednesday, November 17, 2010 5:17 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Getting light-space depth of main pass fragment Hi again, If you don't mind, here is a small example I've put together to show what happens. Err, sorry, the example was missing some code for correct texcoords to get the depth from the shadow map. Here is the corrected example. I also changed it from DB to VB, and the result is still the same. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting light-space depth of main pass fragment
Hi J-S, That may happen if projection matrix changed a little between your read and rendering of ShadowMap. For example you read the projection matrix at some point but later it gets refined by AdjustNearFarPlane callback or second pass of MinimalShadowMap::frameShadowCastingCamera() method used in MinimalShadowMapCB or MinimalShadowMapDB. In DB this adjustment is actually done inside render traversal so you may be unable to read correct matrix unless you override this method. Cheers, Wojtek Lewandowski -Oryginalna wiadomość- From: Jean-Sébastien Guay Sent: Wednesday, November 17, 2010 4:35 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Getting light-space depth of main pass fragment Hi Wojtek, All your math seems correct to me. I would use ( lightSpaceDepth * 0.5 + 0.5 ) to compare with shadow map. But you said you tried it. Yes, * 0.5 + 0.5 seemed "more correct" but still only seemed to use the first part of the possible range, so I think you're right that one of my matrices is probably not set correctly. I'll investigate this. I wonder: Is it possible that the depth range given by the shadow camera's projection matrix doesn't match the depth range in the shadow map? I assumed that since that same camera renders to the shadow map, the depth range should be the same, but is it possible it doesn't match? Because the values I get for light-space main pass fragment depth seem to increase when they get further from the light, as they should, but they're just not in the right range. I think I'll make a small example program to show it and see if you can spot the error more clearly then. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ViewDependentShadow massive flickering problems
Hi J-S, Duelling frusta can be really nasty. However, minLightMargin should not significantly affect precision of shadow map. It may affect performance but precision could get only a little worse in DrawBounds or CullBounds when some large object behind viewer gets classified as shadow casting, which in turn will cause ShadowVolume to grow a bit and hence ShadowMap will loose some precision. But on average it should not change much. maxFarPlane on the other hand can affect the precision significantly. Paritcularly with ViewBounds it can quickly show the ugliness of raserized shadows. minFarPlane is responisble for clipping frustum depth height. When frustum depth grows, the base of the pyramid ie size of far plane rectangle also grows proportionally, and ShadowVolume becomes also larger. With Duelling Frusta case, size of frustum far plane square is almost linearly projected to shadow map. So if for example we have 90 deg FOV and 1 km maxFarPlane, it translates to 2km x 2km (2 * 1km * tan( 45 deg ) ) size of frustum pyramid base. Projecting this into 2048x2048 map will give mapping close to 1m per texel resolution. Now if using similar math to the above, you see that you get worse results than anticipated let me know. There is always a chance for some bug in shadow volume math. When you notice such thing, the best would be, if you could provide simple example illustrating the issue. Then I will gladly look at this problem. Cheers, Wojte -Oryginalna wiadomość- From: Jean-Sébastien Guay Sent: Tuesday, November 16, 2010 9:12 PM To: OpenSceneGraph Users Subject: [osg-users] ViewDependentShadow massive flickering problems Hi Wojtek, 1: fix for a issue with MinimalShadowMap and LightSpacePerspectiveShadowMapVB techniques ignoring minLightMargin parameter. I have tested your changes to LightSpacePerspectiveShadowMapVB in our simulator, and it seems that taking into account the minLightMargin parameter makes it have the same artifacts as the other two techniques (CB and DB) in our simulators. Initially we had selected VB because it did not present these artifacts, but it now seems likely that the artifacts were a result of bad settings on our part, and the fact that minLightMargin wasn't taken into account just masked the problems... So perhaps I can describe the situation and with your help, eventually solve it? When walking in an avatar, if we look in a given direction the shadows will look great, but then if I just turn around a bit, they will pixelate a lot, or seem clipped in front of the avatar, possibly even disappear completely at some angles. We're using a shadow map size of 2048x2048. I tried tweaking the minLightMargin and maxFarPlane parameters, which in the CB and DB cases should work. The values I tried were: minLightMargin: 0 to 500 in increments of 100 maxFarPlane: 1000 to 5000 in increments of 1000. It seemed to me that none of these made any difference at all. (I was using DB in that case). Admittedly, having the camera close to the floor is a tough case for LiSPSM, but I don't think it should be that bad. I can send you a small video showing the effect if you want. The shadow casting objects (and indeed, the whole scene apart from an osgOcean which casts no shadows) are in an area about, say, 120x100x100 meters in size. I've turned on DebugDraw and indeed, at the view angles where there are problems, the debug hud where the shadow map is drawn with volumes around the relevant scene objects (the left-most hud) shows that the volumes seem to go crazy (stretch to infinity). Perhaps that shows that what I'm seeing is the "dueling frusta" singularity? I would have thought it wouldn't be so apparent. And in fact I see the artifacts sometimes even when the view vector is nowhere near the light direction vector. And in any case, I would have thought the minLightMargin and maxFarPlane parameters would prevent the shadow map from stretching to infinity. Would you have any ideas as to what I can do to help the situation? As I said, I can send you a video showing this. It's hard for me to give you a scene that demonstrates this though, and I guess this would be the really useful thing for you... If you think it would help you give me better answers I'll try to find a way. :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting light-space depth of main pass fragment
Hi J-S,
All your math seems correct to me. I would use ( lightSpaceDepth * 0.5 +
0.5 ) to compare with shadow map. But you said you tried it. Using
DEPTH_COMPONENT is also ok IMHO. Debuging shaders display these values so
its possible to access them. So I think that maybe your uniforms or
osg_ViewMatrixInverse should be checked. Long time ago we had an issue with
osg_ViewMatrixInverse not being set for nested cameras. We had to set it
ourselves in this case. I am not sure if this limitiation is still present,
it was few years ago.
Do I correctly decipher PCSS as percentage closer soft shadows ? I was
mixing SoftShadowMap shaders with MimimalShadowMap for some project in the
past. It was actually possible without changing comparison mode because SSM
also uses GL_COMPARE_R_TO_TEXTURE_ARB mode.
Cheers,
Wojtek
Hi all,
I want to do shadow mapping by doing the depth comparisons myself in
order to implement PCSS. In order to do this I modified the
osgShadow::DebugShadowMap and StandardShadowMap classes to not enable
shadow comparison modes (GL_COMPARE_R_TO_TEXTURE_ARB), and when sampling
the shadow map I get raw depth values, which is what I want.
However, to get the right main pass depth to compare to the shadow map
value, I need to transform the fragment position to light space. To do
this, I've added a uniform that stores the shadow camera's view and
projection matrices, which I set in
StandardShadowMap::aimShadowCastingCamera():
_stateset->getOrCreateUniform("ShadowCameraTransform",
osg::Uniform::FLOAT_MAT4)->set(
view * projection);
Using that matrix, I would have thought in my shader I could do the
following:
uniform mat4 ShadowCameraTransform;
uniform mat4 osg_ViewMatrixInverse;
// ...
varying vec4 lightSpacePos;
void main()
{
// ...
mat4 modelMatrix = osg_ViewMatrixInverse * gl_ModelViewMatrix;
vec4 worldPos = modelMatrix * gl_Vertex;
lightSpacePos = ShadowCameraTransform * worldPos;
// ...
}
And then use that to compare a light-space depth value in the fragment
shader which I could use to compare to the shadow map:
float lightSpaceDepth = (lightSpacePos.xyz / lightSpacePos.w).z;
float shadowMapDepth = texture2D( shadowTexture, uv ).r;
However the lightSpaceDepth value above doesn't seem to be in the right
coordinate space or something, as I get values in too small a range.
I've tried the classic transforms ( * 0.5 + 0.5 or * 2.0 - 1.0) but the
values are still not in the right range.
First of all, am I doing the math right?
Second of all, I left the texture internal format set to
GL_DEPTH_COMPONENT and attached to the DEPTH_BUFFER, assuming that it
was OK, but could that explain my problems? Should I change it to a
general purpose float format (say GL_LUMINANCE32F_ARB), attach it to the
COLOR_BUFFER and write to gl_FragData[0] in the shadow pass's fragment
shader?
Just trying to sanity check a bit :-)
Thanks in advance,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] does LiSPSM cull the objects in the scene?
Hi J-S, There is a catch though. ViewBounds method has a bug which basically ignores MinimalLightMargin parameter. I have made a fix for this but it was not yet submitted, because its in the pack with TrapezoidalShadowMap which is still in work. Maybe I can will split them and send separately, if you are interested. Hah! I was wondering why my minLightMargin setting didn't seem to change anything. Sure enough I was using LiSPSMVB... Can I convince you to please submit the change? I already owe you a beer so we'll make it two :-) Change submitted. Let me know if it works for you, I tested this fix some time ago, but hadn't really good test case because my DBs are not well conditioned for ViewBounds and I don't use this mode very often. Don't bet on Trapezoidal, it will have the same performance as LispSM. It really resemble LisPSM but may have some better quality for low level moving viewer (person or driver). That's interesting, am I to understand you're working on adding another ShadowTechnique to OSG? We often have viewers close to the ground so I'm looking forward to this. I actually implemented Trapezoidal before LispSM long time ago . But it was not made as ViewDependentTechnique and I have recently ported it to work as one. But some issues remain and I don't see that I will be able to fix them soon. Have you looked at adding splits as well? (a la Cascading Shadow Maps or Parallel Split Shadow Maps) That would also be interesting, it would likely give excellent results for most cases (viewer high above and close to the ground, looking straight down or towards the horizon, etc.) but for cull-bound scenes it might be slow... I agree. That would be interesting. Unfortuantely I have no plans for it currently. Mixing PSSM with View Dependent Techniques and maybe Geometry shaders drawing all the cascaded shadow maps in one pass is tempting..., but such thing could easily steal few months of my schedule and I am terribly short on time recently. So frankly I don't see it happen soon. Maybe others would do it ? I have read between the lines (or submits) that David Callu was recently improving PSSM and some stuff with Geometry Shaders. I suspect he may be doing something like this... Sorry for late response. I am recently having some trouble with time management ... Cheers, Wojtek Lewandowski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] does LiSPSM cull the objects in the scene?
Hi Ramy, Teoretically LispSM uses one extra pass to render shadow map. However, optimal shadow volume computation requires some extra work. Default LispSM uses DrawBounds to compute shadow volume, which means it does extra pererender to compute box around pixels in prerenderd map. You may check alternative CullBounds variant. IT may offer better performance if you have small number of drawables, (number of tris per drawable does not matter here). Or simplest of the pack ViewBounds which simply computes volume by checking main camera view frustum. Depending on type of application last method may produce similar results to former more complicated ones. There is a catch though. ViewBounds method has a bug which basically ignores MinimalLightMargin parameter. I have made a fix for this but it was not yet submitted, because its in the pack with TrapezoidalShadowMap which is still in work. Maybe I can will split them and send separately, if you are interested. Don't bet on Trapezoidal, it will have the same performance as LispSM. It really resemble LisPSM but may have some better quality for low level moving viewer (person or driver). Wojtek -Original Message- From: Ramy Gowigati Sent: Thursday, November 04, 2010 5:09 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] does LiSPSM cull the objects in the scene? Thanks for your answer :) I knew you were going to reply :-D Thanks for your advise, those are the values I am playing with. I was also tried to give the ShadowScene the objects I want to cast shadows (by applying the castShadowMask on selected objects). that actually worked, but performance was still slow. The problem appears to be that our scene is too big and too complex (in terms of tri count). I believe that's where the problem is, scene has a very large tri count and the shadow almost doubles it which is an overkill for the GPU. So I will look into trying to simplify the scene then having another go. Are there any shadowing techniques that can help? Or is LiSPSM the best in my case? thanks ramy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33460#33460 ___ 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] does LiSPSM cull the objects in the scene?
Hi, LispSM works well with directional infinite lights. So I assume you are using this type of light. With inifinite light objects casting shadows can be far outside visible area. So the viewing frustum for shadow camera is usually larger than view frustum of the camera where shadows are cast. You may try to limit the near and far plane of shadow camera by setting Lispsm setMinLightMargin and setMaxFarPlane. setMinLightMargin defines the distance behind main viewer from which shadows can be cast. It of course depends on light angle, but if you have large buildings then their shadows can cover far located views, but if objects in your scene are small you may set minFarLightMargin to small value. Cheers, Wojtek -Original Message- From: Ramy Gowigati Sent: Wednesday, November 03, 2010 12:16 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] does LiSPSM cull the objects in the scene? Hi, I have been experimenting with Shadows lately for a pretty large scene I have. After reading some posts on the forum I realized I have to go with LiSPSM since it was optimized for large scenes. So I setup LiSPSM, passed in the variables and rendering using shaders. Everything seems to be working fine, until I noticed that LiSPSM doesn't seem to cull the objects in my scene graph. Even when I am viewing a building or two my triangle count is pretty high. If I turn off the shadows I get a much better performance and triangle count drops down to whatever there is on the screen. I have my ShadowScene as a root node, and the models are divided into regions and added as children to their respective regional group. I noticed in the LiSPSM there is a setMaxFarPlane() parameter. When I set a value it seems to only display shadows up to the far plane I specified, however the triangle count is still pretty high, almost as much as the entire scene. Am I missing something to make Shadows cull the models? Thank you! Ramy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=33374#33374 ___ 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] Upside down smoke trail
Hi Kevin,
Below is a piece of code that does exactly what you want in global WGS84
ellipsoid coord space. In your case just replace _xyz with the direction
vector you want the smoke to move.
osgParticle::FluidProgram* fp =
dynamic_cast
( _smokeTrailParticleEffect->getProgram() );
if( fp )
{
osg::Vec3 v = _xyz;
if( v.normalize() > 0.0 )
fp->setAcceleration( v * 9.81 );
}
Cheers,
Wojtek Lewandowski
-Original Message-
From: Kevin Bentley
Sent: Thursday, October 21, 2010 10:35 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Upside down smoke trail
Hi,
I want to have a particle effect that looks like falling dust/dirt. I was
thinking of using something like a smoketrail effect (with a different
texture), but I can't figure out how to make the particles go down instead
of up.
Amy I on the wrong track here? Any ideas how to best accomplish a falling
dust/dirt effect?
Thanks,
Kevin
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=32953#32953
___
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 seems to have a problem scaling to multiple windows on multiple graphics cards
Hi John, This is odd but it sounds bit like swap buffers of the windows are somehow waiting for each other. I believe that WGL_NV_swap_group extension is not used by OSG. This extension could possible help you there. But I could be wrong on above. It is not really my main point I wanted to mention. Instead I wanted to suggest you check SLI mosaic mode. We have done some experiments on 4 channels on Linux / Nvidia QuadroPlex D2 in the past. At first we tried to go the same path as you describe. But later we have read somewhere that fastest method is to use one window filing whole desktop and split this window into 4 screen quarter slave views. Each slave view could be positioned so that it covers one monitor output. Such 4 monitor setup is possible with QP D2 drivers in SLI mosaic mode. Using producer config files one may easily create a .cfg that could be passed from command line to osgViewer and set 4 channel slaves on single window. Best thing with using one window is that all four views use the same context so GL resources are shared and all four are swaped at once with single SwapBuffer call. In our project we ended up with 4 channel rendering using SLI mosaic and we were pleasently surprised how fast it was performing in comparison to separate gl contexts on 4 windows. You may check SLI mosaic if you haven't done this before Hope this helps, Wojtek Lewandowski -- From: "John Kelso" Sent: Thursday, October 07, 2010 9:35 PM To: Subject: [osg-users] OSG seems to have a problem scaling to multiple windows on multiple graphics cards Hi all, Our immersive system is a single host computer with 8 cores and 4 graphics cards running Linux. (1) We are using OSG 2.8.3. We are having a heck of a hard time getting OSG to take advantage of our multiple graphics cards. Help! Here's what we did: If we load a fairly large model into our test program we can get a frame rate of about 150 FPS when displaying in a single window. (2) We are running single-threaded, and assign to a specific core. When we background this and run a second copy of the program to another graphics card and core then both programs run at 150 FPS. Same thing for running three and four copies at once. That is, four processes using four graphics cards on four cores run just as fast as a single process. All four cores are at near 100% CPU utilization according to top. So far, so good. Now we modify the program to load the model and create multiple windows on multiple cards. There's one window per card and each uses a different core. (3) The threading model is "CullThreadPerCameraDrawThreadPerContext", the default chosen by OSG. The environment variable OSG_SERIALIZE_DRAW_DISPATCH is not set, so it defaults to ON, which we think means draw in serial. If we draw to four windows on four different cards we get about 36 FPS. There are four different cores being used, and each has about 25% of the CPU. This probably this makes sense as the draws are in serial. 150 FPS/4 is about 36 FPS. As expected, we get nearly identical results if we create four windows on a single card using four different cores. If we set OSG_SERIALIZE_DRAW_DISPATCH=OFF we hope to see better performance, but with four windows on four graphics cards we only get 16 FPS! There are four different cores bring used, one at about 82%, and the other three at 75%, but what are they doing? Again, we get nearly identical results if using four windows on a single card. So How can we get OSG to draw to four windows on four cards in one process as fast as running four separate processes? Any pointers or suggestions are welcome. Thanks, John 1 - Our immersive system consists of 3 projectors and a console each driven by an Nvidia FX5800 graphics card all genlocked for 3D stereo display. The four graphics cards are in two QuardoPlex Model D2 units connected to the host. The host computer is an 8 core Dell Precision T5400 running 64 bit Linux (CentOS 5.5). We are using Nvidia driver version 195.36.24 2 - the program is attached- it uses only OSG. We run our tests with _GL_SYNC_TO_VBLANK=0 to get the maximum frame rate. 3 - one graphics context per window and one camera per window ___ 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] Workaround for nVidia + fullscreen + Windows 7
One extra note for adventurous types: SWAP_UNDEFINED option currently exits the osgviewer (at least on my NVidia). Its normal behaviour because NVidia driver does not support UNDEFINED option and matching PixelFormat cannot be found. So the viewer exits. Wojtek From: Wojciech Lewandowski Sent: Thursday, October 07, 2010 11:49 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Workaround for nVidia + fullscreen + Windows 7 Hi Everyone, Big Thanks to Farshid for the solution :-) Support for his workaround, to use Copy as a swap Method, was recently included in OSG trunk. SwapCopy is not active by default - people not using Aero should be still happy with default SwapExchange. These who would like to activate the SwapCopy method can use environment variables or osgViewer command line arguments ( provided they use Viewer( ArgumentParser ) ctor ). env var method: set OSG_SWAP_METHOD=COPY command line method: osgviewer --swap-method COPY Inside the code one can select swap method for a particular window via GraphicsContext::Traits or for all windows by changing the default set in DisplaySettings. Traits default to method set in DisplaySettings. DisplaySettings use whats set by env var or command line. If no option is given DEFAULT is used. I hope such solution is fairly complete and covers all possible use cases. All 4 allowed swap method options are: SWAP_EXCHANGE - flip back & front buffers SWAP_COPY - copy contents of back buffer into front buffer SWAP_UNDEFINED - move contents of back buffer into front buffer, leaving back buffer contents undefined SWAP_DEFAULT - let the driver select the method (in my observation NVidia drivers on Win7 defaults to EXCHANGE) Cheers, Wojtek Lewandowski From: Wojciech Lewandowski Sent: Monday, September 27, 2010 2:31 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Workaround for nVidia + fullscreen + Windows 7 Hi, I have submitted code changes. Look at osg-submissions for details. Wojtek Lewandowski From: Wojciech Lewandowski Sent: Friday, September 24, 2010 9:44 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Workaround for nVidia + fullscreen + Windows 7 Hi, Exactly as Farshid Said I have modified PreparePixelFormatSpecification function in GraphicsWindowWin32.cpp to test the workaround. Interestingly PreparePixelFormatSpecification has a input allowSwapExchangeARB parameter as if someone had similar problem before. But this parameter is used when function is called but not influenced directly by GraphicContext::Traits. In my opinion the best option would be expose Swap method in the GraphicContext::Traits. I may try to come up with a patch on monday. Anyone to beat me on this ;-) ? Wojtek From: Farshid Lashkari Sent: Friday, September 24, 2010 6:40 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Workaround for nVidia + fullscreen + Windows 7 Hi Robert, On Fri, Sep 24, 2010 at 9:28 AM, Robert Osfield wrote: Did you modify the OSG to achieve this? If so could you post the changes. Perhaps this could be made as an runtime option in osgViewer. My application handles all the windowing code itself, so I didn't need to make any changes to OSG. I noticed that GraphicsWindowWin32.cpp hard codes the swap method to WGL_SWAP_EXCHANGE_ARB. To apply this workaround the users would just need to change this to WGL_SWAP_COPY_ARB and recompile. Having this configurable would be ideal, however I'm not very familiar with osgViewer, so I'm probably not the best person to make this change, otherwise I would have already submitted a patch ;) Cheers, Farshid ___ 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] Workaround for nVidia + fullscreen + Windows 7
Hi Everyone, Big Thanks to Farshid for the solution :-) Support for his workaround, to use Copy as a swap Method, was recently included in OSG trunk. SwapCopy is not active by default - people not using Aero should be still happy with default SwapExchange. These who would like to activate the SwapCopy method can use environment variables or osgViewer command line arguments ( provided they use Viewer( ArgumentParser ) ctor ). env var method: set OSG_SWAP_METHOD=COPY command line method: osgviewer --swap-method COPY Inside the code one can select swap method for a particular window via GraphicsContext::Traits or for all windows by changing the default set in DisplaySettings. Traits default to method set in DisplaySettings. DisplaySettings use whats set by env var or command line. If no option is given DEFAULT is used. I hope such solution is fairly complete and covers all possible use cases. All 4 allowed swap method options are: SWAP_EXCHANGE - flip back & front buffers SWAP_COPY - copy contents of back buffer into front buffer SWAP_UNDEFINED - move contents of back buffer into front buffer, leaving back buffer contents undefined SWAP_DEFAULT - let the driver select the method (in my observation NVidia drivers on Win7 defaults to EXCHANGE) Cheers, Wojtek Lewandowski From: Wojciech Lewandowski Sent: Monday, September 27, 2010 2:31 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Workaround for nVidia + fullscreen + Windows 7 Hi, I have submitted code changes. Look at osg-submissions for details. Wojtek Lewandowski From: Wojciech Lewandowski Sent: Friday, September 24, 2010 9:44 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Workaround for nVidia + fullscreen + Windows 7 Hi, Exactly as Farshid Said I have modified PreparePixelFormatSpecification function in GraphicsWindowWin32.cpp to test the workaround. Interestingly PreparePixelFormatSpecification has a input allowSwapExchangeARB parameter as if someone had similar problem before. But this parameter is used when function is called but not influenced directly by GraphicContext::Traits. In my opinion the best option would be expose Swap method in the GraphicContext::Traits. I may try to come up with a patch on monday. Anyone to beat me on this ;-) ? Wojtek From: Farshid Lashkari Sent: Friday, September 24, 2010 6:40 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Workaround for nVidia + fullscreen + Windows 7 Hi Robert, On Fri, Sep 24, 2010 at 9:28 AM, Robert Osfield wrote: Did you modify the OSG to achieve this? If so could you post the changes. Perhaps this could be made as an runtime option in osgViewer. My application handles all the windowing code itself, so I didn't need to make any changes to OSG. I noticed that GraphicsWindowWin32.cpp hard codes the swap method to WGL_SWAP_EXCHANGE_ARB. To apply this workaround the users would just need to change this to WGL_SWAP_COPY_ARB and recompile. Having this configurable would be ideal, however I'm not very familiar with osgViewer, so I'm probably not the best person to make this change, otherwise I would have already submitted a patch ;) Cheers, Farshid ___ 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] to registerPagedLODs or not ?
Submission sent. Cheers, Wojtek -- From: "Robert Osfield" Sent: Friday, October 01, 2010 3:29 PM To: "OpenSceneGraph Users" Subject: Re: [osg-users] to registerPagedLODs or not ? Hi Wojtek, On Fri, Oct 1, 2010 at 2:07 PM, Wojciech Lewandowski wrote: I don't need to test it. We already did it. It works and thats the fix we would propose as our submission. We tested if parent is registerd by checking if its present in active & inactive PagedLOD lists If it works then just post the modified file osg-submissions and I'll get on an review it. We did not test looking up for PagedLODs in parent node path, though. I am not sure I understand why is it neccessary... Is it possbile that the PagedLOD needing registration will be few levels above ? I think the registration is only needed for top PageLODs loaded from user ReadNodeFile calls. And these most top PageLODs will get registered when their first child gets loaded. You'd only need to go search the whole parental path if you had preloaded external children of the PagedLOD's that are above the one that is currently being added to. I think you are correct in believe that doing this would be overkill, if the PagedLOD does become active w.r.t loading new children then it'll automatically get registered with the changes that you've already applied, and this should be sufficient. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] to registerPagedLODs or not ?
Hi Robert, [..] Looking at the code it looks like you'd modify DatabasePager::addLoadedDataToSceneGraph to check to see if the Group that the subgraph is being added to is a PagedLOD and if so then add it, or even perhaps check the parent path for the group (the refNodePath in addLoadeDataToSceneGraph). Could you try this and let me know how you get on. I don't need to test it. We already did it. It works and thats the fix we would propose as our submission. We tested if parent is registerd by checking if its present in active & inactive PagedLOD lists We did not test looking up for PagedLODs in parent node path, though. I am not sure I understand why is it neccessary... Is it possbile that the PagedLOD needing registration will be few levels above ? I think the registration is only needed for top PageLODs loaded from user ReadNodeFile calls. And these most top PageLODs will get registered when their first child gets loaded. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] to registerPagedLODs or not ?
Hi Robert, My intention in the revamp of DatabasePager was to make it unnecessary to call registerPagedLODs, and have this done automatically on demand i.e. when the PagedLOD is traversed and invokes a load for the first time. Do your own PagedLOD's contain external children prior to attaching to the scene graph? Yes we have such children. Our database uses a tree of standard LODs at lower detail levels (0..n) and PagedLODs subtrees for higher detail levels (n+). We located the 11580 revision (Fixed double registration bug) as the moment when problem started to appear. This change started running registerPagedLOD visitor on loaded child only. In former version visitor was started from the parent group PageLOD. As I understand this modification was introduced to not double parent PLOD registration but also has the side effect of skiping parents not yet registered. So maybe the workaround would be checking if parent is not registered already and run visitor from parent if neccessary. Cheers, Wojtek Lewandowski Robert. 2010/10/1 Wojciech Lewandowski : Hi Robert, We have recently encountered a case of excessive memory use with a database which contained number of PagedLODs. The problem vanished when we called registerPagedLODs on Scene root. Obviously pagedLODs where not registered when model was loaded. But this is quite surprising to me because I thought we don't have to call registerPagedLODs anymore in recent OSG releases. So my question is : What are current recommendations for registePagedLODs use ? Must we call it or not after loading a scene model ? Or in other words: is this a feature or a bug ? If thats a bug we may have a fix for it. We have spent a lot of time on the issue and learned what is exactly going on under the hood so we may come up with other solution. Cheers, Wojtek Lewandowski ___ 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] to registerPagedLODs or not ?
Hi Robert, We have recently encountered a case of excessive memory use with a database which contained number of PagedLODs. The problem vanished when we called registerPagedLODs on Scene root. Obviously pagedLODs where not registered when model was loaded. But this is quite surprising to me because I thought we don't have to call registerPagedLODs anymore in recent OSG releases. So my question is : What are current recommendations for registePagedLODs use ? Must we call it or not after loading a scene model ? Or in other words: is this a feature or a bug ? If thats a bug we may have a fix for it. We have spent a lot of time on the issue and learned what is exactly going on under the hood so we may come up with other solution. Cheers, Wojtek Lewandowski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Extract ModelView Projection Matrix for GLSLProgram version 150 and higher
Hi Peter, To Wojciech, that would be a workaround, but not a ( correct ) solution, right ? It depends: if you select core 3.x OpenGL profile in OSG CMakeLists then it can be considered a workaround, but if you setup default OpenGL context then its your preferred choice ;-). I tried to compile OSG with pure 3.x GL once, but then I realized that whole lighting piepeline has to be done by hand including setting lights nodes and handling their proper uniforms so I reverted back to compatibility profile ;-) Best option in my opinion is to use shaders and still have the choice of some fixed pipeline features. That is, at least before ShaderComposition is added ;-) Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Extract ModelView Projection Matrix for GLSL Programversion 150 and higher
Hi Peter, Can't you use compatibility profile ? All stuff you mention is still available in compatibility profile. eg place it at the begining of GLSL Shader: #version 150 compatibility [shader code] Wojtek -- From: "Peter Wrobrl" Sent: Wednesday, September 29, 2010 9:21 PM To: Subject: [osg-users] Extract ModelView Projection Matrix for GLSL Programversion 150 and higher Hi, gl_ModelViewProjectionMatrix and ftransform() are deprecated since GLSL Version 120 ( but still working ), in Version 150 not working at all. Is there a straight forward way to extract the current ModelView and Projection Matrices ( e.g. from StateSet ? ), without having to pass around the Camera through the SG, or extract osg::Transform World Matrix ? Moreover, gl_Vertex is depreciated as well, so how to create a VBO ? Is it possible to use only VertexAttribArray, without VertexArray, NormalArray, etc. ? Thank you! Cheers, ParticlePeter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32198#32198 ___ 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] Preparing for OpenSceneGraph-2.9.9 developerrelease, please test :-)
Hi, NVidia 260.63 fixes single screen. Multi screen is still a mess. And Nvidia ControlPanel does not show on some machines including mine. Wojtek Lewandowski -- From: "Martin Naylor" Sent: Tuesday, September 28, 2010 10:29 AM To: "'OpenSceneGraph Users'" Subject: Re: [osg-users] Preparing for OpenSceneGraph-2.9.9 developerrelease, please test :-) Hi, It sounds like the Aero bug, disable Aero? Believe Wojtek may have just submitted a fix for this to workaround the driver bug, also the latest beta driver from NVidia fixes this for me, not sure about a quadro card... Might be worth trying the beta NVidia drivers? Cheers Martin. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of jago jagoc Sent: 27 September 2010 14:57 To: OpenSceneGraph Users Subject: Re: [osg-users] Preparing for OpenSceneGraph-2.9.9 developer release, please test :-) Hi, it compiles without any problem (with examples enabled), when I start any examples that use full-screen display the screen goes black. My configuration: Windows Vista Business,64 bit (SP2) Quadro FX 3600M ( v. 258.96 ) osg - Revision 11792 Cheers, Jagovic ___ 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] Shadows : Creating multiple osgShadow::ShadowedScene
Hi Saravanan, Try other shadowing techniques, Parallel Split Shadow Maps (pssm) or Light Space Perspective Shadow Maps (lispsm). They should be better suited for your case. Cheers, Wojtek Lewandowski -- From: "Saravanan Sivaprahasam" Sent: Monday, September 27, 2010 2:18 PM To: Subject: [osg-users] Shadows : Creating multiple osgShadow::ShadowedScene Hi, I'm rendering shadows using osgShadow::ShadowMap method. For large outdoor scenes with various objects, the rendered shadows look pixelated and self shadows on objects are not correct. I've increased the shadow map resolution to 4096, but still it is not correct. So i have created two shadowed scenes (osgShadow::ShadowedScene ) each having a separate light source and shadow map of 4096 resolution. The second osgShadow::ShadowedScene that is added (last) as a child to root node is getting rendered, while the first shadowed scene added to root is not getting rendered. Please provide some suggestions to get the shadows rendered correctly Thank you! Cheers, Saravanan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32093#32093 ___ 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] Workaround for nVidia + fullscreen + Windows 7
Hi, I have submitted code changes. Look at osg-submissions for details. Wojtek Lewandowski From: Wojciech Lewandowski Sent: Friday, September 24, 2010 9:44 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Workaround for nVidia + fullscreen + Windows 7 Hi, Exactly as Farshid Said I have modified PreparePixelFormatSpecification function in GraphicsWindowWin32.cpp to test the workaround. Interestingly PreparePixelFormatSpecification has a input allowSwapExchangeARB parameter as if someone had similar problem before. But this parameter is used when function is called but not influenced directly by GraphicContext::Traits. In my opinion the best option would be expose Swap method in the GraphicContext::Traits. I may try to come up with a patch on monday. Anyone to beat me on this ;-) ? Wojtek From: Farshid Lashkari Sent: Friday, September 24, 2010 6:40 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Workaround for nVidia + fullscreen + Windows 7 Hi Robert, On Fri, Sep 24, 2010 at 9:28 AM, Robert Osfield wrote: Did you modify the OSG to achieve this? If so could you post the changes. Perhaps this could be made as an runtime option in osgViewer. My application handles all the windowing code itself, so I didn't need to make any changes to OSG. I noticed that GraphicsWindowWin32.cpp hard codes the swap method to WGL_SWAP_EXCHANGE_ARB. To apply this workaround the users would just need to change this to WGL_SWAP_COPY_ARB and recompile. Having this configurable would be ideal, however I'm not very familiar with osgViewer, so I'm probably not the best person to make this change, otherwise I would have already submitted a patch ;) Cheers, Farshid ___ 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] Workaround for nVidia + fullscreen + Windows 7
Hi, Exactly as Farshid Said I have modified PreparePixelFormatSpecification function in GraphicsWindowWin32.cpp to test the workaround. Interestingly PreparePixelFormatSpecification has a input allowSwapExchangeARB parameter as if someone had similar problem before. But this parameter is used when function is called but not influenced directly by GraphicContext::Traits. In my opinion the best option would be expose Swap method in the GraphicContext::Traits. I may try to come up with a patch on monday. Anyone to beat me on this ;-) ? Wojtek From: Farshid Lashkari Sent: Friday, September 24, 2010 6:40 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Workaround for nVidia + fullscreen + Windows 7 Hi Robert, On Fri, Sep 24, 2010 at 9:28 AM, Robert Osfield wrote: Did you modify the OSG to achieve this? If so could you post the changes. Perhaps this could be made as an runtime option in osgViewer. My application handles all the windowing code itself, so I didn't need to make any changes to OSG. I noticed that GraphicsWindowWin32.cpp hard codes the swap method to WGL_SWAP_EXCHANGE_ARB. To apply this workaround the users would just need to change this to WGL_SWAP_COPY_ARB and recompile. Having this configurable would be ideal, however I'm not very familiar with osgViewer, so I'm probably not the best person to make this change, otherwise I would have already submitted a patch ;) Cheers, Farshid ___ 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] Windows 7 Aero Color Scheme issue
Hi Guys, Have you seen last post from Farshid Lashkari in Re: [osg-users] Problem with samples thread ? I've also been experiencing the fullscreen issue with nVidia cards on Windows 7. Just wanted to let you know that I found a workaround. When creating the OpenGL context, I changed the swap method from WGL_SWAP_EXCHANGE_ARB to WGL_SWAP_COPY_ARB. This completely solved the issue for me. Hopefully nVidia will fix their drivers in a future release. Farshid IMHO He has found the workaround and but also the source of the problem. I just checked his solution and it simply works. So I think that with Aero DWM not having front buffer but internal Direct3D texture, its quite understandable why COPY works better than EXCHANGE. Its hard to understand though why NvIdia drivers suggest EXCHANGE in ChoosePixelFormat when it does not work correctly. Btw I checked with DescribePixelFormat if the returned PixelFormat is compatible with PFD_SUPPORTS_COMPOSITION . And yes, returned description structure reports this compatibility. So this whole issue looks weird and definitely points to the drivers as the source of the problem. The drivers have the option to return PixelFormat with SWAP_COPY method but it keeps returning SWAP_EXCHANGE. Regards, Wojtek -- From: "Martin Naylor" Sent: Friday, September 24, 2010 2:11 PM To: "'OpenSceneGraph Users'" Subject: Re: [osg-users] Windows 7 Aero Color Scheme issue Hi Magnus, Not sure about the answer to your question. But I believe this to be fixed in the latest NVidia Beta driver(well for my single screen anyway). I did look at the code and my brain went numb trying to find a fix. Might be worth trying the latest beta drivers see if it still occurs? Regards Martin. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Magnus Kessler Sent: 24 September 2010 06:43 To: OpenSceneGraph Users Subject: Re: [osg-users] Windows 7 Aero Color Scheme issue On Thursday 08 July 2010, Martin Naylor wrote: Hi, Yeah its certainly Aero... I two have the same issue, disabling Aero sorts its out, but mine is on a single screen. Alt-Tab will make it work as well. Have a look here http://www.opengl.org/pipeline/article/vol003_7/ Are we using GDI? I don't understand the viewer code, I might have another attempt later... http://bugreports.qt.nokia.com/browse/QTBUG-6988 might of interest. This what I posted a while back: I did mention this a while back about osgShadow. All my are examples do this now after installing a new Nvidia GTX 480 card(from a gtx 9800), with the latest drivers from Nvidia. My guess you are running Windows Vista/7, try alt tab? For a permanent fix disable the pesky Aero desktop! I tried looking for a fix last night and its something to do with swapbuffers either being called or not, I cannot remember it was late and the viewer code was baffling me! Ok it might be Never found a fix, i have looked into the viewer code, but never got to the bottom of it. Martin. I made an interesting observation recently. One and the same code (essentially osgviewer) showed the black screen when starting up in the automatically chosen "DrawThreadPerContext" threading mode, but worked fine when "SingleThreaded" was forced. What is different in the way the OpenGL context is created in these two cases? Magnus ___ 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] Problem with samples
Thanks Farshid, I think you should post it in separate thread with proper subject. I guess large number of people will be grateful for sharing this info ; - ) Wojtek From: Farshid Lashkari Sent: Friday, September 24, 2010 6:19 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Problem with samples Hi, I've also been experiencing the fullscreen issue with nVidia cards on Windows 7. Just wanted to let you know that I found a workaround. When creating the OpenGL context, I changed the swap method from WGL_SWAP_EXCHANGE_ARB to WGL_SWAP_COPY_ARB. This completely solved the issue for me. Hopefully nVidia will fix their drivers in a future release. Cheers, Farshid On Thu, Sep 2, 2010 at 7:00 AM, Martin Anderson wrote: Hi, Thanks for all your responses guys - that seems to answer the problem ! Will try the offered fixes when I get home from work Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31274#31274 ___ 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] Texture coordinate calculation in vertex shader
Hi Werner, I doubt these five lines kill your framerate. Fixed pipeline on modern graphics boards these days is implemented internally on shaders and must do the same. There must be something else in your vertex shader approach that goes wrong... Wojtek -- From: "Werner Modenbach" Sent: Monday, September 13, 2010 4:15 PM To: "OpenSceneGraph Users" Subject: Re: [osg-users] Texture coordinate calculation in vertex shader Hi Wojtek, thanks for your reply. I have instantly studied the orange book. According to the book I have to use something like: vec4 tmp = gl_ModelViewMatrix * gl_Vertex; ShadowTexcoord.s = dot(tmp, gl_EyePlaneS[1]); ShadowTexcoord.t = dot(tmp, gl_EyePlaneT[1]); ShadowTexcoord.p = dot(tmp, gl_EyePlaneR[1]); ShadowTexcoord.q = dot(tmp, gl_EyePlaneQ[1]); But unfortunately this kills performance inacceptably and also rendering of my scene is not stable (flickering). Shadow appear as expected. On Monday 13 September 2010 13:51:02 Wojciech Lewandowski wrote: Hi Werener, See VertexShader in StandardShadowMap. OpenGL Shading Languege (Orange Book) contains a chapter on emulating fixed pipeline. And you may also try to use 3DLabs ShaderGen. Wojtek Lewandowski -- From: "Werner Modenbach" Sent: Monday, September 13, 2010 12:00 PM To: Subject: [osg-users] Texture coordinate calculation in vertex shader > Hi everybody! > > I'm using osgShadow::ShadowMap on my scene. > Also I have written my own vertex and fragment shaders. > When coming to apply the shadow effect in the fragment shader I have to > access > the shadow map. > The original shader uses just > shadow2DProj( osgShadow_shadowTexture, gl_TexCoord[1] ) > to access the texture. Obviously gl_TexCoord[1] is calculated by the > standard > gl pipeline shader. > Any quick hint, how I have to do the calculation in my vertex shader? > > Many thanks in advance > > - Werner - > ___ > 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 -- TEXION Software Solutions TEXION GmbH - Rotter Bruch 26a - D 52068 Aachen - HRB 14999 Aachen Fon: +49 241 475757-0, Fax: +49 241 475757-29, web: http://www.texion.eu Geschäftsführer/Managing Director: Werner Modenbach ___ 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] Texture coordinate calculation in vertex shader
Hi Werener, See VertexShader in StandardShadowMap. OpenGL Shading Languege (Orange Book) contains a chapter on emulating fixed pipeline. And you may also try to use 3DLabs ShaderGen. Wojtek Lewandowski -- From: "Werner Modenbach" Sent: Monday, September 13, 2010 12:00 PM To: Subject: [osg-users] Texture coordinate calculation in vertex shader Hi everybody! I'm using osgShadow::ShadowMap on my scene. Also I have written my own vertex and fragment shaders. When coming to apply the shadow effect in the fragment shader I have to access the shadow map. The original shader uses just shadow2DProj( osgShadow_shadowTexture, gl_TexCoord[1] ) to access the texture. Obviously gl_TexCoord[1] is calculated by the standard gl pipeline shader. Any quick hint, how I have to do the calculation in my vertex shader? Many thanks in advance - Werner - ___ 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] How to cancel pending pager requests ?
Hi, I was recently developing application where ImageSequences were switched dynamically. Images were rather large and I could not preload them so I used PAGE_AND_DISCARD option. However when switching the sequences I noticed that each restart takes more and more time. I figured out that former pending requests in ImagePager queue were blocking new requests. So I come up with idea to flush the ImagePager queue before starting new sequence. But I was unable to find a method to flush the queue so I ended up with reseting ImagePager: viewer. stopThreading() viewer.setImagePager( new ImagePager ); viewer.startThreading() I am not sure if I had to stop & restart threading but I realized it will be safer this way. I wonder if there is a better approach to the above problem. Perhaps there is a way to selectively abandon certain requests ? For example cancel requests originating from deleted ImageSequence ? I also realized that request queue flush could be also interesting for DatabasePager scenarios when Camera was warped to distant new location. I would also like to hear about any ideas to tackle this problem ? Cheers, Wojtek Lewandowski___ 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 rotate a image
Hi Martin, If you follow the vertexexample closely then then rotation can be simply added (or removed because its already there) to TexMat in TexMatCallback. Look at R matrix in TexMatCallback::operator(). Multiply this R matrix by neccessary rotation. If you don't know what rotation exactly, try 90 or -90 degrees around X, Y, Z axes. After up to 6 tries you will find the one that best suits your need. And you will learn a lot ;-) Wojtek -- From: ""Martin Großer"" Sent: Tuesday, September 07, 2010 1:16 PM To: "OpenSceneGraph Users" Subject: Re: [osg-users] How can I rotate a image Ok, also I have create a sky box like the sky box in the vertexprogramm example of osg. But in my scene the up vector is in the z direction and not in the y direction. Now I have rotate my sky box 90 degrees around the x axis. Is it understandable? But now, the images on the sky box are in the wrong orientation. For example the image in the positiv x direction is 90 degrees rotated. And I want to correct this rotation. Is it understandable? I am not sure. Cheers Martin Original-Nachricht Datum: Tue, 7 Sep 2010 14:57:24 +0400 Von: "Trajce (Nick) Nikolov" An: OpenSceneGraph Users Betreff: Re: [osg-users] How can I rotate a image what do you mean by "rotating an image"? Could you tell what you are actually trying to do? More info you provide more chances to get some advice -Nick 2010/9/7 "Martin Großer" > Hello, > > I would like rotate a image. Because I want to rotate the separate images > from my sky box. I think it is difficult to change the texture coordinates > of my sphere. I my idea is to rotate the images at the beginning. > > Example > > ::osg::Image* image = osgDB::readImageFile(c_posX.Filename); > > // rotate image > > _cubeMap->setImage(::osg::TextureCubeMap::POSITIVE_X, image); > > I hope someone can help me. > > Cheers > > Martin > -- > GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!* > http://portal.gmx.net/de/go/dsl > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl ___ 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] latest NVIDIA drivers
Hi J-S & All, Going back to the subject, I just tested Catalyst 10.8 today and was pleasantly surprised that some bugs were not present anymore. So driven by this small succes, I went further and also installed newest non-WHQL NVidia 259.31 drivers (Windows 7 64 bit). They are available through NVidia OpenGL DeveloperRelations portal. And these drivers also seem to work correctly as pre 256 driver series. At least my pixel lighting shaders compile again. So it looks like NVidia guys fixed the bug while we were complaining ; - ). You may check if theses drivers work for You. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StandardShadowMap on ATI
Hi Everyone browsing this thread. I just downoaded Catalyst 10.8 for Windows. Its a pleasure to report that problems (broken TexMat & base Textures) with osgShadow example on recent Catalyst versions 10.4-10.7 seem to be fixed on 10.8. Thats the way to go AMD ;-). I tested on OSG trunk 32 bit / Windows 7 64 bit / Radeon 5980 . Wojtek -- From: "Bradley Baker Searles" Sent: Wednesday, August 04, 2010 6:13 PM To: Subject: Re: [osg-users] StandardShadowMap on ATI Hi Wojtek, Ahh, good catch with the improper derivation! :) Thank you. I'm attaching the corrected st.h file. I just tried to get the osgShadow example working (-4 --lispsm), and it didn't work with any of the workarounds that I'd used in my code (not using variables to index light sources, don't use derived light values such as gl_FrontLightModelProduct, skip empty program add, etc). Now the standard LispSM does its lighting in the vertex shader, and all of my Programs do their lighting in the fragment programs... so there may be additional tricks for vert shaders that I'm not yet aware of? I haven't tried any of the other techniques yet, but perhaps I'll see if those can be patched up. But... even if we could patch them, the fixes are ugly enough that I don't think they'd belong in the osg source. Perhaps I should post some of these issues on the ATI forums. Thank you! Baker -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30533#30533 Attachments: http://forum.openscenegraph.org//files/st_191.h ___ 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] latest NVIDIA drivers
Hi J-S, Responses below: [...] Actually someone on that thread said that bugs in deprecated functionality were likely to appear often, which to me suggests that nVidia might never fix this bug because it relates to built-in uniforms which are deprecated, and just using your own uniforms instead of gl_LightSource[] works fine, so why should they fix a deprecated feature? I think that breaking gl_LightSource usage in fragment shaders is actually a major problem. On this forum there are three of us who admitted it affected them. Probably few more did not mention it. How many OpenGL developers outside OSG community do pixel lighting ? I bet there thousands if not tens of thousands who were or can be affected in the future. Its not just a minor issue, so I guess NVidia will do something about this sooner or later. I hope they will, despite the fact, they did not respond to my bug report at all ;-(. I am telling myself they probalby did not, because they already knew about it. I actually wonder how true that is, based on this text that can be found on nVidia's site (http://developer.nvidia.com/object/opengl_driver.html) : - 4) Is NVIDIA going to remove functionality from OpenGL in the future? NVIDIA has no interest in removing any feature from OpenGL that our ISVs rely on. NVIDIA believes in providing maximum functionality with minimal churn to developers. Hence, NVIDIA fully supports the ARB_compatibility extension and Compatibility profile, and is shipping OpenGL drivers without any functionality removed, including any functionality that is marked deprecated. 5) Will existing applications still work on current and future shipping hardware? NVIDIA has no plans for dropping support for any version of OpenGL on our existing and future shipping hardware. As a result, all currently shipping applications will continue to work on NVIDIA's existing and future hardware. - Yeah, I thought about the same ;-). Are NVidia continued legacy OpenGL support statements still valid ? But then again, that text might just be PR speak and wishful thinking. If some feature is deprecated (OpenGL 2.x, built-in uniforms, etc.), and less developers are using it over time, how many resources are they likely to devote to fixing bugs that appear in that feature? Of course, from the version number jump, we might assume that nVidia did some big work on their drivers lately, maybe even a rewrite of some or all of them. If that's the case, then they might have had to rewrite the deprecated parts too, and since they most likely tested these parts less than the others, it could explain why we see some bugs in it at this point. This is all conjecture on my part of course, but this kind of thing happens pretty often in development projects... I think NVidia was adding support for OpenGL 4.0 & 4.1 for Fermi based GPUs and they screwed something in shader compilers. If this was a minor issue they could ignore it, but I think its huge problem for many developers and NVidia should be aware of its importance. So I really think they will fix it. If they are not and will continue such attitude, then one day ATI will start to have better quality drivers. And it won't happen because ATI drivers improved ;-) Btw, I would love ATI/AMD OpenGL drivers improve so we have a real competition in OpenGL. What do you think? I don't know what to think at this point, but since we have an acceptable workaround I'm not too concerned. I just hope the situation doesn't go downhill from here (at least not before OSG has a good transition path to OpenGL 3+ that we can use). Since, I said before I think they will fix it, I can now play a little devils advocate ;-). I actually think that such OpenGL legacy support policy prevents faster progress. I think that DirectX has now edge over OpenGL and now dictates the pace of 3D graphics. This success was partially achieved by Microsoft policy to do a revolution with every major DirectX release. They redefined whole API and removed all stuff that did not fit anymore. With such attitude developers were forced to adapt but they also gained a lot. With compatibility profiles OpenGL cannot progress that quick. And number of OpenGL new and older calls & usage combinations certainly makes building fast & well behaving drivers more difficult. So I would rather like to see some revolution is OpenGL and adapt my code to pure OpenGL 4.0 profiles than deal with unexpected driver errors. In any case, let us know if you ever get news from the bug report you sent. In the past when I've reported bugs they've been rather quick to respond, but maybe that has changed too... As I said I have not heard from them after bug report. But I hope its a good sign and it means they are working on the issue. Wojtek ___ osg-users mailing list osg-us
Re: [osg-users] latest NVIDIA drivers
Thanks J-S,
Interesting. I will keep it mind. I remember that case I reported to NVidia
was also doing good as long as light number was less than 4. I guess
compiler was implicitly unrolling the loop, but when number got above 3, it
could not unroll and the problem started to show.
In the meantime I changed the code to use my own (non gl_) uniforms and this
also seems to work. However, instead of array of LightStructs I rather use a
set of arrays each containing single light attribute (for example diffuse)
for all lights. I did it because it allows for better use of uniform memory.
Cheers,
Wojtek Lewandowski
--
From: "Jean-Sébastien Guay"
Sent: Thursday, September 02, 2010 4:27 PM
To: "OpenSceneGraph Users"
Subject: Re: [osg-users] latest NVIDIA drivers
Hello Wojtek,
I have noticed issues with Shader compilation on 256 (and above) series
on Windows 7. Some fragment shaders using gl_LightSource fields were
generating internal compiler errors. In fact I also posted a bug report
to NVidia. These errors were normally reported by OSG with compilation
log showing assembly cg output that was causing trouble for compiler.
You don't see any compilation errors even with
OSG_NOTIFY_LEVEL=DEBUG_INFO ?
I have attached the bug report I posted to NVidia you can check if it
could related.
We have put back updating our simulators' drivers for this reason. Our
lighting shaders did not compile with that same error ("binding in
multiple relative-addressedarrays"). I looked it up last night to try and
find a workaround, and found one.
If you simply unroll the loop that iterates over lights, it compiles fine.
So what you can do is:
// Don't forget the backslash at the end of each line except
// the last in the define...
#define APPLY_LIGHT(i) \
// the code that you had in your loop before \
// that uses gl_LightSource[i]\
// for example: \
// ...\
ambient += attenuation * gl_LightSource[i].ambient; \
// ...
APPLY_LIGHT(0)
APPLY_LIGHT(1)
APPLY_LIGHT(2)
APPLY_LIGHT(3)
// Up to however many lights you want to support
Sure it's just a workaround, I think the behavior you reported to nVidia
is still a bug they should fix, but at least this allows us to keep on
working even if some clients or users update their drivers. I always hate
telling people "don't update your drivers to a version newer than x.y",
because that shows some incompatibility in our own software and also I may
forget to tell them that it's ok to update once the driver bug is fixed,
and then they may run into other issues in the future because they have
old drivers.
Also, I don't have any other loops currently in my code, so I can't say if
this same compiler error might affect looping over other variables.
See this thread on OpenGL.org for some discussion of this issue. I got the
inspiration for the #define above there.
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=281429
Someone mentioned in that thread: "In the GLSL spec, if you use some of
the built in array types (like gl_ClipDistance) you need to either declare
the size of the array or make the source code so that the GLSL compiler
can figure out the maximum index you access." It might be possible to
remove the above workaround if we did what he suggests. But I haven't yet
found out how to do that. What I've tried ("uniform
gl_LightSourceParameters gl_LightSource[gl_MaxLights];" or "uniform
gl_LightSourceParameters gl_LightSource[8];" at the top of the shader)
didn't change anything.
I really hope nVidia fixes the bug...
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] threading and captureCurrentState
Hi John, If you need this to setup uniforms for shadow fragment shaders then maybe standard GL gl_FrontFacing variable could do the trick ? Its available at least in GLSL 1.50 and above. I have not checked when it was introduced maybe its available in earlier GLSL profiles. Wojtek From: PCJohn Sent: Thursday, August 05, 2010 12:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] threading and captureCurrentState Yes. There is. Oh. I see. Sorry for confusion, you call it attribute stack and that is a correct name for it. Anyway, there is State::_attributeMap that is composed of AttributeStack structs and they have a member attributeVec that is serving as a stack of attributes. The top of the stack is "current" attribute or the last pushed attribute. That is the one I need to get. Until now, I see a threading issue like two threads manipulating the "attribute stack". I'll say it again: you can't access those attribute stacks from the cull traversal. They don't contain anything sensible. I that case a different question: How to get "current" osg::FrontFace attribute? I mean the one that would be active for any drawable traversed at the present moment during cull traversal that is just in progress and I am handling it in my custom Shadow class that is already working perfectly except some attribute values that user may pass from the scene graph above and that need to be properly handled to cast shadows correctly. The answer: "you do not need it" would be wrong at the moment. Thx, John ___ 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] latest NVIDIA drivers
Hi Trajce,
I have noticed issues with Shader compilation on 256 (and above) series on
Windows 7. Some fragment shaders using gl_LightSource fields were generating
internal compiler errors. In fact I also posted a bug report to NVidia. These
errors were normally reported by OSG with compilation log showing assembly cg
output that was causing trouble for compiler. You don't see any compilation
errors even with OSG_NOTIFY_LEVEL=DEBUG_INFO ?
I have attached the bug report I posted to NVidia you can check if it could
related.
Cheers,
Wojtek
From: Trajce (Nick) Nikolov
Sent: Thursday, August 05, 2010 8:47 AM
To: OpenSceneGraph Users
Subject: [osg-users] latest NVIDIA drivers
Hi community,
anyone has experienced some weirdness with the latest drivers from NVIDIA? My
shaders just stopped working with them without any warning/error from OSG ...
-Nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Any OpenGL program doing pixel shader lighting using standard
OpenGL state variables may encounter this problem.
Compilation of pretty standard fragment shaders doing pixel lighting math
using gl_LightSource / gl_FrontMaterial uniforms
fail with internal GLSL compiler error:
Internal error: assembly compile error for fragment shader at offset
13132:
-- error message --
line 254, column 1: error: binding in multiple relative-addressedarrays
After examination it looks like gl_LightSource.attenuation factors are multiply
generated into intermediate shader constants. This problem was not present on
Windows drivers before 256 series. I observed the error with driver versions
257.15 and
recent WHQL 257.21 on GeForce FX 280 / GeForce FX 8800 GTS and Quadro 5800
(Quadro Plex D2).
I have not tested other boards. So it was happening on every board I tested.
Below are simplified example shaders and generated GLSL compiler error output
showing the error.
My program uses 3 lights. Using 1 or 2 lights does not generate error:
Compiling VERTEX source:
1: varying vec3 position;
2: varying vec3 normal;
3:
4: void main(void)
5: {
6: gl_Position = ftransform();
7: position = vec3(gl_ModelViewMatrix * gl_Vertex);
8: normal = normalize(gl_NormalMatrix * gl_Normal.xyz);
9: }
Compiling FRAGMENT source:
1: varying vec3 position;
2: varying vec3 normal;
3:
4: void main( )
5: {
6: vec4 ambient = vec4(0.0, 0.0, 0.0, 0.0);
7: vec4 diffuse = vec4(0.0, 0.0, 0.0, 0.0);
8: vec4 specular = vec4(0.0, 0.0, 0.0, 0.0);
9:
10: vec3 normalizedNormal = normalize(normal);
11:
12: for(int lightId = 0; lightId < 3; lightId++)
13: {
14:vec3 lightVector = gl_LightSource[lightId].position.xyz;
15:
16:float attenuation = 1.0;
17:
18:if( gl_LightSource[lightId].position.w != 0.0 )
19:{
20: lightVector -= position;
21: float distance = length(lightVector);
22: attenuation = 1.0 / (gl_LightSource[lightId].constantAttenuation +
23: gl_LightSource[lightId].linearAttenuation * distance +
24: gl_LightSource[lightId].quadraticAttenuation * distance *
distance)
25:}
26:
27:ambient += attenuation * gl_LightSource[lightId].ambient;
28:
29:vec3 normalizedLightVector = normalize(lightVector);
30:
31:float nDotL = dot(normalizedNormal, normalizedLightVector);
32:
33:if( nDotL > 0.0 )
34:{
35: diffuse += attenuation * nDotL * gl_LightSource[lightId].diffuse;
36:
37: if(gl_FrontMaterial.shininess > 0.0) {
38:float nDotHV = 0.0001;
39:float pf = pow( nDotHV, gl_FrontMaterial.shininess );
40:specular += attenuation * pf * gl_LightSource[lightId].specular;
41: }
42:}
43: }
44:
45: gl_FragColor =
46: gl_FrontLightModelProduct.sceneColor +
47: gl_FrontMaterial.emission +
48: ambient * gl_FrontMaterial.ambient +
49: diffuse * gl_FrontMaterial.diffuse +
50: specular * gl_FrontMaterial.specular;
51: }
52:
Linking osg::Program "" id=1 contextID=0
glLinkProgram "" FAILED
Program "" infolog:
Fragment info
-
Internal error: assembly compile error for fragment shader at offset 13132:
-- error message --
line 254, column 1: error: binding in multiple relative-addressedarrays
-- internal assembly text --
!!NVfp4.0
OPTION NV_parameter_buffer_object2;
# cgc version 3.0.0001, build date Jun 7 2010
# command line args:
#vendor NVIDIA Corporation
#version 3.0.0.1
#profile gp4fp
#program main
#semantic gl_LightSource : state.light
#semantic gl_FrontMaterial : state.material.front
#semantic gl_FrontLightModelProduct : state.lightmodel.front
#var float4 gl_LightSource[0].ambient : state.light[0].ambient : c[0] : -1 : 1
#var float4 gl_LightSource[0].diffuse : state.light[0].diff
Re: [osg-users] StandardShadowMap on ATI
Perfect ! One thing got me intrigued, though. You derive internal ViewData class from MinimalShadowMap::ViewData instead of VsvCustomShadowTechniqueClass::ViewData. Is it deliberate ? I suspect this works because VsvCustomShadowTechniqueClass is actually MinimalCullBoundsShadowMap and MinimalCullBoundsShadowMap::ViewData does not differ from MinimalShadowMap::ViewData. But if one day you will try to change VsvCustomShadowTechniqueClass typedef to other ViewDependentTechnique class some issues may appear. PS. In the meantime I managed to install Catalsyst 10.7. Textures on island scene are still broken (as in 10.5/10.6) no matter which shadow technique I use. They are broken even with the simplest ShadowMap. Perhaps, you have found a workaround for this problem ? Wojtek -- From: "Bradley Baker Searles" Sent: Tuesday, August 03, 2010 10:47 PM To: Subject: Re: [osg-users] StandardShadowMap on ATI Alright, so just wanted to post the code for the overrides I did, just in case anyone stumbles upon this forum entry and wants to see precisely what I did. It's a bit different than the example that Wojtek posted in this thread (as referenced above): http://forum.openscenegraph.org/viewtopic.php?t=4178 (Wojtek's MyViewDependentShadowMap example) :D Seems to be working very well. Thanks again- Baker Searles -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30504#30504 Attachments: http://forum.openscenegraph.org//files/osgforum_ati_107_drivers_266.jpg http://forum.openscenegraph.org//files/st_174.cpp http://forum.openscenegraph.org//files/st_482.h ___ 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] threading and captureCurrentState
I see. Apologies for the misinformation.
WL
--
From: "PCJohn"
Sent: Wednesday, August 04, 2010 9:33 AM
To: "OpenSceneGraph Users"
Subject: Re: [osg-users] threading and captureCurrentState
Hi,
captureCurrentState name is misleading - it is not capturing state from
OpenGL.
It should be, maybe, getCurrentState. It is just taking last pushed
attributes on the state stack. These attributes are returned in the
StateSet given as parameter. Thus, the function should work any time
during cull traversal, I guess.
I do not understand, but it work with SingleThreaded and
CullDrawThreadPerContext while it crashes with DrawThreadPerContext and
CullThreadPerCameraDrawThreadPerContext. It seems to me like two threads
are accessing state stack...
John
Wojciech Lewandowski wrote:
Hi,
I don't think its allowed to call captureCurrentState in Cull stage. I am
not certain about this, but would expect that captureCurrentState would
read OpenGL state and update osg::State accordingly. If this is the case
then it does require valid OpenGL context, which is only guaranteed to be
valid in Render stage. SingleThreaded mode is bit different and manages
SceneViews differently which has the side effect that OpenGL context
often remains valid beetwen Render stages .
Wojtek
--
From: "PCJohn"
Sent: Tuesday, August 03, 2010 4:38 PM
To: "OpenSceneGraph Users"
Subject: [osg-users] threading and captureCurrentState
Hi,
I see a threading issue when capturing current attributes in cull phase.
My code placed in my derived ShadowTechnique::cull():
void MyShadowVolume::cull( osgUtil::CullVisitor& cv )
{
ref_ptr< StateSet > currentState = new StateSet;
cv.getState()->captureCurrentState( *currentState );
cv.pushStateSet( _ss1 );
_shadowedScene->Group::traverse( cv );
cv.popStateSet();
cv.pushStateSet( _ss2 );
_shadowedScene->Group::traverse( cv );
cv.popStateSet();
}
StateSets are not changing. It crashes inside captureCurrentState while
I have to wait few seconds. However, the time changes (race-condition?).
It looks like threading issue and if I set viewer.setThreadingModel(
SingleThreaded ), the problem seems to disappear.
Is the code above correct? Am I using captureCurrentState correctly? I
need it to determine FrontFace attribute settings.
Thanks,
John
___
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] threading and captureCurrentState
Hi,
I don't think its allowed to call captureCurrentState in Cull stage. I am
not certain about this, but would expect that captureCurrentState would read
OpenGL state and update osg::State accordingly. If this is the case then it
does require valid OpenGL context, which is only guaranteed to be valid in
Render stage. SingleThreaded mode is bit different and manages SceneViews
differently which has the side effect that OpenGL context often remains
valid beetwen Render stages .
Wojtek
--
From: "PCJohn"
Sent: Tuesday, August 03, 2010 4:38 PM
To: "OpenSceneGraph Users"
Subject: [osg-users] threading and captureCurrentState
Hi,
I see a threading issue when capturing current attributes in cull phase.
My code placed in my derived ShadowTechnique::cull():
void MyShadowVolume::cull( osgUtil::CullVisitor& cv )
{
ref_ptr< StateSet > currentState = new StateSet;
cv.getState()->captureCurrentState( *currentState );
cv.pushStateSet( _ss1 );
_shadowedScene->Group::traverse( cv );
cv.popStateSet();
cv.pushStateSet( _ss2 );
_shadowedScene->Group::traverse( cv );
cv.popStateSet();
}
StateSets are not changing. It crashes inside captureCurrentState while I
have to wait few seconds. However, the time changes (race-condition?). It
looks like threading issue and if I set viewer.setThreadingModel(
SingleThreaded ), the problem seems to disappear.
Is the code above correct? Am I using captureCurrentState correctly? I
need it to determine FrontFace attribute settings.
Thanks,
John
___
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] Visual Studio 2010 binaries
Thank You ! Wojtek -- From: "Christiansen, Brad" Sent: Sunday, August 01, 2010 2:26 PM To: Subject: [osg-users] Visual Studio 2010 binaries Hi All, I have built OSG, VPB and many of the 3rd party libraries using Visual Studio 2010 (trying to decide whether to upgrade). I have just uploaded them in case anyone else might find them useful: http://members.iinet.net.au/~bchrist/OSG-Rev11685-Binaries-2010-x86.zip.zip (today's trunk) http://members.iinet.net.au/~bchrist/VPB-Rev1013-Binaries-VS2010-x86.zip (today's trunk) http://members.iinet.net.au/~bchrist/OSG-3rdParty-VS2010-x86.zip http://members.iinet.net.au/~bchrist/GDAL-1.6.3-Apps-VS2010-x86.zip I had to submit a very small patch to osgTerrain (missing include) and have had to make some small changes to the DirectShow plug-in (not yet submitted) but other than that OSG built without issue. VPB compiled fine but I did get a link error against osgDB which I couldn't resolve (duplicate symbol for a destructor of an iostream or something) but I forced the generation of the dll and it runs without any (obvious) issues. The 3rd party libraries included are: free type gif glut jpeg png tiff squish zlib gdal (no debug) collada (no debug) curl (no ssl) DirectShow (you still need to install the Windows SDK to build the plug-in) Cheers, Brad DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ 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] StandardShadowMap on ATI
Hi Baker, My responses below. Just for reference, the modifications I've made in my glsl shaders to get it running on ATI were mainly the following: - only index texture coordinates with constants, variables (even const) don't seem to work. - ensure all variables are initialized (sloppy on my part) - hardcode to light 0, the accumulation loop did not work. - don't use gl_FrontMaterial / gl_BackMaterial, as the values didn't work as they did with nVidia, and produced unexpected values. - don't use gl_FrontLightModelProduct, same reason as previous. Thats the ATI. I stay with Catalyst 10.4. With 10.5 I had the issues you show on osgshadow screenshots. 10.6 and 10.7 does not start on my machine. Bombs with blue screen on startup. Thats maybe related to the fact that I switched to dual GPU Radeon 5970. I saw on ATI forums that blue screens happen on dual GPU Radeons. I'm not using alpha in a nonstandard way (at least not intentionally), and I don't use discard for anything. That's good information though, and I will fiddle around with my shaders to see if they have any impact (although with the NULL program, they shouldn't be used, eh?). So having said that, the use of a NULL program indeed does seem like it should be valid, as specified in the OpenGL 21.20061201 spec (p. 75), and indeed OSG does call glUseProgram(0), which should revert to fixed function. So this is a driver bug, right? Still, I agree it might be useful to let the user provide a Program to use, or whether to attach the NULL program. I agree. However, its should be more generic to allow for modification of other StateAttributes as well. Some callback maybe... Currently the only option is overriding technique & its internal ViewData class (which is bit tricky but I think I have posted 'how to do it' on the forum). I ran osgshadow on the ATI 4670 with the 10.7 drivers, and I'll post the results below. I'm also attaching a screenshot of the vehicle in osgviewerWX, which seems to be having some texture coordinate issues (again, fine on nVidia). Hmm, even the osg cow seems wrong. I don't know precisely what the Texture Matrix fix is that you're speaking about, but I can poke around the forums and see if I find the issue. There is a line in Main Vertex Shader where tex coords at index zero 0 are computed: gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0; gl_TextureMatrix seems to be initialized to 0 on ATI Catalyst 10.4 and resulting tex coords are always 0. Workaround for this is to either comment out gl_TextureMatrix[0] multiplication in this shader or set up identity osg::TexMat at the scene root state set. With above change I am fairly happy on 10.4. So I recommend you try these drivers. For my laptop with really old ATi XPress 1200 I use Catalyst 10.2 and these drivers seem to be even better because osgshadow works without any modifications. I must be honest with you though. I actually have two cards on my Windows 7 one NVidia 8800 and Radeon 5970. And NVidia is most of the time the card of choice for OpenGL. So I maybe shoud not say I do lots of extensive testing on the Radeon. I switch to it when I want to check code compatibilty. As I wrote earlier I am not able to get 10.6 and 10.7 to start up. But I have earlier tried 10.5 and they showed the same problems with texture that looked like your screenshots. We discussed this on the osg-forum couple weeks ago (http://forum.openscenegraph.org/viewtopic.php?p=29501#29501) So you may consider giving 10.4 or earlier drivers second chance ;-) And by the way, thanks for the lispsm submission, it's really well done! I am happy when people use it ;-) Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ModelView and Projection Matrices
Hi Guy, Are you sure result is 3 ? Maybe rather -3 ? OpenGL is by default (view=identity) looking along Z- axis. When you set near N and far F this means near plane contains point(0,0,-N) and far plane contains point(0,0,-F). So if you want ot get z=1 from multiplication by ModelViewProj you should rather use pt = vec3( 0,0,-zw/z) in your example. Please also note that gluProject also takes viewport and converts your result to Window coordinates where depth range is 0..1. After projection (and scaling by w coordinate) resulting range is -1..1. So called Widnow matrix translates point values from postprojective space to window space. Cheers, Wojtek From: Guy Sent: Wednesday, July 28, 2010 11:23 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] ModelView and Projection Matrices Hi all, I'm encountering an inconsistency between OpenGL vertex manipulation and OSG. It is almost sure that it's my own misuse of OSG so I will present the issue and be glad to learn. J I'm trying to force a point in orthographic projection to have a specific z value. Suppose z = 0.95 I know the world point is (xw,yw,zw) So I calculate near/far planes in orthographic projection to be [0, zw/z] Then I create the projection matrix to be osg::Matrix new_proj = osg::Matrix::ortho(-(width*0.5),width*0.5,-(height*0.5),height*0.5, 0, zw/z); osg::Matrix new_view = osg::Matrix::identity(); The model view matrix is identity. Now, I create a dummy vertex to check the projection: osg::Vec3 pt(0,0,zw/z); osg::Vec3 s = new_proj.preMult(new_view .preMult(pt)); I would expect s.z() to be 1 or a smaller number but very very close to one. What I get is 3. (width x height are 160x120. zw = 800) When I use the utility function double x,y,z; int success = gluProject(pt.x(), pt.y(), pt.z(),new_view.ptr(), new_proj.ptr(), vp, &x, &y, &z); z is very close to 1 (0.9997.) as was expected. Can anyone explain? Thanks, Guy L. ___ 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] Texture2DArray and invalid enumerant error
Hi Glenn, Since TextureArrays are supposed to work only with programmable pipeline, there is no such GL Mode as GL_TEXTURE_2D_ARRAY. It could be considered a bug in OSG that setting this mode is attempted. Workaround: don't attach the textureArray with setTextureAttributeAndModes but with setTextureAttribute. Cheers, Wojtek From: Glenn Waldron Sent: Wednesday, July 28, 2010 3:12 AM To: OpenSceneGraph Users Subject: [osg-users] Texture2DArray and invalid enumerant error Hi, I'm using the Texture2DArray class with a VBO geometry and a shader program. I get a non-stop stream of this message: Warning: detected OpenGL error 'invalid enumerant' after applying GLMode 0x8c1a (..where 0x8c1a = TEXTURE_2D_ARRAY_EXT) The Texture2DArray (and associated sampler2Darray) is working correctly and my scene renders properly. But I'm having no luck tracking down cause of the message ... any ideas? OSG SVN trunk, Win7/VS9, GTS 250. -- Glenn Waldron : Pelican Mapping : +1.703.652.4791 ___ 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] StandardShadowMap on ATI
Hi Bradley,
I have not tested StandardShadowMap with Catalyst 10.7. 10.5 & 10.6 did not
work for me so I have been staying at 10.4. With 10.4 the only issue I had
was TexMat not initialized to identity and mainVertexShader in Standard
Shadow Map was producing 0,0 base texture coords for all frgments.
I guess you have a bit different situation, though. You write that your
scene already contains programs with shaders. When NULL program is applied
with override, it means that your shaders are blocked and fixed pipeline
draws the shadow map. So you may have the problems if your shaders compute
alpha with some non standard (non repeatable in fixed pipeline) way or
discard fragments.
I must admit that for above case setting NULL program might be seen as a
bug. However, it was done in purpose to make shadow map rendering faster
because color does not need to be computed and thus there is no need to use
existing usually more complex shaders. But if they discard fragments or
compute depth it may be not such good idea after all... We may try to come
up with a new method to let user select if he/she wants to set this NULL
program or not.
Out of curiosity does the same problem appear in osgshadow example ? The
example works on 10.4 (with minor TexMat modification).
Try: osgshadow -4 --lispsm or osgshadow -4 --stsm
Cheers,
Wojtek
--
From: "Bradley Baker Searles"
Sent: Wednesday, July 28, 2010 12:48 AM
To:
Subject: [osg-users] StandardShadowMap on ATI
Hi,
I have been working for a while on compatibility issues with nVidia and
ATI in our OpenSceneGraph application. Aside from a fair number of GLSL
shader source issues, one of the last remaining problems was that textured
objects were not casting shadows (please see first attached screenshot).
After a little detective work, it seems that the empty osg Program
attached to the StateSet belonging to the _camera in
StandardShadowMap::ViewData::init() is causing the problem:
// optimization attributes
osg::Program* program = new osg::Program;
stateset->setAttribute( program, osg::StateAttribute::OVERRIDE |
osg::StateAttribute::ON );
stateset->setMode
( GL_LIGHTING, osg::StateAttribute::OVERRIDE |
osg::StateAttribute::OFF );
stateset->setMode
( GL_BLEND, osg::StateAttribute::OVERRIDE |
osg::StateAttribute::OFF );
#if 0 // fixed pipeline seems faster (at least on my 7800)
program->addShader( new osg::Shader( osg::Shader::FRAGMENT,
"uniform sampler2D texture;
\n"
"void main(void)
\n"
"{\n"
" gl_FragColor = texture2D( texture, gl_TexCoord[0].xy );
\n"
"}
\n"
) ); // program->addShader Fragment
program->addShader( new osg::Shader( osg::Shader::VERTEX,
"void main(void)
\n"
"{\n"
" gl_Position = ftransform();
\n"
" gl_TexCoord[0] = gl_MultiTexCoord0;
\n"
"}
\n"
) ); // program->addShader Vertex
#endif
The setting of the fragment and vertex shaders to the stateset are #if
0'd out, but the osg Program setting is not.
Anyway, if I skip adding the empty program, things seem fine. Oddly, if
I keep the empty program and skip the AlphaFunc above it that allows
texture alpha to affect the depth buffer render, it casts shadows properly
(well, without the alpha penetration of course).
Everything works fine with nVidia drivers, even with the empty program.
My scene has a mixture of shader programs depending on how the objects
are setup, but they all include the shadow shader source (except the flat
shaded objects like the force arrows shown below).
So it seems to be an easy fix, but I was curious if anyone else had run
into this problem? I did many searches on the forum and came up empty.
And if anyone has deeper illumination into how the empty program could
affect the statesets (seems like a bug to me since nVidia works fine), or
if there is a more appropriate fix I'm not thinking of, I'd appreciate the
feedback.
Thanks-
Baker Searles
Hardware Versions:
nVidia GTS 250
ATI Radeon HD4670
Software Versions:
OSG @ 2.8.3
ATI Display Drivers @ 10.7
nVidia Display Drivers @ 258.96
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=30329#30329
Attachments:
http://forum.openscenegraph.org//files/ati_emptyglslprogram_noalphafunc_163.jpg
http://forum.openscenegraph.org//files/ati_noemptyglslprogram_192.jpg
http://forum.openscenegraph.org//files/ati_emptyglslprogram_debughud_103.jpg
http://forum.openscenegraph.org//files/ati_emptyglslprogram_167.jpg
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org
Re: [osg-users] DDS S3TC-DXTC compression only accept power of twosizes?
Hi Sukender, I think this is a bug or if you prefer one of the limitations of OSG DDS ReaderWriter. Feel free to fix it ;-) Cheers, Wojtek -- From: "Sukender" Sent: Tuesday, July 13, 2010 5:26 PM To: "osg-users" Subject: [osg-users] DDS S3TC-DXTC compression only accept power of twosizes? Hi all, When writing non power of two images in DDS with S3TC-DXTC compression, I got a scrambled image. - Is it a restriction of the format (it seems not; actually it seems DDS accepts any size, even not mutiple of 4). - Is is a restriction of the writer ? In that case, it should print a warning - Am I totally wrong? Thanks. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ 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] osgPPU and osgShadow::MinimalShadowMap
Hi Serge, I am sorry I have no experience with osgPPU. Long ago (2 years ?) we tried it with HDR and it seemed to work with LispSM shadows on our testbed. Have not tested since then. I could not help you at the moment, I am on vacations and my computer is a netbook. Send me a private email next week if you still have a problem, I will try to test it... Wojtek Lewandowski. PS. Do you by an chance test on ATI ? All techniques stemming from StandardShadowMap do not look good on latest Windows Catalyst drivers due to ATI VertexShader bugs (I can prove it). From: Serge Lages Sent: Tuesday, July 06, 2010 7:37 PM To: OpenSceneGraph Users Subject: [osg-users] osgPPU and osgShadow::MinimalShadowMap Hi all, I am currently having troubles trying to make work osgPPU and specially HDR with osgShadow::MinimalShadowMap, you can find my test program attached (it comes from the list archive, I've made small modifications). Without shadows, it works fine, with MinimalShadowMap, I only have a black model (I am using cow.osg, with the teapot I have a white screen). Here is my command line : osgppu_viewer.exe Data\hdr.ppu Data\cow.osg Any idea where it comes from ? Thanks ! -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Graphical issues with display lists on ATI 5870 cards
Hi Andy, I have seen some funky effects recently on Radeon 5970 & 4890. I was not able to install 10.6 on Windows 7 64 bit on 5970. Driver kept crashing with classic BSOD. But texture corruption you mention was present in 10.5 on Radeon 4890 as well. In both cases we switched back to Catalyst 10.4. We have read on the forums that ATI started to experiment with GL 3.3 & 4.0 recently and broke OpenGL 2.0 compatibility in latest drivers. My other observations on Catalyst 10.4 are related to Texture Matrix default not being identity in the shaders. Light attenuation factors seem to be incorrect in shaders as well. Frankly I don't have much experience with testing on Radeons, I ony have recently made few experiments. I could not count them as successful. Good thing about Windows 7 is one can have both NVidia & ATI installed together. Card that displays main screen renders all OpenGL so usually after some frustrating tests on ATI, I quickly switch main monitor to NVidia ;-). Cheers, Wojtek -- From: "Andy Peruggi" Sent: Tuesday, June 29, 2010 8:02 PM To: Subject: [osg-users] Graphical issues with display lists on ATI 5870 cards Hi everyone, My company has been developing products using OSG for a few years now, and recently we've noticed some rendering issues on two machines that are both running ATI 5870 cards using the latest ATI drivers (Catalyst 10.6). We wanted to know if anyone running similar hardware has seen these issues. We are using the 2.8.2 release of OSG. We notice two major graphical problems: * Incorrect lighting on primitives - flat geometry with equal vertex normals at all vertices appears to have incorrect lighting over the surface (using the default osgviewer lighting) * Corrupted textures - either a single pixel color over the entire surface or it looks like the UV coordinates were run through a blender We have tested rendering using the OSGViewer with a simple .osg file containing two triangles (forming a quad) with identical per-vertex normals and simple per-vertex UVs. What we have found is that we either have to disable display lists on the geometry in order to have the quad render correctly, or else we seem to be able to get correct results by adding additional (bogus) values to the per-vertex normal and UV lists to pad them. We believe this means that somewhere between OSG and the GPU the per-vertex data in the display list is getting corrupted and normals/UVs are getting lost. We have not experienced this issue in any other 3D apps on this hardware, including ones that use display lists. We also do not have the rendering issues with our app on other hardware (tested using several nVidia cards and and older ATI card). We think this may be an ATI driver bug, but we're not sure at this point and would like to hear if anyone else has run into these issues. Thanks. - Andy Peruggi Applied Research Associates, Inc[/list] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29501#29501 ___ 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] Shader composition, OpenGL modes and custom modes
Hi Guys, We all seem to agree that the topic actually consists from two subtopics: ShaderGeneration and ShaderComposition. Shader generation would be mostly used to emulate Fixed Pipeline and replace GL Attributes/Modes with generated uniforms and shader pieces. ShaderComposition would allow mixing and linking of various shader pieces gathered during cull traversal. Shader Generation seems to be the current focus of the discussion. ShaderComposition seems to be of a lower priority. I have the felling that these two subjects could be addressed together but they also could be addressed independently. ShaderComposition is needed to implement ShaderGeneration but not the opposite. So wouldn't it be better to first implement flexible ShaderCompositor that at first would only work with programmable pipeline in OSG ?. And later build ShaderGenerator on top of ShaderCompositor ? I believe there is a number of developers interested only in programmable pipeline. They would not mind writing shader chunks and using their uniforms to attain effect that fixed pipeline would also give them. They would do this to have clear and consistent shader code. And often they want to make transition to fully programmable pipeline as fast as possible because they feel thats how the 3D future will look. I am ready to make such switch. I only need working ShaderComposition. Personally I'm not interested in fixed pipeline emulation and where possible I will try to program shader pipeline myself. Call me short sighted but I am afraid that trying to replace programmers with shader generators will make this coding more complicated. Once ShaderComposition becomes available I am not going to go back to FFP and will avoid StateAttributes that exist only in fixed pipeline. I will thus indirectly avoid using ShaderGeneration feature as well. In my opinion many programmable pipeline concepts are easier to understand than the stuff in Fixed Pipeline (take TexEnv or TexMat for example) and I would always prefer to have direct control over uniforms & shaders neccessary to implement certain feature. With ShaderGeneration I will never be sure what shader code was produced and how uniforms were attached. That's my opinion. But I am taking the risk of presenting it because I think there are others who share this view and would prefer to make transition to fully programmable pipeline as quickly as possible. There is a number of algorithms where Fixed pipeline states simply don't fit. Deffered shading for huge number of lights for example. Its better to implement them in fully programmable environment than mix fixed and programmable approaches. I know there are other users and lots of existing OSG code which relies on fixed pipeline. I understand that this existing code will require ShaderGeneration but I really feel that the discussion is focusing on second step when first one was not made yet. Cheers, Wojtek Lewandowski PS. I won't be able to respond for next 3 days. -- From: "Robert Osfield" Sent: Thursday, June 24, 2010 4:51 PM To: Subject: Re: [osg-users] Shader composition, OpenGL modes and custom modes Hi All, As another step towards experimenting with shader composition I've renamed the osgshadercompositor example to osgvirtualprogram as this example is based around a VirtualProgram class, and I'd like to differentiate between test beds like this and work to towards the final shader composition support. Later I'll add a osgshadercomposition/osgshadercompositor/osgshadercomposer example that will be the test bed for the new work on shader composition. 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] OpenGL Shader application problem
Phil, This method often works. Use it also for other state attributes which seem unitialized to proper defaults. Cheers, Wojtek -- From: "Phil Fugue" Sent: Thursday, June 24, 2010 9:10 PM To: Subject: Re: [osg-users] OpenGL Shader application problem Wojtek, That worked!!! :D Good call. I dont think I ever would have stumbled on that on my own. So thanks, I really appreciate it. Cheers, Phil -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29389#29389 ___ 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] OpenGL Shader application problem
Phil, No shaders attached. This turns off shaders so effectively you turn on fixed pipeline. WL -- From: "Phil Fugue" Sent: Wednesday, June 23, 2010 5:11 PM To: Subject: Re: [osg-users] OpenGL Shader application problem Wojtek, Thanks, I'll try that. Blind shots are fine, since this is so mysterious. :) By empty program, do you mean with no shaders attached, or do you mean with shaders containing the fixed OpenGL functionality? I'm concerned just an empty program will result in overiding the fixed functionalty of all the geometry that doesnt have its own custom shader. But I'll give it a try, and let you know. Thanks Phil -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29320#29320 ___ 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] OpenGL Shader application problem
Hi Phil, Its a blind shot but try setting up empty osg::Program at scene root. There is a chance that somehow your first encountered shader was assumed to be stage default by OSG. And since you don't set anything at the root it may leak on second frame render. Its just a guess. This is a weak hypothesis and don't ask me about solid proof ;-) Wojtek -- From: "Phil Fugue" Sent: Tuesday, June 22, 2010 9:42 PM To: Subject: [osg-users] OpenGL Shader application problem Hi, An odd problem, and not sure quite how to describe. But here goes The quick summary is: When I cull certain geometry from my scene, an openGL shader seems to get applied to the root node (and thus the whole scene) rather than just the geometry it belongs on, but ONLY at the start up of the app. When those same conditions are in place later, it works just fine. Whats happening at start up? More detailed: I have two pieces of geometry (geom1, geom2), they both have individual shaders applied to them respectively (shad1, shad2). I have keyboard controls to toggle the geometry on and off in the scene. My first hacky attempt at toggling (for quickness, and lack of knowledge of other mechanisms), I just translated the geometry out of view to toggle them 'off'. So on start up both geoms were 'off' out of view. But having geom2 out of view at startup resulted in shad1 being applied to the root node. When I toggled it (or anything else) 'on', all the sudden all shaders were applied appropriately. And remained correct for all toggling off and on. I.e, the startup error was not reproducable once into the app. And geom1 and geom2 are totally unrelated. Both are children of the root. After finding the osgSwitch node, I reworked the code so that the toggling was done with SetAllChildrenOff/On() of a switch node parenting each of the geoms. If at startup, I set them on initially, all is well. But when I set them off for startup (desired), then it starts up with shad1 applied to the root again and shading the whole scene. Then if I toggle anything (geom1 or geom2), everyting snaps into working order and all is well. So there's just something at startup when shader geometry is culled initially that is confusing the application of the shader, but is fine later. What is going on here? I dont even know what code to post here, as the shader code seems to be ok, since it works in all cases other than startup. Hope I articulated this clearly. Any ideas? Thank you! Cheers, Phil -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29278#29278 ___ 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] Render graphics for 3DReady-TV?
Hi Guys, Some of the older stereovision standards were also supported by IZ3D & TriDef drivers. I don't know much about TriDef but IZ3D also works with OpenGL and can emulate Quad Buffer on GeForce on Windows. I am not sure if they yet support new HDMI 1.4 3D standard thats used by new TV sets, though. But probably some day they will. Nvidia 3D TV Play is supposed to work with both Quadro and new TVs. But its also not yet available. Have a look at www.mtbs3d.com forums if you want to know more about alternative drivers and their capabilities. Cheers, Wojtek Lewandowski From: Riccardo Corsi Sent: Tuesday, June 22, 2010 5:47 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Render graphics for 3DReady-TV? Hi Jan, at the moment you can use the nVidia 3d kit with osg (with openGL in general) only if you use a quadro card. Besides the fact that this restriction doesn't make any sense to me, if the TV support the nVidia synch signal, it should be ok to use them as 3D monitor with a quadro card. There should be some posts in the forum nVidia about this topic, but the forum is down at the moment... Ricky On Tue, Jun 22, 2010 at 17:27, Jan Ciger wrote: AFAIK, all this stuff supports only the Nvidia 3D technology - which is unfortunately undocumented and DirectX only. Or am I wrong? The classical stereo - interlaced, frame sequential etc. are well supported by OSG and if the device can display such 3D content it will work. Jan ___ 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] Developer release of OSG and VPB imminent, please test.
Hi Robert, I think thats Ok to silence the warning only. Maybe warpPointer should not be called at the inital home() call but I guess it should be called on next home() call when user presses space. So in the end I don't know either, whether its wrong or good to have requestWarpPointer() there. But if I don't know how to fix it, I would leave it as is. Maybe others have better ideas... Wojtek -- From: "Robert Osfield" Sent: Friday, June 18, 2010 4:59 PM To: "OpenSceneGraph Users" Subject: Re: [osg-users] Developer release of OSG and VPB imminent,please test. Hi Guys, I thought I had checked in my changes to make the warning using the INFO notify level, but alas I now find that I didn't, there are now checked in. This will quieten the warning. Whether we need to do anything about osgGA's invoking the warp pointer is still an open question though, I haven't done into the relevant code to answer this. 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] Developer release of OSG and VPB imminent, please test.
HI Wang, Yeah. Default manipulators differ between our test cases. But they booth are derived from the same base class. I looked at osgviewer you looked at osganimate. Wojtek -- From: "Wang Rui" Sent: Friday, June 18, 2010 4:34 PM To: "OpenSceneGraph Users" Subject: Re: [osg-users] Developer release of OSG and VPB imminent,please test. Hi Wojciech, Yes, FlightManipulator also calls centerMousePointer() in its init() and home() method, which calls requestWarpPointer() internally. The FlightManipulator and DriverManipulator both bring about the issue. Cheers, Wang Rui 2010/6/18 Wojciech Lewandowski : I hit send too fast. Let me write it again: Hi J-S, Just put breakpoints at line where warning is output and in GraphicsWindowWin32::realizeImplementation(). First is hit before the second. So case is straight forward: FlightManipulator is added to KeySwithcManipulator set as main Viewer CameraManipulator. When added it calls home() to initialize and home() calls requestWarpPointer() to center mouse position. Its done before Viewer::realize() so the warning is correct. Question is whether requestWarpPointer() should be called there if its not working. GraphicsWindowX11::requestWarpPointer most probably does not work too, but it does not display the warning... Wojtek PS. Hope it clearer now. ___ 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] Developer release of OSG and VPB imminent, please test.
I hit send too fast. Let me write it again: Hi J-S, Just put breakpoints at line where warning is output and in GraphicsWindowWin32::realizeImplementation(). First is hit before the second. So case is straight forward: FlightManipulator is added to KeySwithcManipulator set as main Viewer CameraManipulator. When added it calls home() to initialize and home() calls requestWarpPointer() to center mouse position. Its done before Viewer::realize() so the warning is correct. Question is whether requestWarpPointer() should be called there if its not working. GraphicsWindowX11::requestWarpPointer most probably does not work too, but it does not display the warning... Wojtek PS. Hope it clearer now. -- From: "Wojciech Lewandowski" Sent: Friday, June 18, 2010 4:18 PM To: "OpenSceneGraph Users" Subject: Re: [osg-users] Developer release of OSG and VPB imminent,please test. Hi J-S, Jusat put breakpoints at line where warning is output and in GraphicsWindowWin32::realizeImplementation. First is hit before the second. So case is straight forward. FlightManipulator is added to KeySwithcManipulator set as main Viewer CameraManipulator. When added it call home to initialize and home calls requestWarpPointer to center mouse positio. As its done before Viewer::realize the warning is correct. Question is whether requestWarpPointer should be called there if its not working. GraphicsWindowX11::requestWarpPointer most probably does not work too but it does not display the warning... Wojtek PS. In my opinion -- From: "Jean-Sébastien Guay" Sent: Friday, June 18, 2010 4:00 PM To: "OpenSceneGraph Users" Subject: Re: [osg-users] Developer release of OSG and VPB imminent, please test. Hi Wojtek, Wang Rui, Its on QuadroPlex. But I doubt hardware is involved. Maybe Windows version (mine is 7 64 bit) has more to do with it... Windows 7 64bit here too... Wang Rui, were you able to debug into the code and find anything? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ 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] Developer release of OSG and VPB imminent, please test.
Hi J-S, Jusat put breakpoints at line where warning is output and in GraphicsWindowWin32::realizeImplementation. First is hit before the second. So case is straight forward. FlightManipulator is added to KeySwithcManipulator set as main Viewer CameraManipulator. When added it call home to initialize and home calls requestWarpPointer to center mouse positio. As its done before Viewer::realize the warning is correct. Question is whether requestWarpPointer should be called there if its not working. GraphicsWindowX11::requestWarpPointer most probably does not work too but it does not display the warning... Wojtek PS. In my opinion -- From: "Jean-Sébastien Guay" Sent: Friday, June 18, 2010 4:00 PM To: "OpenSceneGraph Users" Subject: Re: [osg-users] Developer release of OSG and VPB imminent, please test. Hi Wojtek, Wang Rui, Its on QuadroPlex. But I doubt hardware is involved. Maybe Windows version (mine is 7 64 bit) has more to do with it... Windows 7 64bit here too... Wang Rui, were you able to debug into the code and find anything? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Developer release of OSG and VPB imminent, please test.
Yup. Still there. osgviewer ran on all (2) screens produces following warning: Error: [Screen #1] GraphicsWindowWin32::requestWarpPointer() - Window not realized; cannot warp pointer Error: [Screen #1] GraphicsWindowWin32::requestWarpPointer() - Window not realized; cannot warp pointer run with option --screen 0 generates this warning: Error: [Screen #0] GraphicsWindowWin32::requestWarpPointer() - Window not realized; cannot warp pointer Error: [Screen #0] GraphicsWindowWin32::requestWarpPointer() - Window not realized; cannot warp pointer Error: [Screen #0] GraphicsWindowWin32::requestWarpPointer() - Window not realized; cannot warp pointer Error: [Screen #0] GraphicsWindowWin32::requestWarpPointer() - Window not realized; cannot warp pointer Its on QuadroPlex. But I doubt hardware is involved. Maybe Windows version (mine is 7 64 bit) has more to do with it... Cheers, Wojtek Lewandowski -- From: "Wojciech Lewandowski" Sent: Friday, June 18, 2010 3:11 PM To: "OpenSceneGraph Users" Subject: Re: [osg-users] Developer release of OSG and VPB imminent,please test. Hi Wang & J-S I saw it on Radeon 4800 & 5890 in Windows 7 with multiple monitors. But it was week ago and obvioulsy it wasn't the current version. I am currently rebuilding last version. I will let you know when I do the tests. However, in the meantime I have uninstalled the Radeons but have the Quadro instead so results will be still interesting I hope. Cheers, Wojtek Lewandowski -- From: "Wang Rui" Sent: Friday, June 18, 2010 2:30 PM To: "OpenSceneGraph Users" Subject: Re: [osg-users] Developer release of OSG and VPB imminent,please test. Hi Robert, and Adrian, The issue seems to appear around the time of modification of osgGA manipulators. I will look into it. I'm not sure if it is a driver issue. I'm using nVidia Geforce 8600GT. But one of my friend also report the problem. I'll have a test on a Geforce 9600GT system tonight. Cheers, Wang Rui 2010/6/18 Robert Osfield : Curious. How long has the warning been there? As warnings go it's probably something that is safe to ignore. I do wonder if it's related to the refactor of osgGA's camera manipulators. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users 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] Developer release of OSG and VPB imminent, please test.
Hi Wang & J-S I saw it on Radeon 4800 & 5890 in Windows 7 with multiple monitors. But it was week ago and obvioulsy it wasn't the current version. I am currently rebuilding last version. I will let you know when I do the tests. However, in the meantime I have uninstalled the Radeons but have the Quadro instead so results will be still interesting I hope. Cheers, Wojtek Lewandowski -- From: "Wang Rui" Sent: Friday, June 18, 2010 2:30 PM To: "OpenSceneGraph Users" Subject: Re: [osg-users] Developer release of OSG and VPB imminent,please test. Hi Robert, and Adrian, The issue seems to appear around the time of modification of osgGA manipulators. I will look into it. I'm not sure if it is a driver issue. I'm using nVidia Geforce 8600GT. But one of my friend also report the problem. I'll have a test on a Geforce 9600GT system tonight. Cheers, Wang Rui 2010/6/18 Robert Osfield : Curious. How long has the warning been there? As warnings go it's probably something that is safe to ignore. I do wonder if it's related to the refactor of osgGA's camera manipulators. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Successful build using VS2010?
I am using VS 2010 Express on Windows 7. Latest cmake with the extra patched script they mention on download page seems to work just fine. Make sure to clean former installs and former builds first. My often made mistake in the past was not removing former files from install/include/lib directories and I was getting problems while building because build was finding not updated files from the environment path. I bet with latest CMake + patched Find VS 2010 Cmake module + fresh download you would be just fine Cheers, Wojtek Lewandowski -- From: "Nick Schultz" Sent: Friday, June 11, 2010 8:33 PM To: Subject: [osg-users] [build] Successful build using VS2010? Has anybody been able to successfully build the latest dev-head in VS2010? I kept getting several fatal LINK errors saying it cannot open input files ex: LINK : fatal error LNK1181: cannot open input file '..\..\lib\Release\osgGA.lib' I'm assuming it's a path error made somewhere in the build scripts. I posted about this a couple of months ago and I couldn't find a fix. I tried searching the forums about this topic but couldn't find anything, are we just out of luck trying to use VS2010 for now? Thanks, Nick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=28837#28837 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Changing textures tiling without changing texturecoordinates(?)
Alessandro, Check osg::TexMat. Thats exactly the thing you are looking for. You may be also intereste4d in osg::TexGen for automatic texture coords generated from vertex coords. Wojtek From: Alessandro Terenzi Sent: Tuesday, June 08, 2010 5:27 PM To: OpenSceneGraph Users Subject: [osg-users] Changing textures tiling without changing texturecoordinates(?) Maybe this is a silly question...anyway, how is it possible to change the number of times a texture repeats over a surface? For instance I have a model that comes with a texture already applied to it (for example a cube with the texture applied to each face) and I'd like to let the same texture repeat N times (along U or V or both) over each face. So far I can imagine only to change (by scaling) the texture coordinates of each vertex, is there any other way to achive the same result (maybe using methods from osg::Texture or osg::Texture2D)? If changing texture coordinates is the only way, is there a 'clever' way to do it? For example changing some parameter that affects every vertex in the geometry "in one shot" instead of changing each vertex coords individually...I'm just guessing... Thanks. Alessandro ___ 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] vertex shader for SoftShadowMap FragmentShader.
Hi Anders,
I see two problems with your shader.
First it looks like you swaped shadow and jitter map coords. I suppose you want
to generate shadow map coords with texgen. So texgen should produce unit 1
texture coords. But most probably you should use view space (gl_EyePlane)
coords for shadow coords.
Second it looks like lighting/ color math is completely absent so resulting
lighting will be probably random.
Please have a look at Vertex shader in osgShadow::StandardShadowMap.cpp. Its
quite generic and except jitter part it should contain all what you need for
single light scenario.
Cheers,
Wojtek Lewandowski
From: Anders Backman
Sent: Monday, June 07, 2010 3:27 PM
To: OpenSceneGraph Users
Subject: [osg-users] vertex shader for SoftShadowMap FragmentShader.
Hi all.
Im trying to use a VertexShader to drive the SoftShadowMap implementation of
the FragmentShader (which is present in the SoftShadowMap.cpp).
Problem is as usual, that when vertex shader is enabled, all automatic stuff
are disabled, such as texture generation.
Now after browsing archive, surfing the net and looking through the GLSL book,
I have come to the conclusion that the vertex shader below should be enough to
drive the Fragmentshader:
void main( void )
{
gl_Position = ftransform();
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
// Emulate glTexGen (on unit 2)
gl_TexCoord[2].s = dot(gl_Vertex, gl_ObjectPlaneS[2]);
gl_TexCoord[2].t = dot(gl_Vertex, gl_ObjectPlaneT[2]);
gl_TexCoord[2].p = dot(gl_Vertex, gl_ObjectPlaneR[2]);
gl_TexCoord[2].q = dot(gl_Vertex, gl_ObjectPlaneQ[2]);
}
baseTexture - Texture unit = 0
osgShadow_shadowTexture - Texture unit = 1
osgShadow_jitterTexture - Texture unit = 2
But as soon as I enable this vertex shader, the shadow stops working.
I need to write my own vertex shader to calculate vertex pos in eye coordinates
etc. Im basically trying to merge the shadows with other texturing, such as
parallax mapping etc.
Any hints on how to write a vertex shader that will replace the fixed
functionality for the SoftShadowMap Fragment shader (with base texture)??
/Anders
--
___
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] shadowmaps and texture arrays (Wojciech?)
I did something like this. Unfortunately I cannot disclose the source. But during this work I cleared the path for use of texture arrays for shadow map comparison. So yes its doable. With recent glFramebeufferTexture additon texture arrays seem like good match for one pass cascaded shadow map rendering using geometry shaders Cheers and Good Luck. Wojtek From: Trajce (Nick) Nikolov Sent: Monday, June 07, 2010 8:19 PM To: OpenSceneGraph Users Subject: [osg-users] shadowmaps and texture arrays (Wojciech?) Hi, I started with something lately and was wondering if there is implementation of shadows with texture arrays. if so, could someone give some insights ? Thanks a lot -Nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development Environment
Nope ;-) With VS2010 Express Beta I was using dependencies for 2008 + 2008 runtime. I intend to do the same before 3rd pary libs appear for VS 2010. WL - Original Message - From: "Jean-Sébastien Guay" To: "OpenSceneGraph Users" Sent: Monday, May 17, 2010 4:05 PM Subject: Re: [osg-users] Development Environment Hi Wojtek, FYI: Yesterday I tried to build OSG with 2010. Last stable CMake 2.8.1 is generating some cryptic errors so I checked most recent CMake 2.9.x from nightly builds. That version seems to work, so if you want to work with OSG under VS 2010 try nightly builds CMake version. Are you going to submit a basic set of 3rd party dependencies compiled for VS 2010? :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Development Environment
Hi Guys, FYI: Yesterday I tried to build OSG with 2010. Last stable CMake 2.8.1 is generating some cryptic errors so I checked most recent CMake 2.9.x from nightly builds. That version seems to work, so if you want to work with OSG under VS 2010 try nightly builds CMake version. Cheers, Wojtek - Original Message - From: "Torben Dannhauer" To: Sent: Sunday, May 16, 2010 10:24 AM Subject: Re: [osg-users] Development Environment Hi J-S, oops, you are right, I marked it as optional. I always integrate it, so I forgot that it is optional :) Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27912#27912 ___ 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] Development Environment
At the moment VS2010 Express seems to not work well with CMake 2.8.1 and OSG. Its too fresh probably... Maybe your result will vary but I would rather try 2008 Express to be on safe side. Cheers Wojtek Lewandowski -- From: "Frank Henard" Sent: Saturday, May 15, 2010 4:34 PM To: Subject: Re: [osg-users] Development Environment Hi Torben, That is extremely kind of you. I just downloaded Visual C++ Express 2010 last night. I will see if I can get VS 2008, and follow the instructions for that. Hopefully I won't need too much help. Thanks! Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27906#27906 ___ 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] Problem with projection
Czolem, I took a brief look. There might be other issues but one thing seems suspect to me. 720/568 in makePerspective call is computed on ints and hence is equal to 1. I am sure its not what you are after. Replace it with 720.f/568. Cheers, Wojtek -- From: "Tomek Krze" Sent: Monday, May 10, 2010 11:43 AM To: Subject: [osg-users] Problem with projection Hi, I have problem draw a points correctly on image. I want to manualy doing projection of vertex and draw on image. I set a camera position: Code: osg::Matrixf l; l.makeLookAt(osg::Vec3(0, 0, 500), osg::Vec3(0,0,0), osg::Vec3(0,1,0)); Projection matrix: Code: osg::Matrixf p; p.makePerspective(osg::DegreesToRadians(50.0f), 720/568, 1, 1000); and next i compute new vertex cordinate (vertex is osg::Vec3): Code: vertex = vertex*l; next i multiple new vertex cordinate by perspective matrix Code: vertex4 = osg::Vec4(vertex, 1); vertex4 = vertex4*p; vertex4.set(vertex4.x()/vertex4.w(), vertex4.y()/vertex4.w(), vertex4.z()/vertex4.w(), vertex4.w()); Now I draw vertex to image but result is diffrent with image with i get from 3dmax with this same camera parametr. I think I need multiple with viewport matrix Code: osg::Matrixf v ; osg::Viewport* viewport = new osg::Viewport(0,0,720,568); v = viewport->computeWindowMatrix(); But when i do it vertex cordinate is too big. Could someone tell what i doing wrong? ... Thank you! Cheers, Tomek -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27695#27695 ___ 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] Render to texture memory usage
Hi, Multithreading modes allocate two instances of OpenGL resources to speed up rendering . Default implicit buffer attachment policy adds depth buffer to FBOs if only color buffer was attached. Try running your app in SingleThreaded mode with Camera implicitBufferAttachmentRenderMask set to zero. Cheers, Wojtek - Original Message - From: "Martin Aasen" To: Sent: Wednesday, May 05, 2010 3:32 PM Subject: [osg-users] Render to texture memory usage Hi, I am rendering to a texture using a FBO: camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); camera->attach(osg::Camera_COLOR_BUFFER, texture, 0, 0, false, 0, 0); The consumption of GPU memory is about three times higher than I would expect: about 800 MB for a 8192 x 8192 GL_RGBA texture. Is this due to allocation of a depth buffer and others? I don't need depth testing so that could be disabled, but I don't understand how to... I was hoping that the memory consumption of the texure was all that was needed. Any help is much appreciated! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27573#27573 ___ 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
