Re: [osg-users] ViewDependentShadowMap
On 11 April 2012 15:35, Daniel Schmid daniel.sch...@swiss-simtec.ch wrote:
Hi all
** **
Somehow I feel pretty alone out here working with VDSM… ** **
I have a huge paged terrain, and shadow looks awesome unless that as soon
as I change my viewpoint (move camera), the shadows start to flicker and
fuzz. I need somehow to limit the shadow distance… similar to
MinimalShadowMap where you can set min max clip plane. I tried to modify
computeShadowCameraSettings method by setting the xyzMinMax values fort he
projectionMatrix to fix values, but this didn’t bring much success.
** **
Does anybody have a modified or advanced version of VDSM with a clipping
limit ?
** **
Regards
Daniel
** **
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Hi Daniel
I replied to you on the forum last week but I see my post never got through.
I have done this, although I don't have a copy against the current VDSM
source. I haven't tested this code, but it was working for me when I used
it, so what you want to do is certainly possible. What I did was to
override the VDSM::cull method and then after the first scenegraph
traversal I had code like this:
// 1. Traverse main scene graph
cv.pushStateSet( _shadowRecievingPlaceholderStateSet.get() );
osg::ref_ptrosgUtil::StateGraph decoratorStateGraph =
cv.getCurrentStateGraph();
cullShadowReceivingScene(cv);
cv.popStateSet();
if (cv.getComputeNearFarMode()!=osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR)
{
OSG_INFOJust done main subgraph traversakstd::endl;
// make sure that the near plane is computed correctly so that any
projection matrix computations are all done correctly.
cv.computeNearPlane();
}
maxZFar=osg::minimum( maxZFar , (double)_maxFarDistance ); // -- The
change
Frustum frustum(cv, minZNear, maxZFar);
Where _maxFarDistance was my cutoff value.
I'm currently playing with Wang Rui's updates which look good - at least
the PSSM implementation works well, but VSM is failing for me atm. We still
have major clipping problems with directional lights so are using
positional instead.
best wishes
Mike
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget examples dataset
Did you ever use png themes? I am trying to use 66x66 pngs for theming with osgWidget::Frame::createSimpleFrameFromTheme(), but the corners/borders of the frame are not displayed correctly. There is a one pixel wide gap at corners of the frame. This also happens with stock theme-2.png that's included in the osg dataset. Does anyone know how this should work? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47072#47072 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] stutter while loading new scenery
Hi, I'm fighting with some stutter issues using Flightgear (2.6 and OSG 3.0.1). In my scenario I can reproduce it and it seems to be related to tile loading. The frame rate is above 50 Hz but in one frame cycle it takes 678 msec. I extended OSG notify with a [usec][thread id] prefix and run it with DEBUG_FP level. Below the long lasting frame cycle. It starts at line 21. Up to line 246 it consumes 139 msec. The Create new ... TextureObjects lines up to 257 consume another 543 msec. Is this log showing something I can improve? Why is the time consuming part on the draw() thread (1818)? I would assume this could be done somehow in the background (I'm using DrawThreadPerContext). Thanks in advance Wolfgang R. 1... 2[1334570577612543][1817] cull() got SceneView 0x12e6f20 3[1334570577612702][1817] end cull() 0x12d9b90 4[1334570577612854][1817] DatabasePager::requestNodeFile(3546378.stg) updating already assigned. 5[1334570577619390][1818] end draw() 0x12d9490 6[1334570577619564][1818] draw() 0x12d9360 7[1334570577619652][1818] draw() got SceneView 0x12df9c0 8[1334570577620805][1818] end draw() 0x12d9360 9[1334570577621001][1818] draw() 0x12d9b90 10[1334570577621117][1818] draw() got SceneView 0x12e6f20 11[1334570577623045][1818] end draw() 0x12d9b90 12[1334570577624246][1817] PrecipitationEffect::update() 13[1334570577624423][1818] draw() 0x12d9490 14[1334570577624550][1817] Cell size X=20 15[1334570577624839][1817] Cell size Y=20 16[1334570577624995][1817] Cell size Z=5 17[1334570577625140][1817] PrecipitationEffect::update() 18[1334570577625239][1817] Cell size X=20 19[1334570577625326][1817] Cell size Y=20 20[1334570577625532][1817] Cell size Z=5 21[1334570577632117][1817] cull() = new frame 22[1334570577632320][1817] cull() got SceneView 0x12d9fb0 23[1334570577633588][1817] Doing add 24[1334570577634477][1817] Doing add 25[1334570577634573][1817] Doing add 26[1334570577634693][1817] Doing add 27[1334570577634779][1817] Doing add 28[1334570577635150][1817] Doing add 29[1334570577635280][1817] Doing add 30[1334570577635403][1817] Doing add 31[1334570577635489][1817] Doing add 32[1334570577635627][1817] Doing add 33[1334570577635751][1817] Doing add 34[1334570577635948][1817] Doing add 35[1334570577636053][1817] Doing add 36[1334570577636225][1817] In DatabasePager::requestNodeFile(/flightgear/fg26/install/fgfs/scenery/Terrain/e030n20/e036n26/LIME_hangarsemicircular.ac) 37[1334570577636362][1817] In DatabasePager::requestNodeFile(/flightgear/fg26/install/fgfs/scenery/Terrain/e030n20/e036n26/LIME_hangarsemicircular.ac) 38[1334570577636493][1817] In DatabasePager::requestNodeFile(/flightgear/fg26/install/fgfs/scenery/Terrain/e030n20/e036n26/LIME_hangarsemicircular.ac) 39[1334570577638329][1818] draw() got SceneView 0x12d9fb0 40[1334570577638390][1817] end cull() 0x12d9490 41[1334570577638482][1817] cull() 42[1334570577638611][1817] cull() got SceneView 0x12e05c0 43[1334570577639351][1817] end cull() 0x12d9360 44[1334570577639440][1817] cull() 45[1334570577639642][1817] cull() got SceneView 0x12e7740 46[1334570577639822][1817] end cull() 0x12d9b90 47[1334570577639947][1817] DatabasePager::requestNodeFile(3546378.stg) updating already assigned. 48[1334570577644473][1818] Created new 0x4db9620 TextureObject, _numOfTextureObjects 6 49[1334570577654321][1819] itr='/flightgear/fg26/install/fgfs/fgdata26' 50[1334570577655443][1819] FindFileInPath() : trying /flightgear/fg26/install/fgfs/fgdata26/Models/Buildings/cow-stable.osg ... 51[1334570577655824][1819] itr='/flightgear/fg26/install/fgfs/fgdata26' 52[1334570577656695][1819] FindFileInPath() : trying /flightgear/fg26/install/fgfs/fgdata26/cow-stable.osg ... 53[1334570577657007][1819] itr='/flightgear/fg26/install/fgfs/fgdata26' 54[1334570577658216][1819] FindFileInPath() : trying /flightgear/fg26/install/fgfs/fgdata26/Models/Buildings/cow-stable.ac ... 55[1334570577658401][1819] FindFileInPath() : USING /flightgear/fg26/install/fgfs/fgdata26/Models/Buildings/cow-stable.ac 56[1334570577658480][1819] osgDB ac3d reader: starting reading /flightgear/fg26/install/fgfs/fgdata26/Models/Buildings/cow-stable.ac 57
Re: [osg-users] stutter while loading new scenery
Hi, On Monday 16 April 2012, Wolfgang Rostek wrote: I'm fighting with some stutter issues using Flightgear (2.6 and OSG 3.0.1). In my scenario I can reproduce it and it seems to be related to tile loading. The frame rate is above 50 Hz but in one frame cycle it takes 678 msec. I extended OSG notify with a [usec][thread id] prefix and run it with DEBUG_FP level. Below the long lasting frame cycle. It starts at line 21. Up to line 246 it consumes 139 msec. The Create new ... TextureObjects lines up to 257 consume another 543 msec. Is this log showing something I can improve? Why is the time consuming part on the draw() thread (1818)? I would assume this could be done somehow in the background (I'm using DrawThreadPerContext). You are using the nvidia binary driver? This one is known to be extremely bad with computing mipmapping together with texture compression. Can you give the following command line fgfs --prop:/sim/rendering/texture-compression=off a try? This will switch off the use of forced texture compression which might help in this situation. Please tell me if ths works for you. Thanks Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] stutter while loading new scenery
Hi Mathias, that was an incredible helpful response after 11min :D I was hunting for a couple of weeks to track it down. My first test shows no longer any stutter above my test threshold of 100msec. thanks and greetings from Munich Wolfgang R. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47077#47077 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] stutter while loading new scenery
Hi, On Monday 16 April 2012, Wolfgang Rostek wrote: that was an incredible helpful response after 11min :D I was hunting for a couple of weeks to track it down. My first test shows no longer any stutter above my test threshold of 100msec. Thanks for the response. It's probably because you will find my name on plenty of the commit messages in flightgear. :) So the problem is known and we are thinking about workarounds to that long standing problem that is more or less only visible with nvidia. In the end it's really about mipmapping. And one method to get around that is precomputing the mipmaps in the database pager thread. That's on my todo list for some time. But well, as flightgear is not my day job, this might also take some time. And yes, it's really nice to see where flightgear is used today. Just last week we visited some extremely exciting VR and training devices at the MPI in Tübingen where we could see flightgear running. For interrest, what are you using flightgear for? ... can you tell that? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgWidget performances
Hi all, I'm currently trying to find a performance improvement in osgWidget due to some lag we have in our application : We use osgWidget to manage some things at runtime, but we realized that performances were dropping in big scenes. Using profiler co, I found that the osgWidget::WindowManager::pickAtXY function is very expensive in time... Here is my question : this method is called on every event, specially on mouse move and click, event if the mouse is not over Widgets... Is there any reason to make this ? Can this be improved, for example doing it only if the mouse is over the widgets, using a simple XY square test... Thanks for your answers. Regards, Vincent. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] problem getting texture image from a model
Hi everyone.
I'm experiencing an issue with texture images. I am using line segment
intersectors in a manner similar to picking. With a couple of models, the
texture retrieving algorithm works fine, however, with one model it fails. This
is the extract of the code:
Code:
osg::Drawable *collisionDrawable = intersection.drawable.get();
osg::StateSet *collisionStateSet = collisionDrawable ?
collisionDrawable-getStateSet() : null;
osg::Geometry *collisionGeometry = collisionDrawable ?
collisionDrawable-asGeometry() : null;
...
osg::Texture* texture = dynamic_castosg::Texture*
(collisionStateSet-getTextureAttribute(0, osg::StateAttribute::TEXTURE));
osg::Image *textureImage = texture ? texture-getImage(osg::Material::FRONT) :
null;
the textureImage equals to NULL after this sequence, while the texture does
not. so why does the texture-getImage() method not return expected texture ? I
checked the model, it seems to be all right. this is an example
Code:
...
Geode {
...
num_drawables 1
Geometry {
DataVariance STATIC
StateSet {
DataVariance STATIC
...
textureUnit 0 {
GL_TEXTURE_2D ON
Texture2D {
file .\\textures\\102.jpg
wrap_s REPEAT
wrap_t REPEAT
wrap_r CLAMP
min_filter LINEAR_MIPMAP_LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply TRUE
internalFormatMode USE_IMAGE_DATA_FORMAT
resizeNonPowerOfTwo TRUE
shadowComparison FALSE
shadowCompareFunc GL_LEQUAL
shadowTextureMode GL_LUMINANCE
}
TexEnv {
UniqueID TexEnv_4
mode MODULATE
}
}
}
the other model, where it works, looks alike, when exported to osg format. so
why is it, that for this model, the algorithm fails ? can anyone tell?
Thank you very much, and i mean it, for anything useful!
Cheers,
Andrey
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=47080#47080
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget performances
Whilst I haven't used osgWidget, I know we had a similar performance issue with picking when we didn't use an appropriate node mask for picking so that only the pickable objects in the scene are considered. I wonder if osgWidget has implemented one in it's pick handler. Regards, Kim. On 16 April 2012 16:19, Vincent Bourdier vincent.bourd...@gmail.com wrote: Hi all, I'm currently trying to find a performance improvement in osgWidget due to some lag we have in our application : We use osgWidget to manage some things at runtime, but we realized that performances were dropping in big scenes. Using profiler co, I found that the osgWidget::WindowManager::**pickAtXY function is very expensive in time... Here is my question : this method is called on every event, specially on mouse move and click, event if the mouse is not over Widgets... Is there any reason to make this ? Can this be improved, for example doing it only if the mouse is over the widgets, using a simple XY square test... Thanks for your answers. Regards, Vincent. -- __**_ osg-users mailing list osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** openscenegraph.orghttp://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] stutter while loading new scenery
Mathias Fröhlich wrote: Hi, ... So the problem is known and we are thinking about workarounds to that long standing problem that is more or less only visible with nvidia. I'm running Nvidia for test only (GTX560) but my main workstations have ATI. We need to connect several screens to each board. I'll test on these machines tomorrow. The stutter there was similar and I hope this switch will fix it as well. For this summer I'm looking forward to switch over to GTX680. In the end it's really about mipmapping. And one method to get around that is precomputing the mipmaps in the database pager thread. That's on my todo list for some time. But well, as flightgear is not my day job, this might also take some time. No idea what you're talking about ;) I'm just at the beginning to understand what OSG is doing actually. I hope I can spend some more time during the next months to become more familiar with it. And yes, it's really nice to see where flightgear is used today. Just last week we visited some extremely exciting VR and training devices at the MPI in Tübingen where we could see flightgear running. For interrest, what are you using flightgear for? ... can you tell that? We are working on a cockpit prototyping tool. FG is mainly used for the outside view only. The instruments and even the HUD is done in its own way. My personal interest is to enhance the quality of the outside view part. That means a mandatory = 60fps and maximum resolution. In other departments we run flight simulators with COTS components as well. It seems that they scale sometimes better by throwing more HW on it (more cores, multiple GPUs). But as I read within the discussions here that seems to be a not so simple topic. From my user point of view it is most disturbing to see the framerate. I would prefer to have this fix and in high resolution areas the LOD should drop. I did a short comparison to GenesisRT and their fixed framerate seems more natural to me. But anyway I like FG and saw a bunch of excelent features (property tree, IPC) to learn from. regards Wolfgang R. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47082#47082 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] How to use extensible file formats?
Hi, I'm looking for someone to point me in the right direction regarding using extensible file formats such as .osgx. Can someone please help? I have looked around on the OSG website for any documentation but so far the fruits of my labor have been rather... fruitless. If there is a tutorial website or some documentation, that would be a really great help to my project. Thank you! Cheers, Nick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47083#47083 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android OSG SVN version
On 04/14/2012 07:09 PM, Jorge Izquierdo Ciges wrote: Well I'll save you some headaches... DO NOT use the function draw me the camera frame now it changes some OpenGL states and screws the drawing of OSG. You can start from the example where they bind the texture and draw it... the extrange is that even so OSG doesn't draw EXCEPT if you remove the glDisables... then it works perfectly. It took me some time compiling and recompiling once and again and again until i found the troublesome lines. I need to check if the Nvidia Pack has a trully functional OpenGL call inspector to understand what is happening. Arg, thanks for the heads up. We may finally end up not using QCAR because of the intrusive phone-home behaviour (big no go when you have confidentiality agreement with customer in place) and the onerous license - e.g. they explicitly forbid linking with GPL/LGPL code (the Android build is static, so it likely matters) and there are some patent-related clauses that could be a large headache, but I am not a lawyer to be able to judge that properly. The QCAR EULA is one of the worst piece of legalese I ever had the bad luck to read - even the Microsoft's one is more readable. Regarding the state mess-up - I think that this is in fact documented in the QCAR doc, they say what state is modified. You can probably save the OpenGL state, then execute QCAR and then restore - that is how I integrated OSG with Qt before. Not pretty and also quite slow, but works. Regards, Jan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
