Re: [osg-users] How to create a decal on a road segment?
Hi Brad, Thanks for your answer. Currently, I place the decal on the road segment without depth testing. For flat surfaces (planes) it works fine. When the road has a bump or has an incline the depth test seems to be needed. Some lane markers are drawn where they should be hidden (depth test fail). I start to think there is no overall solution. Probably have to separate the problem in two: 1. 2D Surfaces: Use stencil buffer. 2. 3D Surfaces: Use polygon offset, height offset. Cheers, Raymond. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44130#44130 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgga event on mouse enter window?
Hi, it seems there is no osgga event being fired when the mouse is moved over the 3d window. This would be useful for applications with multiple 3d windows. I have implemented this as a user event in my qt based app, but maybe it would be interesting to have that feature for the standard osg window, too? If you are interested I could submit an implementation for GraphicsWIndowX11 and GraphicsWindowWin32. What do you think? Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44131#44131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgexport for blender?
Hi Cedric, With Blender 2.6, for some 3D models, the model is exported (xxx.osg is created on the Blender interface) but there are bugs in writing the file on disk (the file is 0K on disk). Here are some bugs reporting: - ..\osgdata.py, line 497, in write, self.root.write(sfile); - ..\osgobject.py, line 87, in write, Write.SerializeInstanceOrUselt(self,output); - ..\osgobject.py, line 566, in serializeContent, i.write(outout) etc. Cheers, Maia -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44134#44134 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgexport for blender?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Can you report send the model in order I reproduce the problem ? or a model that produces similar problems ? Cedric On 11/30/2011 03:28 PM, Maia Randria wrote: Hi Cedric, With Blender 2.6, for some 3D models, the model is exported (xxx.osg is created on the Blender interface) but there are bugs in writing the file on disk (the file is 0K on disk). Here are some bugs reporting: - ..\osgdata.py, line 497, in write, self.root.write(sfile); - ..\osgobject.py, line 87, in write, Write.SerializeInstanceOrUselt(self,output); - ..\osgobject.py, line 566, in serializeContent, i.write(outout) etc. Cheers, Maia -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44134#44134 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org - -- Cedric Pinson Provide OpenGL, WebGL and OpenSceneGraph services +33 659 598 614 - cedric.pin...@plopbyte.com http://plopbyte.com - http://osgjs.org - http://showwebgl.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7WQL4ACgkQs6ZHzVQN0Iio6gCfR5FILYo0HIOfLne2Gx4sW9vE VTgAn1EL2TP4OxRei4nicZVqHRyo8UXT =v8lf -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Opaque black shadows since moving to OSG V3.0.1
Hello everybody, I'm updating some of my projects from V2.8.3 to V3.0.1 of OSG and i'm struggling with a shadow problem. In fact, osgShadow::LightSpacePerspectiveShadowMapCB produces opaque black shadows, while in previous version it darkened the objects. I've tried to change ambiant in light and objects materials with no success. What i'm looking for is something like AmbiantBias, to control the shadow intensity. Do you know any way to achieve this please? With this shadow technique, if possible. I'm running Windows 7 on an ATI Radeon HD 6850 Thanks! Cyril -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44136#44136 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Opaque black shadows since moving to OSG V3.0.1
Hi Cyril, None of the View Dependent Techniques was using Ambient Bias before. So thats not the case here I suppose. I am not sure if thats it but look at the shaders located in StandardShadowMap.cpp. I believe that Robert has switched the shadow shaders to use only fragment shaders somewhere between 2.9 and 3.0. That might have affected the ambient/emissive handling... Formerly ambientEmissive value was computed in shadow vertex shaders and passed to fragment shader. Now fragment shaders simply read material and light ambient colors and use them insted of former ambienEmiissive varying. Cheers, Wojtek Lewandowski 2011/11/30 Cyril Bondue c.bon...@cbbknet.com Hello everybody, I'm updating some of my projects from V2.8.3 to V3.0.1 of OSG and i'm struggling with a shadow problem. In fact, osgShadow::LightSpacePerspectiveShadowMapCB produces opaque black shadows, while in previous version it darkened the objects. I've tried to change ambiant in light and objects materials with no success. What i'm looking for is something like AmbiantBias, to control the shadow intensity. Do you know any way to achieve this please? With this shadow technique, if possible. I'm running Windows 7 on an ATI Radeon HD 6850 Thanks! Cyril -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44136#44136 ___ 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] Custom osg::NotifyHandler problems and multi-threading
Hi George,
The effect of removing the _logmessage suggests to me that the MS
implementation does something odd making it unreliable when being
called from multiple threads. Try replacing the _logmessage with a
fprintf or equivalent C function to see if that helps.
Robert.
On 29 November 2011 11:38, George Bekos bekos...@live.com wrote:
Hello Robert,
Thank you very much for your reply. I did remove the _log message; line
and the problem goes away. When I get the crush, in which VStudio reports
heap corruption, I use the debugger to have a look at the corrupted memory
block, and it always points to some region where the notice strings are
saved. In my program I do not do anything fancy. It is an extremely simple
case:
Code:
#include cstdlib
#include osg/Group
#include osgViewer/Viewer
#include LogFileHandler.h
// -
class MyUpdateCallback : public osg::NodeCallback
{
virtual void operator()( osg::Node* node, osg::NodeVisitor* nv) {
for(size_t i = 0; i 1000; ++i) {
osg::notify( osg::NOTICE ) hello!;// std::endl;
}
}
};
// -
int main( int agc, char** argv )
{
osg::setNotifyLevel(osg::DEBUG_FP);
osg::Group* root = new osg::Group();
LogFileHandler* fileHandler = new LogFileHandler(log.txt);
osg::setNotifyHandler(fileHandler);
root-setUpdateCallback(new MyUpdateCallback());
osgViewer::Viewer viewer;
viewer.setSceneData(root);
viewer.setUpViewInWindow(50,50,800,600);
viewer.run();
return EXIT_SUCCESS;
}
When I check the corrupted memory block sometimes I see something like
hello!!hello!!hel«þîþîþ..þîþþîþþîþþîþ. Which looks corrupted to me.
If I add an std::endl at the end of my message in the above callback the
problem still appears but not very often. I have tried this program on 2
different PCs but both of them had windows7x64. I checked my lib and dll
files, I do not mix release and debug builds. The problem is very strange...
I guess I am missing something.
Thanks for your help!
Cheers,
George
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44106#44106
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] png plugin - problem loading images
thank you for the tip. i tried locating the libpng library and i found there was a file libpng15.dll in the system path. i don't really know how this library file-name-thing really works so i renamed it to libpng.dll and tried running my osg app again, but without any success. i will try the program you suggested shortly and report the result, though i have all the libraries that i needed to compile the libpng and the osg in the system path variable. Andrey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44139#44139 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] starting with stencil buffer to achieve ray tracing
hello good people! i need a bit of advice ragarding some more advanced rendering techniques. advanced for me, anyway. i am trying to build a simple ray tracing application on top of the basic osgviewer program. to start off, i am trying to look at the loaded model and decide where to cast rays, e.g. i don't want to cast any rays where the model would be missed. i was thinking of using the stencil buffer and the first thing i need is to draw say white pixels where the model is and say black pixels where the model is not. then display this buffer as the frame buffer, you know what i mean. is this possible? i remember doing something similar with GLUT long, long time ago. //if i was able to do this kind of evaluation on the per-pixel basis, i think, i could add some more advanced features like the color of the first hit object (instead of white) and then maybe continue with some real ray tracing, as i mention in the following lines.// later on, according to where the model would be hit (the white pixels), i would cast rays using line intersectors. haven't thought about details here yet. it would be kind of any of you if you could give me some pointers, especially for the first part with the buffers that i am currently dealing with - is it even possible? is my concept good? - for my knowledge in this area has gotten very poor :( and i am also new to the osg. thank you very much in advance. Andrey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44140#44140 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OsgMaxExp (OSGExp for 3dsmax) patch for crash on mixmaps
Hi Laurens, I just committed your patch. Thanks a lot! Cheers, Farshid On Thu, Nov 17, 2011 at 4:34 AM, Laurens Voerman l.voer...@rug.nl wrote: Hi Farshid, I experienced a crash while exporting a file from max2012 (x64). I traced the problem to a mixmap having no texture on one of the imputs, that triggered a bug in MtlKeeper.cpp line812: texUnits[i] = getNextTexUnit(stateset, subTexmap-GetMapChannel()); BUG: subTexmap is NULL Also the mixmap doesn't respond to lighting due to the way the texEnv is set up. To fix both problems I rewrote the entire MtlKeeper::convertMixTexmap functon, setting up the texEnv to first mix texure 1/2 controlled by tex3 and a second texEnv for modulating the result (of the previous texEnv) with the primary fragment color. Attached as MtlKeeper.zip Second problem I encountered with max2012 is that the exported textures are garbage is gamma correction is enabled in 3dstudio. Attached is a simple fix disabling gamma correction during export. Attached as OSGExp.zip Both files are based on svn trunk rev. 230 Regards, Laurens. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText::Text is quite a heavyweight (memory-wise)
Thank you for your answer. We've changed our code from holding ten thousands of pre-generated text labels to a code that dynamically creates them. Because we do single threaded rendering in a Qt window, it is not much of a problem to modify the scene graph at runtime and to create them on an as-needed basis. Again, thank you (and all contributors) for providing such a powerful scene graph (and support) at zero cost. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] starting with stencil buffer to achieve ray tracing
Hi Andrey, Just a thought, but wouldn't this only work for orthographic projections? I believe the traditional ray tracing approach to this problem is to use an octree. Kim. On 30 November 2011 17:53, Andrey Ibe xry...@gmail.com wrote: hello good people! i need a bit of advice ragarding some more advanced rendering techniques. advanced for me, anyway. i am trying to build a simple ray tracing application on top of the basic osgviewer program. to start off, i am trying to look at the loaded model and decide where to cast rays, e.g. i don't want to cast any rays where the model would be missed. i was thinking of using the stencil buffer and the first thing i need is to draw say white pixels where the model is and say black pixels where the model is not. then display this buffer as the frame buffer, you know what i mean. is this possible? i remember doing something similar with GLUT long, long time ago. //if i was able to do this kind of evaluation on the per-pixel basis, i think, i could add some more advanced features like the color of the first hit object (instead of white) and then maybe continue with some real ray tracing, as i mention in the following lines.// later on, according to where the model would be hit (the white pixels), i would cast rays using line intersectors. haven't thought about details here yet. it would be kind of any of you if you could give me some pointers, especially for the first part with the buffers that i am currently dealing with - is it even possible? is my concept good? - for my knowledge in this area has gotten very poor :( and i am also new to the osg. thank you very much in advance. Andrey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44140#44140 ___ 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] transformation matrix explanation
Hello to all, I know that this is sort of a newbie question but i need to clear this one out. I have these two matrice Object near the camera: 0.00581384 -0.997389 -0.0719816 0 0.99705 0.0112907 -0.0759159 0 0.0765305 -0.0713279 0.994513 0 -10.7682 9.27382 -316.446 1 Object far from camera 0.0419087 -0.965536 0.256872 0 0.99876 0.0473957 0.0152043 0 -0.026855 0.255917 0.966326 0 -10.7372 31.5448 -722.176 1 I am trying to find some documentation about these 4x4 but everything confuses me more and more. Please is there -anywhere- an explanation of these? is it like I describe below? x y z ? transform 0.00581384-0.997389 -0.0719816 0 translate 0.99705 0.0112907 -0.0759159 0 rotate 0.0765305 -0.0713279 0.994513 0 projection -10.7682 9.27382 -316.446 1 The thing is that I need to compute a distance using these two matrice. Is possible by using these numbers? Thank you for your time Cheers, Stefanos -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44144#44144 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] transformation matrix explanation
On 11/30/2011 1:37 PM, Jean-Sébastien Guay wrote: Distance from one object to the other? Simply subtract the translation of each matrix, which gives you the vector from one to the other. Then take the length of that. In OSG, you would do: osg::Vec3 o1_to_o2 = o1Matrix.getTrans() - o2Matrix.getTrans(); double distance = o1_to_o2.length(); That works when there's no scaling, and that appears to be the case in the OP's matrices. When scaling is used, it's possible for the translation values to be scaled (depending on order of matrix concatenation). One way to account for that would be to multiply the same vector by both matrices, subtract one result from the other, then get the length of the difference vector. But it really depends on what the OP wants. Does he want the distance from the transformed model origin of the two objects? Does he want the distance from the exterior of one bounding sphere to another? Does he want an exact closest distance accounting for possibly concave objects? Just a few different ways to interpret I need to compute a distance, in increasing order of complexity. :-) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Augmented reality with OSG
Hi. I'm trying to port an OpenGL augmented reality program based on the ArUco library (http://www.uco.es/investiga/grupos/ava/node/26) to OSG (I'm not trying OSGArToolkit yet). The original OpenGL program shows a perfect overlap between the AR marker and the geometric model. The OSG version doesn't. Here's the code outline. Differences between versions are marked with --. OPENGL PROGRAM == 1) Projecton matrix initialization: double projection_array[16]; ar::getProjectionMatrix(opencv camera parameters, projection_array); --glMatrixMode(GL_PROJECTION); --glLoadMatrix(projection_array); 2) Main loop: cameraCapture(frame); // frame is unsigned char *. double modelview_array[16]; ar::getMarkerModelViewMatrix(frame, modelview_array); --glMatrixMode(GL_MODELVIEW); --glLoadMatrix(modelview_array); ...draw stuff OSG PROGRAM === 0) OSG misc initialization: // Prevent the default (trackball) manipulator from overwriting the modelView matrix continuously. // http://forum.openscenegraph.org/viewtopic.php?p=44126#44126 --osg::Camera *cam = viewer.getCamera(); --cam-setAllowEventFocus(false); 1) Projection matrix initialization: double projection_array[16]; ar::getProjectionMatrix(opencv camera parameters, projection_array); --osg::Matrixd projectionMatrix; --projectionMatrix.set(projection_array); --viewer.getCamera()-setProjectionMatrix(projectionMatrix); 2) Main loop: cameraCapture(frame); double modelview_array[16]; ar::getMarkerModelViewMatrix(frame, modelview_array); --osg::Matrixd modelViewMatrix; --modelViewMatrix.set(modelview_array); --viewer.getCamera()-setViewMatrix(modelViewMatrix); ... draw stuff (with NodeCallbacks). What could be wrong? Thanks, Juan Herrera ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] starting with stencil buffer to achieve ray tracing
basically, what i want to do is to cast primary rays from the camera (for each pixel on the screen) into the scene using line intersectors. then i want to retrieve normal of the intersection to be able to compute the direction of the secondary ray and then to cast it the way i cast the primary rays. i want to continue recursively until a certain point. with the buffer i want to optimize the number of the primary rays casted. ultimately, my goal is to render the scene normally using opengl pipeline into FBO, then turn on ray tracing for certain objects/materials in the scene. i need to know whether this is possible and in what ways can osg help. what i see as the greatest advantage are the intersetors and the osg's ability to compute the intersections automatically. i don't get the connection between the octree, which if i am not mistaken is a way of organizing the data or the scene, and my goal. neither i get the reason why this buffer thing would not work on perspective projection, if that's what you meant. thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44147#44147 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Opaque black shadows since moving to OSG V3.0.1
I am also experiencing the same thing upgrading from 2.8.5 to 3.0.1. For a
while I thought it was completely opaque until I looked closely at my lcd
monitor where I found it to be just really really dark instead.
Here is the relevant frag shader code from 3.0.1:
Code:
void main(void)
{
vec4 colorAmbientEmissive = gl_FrontLightModelProduct.sceneColor;
// Add ambient from Light of index = 0
colorAmbientEmissive += gl_FrontLightProduct[0].ambient;
vec4 color = texture2D( baseTexture, gl_TexCoord[0].xy );
color *= mix( colorAmbientEmissive, gl_Color, DynamicShadow() );
According to the opengl Orange book (shading language),
gl_FrontLightModelProduct.sceneColor = gl_FrontMaterial.emission +
gl_FrontMaterial.ambient * gl_LightModel.ambient.
Using GDebugger I was able to inspect these values as my shadowed geometry was
drawn and saw:
gl_FrontMaterial.emission = {0,0,0,1}
gl_FrontMaterial.ambient = {0.588,0.588,0.588,1}
gl_LightModel.ambient = {0.1,0.1,0.1,1}
Given these values, gl_FrontLightModelProduct.sceneColor = colorAmbientEmissive
= {0.0588,0.0588,0.588,1} which explains the extreme darkness of the shadows.
In OSG 2.8.5 colorAmbientEmissive was calculated like this:
Code:
colorAmbientEmissive = gl_FrontLightModelProduct.sceneColor + amb *
gl_FrontMaterial.ambient;
For me this version results in much brighert/less dark shadows.
I see 2 choices to restore the previous look:
1) Use custom shaders in order to use our own colorAmbientEmissive calculation
or
2) Make sure the LightModel's ambient is much higher than 0.1.
If there's something easier that I'm missing, please let me know,
Thanks,
Michael
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44149#44149
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Opaque black shadows since moving to OSG V3.0.1
Hi Michael,
Haven't you just skipped addition of gl_FrontLightProduct[0].ambient which
should contain contribution of light 0 ambient * material ambient ? So
final colorAmbientEmissive is gl_FrontLightModelProduct.sceneColor
+ gl_FrontLightProduct[0].ambient. This should produce
similar colorAmbientEmissive term as old vertex shader version unless
something else do not come into play. Perhaps you draw using BackFace
materials ?. I also wonder if use of ColorMaterial mode may somehow result
it different colorAmbientEmissive now
Cheers,
Wojtek
2011/11/30 Michael Guerrero mjgue...@nps.edu
I am also experiencing the same thing upgrading from 2.8.5 to 3.0.1. For
a while I thought it was completely opaque until I looked closely at my lcd
monitor where I found it to be just really really dark instead.
Here is the relevant frag shader code from 3.0.1:
Code:
void main(void)
{
vec4 colorAmbientEmissive = gl_FrontLightModelProduct.sceneColor;
// Add ambient from Light of index = 0
colorAmbientEmissive += gl_FrontLightProduct[0].ambient;
vec4 color = texture2D( baseTexture, gl_TexCoord[0].xy );
color *= mix( colorAmbientEmissive, gl_Color, DynamicShadow() );
According to the opengl Orange book (shading language),
gl_FrontLightModelProduct.sceneColor = gl_FrontMaterial.emission +
gl_FrontMaterial.ambient * gl_LightModel.ambient.
Using GDebugger I was able to inspect these values as my shadowed geometry
was drawn and saw:
gl_FrontMaterial.emission = {0,0,0,1}
gl_FrontMaterial.ambient = {0.588,0.588,0.588,1}
gl_LightModel.ambient = {0.1,0.1,0.1,1}
Given these values, gl_FrontLightModelProduct.sceneColor =
colorAmbientEmissive = {0.0588,0.0588,0.588,1} which explains the extreme
darkness of the shadows.
In OSG 2.8.5 colorAmbientEmissive was calculated like this:
Code:
colorAmbientEmissive = gl_FrontLightModelProduct.sceneColor + amb *
gl_FrontMaterial.ambient;
For me this version results in much brighert/less dark shadows.
I see 2 choices to restore the previous look:
1) Use custom shaders in order to use our own colorAmbientEmissive
calculation or
2) Make sure the LightModel's ambient is much higher than 0.1.
If there's something easier that I'm missing, please let me know,
Thanks,
Michael
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44149#44149
___
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] ShadowMapping in a multipass deferred setup
Hi Sebastian, Unfortuantely I do not have enough time to get as deep as neccessary into this complex problem you are considering. There could be many approaches to integration of deffered shading with OSG. And I guess algorithms and data structures used in such implementations would most probably impact the ways of Shadow integration. So its hard to speak how to best adopt the Shadow techniques without deeper knowledge of your DefferedShader classes and their call graphs. I have seen few projects recently where fixed lighting was replaced by programmable lighting and in almost all cases certain ShadowTechique was a natural class to derive a LightManager which would be a main class controlling which lights are processed and which lights generate shadows. If I was to implement my deffered shader I would do the same. I would create LightManager class that would override my favourite shadow Technique. That class would be a center point for light handling and like all shadow techniques it would capture the cull method of main scene traversal to do following steps: 1: run the main scene cull to fill RenderStage to fill opaque geometry to G-Buffers. 2: read all traversed lights from PossitionalStateAttributes or run light traversal to select (cull) light sources lighting the view. Such Light cull traversal could take light volumes into consideration and could reject lights landing outside view frustum. 3: Then from list of processed lights I would probably select few (N) closest or brightest or largest volume (policy may vary) lightsources as those which cast the shadows and would run N cull traversals for the scene to generate RenderStages for their shadow maps. Remaining lights would not need own RenderStages because would be rendered without shadows. 4: Then in next step would add light geometries used to lit the pixels in lighting passes each light geometry would also take proper shadow map and would set the positioning and scaling matrices on some uniform. Shader applied for geometry would add light contribution to color buffers. 5: Next steps would be transparency pass and postprocessors. (I must say I have not thought much about how to integrate them yet, but I am sure something tehre must be a way to do it;-) Certainly the steps 1..4 (if not all) can be invoked from such overriden cull method of LightManager. So refering to your questions I would rather make my customized ShadowTechnique a center class for the algorithm. So I would not import external shadow textures and cameras but would create container of shadow maps (actually single Shadow2DArray is perfect here) and vector of cameras for shadow maps as technique variables. The first one is to specify the texture the shadow-pass renders in by myself so I can bind the appropriate texture object and set the render order individually. I believe ShadowTechnique extended to process N lights is a perfect place to do this. I would not render it individually just would make sure the Cameras have proper rendering order... The second step is to tell the shadow pass not to apply the shadow texture to the scene, but instead just guarantee that is finished after the render-pass and must be able to pass me the matrices used for shadow calculation so I can transform my scene's depth into light-view space on my own. Well... applying the shadow is actually done be global shader. As far as I understand you would need a special shader to generate MRT gbuffers. So will not render the shadows anyway then. Shadows maps would be most probaly multiplying light cotribution in later light passes. I've taken a look into the DebugShadowMap which curiously seems to be the place where the shadow-camera for the ViewDependentTechniques is declared. Yes DebugShadowMap defines ShadowMap and ShadowCamera because DebugShadowMap defines a lowest layer of Debug functionality of all ViewDependentShadowTechniques. This Debug functionality needs acces to shadow map so it declares it. StandardShadowMap is derived from DebugShadowMap and rest of stems from StandardShadowMap. So my general idea was to provide a public function to set the camera/render texture from the outside and tell the init function only to create it if the cam wasn't setup from the outside. Honestly I found the split up code for the different shadow implementations hard to understand, as they are scattered a bit too much to get the idea. I admit its terribly complex but other option would be to create a 8 or 9 techinques that would have all the code separated and lots of this code would identical and redundant. Maintaining such thing would be a greater problem I guess. Has anyone a better idea to render the shadow map to a predefined FBO-attached texture and let my own shader do the reprojection in order to do shadow mapping in a deferred setup? As I said shadow map techniques do this for you. So I guess this means you have rather different class structure than I would
