[osg-users] Camera attached to object
Hi Sergey, osg::ref_ptrosgGA:: KeySwitchMatrixManipulator keyswitchManipulator = new osgGA::KeySwitchMatrixManipulator; I'm sorry osgGA was from prev version of osg, now manipulators are attached a bit differently, I will try to respond today later. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Camera attached to object
Hi Sergey, I'm back, actually you were right, osg::ref_ptrosgGA::KeySwitchMatrixManipulator keyswitchManipulator = new osgGA:: KeySwitchMatrixManipulato yes this way add that custom manipulator Regards Sergey On Mon, Mar 12, 2012 at 12:07 PM, Sergey Kurdakov sergey.fo...@gmail.comwrote: Hi Sergey, osg::ref_ptrosgGA:: KeySwitchMatrixManipulator keyswitchManipulator = new osgGA::KeySwitchMatrixManipulator; I'm sorry osgGA was from prev version of osg, now manipulators are attached a bit differently, I will try to respond today later. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph performance drop between Qt 4.7 and 4.8
Hi Marco, On 11 March 2012 18:13, Marco Fiocco marco.fio...@gmail.com wrote: I'm working with OpenSceneGraph 3.0.1 (the latest stable) and Qt. I have noticed a strange frame rate drop switching from Qt 4.7 to 4.8. With 4.7.3, the frame rate was maximum 60fps on every computer. With 4.8 the frame is maximum 38-40fps on every computer. Definitely too much to accept. I cannot understand why! Is it a bug or what? I'm not a Qt engineer so can only speculate on what might be the difference. My best guess is that the app your are testing is running a idle or timer callback to run each frame and this is being called less often by Qt 4.8 than Qt 4.7. With real-time apps one should never use a GUI timer or idle callback to instigate frame, rather the application should be frame driven and check for events on each frame. Most osgViewer based apps will be frame driven unless they change the mechanism for calling frame. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph performance drop between Qt 4.7 and 4.8
Hi, is Qt 4.8 already allowing multiple threads to write into one opengl context? If so it must handle this internal and this might generate some overhead. Also from the fps you gave it sounds like v-sync is on and given the afore mentioned slight delay might cause a large delay due to sync missis in the end. Arne Am 11.03.2012 um 19:13 schrieb Marco Fiocco: I'm working with OpenSceneGraph 3.0.1 (the latest stable) and Qt. I have noticed a strange frame rate drop switching from Qt 4.7 to 4.8. With 4.7.3, the frame rate was maximum 60fps on every computer. With 4.8 the frame is maximum 38-40fps on every computer. Definitely too much to accept. I cannot understand why! Is it a bug or what? Thanks for any help Marco ___ 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] Methods to improve large scene shadows with ViewDependentShadowMap
Hi all,
I'm currently working on an example that uses
osgShadow::ViewDependentShadowMap for generating dynamic shadows on a large
area of buildings. It can work correctly on a huge city which is created by
CityEngine and then converted to OSG styled scene graph. It also generates
aliasing issues as expected, but I'm still looking for some good solutions
to reduce such problem and want to discuss them in this thread if possible.
My test program and a simple shader file can be found in attachement.
I've already read a similar topic at:
http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2011-August/053731.html
And I believe it is necessary to apply some filters on the shadow map (the
test shader file simply uses PCF here) and increase the texture resolution
as well. But for huge scene, a 4096-sized RTT texture will be a heavy
burden. So I wonder if there are some more methods to choose, for example,
is it possible to change the internal format of the texture to
GL_DEPTH_COMPONENT32 to improve the shadow comparision process?
Meanwhile, is it necessary to perform a screen space blurring to reduce the
aliasing effect? It is a serious problem for my scene now as I can't use a
very high resolution. Could anyone suggest some other possible methods on
the post-processing level? To be honest, the ViewDependentShadowMap is the
best shadow solution for me at present as it is easy to be integrated with
custom shaders and embedded into a deferred shading framework.
The test city models are about 180MB. If any of you think it important for
digging into the problem. I'd like to share them freely, too, as I believe
these automatically generated models should not have any copyrights with
them. :-)
Cheers,
Wang Rui
#include osg/AnimationPath
#include osg/PolygonMode
#include osg/Texture2D
#include osg/Geometry
#include osg/Geode
#include osg/MatrixTransform
#include osgDB/ReadFile
#include osgShadow/ShadowedScene
#include osgShadow/SoftShadowMap
#include osgShadow/LightSpacePerspectiveShadowMap
#include osgShadow/ParallelSplitShadowMap
#include osgShadow/ViewDependentShadowMap
#include osgGA/TrackballManipulator
#include osgViewer/ViewerEventHandlers
#include osgViewer/Viewer
int main( int argc, char** argv )
{
unsigned int rcvShadowMask = 0x1;
unsigned int castShadowMask = 0x2;
osg::ref_ptrosg::Program program = new osg::Program;
program-addShader( osgDB::readShaderFile(shadowRenderer.frag) );
osg::ref_ptrosg::MatrixTransform city = new osg::MatrixTransform;
city-addChild( osgDB::readNodeFile(city_root.osgb) );
city-setNodeMask( rcvShadowMask|castShadowMask );
city-getOrCreateStateSet()-setMode( GL_LIGHTING, osg::StateAttribute::OFF );
city-getOrCreateStateSet()-setAttribute( program.get() );
osg::ref_ptrosg::LightSource light = new osg::LightSource;
light-getLight()-setPosition( osg::Vec4(1.0, 1.0, 1.0, 0.0) );
osg::ref_ptrosgShadow::ViewDependentShadowMap sm = new osgShadow::ViewDependentShadowMap;
osg::ref_ptrosgShadow::ShadowSettings settings = new osgShadow::ShadowSettings;
settings-setShaderHint( osgShadow::ShadowSettings::NO_SHADERS );
settings-setTextureSize( osg::Vec2s(2048, 2048) );
settings-setMinimumShadowMapNearFarRatio( 0.05 );
osg::ref_ptrosgShadow::ShadowedScene shadowRoot = new osgShadow::ShadowedScene;
shadowRoot-setShadowTechnique( sm.get() );
shadowRoot-setShadowSettings( settings.get() );
shadowRoot-setReceivesShadowTraversalMask( rcvShadowMask );
shadowRoot-setCastsShadowTraversalMask( castShadowMask );
shadowRoot-addChild( city.get() );
shadowRoot-addChild( light.get() );
osg::ref_ptrosgDB::Options options = new osgDB::Options(dds_flip);
options-setObjectCacheHint( osgDB::Options::CACHE_IMAGES );
osgDB::Registry::instance()-setOptions( options.get() );
osgDB::Registry::instance()-getOrCreateSharedStateManager();
osgViewer::Viewer viewer;
viewer.setSceneData( shadowRoot.get() );
viewer.addEventHandler( new osgViewer::StatsHandler );
return viewer.run();
}
shadowRenderer.frag
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Scene.cpp deadlock
Hi, I found a deadlock in Scene.cpp. The problem exhibits itself when calling std::exit() instead of standard way of terminating of the application. The deadlock is seen on Windows only. On Linux, I get sigsegv or, at least, valgrind gives me info about using already freed memory. After the investigation, I found that the problem is using of static variables in getSceneCache() and getSceneCacheMutex() in Scene.cpp. The destructors of these static variables are registered by the compiler (gcc) using atexit() approach. (I could not believed it and made additional tests, but all the same.) As a result, the mentioned variables are destructed too early and before all global variables, resulting sigsegv and deadlocks... I moved the static variables to global scope and the problem disappeared. Is it the correct fix of the problem? Should I submit a patch? Comments? Ideas? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Methods to improve large scene shadows with ViewDependentShadowMap
Hi Wang Rui, I'm also working on very large urban areas with osgShadow::ViewDependentShadowMap. I encounter the same problems. I also had to use some kind of PCF to reduce some inacceptable noise (huge 'Moiré' effects). I tried to use PSSM recently introduced in ViewDependentShadowMap to cope with aliasing effects with no success : - PSSM procuce some strange artifacts on half of the view when mixing the two shadow textures (each half shadow is ok) - the separation line is not adapted to a 'human walking' point of view (too far in the scene) I doubt that changing the depth of the shadow map will produce noticable effects : numerical instabilities will exist, whatever the depth. At what angles did you encounter innacceptable alisasing issues ? For views that are not near tangent to the ground plane, the results I got seems ok. Is your problem global or limited to certain points of view ? Is your target resolution way beyond the resolution of the shadow map (1*1) per ex ? Luc De : Wang Rui wangra...@gmail.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 12/03/2012 10:39 Objet : [osg-users] Methods to improve large scene shadows with ViewDependentShadowMap Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi all, I'm currently working on an example that uses osgShadow::ViewDependentShadowMap for generating dynamic shadows on a large area of buildings. It can work correctly on a huge city which is created by CityEngine and then converted to OSG styled scene graph. It also generates aliasing issues as expected, but I'm still looking for some good solutions to reduce such problem and want to discuss them in this thread if possible. My test program and a simple shader file can be found in attachement. I've already read a similar topic at: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2011-August/053731.html And I believe it is necessary to apply some filters on the shadow map (the test shader file simply uses PCF here) and increase the texture resolution as well. But for huge scene, a 4096-sized RTT texture will be a heavy burden. So I wonder if there are some more methods to choose, for example, is it possible to change the internal format of the texture to GL_DEPTH_COMPONENT32 to improve the shadow comparision process? Meanwhile, is it necessary to perform a screen space blurring to reduce the aliasing effect? It is a serious problem for my scene now as I can't use a very high resolution. Could anyone suggest some other possible methods on the post-processing level? To be honest, the ViewDependentShadowMap is the best shadow solution for me at present as it is easy to be integrated with custom shaders and embedded into a deferred shading framework. The test city models are about 180MB. If any of you think it important for digging into the problem. I'd like to share them freely, too, as I believe these automatically generated models should not have any copyrights with them. :-) Cheers, Wang Rui [pièce jointe screen_space_shadow.cpp supprimée par Luc Frauciel/STAR-APIC] [pièce jointe shadowRenderer.frag supprimée par Luc Frauciel/STAR-APIC] ___ 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] OpenSceneGraph performance drop between Qt 4.7 and 4.8
I've even disabled the vsync but it does not improve the frame rate. You can verify this just by running osgViewerQt right away. Marco ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scene.cpp deadlock
Hi John, I suspect this issue is down to the Scene object being destructed after the sceneCacheMutex and s_sceneCache are destructed as both of these are constructed till after the first Scene object is constructed. To force these objects to be constructed first I think it is probably best to move the static s_sceneCacheMutex and s_sceneCache into the global scope to ensure they get created before the first Scene object ever gets created. Robert. On 12 March 2012 10:03, PC John pec...@fit.vutbr.cz wrote: Hi, I found a deadlock in Scene.cpp. The problem exhibits itself when calling std::exit() instead of standard way of terminating of the application. The deadlock is seen on Windows only. On Linux, I get sigsegv or, at least, valgrind gives me info about using already freed memory. After the investigation, I found that the problem is using of static variables in getSceneCache() and getSceneCacheMutex() in Scene.cpp. The destructors of these static variables are registered by the compiler (gcc) using atexit() approach. (I could not believed it and made additional tests, but all the same.) As a result, the mentioned variables are destructed too early and before all global variables, resulting sigsegv and deadlocks... I moved the static variables to global scope and the problem disappeared. Is it the correct fix of the problem? Should I submit a patch? Comments? Ideas? 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] Methods to improve large scene shadows with ViewDependentShadowMap
Hi Rui, Artifacts can be caused by a number of different reasons, as I have seen the models, screenshots of the artefacts I don't feel comfortable pointing at any particular cause or solution. Having a public model we can test against would be very useful. Also modifying the osgshadow example to have a unit test for these case would also be useful. Given a unit test we as group can start refining things for the problem cases. As a more general note ViewDependentShadowMap doesn't yet provide shaders that resolve the issue correct lighting of shadows, the thread you link to discusses this topic. Introducing the required shaders as an option into ViewDependentShadowMap would address one of the areas that artefacts can be seen when users don't provide their own shaders that do the lighting correctly. This won't solve all the potential artefacts that we see when doing shadow mapping but it would at least discount one possible set of problems. Robert. On 12 March 2012 09:38, Wang Rui wangra...@gmail.com wrote: Hi all, I'm currently working on an example that uses osgShadow::ViewDependentShadowMap for generating dynamic shadows on a large area of buildings. It can work correctly on a huge city which is created by CityEngine and then converted to OSG styled scene graph. It also generates aliasing issues as expected, but I'm still looking for some good solutions to reduce such problem and want to discuss them in this thread if possible. My test program and a simple shader file can be found in attachement. I've already read a similar topic at: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2011-August/053731.html And I believe it is necessary to apply some filters on the shadow map (the test shader file simply uses PCF here) and increase the texture resolution as well. But for huge scene, a 4096-sized RTT texture will be a heavy burden. So I wonder if there are some more methods to choose, for example, is it possible to change the internal format of the texture to GL_DEPTH_COMPONENT32 to improve the shadow comparision process? Meanwhile, is it necessary to perform a screen space blurring to reduce the aliasing effect? It is a serious problem for my scene now as I can't use a very high resolution. Could anyone suggest some other possible methods on the post-processing level? To be honest, the ViewDependentShadowMap is the best shadow solution for me at present as it is easy to be integrated with custom shaders and embedded into a deferred shading framework. The test city models are about 180MB. If any of you think it important for digging into the problem. I'd like to share them freely, too, as I believe these automatically generated models should not have any copyrights with them. :-) Cheers, Wang Rui ___ 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] Scene.cpp deadlock
Hi Robert, I suspect this issue is down to the Scene object being destructed after the sceneCacheMutex and s_sceneCache are destructed Exactly. I managed to modify osgviewer app to exhibit this problem. I just moved viewer object from local scope to global and added std::exit(0); after viewer's construction. Valgrind reports following: ==15282== Invalid read of size 4 ==15282==at 0x5A99004: pthread_mutex_lock (pthread_mutex_lock.c:50) ==15282==by 0x656E199: OpenThreads::Mutex::lock() (PThreadMutex.cpp:130) ==15282==by 0x519CECF: OpenThreads::ScopedLockOpenThreads::Mutex::ScopedLock(OpenThreads::Mutex) (ScopedLock:31) ==15282==by 0x57DB40F: osgViewer::Scene::~Scene() (Scene.cpp:45) ==15282==by 0x57DB579: osgViewer::Scene::~Scene() (Scene.cpp:57) ==15282==by 0x52F486B: osg::Referenced::signalObserversAndDelete(bool, bool) const (Referenced.cpp:323) ==15282==by 0x403018: osg::Referenced::unref() const (Referenced:198) ==15282==by 0x580F250: osg::ref_ptrosgViewer::Scene::~ref_ptr() (in /usr/local/lib64/libosgViewerd.so.3.1.0) ==15282==by 0x57FEF7C: osgViewer::View::~View() (View.cpp:177) ==15282==by 0x581AEA8: osgViewer::Viewer::~Viewer() (Viewer.cpp:216) ==15282==by 0x581AFDF: osgViewer::Viewer::~Viewer() (Viewer.cpp:249) ==15282==by 0x52F486B: osg::Referenced::signalObserversAndDelete(bool, bool) const (Referenced.cpp:323) ==15282==by 0x403018: osg::Referenced::unref() const (Referenced:198) ==15282==by 0x4036F2: osg::ref_ptrosgViewer::Viewer::~ref_ptr() (in /usr/local/bin/osgviewerd) ==15282==by 0x6204820: __run_exit_handlers (exit.c:78) ==15282==by 0x62048A4: exit (exit.c:100) ==15282==by 0x402C62: main (osgviewer.cpp:48) ==15282== Address 0x92dc618 is 24 bytes inside a block of size 48 free'd ==15282==at 0x4C27FF2: operator delete(void*) (vg_replace_malloc.c:387) ==15282==by 0x656E267: OpenThreads::PThreadMutexPrivateData::~PThreadMutexPrivateData() (PThreadMutexPrivateData.h:38) ==15282==by 0x656E131: OpenThreads::Mutex::~Mutex() (PThreadMutex.cpp:115) ==15282==by 0x6204820: __run_exit_handlers (exit.c:78) ==15282==by 0x62048A4: exit (exit.c:100) ==15282==by 0x402C62: main (osgviewer.cpp:48) So, the mutex is already destructed when Scene is about to be destroyed. I guess the user should have the right to place osg::ref_ptr osgViewer::Viewer viewer; to the global scope, so the issue needs to be fixed. Ideas? Do you think moving static s_sceneCacheMutex and s_sceneCache of Scene.cpp into the global scope would be the proper fix? John On Monday 12 of March 2012 10:25:07 Robert Osfield wrote: Hi John, I suspect this issue is down to the Scene object being destructed after the sceneCacheMutex and s_sceneCache are destructed as both of these are constructed till after the first Scene object is constructed. To force these objects to be constructed first I think it is probably best to move the static s_sceneCacheMutex and s_sceneCache into the global scope to ensure they get created before the first Scene object ever gets created. Robert. On 12 March 2012 10:03, PC John pec...@fit.vutbr.cz wrote: Hi, I found a deadlock in Scene.cpp. The problem exhibits itself when calling std::exit() instead of standard way of terminating of the application. The deadlock is seen on Windows only. On Linux, I get sigsegv or, at least, valgrind gives me info about using already freed memory. After the investigation, I found that the problem is using of static variables in getSceneCache() and getSceneCacheMutex() in Scene.cpp. The destructors of these static variables are registered by the compiler (gcc) using atexit() approach. (I could not believed it and made additional tests, but all the same.) As a result, the mentioned variables are destructed too early and before all global variables, resulting sigsegv and deadlocks... I moved the static variables to global scope and the problem disappeared. Is it the correct fix of the problem? Should I submit a patch? Comments? Ideas? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Simuating realistic large crowds with RVO2 C++ library
Videos looks great. I wonder if this can be adapted to simulate fluid flow :D 09.03.2012, 22:40, Christian Buchner christian.buch...@gmail.com: Hello, I am currently working on a demo that shows the use of the RVO2 C++ library with OpenSceneGraph. Check out these videos to get an idea of what RVO2 is capable of: http://www.youtube.com/playlist?list=PLD56A0C7765234DCDfeature=plcp This amazing library can be used for simulating large crowd of agents. It implements an algorithm called optimal reciprocal collision avoidance. My demo will be using an efficient billboarded renderer for animated persons with approximation of camera perspective (this can display thousands of people and is loosely based on the billboard shaders found in the osgforest sample). When done, I will be submitting the demo to osg-submissions. However the textures required for the animated walking persons would be a few hundred kilobytes in size. Unfortunately there are dependencies on OpenMP (for which a CMake Module exists) and on the RVO2 library however (for which I crafted my own CMake module that hasn't been tested much so far). Christian ___ 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] Simuating realistic large crowds with RVO2 C++ library
The algorithm in RVO2 switches to some kind of fluid model for very dense clusters of agents. They have papers about it on their web site if you are interested. I have my demo running now. Some 1200 people trying to walk across an intersection, like in Japan ;) Now I need to make sure the required artwork stays within reasonable size limitations before I submit this. And maybe some code cleanup. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph performance drop between Qt 4.7 and 4.8
Hi Marco, I can not test it right now, but when Qt 4.8 will be made available with the new Ubuntu release in April, I will probably dig in the problem if I notice it on my application. John On Monday 12 of March 2012 11:10:51 Marco Fiocco wrote: I've even disabled the vsync but it does not improve the frame rate. You can verify this just by running osgViewerQt right away. Marco ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scene.cpp deadlock
On 12 March 2012 11:19, PC John pec...@fit.vutbr.cz wrote: Do you think moving static s_sceneCacheMutex and s_sceneCache of Scene.cpp into the global scope would be the proper fix? Yes I think it'll be the least intrusive way to fix the issue. Could you try it and see if it works fine, if so just post me the changes. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera attached to object
Hi Sergey, why don't you use OSGs standard nodetrackermanipulator? You can track a node and configure which DOF are controllable via the manipulator. Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46175#46175 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph performance drop between Qt 4.7 and 4.8
I forgot to mention that I'm running in Window 7 x64. Marco ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Methods to improve large scene shadows with ViewDependentShadowMap
Hi Luc, I'm glad that someone is working on the same topic and we can share opinions and experience all the time. :-) 2012/3/12 Luc Frauciel luc.frauc...@star-apic.com At what angles did you encounter innacceptable alisasing issues ? A snapshot of the shadowed city I'm working with is attached in my last post, so does the download link of the model files. It shows some distinct jags and streaks on a few building surfaces. For views that are not near tangent to the ground plane, the results I got seems ok. Is your problem global or limited to certain points of view ? I think it may happen in any position. But a view from the high altitude is always better. Is your target resolution way beyond the resolution of the shadow map (1*1) per ex ? The target city's radius is about 2800 and it is formed up by about 1000 mansions. Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Methods to improve large scene shadows with ViewDependentShadowMap
HI Rui, Thanks for the links to the data, I will download and have a experiment later, most likely tomorrow as I have to go out quite soon. The screenshot is suggests to me that the main artefact is simply that the shader used/fixed function pipeline isn't computing the shadowed colour correctly and would disappear if appropriate shaders were used to make sure the back facing triangles are coloured the same as the shadowed region. When using the standard fixed function pipeline you just get black for the shadowed around so the result always has this artefact. Robert. On 12 March 2012 13:20, Wang Rui wangra...@gmail.com wrote: Hi Robert, I'd like to provide a set of city models for shadow tests. It is already constructed with paged LODs so can be viewed smoothly on my Windows 7 and GTX 460. I've uploaded it at box.com, totally two compressed packages: http://www.box.com/s/s1bnf4eqenrc30opxzj4 http://www.box.com/s/ubu4186593fjc8tslntq Of course tarballs are not suitable for public test. It should be comfortable if we could load and render the city from an HTTP address, just like the earth_bayarea example dataset. The snapshot attached shows that most of the shadows are at the right place but some with obvious aliasing issues and streaks (as on the right bottom side). Cheers, Wang Rui 2012/3/12 Robert Osfield robert.osfi...@gmail.com Hi Rui, Artifacts can be caused by a number of different reasons, as I have seen the models, screenshots of the artefacts I don't feel comfortable pointing at any particular cause or solution. Having a public model we can test against would be very useful. Also modifying the osgshadow example to have a unit test for these case would also be useful. Given a unit test we as group can start refining things for the problem cases. As a more general note ViewDependentShadowMap doesn't yet provide shaders that resolve the issue correct lighting of shadows, the thread you link to discusses this topic. Introducing the required shaders as an option into ViewDependentShadowMap would address one of the areas that artefacts can be seen when users don't provide their own shaders that do the lighting correctly. This won't solve all the potential artefacts that we see when doing shadow mapping but it would at least discount one possible set of problems. Robert. On 12 March 2012 09:38, Wang Rui wangra...@gmail.com wrote: Hi all, I'm currently working on an example that uses osgShadow::ViewDependentShadowMap for generating dynamic shadows on a large area of buildings. It can work correctly on a huge city which is created by CityEngine and then converted to OSG styled scene graph. It also generates aliasing issues as expected, but I'm still looking for some good solutions to reduce such problem and want to discuss them in this thread if possible. My test program and a simple shader file can be found in attachement. I've already read a similar topic at: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2011-August/053731.html And I believe it is necessary to apply some filters on the shadow map (the test shader file simply uses PCF here) and increase the texture resolution as well. But for huge scene, a 4096-sized RTT texture will be a heavy burden. So I wonder if there are some more methods to choose, for example, is it possible to change the internal format of the texture to GL_DEPTH_COMPONENT32 to improve the shadow comparision process? Meanwhile, is it necessary to perform a screen space blurring to reduce the aliasing effect? It is a serious problem for my scene now as I can't use a very high resolution. Could anyone suggest some other possible methods on the post-processing level? To be honest, the ViewDependentShadowMap is the best shadow solution for me at present as it is easy to be integrated with custom shaders and embedded into a deferred shading framework. The test city models are about 180MB. If any of you think it important for digging into the problem. I'd like to share them freely, too, as I believe these automatically generated models should not have any copyrights with them. :-) Cheers, Wang Rui ___ 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
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
Thanks Jason,
I understand about the interpolation. I have been operating under the
assumption that if I use a node visitor to loop over each primitive in my
object, create a floatArray of index numbers of size=size(primitive array), and
then bind_per_primitive, then I shouldn't have to worry about interpolation of
those index numbers within the shader. Is that correct?
I noticed that in Christian's code snippet that the osg::Program that he
created was not attached to the geometry's stateset. Without attaching it, you
will still have a floatArray stored in the 6 position, but it will not have a
name and therefore I don't think you can access it from the shader.
In either case, when i try to add my floatArray to the 6th vertex attribute, my
shaders stop working. I don't get any glsl errors printed to screen, but even
if I try to do something simple like assign all color values to black, the
shader just spits out the underlying object colors and ignores my shader
commands. If I don't attach the osg::Program to my object's stateset, the
shader commands do work again but I can't access my 6th vertex attribute
because it wasn't named.
Here is the stateset that was added to my object.obj's geometry:
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Program {
name targetIndices
GeometryVerticesOut 1
GeometryInputType TRIANGLES
GeometryOutputType TRIANGLE_STRIP
AttribBindingLocation indices 6
num_shaders 0
}
}
I'm assuming most of these things are default values since I never specified
GeometryVerticesOut, GeometryInputType, GeometryOutputType, or num_shaders when
I created my osg::Program. Are these defaults the cause of my problems?
I know that this post is a bit scatter-brained but I tried my best to represent
my problem.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46183#46183
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] Cloud node kit
Yes, we use GLSL for computing. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46153#46153 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How do I tell osg the name of my modelview uniform
I'm using useModelViewAndProjectionUniforms but I would like to be able to use my own variable names. In a related problem: I'm using #version 400 in my shaders, and I think that's breaking useVertexAtrtibuteAliasing code in osg::State. I get the compiler error message declaration of osg_Vertex conflicts with previous declaration. Is there any way to tell osg what the name of my vertex variable is? It looks like I should be using State::setUpVertexAttribAlias() but it's protected. I worked around this by binding my vertex data to position 0, and not calling Geometry::SetVertexArray() If someone could point me to a correct example of using tessellation shaders in osg I may be able to figure this out myself. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46117#46117 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] display problem with transparency
Hi, i have 2 transparents spheres, one inside another. The smallest one (inside) has a texture. My pb is: when moving camera, the smallest sphere disappear. (Spheres et lights have always the same position) Is there some constraint in osg with transparency? ( maximum number of transparent object in graph? maximum number of embedded transparent object ? Thank you for your help ! Cheers, vincent -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46159#46159 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Point attribute affecting display of triangle on OS X
Thanks, Ulrich. Sorry, I missed your reply before. Yes, your results do sound different. I'd expect no argument to have green dots instead of green discs, because the point size won't be set. They're small and right on the edge of the triangle. And in our case, the red triangle and the line aren't visible when the point attribute is set, so when the PointAttribute is set. My co-worker is trying to get a straight OpenGL program to show this problem. If we can get it to happen, we'll see about talking to Apple. thanks, andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46063#46063 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [3rdparty] getshape() on geometry return Null pointer ?
Hi, i construct some geometry (with setVertexArray, addPrimitiveSet, ...) when i call getshape() from this geometry, it return me null pointer ? could anyone tell me why ? Thank you! Cheers, vincent -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46046#46046 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Transforming the hierarchy created by BVH plugin
Hi, I am reading a BVH file using the BVH plugin of OSG. Then, I want to translate the entire hierarchy of the character to some other position and also rotate it. I tried to insert a PositionAttitudeTransform node in the hierarchy above the Geode node, but I am not allowed to remove the previous parent of Geode. Is there any other way to transform the character to another position? Thank you! Cheers, Utkarsh -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46030#46030 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I tell osg the name of my modelview uniform
So I've converted Philip Rideout's tesselation demo to OpenScenegraph. But I'm still using the osg_Vertex, osg_ModelViewMatirx, etc. variables. I'm still looking for a way to use my own variable names. Is this even possible? Do I need to use a node visitor and set the Uniforms manually? Thanks, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46185#46185 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I tell osg the name of my modelview uniform
Here's the link to the demo in case you're interested: http://prideout.net/blog/?p=48 -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46186#46186 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] getshape() on geometry return Null pointer ?
vincent Sauvage writes: Hi, i construct some geometry (with setVertexArray, addPrimitiveSet, ...) when i call getshape() from this geometry, it return me null pointer ? could anyone tell me why ? Because what you create with setVertexArray, addPrimitiveSet... is a osg::Geometry, not a osg::ShapeDrawable. They are different objects inheriting from osg::Drawable. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I tell osg the name of my modelview uniform
Would a #define in the shader source be a solution for you? -Paul On 3/12/2012 9:06 AM, John Kaniarz wrote: So I've converted Philip Rideout's tesselation demo to OpenScenegraph. But I'm still using the osg_Vertex, osg_ModelViewMatirx, etc. variables. I'm still looking for a way to use my own variable names. Is this even possible? Do I need to use a node visitor and set the Uniforms manually? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
So I tried writing my osg Node object to an osg file at various points during my code to compare the differences. What I noticed was that if I attach the program to the geometry stateset while in my nodevisitor, that the properties of the geometry stateset will replace those of the geode stateset. I was putting all of my shader program stuff in the geode stateset. Since my geometry stateset where I attached my program had a default num_shader of 0, I think the shaders were being ignored even though they were in the geode's stateset. So, I tried attaching the program from my nodevisitor to the geode instead of the geometry, but then when i go to add my shader program to the geode stateset, the nodevisitor program and stateset get overwritten. I need to somehow make sure that my generic vertex attribute program does not get overwritten when I attach my shader program. I think it's probably time for me to revisit some osg documentation at this point... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46190#46190 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] display problem with transparency
Hi Vincent, What you are hitting as an transparent ordering issue that is common issue when trying to rendering transparent objects that overlap in depth. This isn't specially an OSG issue, rather it's basic limit of way that the depth and colour buffers work and the standard technique for rendering transparent objects by drawing opaque objects first, then rendering transparent objects from furthers from the eye to nearest to the eye. This technique only works perfectly when objects don't overlap in screen space and depth at the same time, when they overlap there are potential ordering issues where triangles from one object can be drawn prior to triangles that are infact nearer. One can potentially sort by triangles but this is typically too expensive. Breaking objects up into small parts is often sufficient. As this is a standard graphics issue it's been discussed many times on the list over the years so I'd recommend reading through the archives to familiarise yourself with the general topic and the types of solutions that you can use. Robert. On 12 March 2012 08:28, vincent Sauvage vinc...@lessauvage.fr wrote: Hi, i have 2 transparents spheres, one inside another. The smallest one (inside) has a texture. My pb is: when moving camera, the smallest sphere disappear. (Spheres et lights have always the same position) Is there some constraint in osg with transparency? ( maximum number of transparent object in graph? maximum number of embedded transparent object ? Thank you for your help ! Cheers, vincent -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46159#46159 ___ 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 animations initial frame bones matrix
Another way to do this could be using the bones initial matrix.
The method that I use to charge different animations to the same model is;
first read a model fbx (with the model and skeleton) and then for each
animation read their fbx (with the animated skeleton, without model). So we
will have different fbx for the same animated model: model.fbx, modelAnim1.fbx,
modelAnim2.fbx
We can take the bone matrix as follows:
Code:
struct OSGBoneFinder : public osg::NodeVisitor
{
std::vectorosg::ref_ptrosgAnimation::Bone _bones;
OSGBoneFinder() :
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN) {}
void apply(osg::Transform node) {
osg::ref_ptrosgAnimation::Bone bone =
dynamic_castosgAnimation::Bone*(node);
if (bone.valid()){
_bones.push_back(bone);
}
traverse(node);
}
};
...
std::vectorosg::ref_ptrosgAnimation::Bone bones;
OSGBoneFinder boneFinder;
modelAnimation-accept(boneFinder);
if (boneFinder._bones.size()0) {
bones.swap(boneFinder._bones);
bones[0]-getMatrixInSkeletonSpace();
}
The problem here is that if I read a fbx file that it has only skeleton
information with the animation them the matrix obteined will always 0. This is
not occur if we read a fbx with skeleton binded model. I do not know if I
explained well... Why is this so?
Thank you!
Cheers,
Aitor
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=46193#46193
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph performance drop between Qt 4.7 and 4.8
Hi osg-users, I noticed a related problem when moving from Qt 4.7.1 to 4.8.0, the time spent in event is continuously growing when moving my camera with my manipulator... It wasn't the case with Qt 4.7.1. I'm running on Window 7 x64 too using OSG 3.0.1 Le 12 mars 2012 14:08, Marco Fiocco marco.fio...@gmail.com a écrit : I forgot to mention that I'm running in Window 7 x64. Marco ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/12/2012 10:04 AM, Ethan Fahy wrote:
Thanks Jason,
I understand about the interpolation. I have been operating under the
assumption that if I use a node visitor to loop over each primitive in my
object, create a floatArray of index numbers of size=size(primitive array), and
then bind_per_primitive, then I shouldn't have to worry about interpolation of
those index numbers within the shader. Is that correct?
If you're trying to get the same value for all fragments on a primitive,
then yes, this will work. Be aware, though, that rendering geometry
with per-primitive binding is going to be quite slow compared to overall
or per-vertex binding.
As an alternative, you could specify your floatArray at
size=size(primitive array) * 3 (assuming you're rendering triangles) and
just specify the same index for all three vertices of each triangle.
Then, you could use per-vertex binding and not fall off the fast path.
I noticed that in Christian's code snippet that the osg::Program that he
created was not attached to the geometry's stateset. Without attaching it, you
will still have a floatArray stored in the 6 position, but it will not have a
name and therefore I don't think you can access it from the shader.
In either case, when i try to add my floatArray to the 6th vertex attribute, my
shaders stop working. I don't get any glsl errors printed to screen, but even
if I try to do something simple like assign all color values to black, the
shader just spits out the underlying object colors and ignores my shader
commands. If I don't attach the osg::Program to my object's stateset, the
shader commands do work again but I can't access my 6th vertex attribute
because it wasn't named.
Here is the stateset that was added to my object.obj's geometry:
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Program {
name targetIndices
GeometryVerticesOut 1
GeometryInputType TRIANGLES
GeometryOutputType TRIANGLE_STRIP
AttribBindingLocation indices 6
num_shaders 0
}
}
I'm assuming most of these things are default values since I never specified
GeometryVerticesOut, GeometryInputType, GeometryOutputType, or num_shaders when
I created my osg::Program. Are these defaults the cause of my problems?
The defaults are probably fine (they apply to geometry shaders, which I
don't think you're using). The attribute binding for indices at
attribute 6 looks good as well. However, it looks as if there are not
any shaders attached to your Program (num_shaders 0), which isn't
going to work at all. You need to create an osg::Shader (specifying the
type of shader, vertex, geometry, or fragment), add the shader's source
to it, and then add the shader to the Program. Then, you can attach the
program to the StateSet and everything should work:
shader = new osg::Shader(osg::Shader::FRAGMENT);
shader-setShaderSource(source);
program-addShader(shader);
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
Does that mean that an osg::StateSet can only have one osg::Program? I have one application that uses a nodeVisitor to assign my generic vertex attribute and sets a program with the generic vertex names. After saving the result as an ive file I have another application that reads in that ive file and attaches a shader program and renders the node. Is it possible to either have multiple osg::Programs per stateset or to combine osg::Programs? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46197#46197 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenThreads/Atomic currently broken with Xcode 4.3.1 and IOS
Hi, it seems that compiling osg and specifically OpenThreads is currently broken for IOS when using xcode 4.3.1. The compilation fails at OpenThreads/Atomic with Users/stephan/Documents/Projekte/cefix/cefix/ios/../../libs/ios/include/OpenThreads/Atomic:244:48: error: cannot initialize a parameter of type 'void *' with an lvalue of type 'const void *const' return __sync_bool_compare_and_swap(_ptr, ptrOld, ptrNew); Googling around it seems, that this is because of a bug in the clang-compiler: http://llvm.org/bugs/show_bug.cgi?id=11280 Has anybody an idea how to fix the issue? In the meantime i'll switch to _OPENTHREADS_ATOMIC_USE_MUTEX cheers, stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/12/2012 01:15 PM, Ethan Fahy wrote: Does that mean that an osg::StateSet can only have one osg::Program? I have one application that uses a nodeVisitor to assign my generic vertex attribute and sets a program with the generic vertex names. After saving the result as an ive file I have another application that reads in that ive file and attaches a shader program and renders the node. Is it possible to either have multiple osg::Programs per stateset or to combine osg::Programs? Yes, there can be only one GLSL program active at any time (this is an OpenGL rule), hence there is only one osg::Program allowed per StateSet. Currently, there is no provision in OSG for combining Shaders or Programs (though I believe this is on the to-do list). For now, though, you'll have to do the combining yourself. There are several tricks you can use to get different code to execute from the same shader. One simple method is to define an if/else block and switch code paths based on the value of a Uniform. You can also define a function in one shader, and have it called from another shader. This way, you can switch behavior by using different implementations of the same function. Shader A implements the shader's main() function and defines the prototype for function foo(), which is called in main(). Function foo() is implemented in both shader A and shader B, using the prototype defined in shader A, but each having different code. In one case, you attach shaders A and C to the program, and in the other case, you attach shaders B and C. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
Thanks Jason, So, since I can't combine programs (I didn't necessarily mean multiple shaders, I just meant multiple programs), I decided to take this line of code: program-addBindAttribLocation(indices, 6); and move it to where I assemble my shader program and attach it to the node's stateset. This way my nodeVisitor can still set my generic vertex array in position 6 and my osg::Program's shader can access those index values by including the following line in the frag shader: in float indices; I looked at the osg file that I wrote to disk and verified that my stateset's program contained this line: AttribBindingLocation indices 6 However, when I use indices in my shader, the resulting value is always equal to 0.0, even though my VertexAttributeArray values range from 0.0 to 124.0. I don't want to impose on you too much since you've already helped me out a great deal, but I'm going to go ahead and attach an osg file that demonstrates this behavior. The file is a simple human shape with 125 primitives. I created a generic vertex array with index values sequential from 0-124. I also attached a simple shader that paints everything green if the indices = 0 and red otherwise. As you can see by opening this file in osgviewer, all values are green. If you have time to look at it that would be fantastic but I completely understand if you don't. Thanks again, -Ethan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46200#46200 human.osg Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access thevertex color in a shader, is there a loss of precision?
On 03/12/2012 02:02 PM, Jason Daly wrote: You can also define a function in one shader, and have it called from another shader. This way, you can switch behavior by using different implementations of the same function. Shader A implements the shader's main() function and defines the prototype for function foo(), which is called in main(). Function foo() is implemented in both shader A and shader B, using the prototype defined in shader A, but each having different code. In one case, you attach shaders A and C to the program, and in the other case, you attach shaders B and C. Hang on, I messed that up :-) I meant shader A defines main() and the prototype for foo(). Shaders B and C each define an implementation of foo(), with different sets of code. In one case, you attach shaders A and B to the program, and in the other, you attach shaders A and C. This allows foo() to behave differently, depending on which shader (e.g.: which implementation of foo() ) is attached to the program. Sorry for the confusion :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
On 03/12/2012 02:21 PM, Ethan Fahy wrote:
Thanks Jason,
So, since I can't combine programs (I didn't necessarily mean multiple shaders,
I just meant multiple programs), I decided to take this line of code:
program-addBindAttribLocation(indices, 6);
and move it to where I assemble my shader program and attach it to the node's
stateset. This way my nodeVisitor can still set my generic vertex array in
position 6 and my osg::Program's shader can access those index values by
including the following line in the frag shader:
in float indices;
I looked at the osg file that I wrote to disk and verified that my stateset's
program contained this line:
AttribBindingLocation indices 6
However, when I use indices in my shader, the resulting value is always equal
to 0.0, even though my VertexAttributeArray values range from 0.0 to 124.0. I
don't want to impose on you too much since you've already helped me out a great
deal, but I'm going to go ahead and attach an osg file that demonstrates this
behavior. The file is a simple human shape with 125 primitives. I created a
generic vertex array with index values sequential from 0-124. I also attached
a simple shader that paints everything green if the indices = 0 and red
otherwise. As you can see by opening this file in osgviewer, all values are
green. If you have time to look at it that would be fantastic but I completely
understand if you don't. Thanks again,
Yeah, it's green for me, too.
One problem appears to be that while your VertexAttribArray on attribute
6 looks fine, you have a vertex shader defined that isn't passing the
value down to the fragment shader. The fragment shader will never
receive your attribute data this way.
I did a quick try to get the vertex shader to pass the data down, but I
couldn't get it working in the five minutes I spent. I attached my
attempt to hopefully inspire you to get to the real solution :-)
Note that I went back to the GLSL 1.2-style of attribute and varying
instead of the in and out qualifiers that were introduced in OpenGL 3.
If I get some time, I'll try to play with it some more.
--J
Geode {
nodeMask 0x
cullingActive TRUE
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode USE
binNumber 6
binName RenderBin
GL_LIGHTING OFF
Program {
name Environment
GeometryVerticesOut 1
GeometryInputType TRIANGLES
GeometryOutputType TRIANGLE_STRIP
AttribBindingLocation indices 6
num_shaders 2
Shader {
type FRAGMENT
code {
varying float fIndices;
void main(void)
{
vec4 color = gl_Color;
if( fIndices == 0.0 ){
color.r = 0.0;
color.g = 1.0;
color.b = 0.0;
}else{
color.r = 1.0;
color.g = 0.0;
color.b = 0.0;
}
gl_FragColor = color;
}
}
}
Shader {
type VERTEX
code {
attribute float indices;
varying float fIndices;
void main(void)
{
gl_FrontColor = gl_Color;
gl_Position = ftransform();
fIndices = indices;
}
}
}
}
textureUnit 0 {
}
textureUnit 1 {
GL_TEXTURE_2D ON
Texture2D {
UniqueID Texture2D_0
wrap_s CLAMP_TO_EDGE
wrap_t CLAMP_TO_EDGE
wrap_r CLAMP_TO_EDGE
min_filter NEAREST
mag_filter NEAREST
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply FALSE
internalFormatMode USE_IMAGE_DATA_FORMAT
resizeNonPowerOfTwo FALSE
shadowComparison FALSE
shadowCompareFunc GL_LEQUAL
shadowTextureMode GL_LUMINANCE
}
}
}
num_drawables 1
Geometry {
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 125
{
DrawElementsUInt QUADS 4
{
0 1 2 3
}
DrawElementsUInt QUADS 4
{
3 4 5 0
}
DrawElementsUInt QUADS 4
{
1 6 7 2
}
DrawElementsUInt QUADS 4
{
5 4 7 6
}
DrawElementsUInt QUADS 4
{
8 9 10 11
}
DrawElementsUInt QUADS 4
{
9 12 13 10
}
DrawElementsUInt QUADS 4
{
10 16 17 11
}
DrawElementsUInt QUADS 4
{
10 13 18 16
}
DrawElementsUInt QUADS 4
{
13 14 19 18
}
DrawElementsUInt QUADS 4
{
17 20 22 11
}
DrawElementsUInt QUADS 4
{
22 20 21 23
}
DrawElementsUInt QUADS 4
{
23 21 19 14
}
DrawElementsUInt
Re: [osg-users] If I set a vertex color using floats and access thevertex color in a shader, is there a loss of precision?
On 03/12/2012 03:40 PM, Jason Daly wrote:
On 03/12/2012 02:21 PM, Ethan Fahy wrote:
Thanks Jason,
So, since I can't combine programs (I didn't necessarily mean multiple shaders,
I just meant multiple programs), I decided to take this line of code:
program-addBindAttribLocation(indices, 6);
and move it to where I assemble my shader program and attach it to the node's
stateset. This way my nodeVisitor can still set my generic vertex array in
position 6 and my osg::Program's shader can access those index values by
including the following line in the frag shader:
in float indices;
I looked at the osg file that I wrote to disk and verified that my stateset's
program contained this line:
AttribBindingLocation indices 6
However, when I use indices in my shader, the resulting value is always equal
to 0.0, even though my VertexAttributeArray values range from 0.0 to 124.0. I
don't want to impose on you too much since you've already helped me out a great
deal, but I'm going to go ahead and attach an osg file that demonstrates this
behavior. The file is a simple human shape with 125 primitives. I created a
generic vertex array with index values sequential from 0-124. I also attached
a simple shader that paints everything green if the indices = 0 and red
otherwise. As you can see by opening this file in osgviewer, all values are
green. If you have time to look at it that would be fantastic but I completely
understand if you don't. Thanks again,
It seems that generic vertex attributes don't work in PER_PRIMITIVE mode
(at least not with shaders). Changing the binding to PER_VERTEX (and
adding enough values to cover all the vertices) makes it work. Have a look:
--J
Geode {
nodeMask 0x
cullingActive TRUE
StateSet {
rendering_hint DEFAULT_BIN
renderBinMode USE
binNumber 6
binName RenderBin
GL_LIGHTING OFF
Program {
name Environment
GeometryVerticesOut 1
GeometryInputType TRIANGLES
GeometryOutputType TRIANGLE_STRIP
AttribBindingLocation indices 6
num_shaders 2
Shader {
type FRAGMENT
code {
varying float fIndices;
void main(void)
{
vec4 color = gl_Color;
if( fIndices == 0.0 ){
color.r = 0.0;
color.g = 1.0;
color.b = 0.0;
}else{
color.r = 1.0;
color.g = 0.0;
color.b = 0.0;
}
gl_FragColor = color;
}
}
}
Shader {
type VERTEX
code {
attribute float indices;
varying float fIndices;
void main(void)
{
gl_FrontColor = gl_Color;
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
fIndices = indices;
}
}
}
}
textureUnit 0 {
}
textureUnit 1 {
GL_TEXTURE_2D ON
Texture2D {
UniqueID Texture2D_0
wrap_s CLAMP_TO_EDGE
wrap_t CLAMP_TO_EDGE
wrap_r CLAMP_TO_EDGE
min_filter NEAREST
mag_filter NEAREST
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply FALSE
internalFormatMode USE_IMAGE_DATA_FORMAT
resizeNonPowerOfTwo FALSE
shadowComparison FALSE
shadowCompareFunc GL_LEQUAL
shadowTextureMode GL_LUMINANCE
}
}
}
num_drawables 1
Geometry {
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 125
{
DrawElementsUInt QUADS 4
{
0 1 2 3
}
DrawElementsUInt QUADS 4
{
3 4 5 0
}
DrawElementsUInt QUADS 4
{
1 6 7 2
}
DrawElementsUInt QUADS 4
{
5 4 7 6
}
DrawElementsUInt QUADS 4
{
8 9 10 11
}
DrawElementsUInt QUADS 4
{
9 12 13 10
}
DrawElementsUInt QUADS 4
{
10 16 17 11
}
DrawElementsUInt QUADS 4
{
10 13 18 16
}
DrawElementsUInt QUADS 4
{
13 14 19 18
}
DrawElementsUInt QUADS 4
{
17 20 22 11
}
DrawElementsUInt QUADS 4
{
22 20 21 23
}
DrawElementsUInt QUADS 4
{
23 21 19 14
}
DrawElementsUInt QUADS 4
{
17 16 24 25
}
DrawElementsUInt QUADS 4
{
16 18 26 24
}
DrawElementsUInt QUADS 4
{
18 19 27 26
}
DrawElementsUInt QUADS 4
{
25 28 20 17
}
DrawElementsUInt QUADS 4
{
20 28 29 21
}
DrawElementsUInt QUADS 4
{
29 27 19 21
}
Re: [osg-users] If I set a vertex color using floats and access the vertex color in a shader, is there a loss of precision?
Thanks Jason, I didn't even realize that in and out were OpenGL 3 things. My GPU does have OpenGL 3 capability. Thanks for looking at that code but I don't think it attached to the site properly? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46204#46204 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Loading an archived reference from archive root instead of specified directory
Hi Robert, I'm making a separate thread out of this and putting it into osg-users, because it's not a submission and really is a different issue than what I was working on in my virtual file system thread. The specific problem I'm talking about here is easy to test: Make an archive archive.zip Make it contain model.osg and texture.png osgviewer archive.zip/model.osg If model.osg references texture.png, the texture will be loaded. If model.osg references some/crazy/path/to/texture.png, the texture will not be loaded. I think it should be loaded in both cases so that the full full directory structure is not required inside the archive. Do you agree? - Terry Hi Terry, On 11 March 2012 01:58, Terry Welsh mogu...@gmail.com wrote: I think your osgDB::Options idea is mostly working for finding references in the same archive as the parent. ?I find that this works when the reference is just a filename, but it fails if the filename comes with a path, such as the absolute path that an exporter might give you. ?This should probably be fixed regardless of whatever else we do on this subject. This could probably be made to work if a call to getSimpleFileName() was inserted somewhere along the way, but I don't see a good place to put it yet. ?Somewhere in Registry::read()? ?Or in the archive plugin? ?Any suggestions on this one? I've been working on various other topics over the last month so will need to spend some time getting back familiar with it again. I think the best thing to do would be to create a series of test models and usages that flesh out what we want to achieve. The osgarchive example could possibly be extended to have a unit test section, and we could add some simple archive models to OpenSceneGraph-Data. Could you make some suggestions about some simple example data and usages that we can put together to test the specific issues you are seeing. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [forum] using a TV remote control
Hi Helen, On 9/03/12 3:10 , Helen Diez wrote: I'm trying to implement an OSG application using a TV remote control. At the beggining I had my code prepared to detect keyboard events as follows: ... Everything worked fine. The thing is the application's final device will be a TV. So I need to make the application work, not with keyboard events, but with the remote control buttons. I'm using a IR receiver, everything seems to be well configured. When I press red button on my remote, letter a is written, however my app. doesn´t seem to detect it. What platform are you on? One issue I've come across on Unix / X11 with having another application send keystrokes was that the target application might not have focus and the key would instead go to e.g. the terminal. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
