Re: [osg-users] Problem using osg::ColorMatrix
Hi Rahul. If I recall correctly the color matrix isn't working on most
consumer cards. You need the the GL_ARB_IMAGING extension.
Alternatively you can achieve the desired effect with a shader.
cheers
psy
Hi all,
I am trying to use OpenFL color matrix functionality through
osg::ColorMatrix but not able to do so. When i apply this to a node
|(cessna.osg) i do not see any effect. I am pasting the code below for
you guys to have a look.
I don't know what am i doing wrong in this simple piece of code .
cheers RJ
int main(int argc, char** argv)
{
osg::MatrixTransform* cessnaMT = new osg::MatrixTransform;
osg::Node* cessna = osgDB::readNodeFile(cessna.osg);
cessnaMT-addChild(cessna);
// Set color matrix
osg::ColorMatrix* colorMatrix = new osg::ColorMatrix;
const osg::Matrix cm (0.15, 0.0, 0.0, 0.0,
0.0, 0.3, 0.0, 0.0,
0.05, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);
colorMatrix-setMatrix(cm);
cessnaMT-getOrCreateStateSet()-setAttributeAndModes(colorMatrix,
osg::StateAttribute::OVERRIDE | osg::StateAttribute::ON);
osgViewer::Viewer viewer;
// add model to viewer.
viewer.setSceneData(cessnaMT);
viewer.run();
return 0;
}
___
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] vpb on cluster example
Hi, Greg Myers wrote: Hi JP, I'm new and I'm a little fuzzy on the versioning between VPB and OSG. It looks like for the example you have provided, we need an older version (2.3.6) of OSG. Do you know if there are plans to upgrade VPB to work with the latest releases of OSG or am I totally missing something? Thanks for any info. Greg sorry, I should have made the versions I used more explicit. For the example I used OSG and VPB from svn around June. osgversion says 2.5.1. svn info gives: Revision: 8413 for OSG and Revision: 914 for VPB I'll add the info to the example page. regards jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Pick color from scene
Hi, I want to do a ray-intersection toward a tree model (as an example) and ignore the hit-location if it contain zero alpha value. Basically this is a line-of-sight-check that take textures into consideration. I think a good way is to use the existing intersection system and thus produce a list of hit-locations. I will then for each hit location need to figure out what alpha-value it holds. I can then ignore those hit-locations that we can see through. So, I am looking for a scene-graph color-picker. Does anybody have something like this that they want to share? Note: I am not looking for something that use hardware to render part of the scene and then a read-back from hardware. This should be CPU only :-) Regards, Viggo _ Hold kontakten med Windows Live Messenger. http://clk.atdmt.com/GBL/go/msnnkdre001003gbl/direct/01/___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem using osg::ColorMatrix
Hi Ulrich, Thanks for the reply, you are absolutely right, color matrix is part of imaging subset which is used during pixel transfer operation. The concept just slipped out of my mind ;) thanks for the correcting my thoughts cheers RJ Ulrich Hertlein wrote: Hi Rahul, Rahul Jain wrote: Color matrix in OpenGL is used for color space conversion, for example using color matric you can convert RGB to BGR , RGB to CMY. Unfortunately i do not have any screen grabs for the moment, but i am trying to achieve night vision effect using this code , doesn't the color matrix only affect pixel transfer operations? Like texture upload/download, framebuffer reads and such? So you can't use it to modify object appearance on the fly. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] View Frustrum Culling
Hello everyone, Maybe it sounds basic. I have camera that will never change place. I have a database with one Object/onFile-Mapping. So next time I load my Scene id like to load only relevant Objects to shorten Loading time. Simple Task: I need to get a list of all VISIBLE Objects in the ViewFrustrum. Can this be done with the cull-Traverser. The docs say it collects all the objects in a special order. Are these objects all objects in the end or only the visible? How can I get the visbile Nodes? What things are to be taken care of? Greetings? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg make error in mingw
thanks Philip Lowman! i will try it! 在2008-07-29，Philip Lowman [EMAIL PROTECTED] 写道： On Tue, Jul 29, 2008 at 1:00 AM, songbo_1220 [EMAIL PROTECTED] wrote: hello everyone! sorry my english is poor. i working at the mingw, i make the osg, find below some error, can you tell me why and how to do? thanks! [EMAIL PROTECTED] /f/OpenSceneGraph/OpenSceneGraph-2.2.0/OpenSceneGraph/build_msys $ make Scanning dependencies of target OpenThreads [ 0%] Building CXX object src/OpenThreads/win32/CMakeFiles/OpenThreads.dir/WIN32Condition.obj In file included from f:/OpenSceneGraph/OpenSceneGraph-2.2.0/OpenSceneGraph/src/OpenThreads/win32/Win32ConditionPrivateData.h:29, from f:/OpenSceneGraph/OpenSceneGraph-2.2.0/OpenSceneGraph/src/OpenThreads/win32/WIN32Condition.cpp:20: f:/OpenSceneGraph/OpenSceneGraph-2.2.0/OpenSceneGraph/src/OpenThreads/win32/Win32ThreadPrivateData.h:22:1: warning: _WIN32_WINNT redefined In file included from f:\mingw\build\bin\../lib/gcc/i386-pc-mingw32/4.3.0/../../../../include/windows.h:48, from f:/OpenSceneGraph/OpenSceneGraph-2.2.0/OpenSceneGraph/src/OpenThreads/win32/Win32ConditionPrivateData.h:24, from f:/OpenSceneGraph/OpenSceneGraph-2.2.0/OpenSceneGraph/src/OpenThreads/win32/WIN32Condition.cpp:20: f:\mingw\build\bin\../lib/gcc/i386-pc-mingw32/4.3.0/../../../../include/windef.h:20:1: warning: this is the location of the previous definition [ 0%] Building CXX object src/OpenThreads/win32/CMakeFiles/OpenThreadsdir/Win32Mutex.obj [ 0%] Building CXX object src/OpenThreads/win32/CMakeFiles/OpenThreads.dir/Win32Thread.obj f:/OpenSceneGraph/OpenSceneGraph-2.2.0/OpenSceneGraph/src/OpenThreads/win32/Win32Thread.cpp: In static member function 'static int OpenThreads::ThreadPrivateActions::SetThreadSchedulingParams(OpenThreads::Thread*)': f:/OpenSceneGraph/OpenSceneGraph-2.2.0/OpenSceneGraph/src/OpenThreads/win32/Win32Thread.cpp:196: error: 'getenv' was not declared in this scope make[2]: *** [src/OpenThreads/win32/CMakeFiles/OpenThreads.dir/Win32Thread.obj] Error 1 make[1]: *** [src/OpenThreads/win32/CMakeFiles/OpenThreads.dir/all] Error 2 make: *** [all] Error 2 Songbo, Looks like a bug. To workaround the problem on your system, add the following to Win32Thread.cpp, near the top: #include stdlib.h osg-submissions, I can't reproduce the compilation error with my MinGW and the latest OSG trunk but I'm attaching the fix anyways since stdlib.h should be #included in this source file anyways. I can reproduce the warning due to the redefinition of _WIN32_WINNT and I've fixed it. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] View Frustrum Culling
Hi Kaiser,
I have just done parts of what you need.
Make yourself a group node which you place as the root of the scene-graph that
you need to list objects from.
Override it's traverse function and post process the cull-visitor:
void yourGroupClass::traverse( osg::NodeVisitor nv )
{
osg::Group::traverse( nv );
if( nv.getVisitorType() == osg::NodeVisitor::CULL_VISITOR )
{
osgUtil::CullVisitor* cv = dynamic_castosgUtil::CullVisitor*( nv );
if( cv )
{
// Do your stuff here
// You should be able to find what you need inside
cv-RenderStage-RenderBinList...
// The cull-traverse is done, so everything that is visible must be
stored in the render-bins.
// I am pretty sure you should be able to find some information in
these structures which points you to your objects.
}
}
}Cheers,
Viggo
Date: Tue, 29 Jul 2008 09:56:59 +0200From: [EMAIL PROTECTED]: [EMAIL
PROTECTED]: [osg-users] View Frustrum Culling
Hello everyone,
Maybe it sounds basic. I have camera that will never change place. I have a
database with one Object/onFile-Mapping. So next time I load my Scene id like
to load only relevant Objects to shorten Loading time.
Simple Task: I need to get a list of all VISIBLE Objects in the ViewFrustrum.
Can this be done with the cull-Traverser. The docs say it collects all the
objects in a special order. Are these objects all objects in the end or only
the visible? How can I get the visbile Nodes? What things are to be taken care
of?
Greetings?
_
Windows Live Messenger - også på mobilen.
http://windowslivemobile.msn.com/Homepage.aspx?lang=nb-noocid=30032___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pick color from scene
Hi Brede, Thanx for the info, it looks like it will give me the texture coordinates of the polygon that is hit, and that is a very good start :-) Regards, Viggo Date: Tue, 29 Jul 2008 12:14:18 +0200 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Pick color from scene Hi Viggo, Some time ago there was a thread called How to retrieve a U, V texture coordinate from a picking action ?. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/26306/focus=26352 Regrads, Brede On Tue, Jul 29, 2008 at 9:23 AM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi, I want to do a ray-intersection toward a tree model (as an example) and ignore the hit-location if it contain zero alpha value. Basically this is a line-of-sight-check that take textures into consideration. I think a good way is to use the existing intersection system and thus produce a list of hit-locations. I will then for each hit location need to figure out what alpha-value it holds. I can then ignore those hit-locations that we can see through. So, I am looking for a scene-graph color-picker. Does anybody have something like this that they want to share? Note: I am not looking for something that use hardware to render part of the scene and then a read-back from hardware. This should be CPU only :-) Regards, Viggo Få Hotmail du også. Windows Live Hotmail nå med 5000 MB gratis lagringsplass. ___ 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 _ Windows Live Messenger - også på mobilen. http://windowslivemobile.msn.com/Homepage.aspx?lang=nb-noocid=30032___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pick color from scene
Hi Viggo, Some time ago there was a thread called How to retrieve a U, V texture coordinate from a picking action ?. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/26306/focus=26352 Regrads, Brede On Tue, Jul 29, 2008 at 9:23 AM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi, I want to do a ray-intersection toward a tree model (as an example) and ignore the hit-location if it contain zero alpha value. Basically this is a line-of-sight-check that take textures into consideration. I think a good way is to use the existing intersection system and thus produce a list of hit-locations. I will then for each hit location need to figure out what alpha-value it holds. I can then ignore those hit-locations that we can see through. So, I am looking for a scene-graph color-picker. Does anybody have something like this that they want to share? Note: I am not looking for something that use hardware to render part of the scene and then a read-back from hardware. This should be CPU only :-) Regards, Viggo Få Hotmail du også. Windows Live Hotmail nå med 5000 MB gratis lagringsplass. ___ 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] Using SSE within OSG
Dear All, There's a discussion going on at the moment over in osg-submissions, and it has been raised that this ought to be opened up to the non-submissions community for feedback. Note that the following is my reading of the issues, and certainly doesn't represent the consensus view of the osg-submissions crowd, so feel free to challenge what I'm saying! *Background* Several people already use SSE instructions ( http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions) alongside OSG to obtain speed improvements through parallelising math operations. The general point that has been raised is that under-the-hood, OSG does quite a lot that could benefit from the potential performance boost given by SSE operations. Obvious targets include some of the Vec/Matrix routines, for example. SSE is now sufficiently mainstream that the risk of processor incompatibility is felt to be low. *Question 1 : Where could the core OSG include SSE?* Most people follow the sensible approach of profiling to determine their bottlenecks, and then optimising particular methods in order to gain speed-up. This would be a sensible approach to follow, as SSEing all methods would probably be a waste of effort. It would therefore be instructive firstly to know if anybody is using SSE with OSG, and where. Secondly, for those who have profiling data and know how much time they spend in Vec/Matrix/whatever methods, it would be useful to know which methods the community considered good targets for SSEing. Any other maths heavy lifting going on? (e.g. Intersection testing? Delauney triangulation? etc.) *Question 2 : How could the core OSG include SSE?* SSE code benefits from aligned data. Hence there are several ways in which OSG could include SSE: a) Provide an aligned Vec4f and aligned Matrix4f class, which support SSE operations. This would appear (to me) to be the least intrusive. b) Provide branching code within the existing Vec4/Matrix4 methods for detecting whether data is aligned, and performing the correct operations. This would appear to me to be the most user-transparent. Although it would appear to be a performance hit, testing so far on some specific code would support the argument that the speed gains from SSE outweigh the branch cost; more testing needed, I guess. c) Robert suggested that SSE enabled array operators (e.g. providing a cross-product operator for Vec3Array) might be appropriate and provide the best speed improvement for those who want it. Certainly using SSE on large array type data sets is where one gains the most performance improvement. This question includes the possibility of linking out to, or pulling source code our of, an external optimised math library. Any other suggestions? *Question 3 : (possibly the biggest) Should the core OSG include SSE?* There are several downsides to including SSE. Firstly, x-platform provision of SSE may be tricky due to the way different compilers define aligned data, and how SSE instructions are used within the code. I personally don't have much experience here, so any feedback on x-plaform issues is useful. Secondly, the code readability drops, and the use the source argument may be trickier when many might not know much SSE. So - your opinion, experience and suggestions welcome! David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems with new version OSG 2.6.0
Hi. After some more debugging I got next: file osgUtil/LineSegmentIntersector.cpp lost Transform/Geode/drawable reaches this expression line 388: drawable-accept(ti); but next if executes time by time(drawable-accept fails in some situations). if (ti._hit) It means that error is in the drawable-accept(ti). I can't say any more because I have not enough knowledges about OSG. ( I think I have found place where error with intersection is. While debugging I got next results: In file osgUtil/IntersectionVisitor.cpp void IntersectionVisitor::apply(osg::Node node), void IntersectionVisitor::apply(osg::Group group) etc. all ok, names of intersected objects appeares all times it must be (std::cout Node appy= node.getName() std::endl;) file osgUtil/LineSegmentIntersector.cpp function void LineSegmentIntersector::intersect(osgUtil::IntersectionVisitor iv, osg::Drawable* drawable) in line 338 expected name also appeares but line 444 (osgUtil/LineSegmentIntersector.cpp) (insertIntersection(hit);) sometimes never executes! It means that problem somewhere in osgUtil/LineSegmentIntersector.cpp ) 28.07.08, 22:44, GMD GammerMaxyandex.ru [EMAIL PROTECTED]: Here is the small example, where described problem appeares. Example is modified example of osgpick (chenged code which returns name of object and osg scene). To see this problem you must go in the deep of room (way is showen in 00.jpeg). Then you need make several clicks in different positions (movements bitween positions must be small) and you will see that cursor often falls throught the object over which cursor is (possible positions is showen on 11.jpg). There is two archives in attachement (with textures and without them). Code is in osgpick.zip file which taken from example osgpick. I hope this is enough to illustrate described problem. And I think it will be not good if this error appeares in this release (2.6.0). Thanks, Max. files: (download: enter number, click green button) http://narod.ru/disk/171128/osgpick.zip.html http://narod.ru/disk/1711073000/00.JPG.html http://narod.ru/disk/1711279000/11.JPG.html http://narod.ru/disk/1712663000/museum_with_textures.zip.html Thanks, Max. 28.07.08, 10:47, GMD GammerMaxyandex.ru [EMAIL PROTECTED]: Ok, I'll make small example and show where problem occures. I'll try do this today. 28.07.08, 00:33, sherman wilcox [EMAIL PROTECTED]: Can you make a small and simple prototype that *reliably* reproduces the problem? You have a better chance of getting help that way. On Sun, Jul 27, 2008 at 2:50 AM, GMD GammerMaxyandex.ru [EMAIL PROTECTED] wrote: Some offers of OSG 2.6.0( problems with new version). Let's wait with OSG 2.6.0 release. I asked this because I found a problem with osgUtil::LineSegmentIntersector function. In OSG v 2.5.5 version of OSG function viewer-computeIntersections(x,y, hlist) works very strange - when cursor movements over object is short it(cursor) falls throught the object and function returns name of object which is behind current(object over which cursor is). In earlyer(less 2.5.2) versions of OSG this error has never appeared. How can I solve this problem in this(2.5.5) version of OSG? It is necessary to solve the problem until OSG 2.6.0 release. Thanks in advance. Best regards, Max. ___ 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 -- Яндекс.Открытки на все случаи жизни http://cards.yandex.ru/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
Hi David My company makes very heavy use of SSE in our main products, and there are vast speed improvements to be gained, sadly I don't have permission to provide profiling data We use SSE's for heavy heavy matrix work outside of OSG, we use some we have added to our OSG/OGL apps such as for normal generations, fast sqr root routines, texture operations, the clock cycles saved can mount up quickly I would say adding SSE operation in the right places would be highly beneficial for the OSG core in performance gains. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Spilling Sent: Tuesday, July 29, 2008 8:05 AM To: OpenSceneGraph Users Subject: [osg-users] Using SSE within OSG Dear All, There's a discussion going on at the moment over in osg-submissions, and it has been raised that this ought to be opened up to the non-submissions community for feedback. Note that the following is my reading of the issues, and certainly doesn't represent the consensus view of the osg-submissions crowd, so feel free to challenge what I'm saying! Background Several people already use SSE instructions (http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions) alongside OSG to obtain speed improvements through parallelising math operations. The general point that has been raised is that under-the-hood, OSG does quite a lot that could benefit from the potential performance boost given by SSE operations. Obvious targets include some of the Vec/Matrix routines, for example. SSE is now sufficiently mainstream that the risk of processor incompatibility is felt to be low. Question 1 : Where could the core OSG include SSE? Most people follow the sensible approach of profiling to determine their bottlenecks, and then optimising particular methods in order to gain speed-up. This would be a sensible approach to follow, as SSEing all methods would probably be a waste of effort. It would therefore be instructive firstly to know if anybody is using SSE with OSG, and where. Secondly, for those who have profiling data and know how much time they spend in Vec/Matrix/whatever methods, it would be useful to know which methods the community considered good targets for SSEing. Any other maths heavy lifting going on? (e.g. Intersection testing? Delauney triangulation? etc.) Question 2 : How could the core OSG include SSE? SSE code benefits from aligned data. Hence there are several ways in which OSG could include SSE: a) Provide an aligned Vec4f and aligned Matrix4f class, which support SSE operations. This would appear (to me) to be the least intrusive. b) Provide branching code within the existing Vec4/Matrix4 methods for detecting whether data is aligned, and performing the correct operations. This would appear to me to be the most user-transparent. Although it would appear to be a performance hit, testing so far on some specific code would support the argument that the speed gains from SSE outweigh the branch cost; more testing needed, I guess. c) Robert suggested that SSE enabled array operators (e.g. providing a cross-product operator for Vec3Array) might be appropriate and provide the best speed improvement for those who want it. Certainly using SSE on large array type data sets is where one gains the most performance improvement. This question includes the possibility of linking out to, or pulling source code our of, an external optimised math library. Any other suggestions? Question 3 : (possibly the biggest) Should the core OSG include SSE? There are several downsides to including SSE. Firstly, x-platform provision of SSE may be tricky due to the way different compilers define aligned data, and how SSE instructions are used within the code. I personally don't have much experience here, so any feedback on x-plaform issues is useful. Secondly, the code readability drops, and the use the source argument may be trickier when many might not know much SSE. So - your opinion, experience and suggestions welcome! David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
Am Dienstag, 29. Juli 2008 14:04:59 schrieb David Spilling: Dear All, [...] Any other suggestions? *Question 3 : (possibly the biggest) Should the core OSG include SSE?* There are several downsides to including SSE. Firstly, x-platform provision of SSE may be tricky due to the way different compilers define aligned data, and how SSE instructions are used within the code. I personally don't have much experience here, so any feedback on x-plaform issues is useful. Secondly, the code readability drops, and the use the source argument may be trickier when many might not know much SSE. Hello David, may I suggest that you check the assembler code that the compilers create when compiling the OSG code? I have not done it for the OSG code, but for another project I have done some time ago. There I tried to optimize the performance for composing depth-buffer attached images for sort-last rendering. Somehow I was not able to be much better than the compiler was. In some rare cases my procedures were faster, but most of the time the compiler was the winner. The code created by the compilers consider so many things - e. g. branch prediction by the processer, code reordering - that it is quite hard for a human programmer to beat them. For example if you use g++ with -march=core2 -O3 (see man page for description of parameters) the compiler automatically uses SSE or even SSE2, 3dNOW!, etc. instructions. In some cases the compiler generates much better assembler code than a normal programmer would do. There are some case though were manual improvements could yield better results. I heard that the Intel C++ compiler is able to optimize even better. Furthermore the use of profiling first is a good approach. Maybe it would be reasonable to compare profiling data of the Math/Vector/Matrix classes with and without compiler optimizations and see if some bottlenecks disappear when using the optimizations. Regards, Benjamin So - your opinion, experience and suggestions welcome! David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow techniques status
Hello Dan, I'm looking at shadow techniques provided by the osgshadow nodekit for use in a production project. On the wiki it reads like only ShadowMap is production ready and all the others have problems. Is this the case? Or have the others been marked as experimental because they do not work across video cards? Here is my opinion on the current shadow techniques in osgShadow. Please take these with a grain of salt. And bare in mind that it's pretty easy to compare them yourself in your environment, because in most cases once you have one shadow technique running you can just swap out the ShadowTechnique that you give to your ShadowedScene for another one. Some tweaks are technique-specific but that will give you a good idea of what they look like in your context. osgShadow::ShadowVolume is broken, I have never seen it work correctly even with simple test scenes. There are inverted shadows everywhere (which hints at a problem with the z-pass or z-fail implementation). If someone wants to fix it, it would be a nice alternative to other techniques in some situations. osgShadow::ShadowTexture is the simplest technique. It works well for planar shadows, but for anything more complex you'll want at least osgShadow::ShadowMap. osgShadow::ShadowMap is what I would call the main workforce of osgShadow at the moment. It works well, is well tested, and is flexible. The only downside is the heavy shadow map aliasing you get on medium to large environments, but this is to be expected from a simple technique like this. It's really just the basic shadow map, no bells or whistles. osgShadow::SoftShadowMap is ShadowMap augmented with a simple filtering of shadows. The look is not too realistic (it smooths everywhere uniformly instead of considering distance of occluder for the width of the penumbra, which would be more complex of course) but it alleviates the aliasing problem somewhat. It can still only go so far if the environments are large. osgShadow::ParallelSplitShadowMap is the first of the next-gen shadow mapping techniques integrated into OSG. Essentially, it uses several shadow maps and is view-dependent which reduces aliasing dramatically. It's less tested, and until recently was completely broken. It now should work on most machines, but I'm still not confident enough about it to use it in production (my personal opinion - try it out and see for yourself). A few more techniques will soon be added (shortly after 2.6, hopefully) which are also view dependent, and will give some more choices to users. Essentially a shadow technique is a tool, and you just have to find the right one for your needs. If the wiki misrepresents this state of affairs, could you please update it or post the pages where there is outdated info here? Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
Am Dienstag, 29. Juli 2008 14:28:18 schrieb Benjamin Eikel: Am Dienstag, 29. Juli 2008 14:04:59 schrieb David Spilling: Dear All, [...] Any other suggestions? *Question 3 : (possibly the biggest) Should the core OSG include SSE?* There are several downsides to including SSE. Firstly, x-platform provision of SSE may be tricky due to the way different compilers define aligned data, and how SSE instructions are used within the code. I personally don't have much experience here, so any feedback on x-plaform issues is useful. Secondly, the code readability drops, and the use the source argument may be trickier when many might not know much SSE. Hello David, may I suggest that you check the assembler code that the compilers create when compiling the OSG code? I have not done it for the OSG code, but for another project I have done some time ago. There I tried to optimize the performance for composing depth-buffer attached images for sort-last rendering. Somehow I was not able to be much better than the compiler was. In some rare cases my procedures were faster, but most of the time the compiler was the winner. The code created by the compilers consider so many things - e. g. branch prediction by the processer, code reordering - that it is quite hard for a human programmer to beat them. For example if you use g++ with -march=core2 -O3 (see man page for description of parameters) the compiler automatically uses SSE or even SSE2, 3dNOW!, etc. instructions. In some cases the compiler generates much better assembler code than a normal programmer would do. There are some case though were manual improvements could yield better results. I heard that the Intel C++ compiler is able to optimize even better. Furthermore the use of profiling first is a good approach. Maybe it would be reasonable to compare profiling data of the Math/Vector/Matrix classes with and without compiler optimizations and see if some bottlenecks disappear when using the optimizations. Regards, Benjamin Hello, I have an addition: With gcc/g++ you can use profiling (option -fprofile-generate) to help the compiler to do better optimizations (option -fprofile-use, e. g. loop unrolling). Maybe this can improve the performance further. If you want performance and sacrifice safety and precision for it, you may even think about -ffast-math (may be dangerous). The options are explained on the gcc/g++ man page or in the online manual [1]. There may be similar options for other compilers. And please do not get me wrong. I do not want to stop your efforts to improve the performance of OSG; far from it! But putting assembler code into the project decrease the readability and serviceability of the code. Furthermore it might be that it does not improve the speed at all. I just want to suggest that you try to exhaust the possibility of modern compilers as much as possible. If you see any bottlenecks after that, it might make sense to include manual performance tuning. Regards, Benjamin [1] http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Optimize-Options.html#Optimize-Options So - your opinion, experience and suggestions welcome! David ___ 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] Texturing issues second window
We are seeing the texture problem in the additional windows for simple objects, ones that are not using paged LOD. It definitely seems to be related to the contexts but can't find the right settings to get it to work. What is strange is that, like I mentioned before, if we create the sphere and texture it internally, it works fine. But if I load a sphere with a texture on it, it will have problems in the second/third windows, giving the invalid enumerant error. Thanks again. Scott On Mon, 2008-07-28 at 16:38 +0200, Serge Lages wrote: Hi Scott, Have you setted the pager to not unref images after applying them ? When you have multiple contexts, you have to make sure images are not deleted before each context has applied it. On Mon, Jul 28, 2008 at 4:12 PM, Scott Angster [EMAIL PROTECTED] wrote: Hello- We are seeing an interesting problem that we can not track down. Several previous postings have been similar but not quite what we are seeing. We are hoping someone can point us in a possible direction to find a solution. We have an OSG/QT application using multiple windows with views into the same scene graph. We use multiple instances of the Viewer to do this. We are seeing issues in the second/third/etc window for models loaded in containing textures. The textures do not load and we get Warning: detected OpenGL error 'invalid enumerant' after applying attribute Texture2D when the second window is opened. However if we create an object at runtime, say a sphere, and apply a texture to it, the second/third/etc window do not have problems with it. If we save out the node we created to an IVE file and reload it, the problem is there. I have tried to duplicate this problem using the osgviewer QT example such that I have a simpler code base to work with, and I can't. I have made this example more complex, adding features to it to replicate our code (HUD, textured background, our update loop for updating dynamic transform nodes and camera positioning, our state settings, thread settings, etc). We seem to have an issue with PagedLOD too in our application for the second/third windows. I hope this issue is related so if we focus on the texture problem, maybe the other will be solved. We are using OSG 2.4 and currently QT 3.3 (hope to be moving to 4.X soon). We are seeing this on both our Linux and Windows machines. Thanks for any suggestions or insight into this. Scott ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
Benjamin, may I suggest that you check the assembler code that the compilers create when compiling the OSG code? ... g++ with -march=core2 -O3 (see man page for description of parameters) the compiler automatically uses SSE I don't have much recent Linux/gcc experience, but can certainly attest that the MS compilers don't do a good job of spotting SSE vectorisation possibilities, even when you tell them to optimise with them (and this is from reading the generated ssembler). In MS you can insert SSE intrinsics , which still allow the compiler to optimise the execution order and memory/register usage e.g. based on cycle counts. I understand (from other sources) that the Intel vectorising compilers are much better at this, naturally. Perhaps this is then all only aMS/Windows thing? David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow techniques status
2008/7/29 Jean-Sébastien Guay [EMAIL PROTECTED] Hello Dan, I'm looking at shadow techniques provided by the osgshadow nodekit for use in a production project. On the wiki it reads like only ShadowMap is production ready and all the others have problems. Is this the case? Or have the others been marked as experimental because they do not work across video cards? Here is my opinion on the current shadow techniques in osgShadow. Please take these with a grain of salt. And bare in mind that it's pretty easy to compare them yourself in your environment, because in most cases once you have one shadow technique running you can just swap out the ShadowTechnique that you give to your ShadowedScene for another one. Some tweaks are technique-specific but that will give you a good idea of what they look like in your context. osgShadow::ShadowVolume is broken, I have never seen it work correctly even with simple test scenes. There are inverted shadows everywhere (which hints at a problem with the z-pass or z-fail implementation). If someone wants to fix it, it would be a nice alternative to other techniques in some situations. osgShadow::ShadowTexture is the simplest technique. It works well for planar shadows, but for anything more complex you'll want at least osgShadow::ShadowMap. osgShadow::ShadowMap is what I would call the main workforce of osgShadow at the moment. It works well, is well tested, and is flexible. The only downside is the heavy shadow map aliasing you get on medium to large environments, but this is to be expected from a simple technique like this. It's really just the basic shadow map, no bells or whistles. osgShadow::SoftShadowMap is ShadowMap augmented with a simple filtering of shadows. The look is not too realistic (it smooths everywhere uniformly instead of considering distance of occluder for the width of the penumbra, which would be more complex of course) but it alleviates the aliasing problem somewhat. It can still only go so far if the environments are large. osgShadow::ParallelSplitShadowMap is the first of the next-gen shadow mapping techniques integrated into OSG. Essentially, it uses several shadow maps and is view-dependent which reduces aliasing dramatically. It's less tested, and until recently was completely broken. It now should work on most machines, but I'm still not confident enough about it to use it in production (my personal opinion - try it out and see for yourself). Parallel Split Shadow Map: it's still under *beta* release :-) i wait for a review by a specialist, ... please review, test this algorithme, for terrain, ... it's once of the most robust algorithm, but it has to be tested. *** A few more techniques will soon be added (shortly after 2.6, hopefully) which are also view dependent, and will give some more choices to users. Essentially a shadow technique is a tool, and you just have to find the right one for your needs. If the wiki misrepresents this state of affairs, could you please update it or post the pages where there is outdated info here? Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
I heard that the Intel C++ compiler is able to optimize even better. Furthermore the use of profiling first is a good approach. Maybe it would be reasonable to compare profiling data of the Math/Vector/Matrix classes with and without compiler optimizations and see if some bottlenecks disappear when using the optimizations. I 100% agree with that as that is the first thing I did. For the matrixf mult I got 50% improvement with aligned data and 35% with unaligned. For the Invert4x4 I got 80% improvement with aligned and 70% aligned with unaligned. I've submitted this code in as it was the most time spent in the profiles of our game. While I am here I think whatever we do we should have CMake have an option to compile using SSE, and provide alternative c code for those who do not want it. Actually, one of the techniques we use at work we handled the case during when SSE2 was only available to some machines, where we wrote the main loop to do the bulk of the work and the remainder loop do finish the work in c code. We could then macro out the main loop for those who didn't have SSE2 as it fell to the remainder code which then did the entire loop. I believe the time has passed to make SSE and SSE2 distinction, so either someone can support SSE2, or they use the c code version. It should be implied that people who write SSE/SSE2 have tested against the c code and have seen a significant gain in performance before considering to use. James Killian - Original Message - From: Benjamin Eikel [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, July 29, 2008 7:28 AM Subject: Re: [osg-users] Using SSE within OSG Am Dienstag, 29. Juli 2008 14:04:59 schrieb David Spilling: Dear All, [...] Any other suggestions? *Question 3 : (possibly the biggest) Should the core OSG include SSE?* There are several downsides to including SSE. Firstly, x-platform provision of SSE may be tricky due to the way different compilers define aligned data, and how SSE instructions are used within the code. I personally don't have much experience here, so any feedback on x-plaform issues is useful. Secondly, the code readability drops, and the use the source argument may be trickier when many might not know much SSE. Hello David, may I suggest that you check the assembler code that the compilers create when compiling the OSG code? I have not done it for the OSG code, but for another project I have done some time ago. There I tried to optimize the performance for composing depth-buffer attached images for sort-last rendering. Somehow I was not able to be much better than the compiler was. In some rare cases my procedures were faster, but most of the time the compiler was the winner. The code created by the compilers consider so many things - e. g. branch prediction by the processer, code reordering - that it is quite hard for a human programmer to beat them. For example if you use g++ with -march=core2 -O3 (see man page for description of parameters) the compiler automatically uses SSE or even SSE2, 3dNOW!, etc. instructions. In some cases the compiler generates much better assembler code than a normal programmer would do. There are some case though were manual improvements could yield better results. I heard that the Intel C++ compiler is able to optimize even better. Furthermore the use of profiling first is a good approach. Maybe it would be reasonable to compare profiling data of the Math/Vector/Matrix classes with and without compiler optimizations and see if some bottlenecks disappear when using the optimizations. Regards, Benjamin So - your opinion, experience and suggestions welcome! David ___ 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] Using SSE within OSG
Benjamin, And please do not get me wrong. I do not want to stop your efforts to improve the performance of OSG; far from it! Not necessarily my efforts - I'm just being the messenger...! But putting assembler code into the project decrease the readability and serviceability of the code. Absolutely. Furthermore it might be that it does not improve the speed at all. I agree, and this is an oft quoted issue. Here, I think, only testing (and experience) will help. For example, is it worth performing a single Vec3f cross product in SSE? Probably not. But as a counter example, over on osg-submissions (EDIT - and now here), one user (James) is getting large performance gains from having SSE'd the invert_4x4 function. I just want to suggest that you try to exhaust the possibility of modern compilers as much as possible. If you see any bottlenecks after that, it might make sense to include manual performance tuning. I agree. This call-for-ideas was motivated by an understanding that several people are pushing in the same direction, and it would be perhaps beneficial to make use of this push. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
MS does a very poor job, I know most of our SSE is asm'ed _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Spilling Sent: Tuesday, July 29, 2008 9:11 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Using SSE within OSG Benjamin, may I suggest that you check the assembler code that the compilers create when compiling the OSG code? ... g++ with -march=core2 -O3 (see man page for description of parameters) the compiler automatically uses SSE I don't have much recent Linux/gcc experience, but can certainly attest that the MS compilers don't do a good job of spotting SSE vectorisation possibilities, even when you tell them to optimise with them (and this is from reading the generated ssembler). In MS you can insert SSE intrinsics , which still allow the compiler to optimise the execution order and memory/register usage e.g. based on cycle counts. I understand (from other sources) that the Intel vectorising compilers are much better at this, naturally. Perhaps this is then all only aMS/Windows thing? David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow techniques status
Hello Adrian, Parallel Split Shadow Map: it's still under *beta* release :-) i wait for a review by a specialist, ... please review, test this algorithme, for terrain, ... it's once of the most robust algorithm, but it has to be tested. I knew any talk about PSSM would get a reply from you :-) I was not criticizing your work. Please don't take it so personally. I only gave my opinion of the current state of things. As for review, someone will need to have the knowledge of the algorithm to be able to review it, and that isn't my case personally... It's a very specialized and low-level thing to be able to review this kind of code. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
Hi, On Tuesday 29 July 2008 15:18, James Killian wrote: I 100% agree with that as that is the first thing I did. For the matrixf mult I got 50% improvement with aligned data and 35% with unaligned. For the Invert4x4 I got 80% improvement with aligned and 70% aligned with unaligned. I've submitted this code in as it was the most time spent in the profiles of our game. I wonder what your scenegraph looks like. Why do you have that much matrix operations? Where are they called from? Why do you need that many inverted matrices? Also the invert method makes me wonder. As far as I can tell, you do not need inverted matrices to do cull and draw. At least not in a magnitude that makes that method appear in profiles. Do you compute intersection tests where you need that inverse? And what kind of matrices are in your code that you really need the full 4x4 inverse? Almost alway the cheaper 3x4 variant can be used for usual transforms. Well, I ask that because I get the impression that the real botteneck - where you can gain much performance - is somwhere different. 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 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder 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] Using SSE within OSG
Paul asked me the same question a few days ago, and I just realized that we took that offline so I'll repost here: One of the things I should add is the actual profile dump, since that shows a more comprehensive picture. The actual game demo is free to download and play here: http://www.fringe-online.com/ The current installer of the game does not have my optimization in it yet, but it should be noted even with the optimization the postmult is still at the top. The Invert4x4() however got pushed way down to the bottom (which is great). I'll post my profiles when I get home. -snip--- --- That is a good question, and I believe the answer is collision detection. I should disable it and run the numbers again to confirm. All ships fire machine guns at a fast rate, and each bullet that gets close enough to a bounding box/sphere region has to go through the osg code to get the precise point where it hit. Rick would probably have a better explanation of this and other factors since he coded the bulk of the collision detection (and osg integration). Most of my time development in the game has been spent on the physics and flight dynamics (and now optimization). It may turn out that we could find some caching technique to reduce the collision stress (like the KBDtree), but in the mean time, matrix optimizations can benefit the whole community if we do them right, and I would like to make some contribution to the community. - Original Message - From: Paul Melis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 28, 2008 9:05 AM Subject: [Fwd: Re: [osg-users] [osg-submissions] Matrixf multiply Optimization] Hi James, I noted you posts on the osg-users list on the Matrix multiplication optimizations using SSE. You mention Our game uses approximately 25% of all processing to these functions [...]. What on earth takes up so much matrix computing time in your game? Regards, Paul -snip--- --- - Original Message - From: Mathias Fröhlich [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, July 29, 2008 9:31 AM Subject: Re: [osg-users] Using SSE within OSG Hi, On Tuesday 29 July 2008 15:18, James Killian wrote: I 100% agree with that as that is the first thing I did. For the matrixf mult I got 50% improvement with aligned data and 35% with unaligned. For the Invert4x4 I got 80% improvement with aligned and 70% aligned with unaligned. I've submitted this code in as it was the most time spent in the profiles of our game. I wonder what your scenegraph looks like. Why do you have that much matrix operations? Where are they called from? Why do you need that many inverted matrices? Also the invert method makes me wonder. As far as I can tell, you do not need inverted matrices to do cull and draw. At least not in a magnitude that makes that method appear in profiles. Do you compute intersection tests where you need that inverse? And what kind of matrices are in your code that you really need the full 4x4 inverse? Almost alway the cheaper 3x4 variant can be used for usual transforms. Well, I ask that because I get the impression that the real botteneck - where you can gain much performance - is somwhere different. 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 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
Hi All, Regarding question 2: Wouldn't it be possible to dynamically link different versions of the OSG-DLLs? So there would be two Version of the DLLs, one with the SSE-Optimizations and one with the straightforward code. I've seen examples of games some years ago, where they linked different Versions of DLLs depending on the machine the program was run on. cheers Sebastian Dear All, There's a discussion going on at the moment over in osg-submissions, and it has been raised that this ought to be opened up to the non-submissions community for feedback. Note that the following is my reading of the issues, and certainly doesn't represent the consensus view of the osg-submissions crowd, so feel free to challenge what I'm saying! *Background* Several people already use SSE instructions (http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions) alongside OSG to obtain speed improvements through parallelising math operations. The general point that has been raised is that under-the-hood, OSG does quite a lot that could benefit from the potential performance boost given by SSE operations. Obvious targets include some of the Vec/Matrix routines, for example. SSE is now sufficiently mainstream that the risk of processor incompatibility is felt to be low. *Question 1 : Where could the core OSG include SSE?* Most people follow the sensible approach of profiling to determine their bottlenecks, and then optimising particular methods in order to gain speed-up. This would be a sensible approach to follow, as SSEing all methods would probably be a waste of effort. It would therefore be instructive firstly to know if anybody is using SSE with OSG, and where. Secondly, for those who have profiling data and know how much time they spend in Vec/Matrix/whatever methods, it would be useful to know which methods the community considered good targets for SSEing. Any other maths heavy lifting going on? (e.g. Intersection testing? Delauney triangulation? etc.) *Question 2 : How could the core OSG include SSE?* SSE code benefits from aligned data. Hence there are several ways in which OSG could include SSE: a) Provide an aligned Vec4f and aligned Matrix4f class, which support SSE operations. This would appear (to me) to be the least intrusive. b) Provide branching code within the existing Vec4/Matrix4 methods for detecting whether data is aligned, and performing the correct operations. This would appear to me to be the most user-transparent. Although it would appear to be a performance hit, testing so far on some specific code would support the argument that the speed gains from SSE outweigh the branch cost; more testing needed, I guess. c) Robert suggested that SSE enabled array operators (e.g. providing a cross-product operator for Vec3Array) might be appropriate and provide the best speed improvement for those who want it. Certainly using SSE on large array type data sets is where one gains the most performance improvement. This question includes the possibility of linking out to, or pulling source code our of, an external optimised math library. Any other suggestions? *Question 3 : (possibly the biggest) Should the core OSG include SSE?* There are several downsides to including SSE. Firstly, x-platform provision of SSE may be tricky due to the way different compilers define aligned data, and how SSE instructions are used within the code. I personally don't have much experience here, so any feedback on x-plaform issues is useful. Secondly, the code readability drops, and the use the source argument may be trickier when many might not know much SSE. So - your opinion, experience and suggestions welcome! David ___ 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] Using SSE within OSG
I have to disagree, using VS 7 and up to VS 9. It has done a terrific job with the instruction scheduling. We use to use that technique of asm back when P3's MMX were around and we had VS 6. We had one engineer who would use DOS and MASM. Times have changed (we had to let him go), intrinsics have proved to optimize quite well as we use the AMD code analyzer to confirm that the U and V pipes remain full due to well scheduled placement of the instructions. I should add that we avoid using any MMX instructions like the plague now days. - Original Message - From: Gordon Tomlinson [EMAIL PROTECTED] To: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Sent: Tuesday, July 29, 2008 8:56 AM Subject: Re: [osg-users] Using SSE within OSG MS does a very poor job, I know most of our SSE is asm'ed _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Spilling Sent: Tuesday, July 29, 2008 9:11 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Using SSE within OSG Benjamin, may I suggest that you check the assembler code that the compilers create when compiling the OSG code? ... g++ with -march=core2 -O3 (see man page for description of parameters) the compiler automatically uses SSE I don't have much recent Linux/gcc experience, but can certainly attest that the MS compilers don't do a good job of spotting SSE vectorisation possibilities, even when you tell them to optimise with them (and this is from reading the generated ssembler). In MS you can insert SSE intrinsics , which still allow the compiler to optimise the execution order and memory/register usage e.g. based on cycle counts. I understand (from other sources) that the Intel vectorising compilers are much better at this, naturally. Perhaps this is then all only aMS/Windows thing? David ___ 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] Using SSE within OSG
James, On Tuesday 29 July 2008 16:59, James Killian wrote: Paul asked me the same question a few days ago, and I just realized that we took that offline so I'll repost here: One of the things I should add is the actual profile dump, since that shows a more comprehensive picture. The actual game demo is free to download and play here: http://www.fringe-online.com/ The current installer of the game does not have my optimization in it yet, but it should be noted even with the optimization the postmult is still at the top. The Invert4x4() however got pushed way down to the bottom (which is great). I'll post my profiles when I get home. -snip-- - --- That is a good question, and I believe the answer is collision detection. I should disable it and run the numbers again to confirm. All ships fire machine guns at a fast rate, and each bullet that gets close enough to a bounding box/sphere region has to go through the osg code to get the precise point where it hit. Rick would probably have a better explanation of this and other factors since he coded the bulk of the collision detection (and osg integration). Most of my time development in the game has been spent on the physics and flight dynamics (and now optimization). It may turn out that we could find some caching technique to reduce the collision stress (like the KBDtree), but in the mean time, matrix optimizations can benefit the whole community if we do them right, and I would like to make some contribution to the community. Ok, you can do here much for the collision detection. I expect that you should optimize that algorithmically and gain magnitudes without sse. So the question is more if such optimizations will bring performance improovements for the usual scenegraph case. 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 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder 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] Using SSE within OSG
James, I have to disagree, using VS 7 and up to VS 9. Just to clarify - what are you disagreeing with? Do you find that MS compilers will produce SSE vectorised code _without_ use of intrinsics or raw __asm? David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] somewhat off-topic: sources of real-world lidar point cloud data?
I've been looking around for non-topographic lidar data, does anyone here know of any sources? Radiohead's House of Cards data is very interesting to visualize with and a great resource for students and hobbyists, and I'd like to get access to more. Data derived from or applicable to mobile robotics would be particularly useful. I've had some luck getting sample data from lidar manufacturers, but very little with google. Thanks, Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] The problem disappeared! (problem with osgUtil::LineSegmentIntersector) Make it please in the next version.
I decided my issue. I removed the code from the file. (as was the case
previously in 2.5.2). The problem disappeared! Make it please in the next
version.
LineSegmentIntersector.cpp
removed the code from the file: line 290 ..
double epsilon = 1e-8;
if ((s-e).length()epsilon)
{
osg::Vec3d delta_e_end = _end - e;
osg::Vec3d delta_s_start = _start - s;
double scale = 0.001;
s += (delta_s_start * scale);
e += (delta_e_end * scale);
}
code version 2.5.2:
s = _start;
e = _end;
The problem disappeared! Make it please in the next version.
28.07.08, 22:44, GMD GammerMaxyandex.ru [EMAIL PROTECTED]:
Here is the small example, where described problem appeares. Example is
modified example of osgpick (chenged code which returns name of object and osg
scene). To see this problem you must go in the deep of room (way is showen in
00.jpeg). Then you need make several clicks in different positions (movements
bitween positions must be small) and you will see that cursor often falls
throught the object over which cursor is (possible positions is showen on
11.jpg). There is two archives in attachement (with textures and without them).
Code is in osgpick.zip file which taken from example osgpick. I hope this is
enough to illustrate described problem. And I think it will be not good if this
error appeares in this release (2.6.0).
Thanks, Max.
files:
(download: enter number, click green button)
http://narod.ru/disk/171128/osgpick.zip.html
http://narod.ru/disk/1711073000/00.JPG.html
http://narod.ru/disk/1711279000/11.JPG.html
http://narod.ru/disk/1712663000/museum_with_textures.zip.html
Thanks, Max.
28.07.08, 10:47, GMD GammerMaxyandex.ru [EMAIL PROTECTED]:
Ok, I'll make small example and show where problem occures. I'll try do
this today.
28.07.08, 00:33, sherman wilcox [EMAIL PROTECTED]:
Can you make a small and simple prototype that *reliably* reproduces
the problem? You have a better chance of getting help that way.
On Sun, Jul 27, 2008 at 2:50 AM, GMD GammerMaxyandex.ru
[EMAIL PROTECTED] wrote:
Some offers of OSG 2.6.0( problems with new version).
Let's wait with OSG 2.6.0 release. I asked this because I found a
problem with osgUtil::LineSegmentIntersector function.
In OSG v 2.5.5 version of OSG function
viewer-computeIntersections(x,y, hlist) works very strange - when cursor
movements over object is short it(cursor) falls throught the object and
function returns name of object which is behind current(object over which
cursor is). In earlyer(less 2.5.2) versions of OSG this error has never
appeared. How can I solve this problem in this(2.5.5) version of OSG?
It is necessary to solve the problem until OSG 2.6.0 release.
Thanks in advance. Best regards, Max.
___
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
--
Яндекс.Открытки на все случаи жизни http://cards.yandex.ru/
___
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] The problem disappeared! (problem withosgUtil::LineSegmentIntersector) Make it please in the next version.
You'll need to post a changed copy of the entire file to osg-submissions.
-Paul
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of GMD GammerMaxyandex.ru
Sent: Tuesday, July 29, 2008 12:18 PM
To: osg-users@lists.openscenegraph.org; Robert Osfield
Subject: [osg-users] The problem disappeared! (problem
withosgUtil::LineSegmentIntersector) Make it please in the
next version.
I decided my issue. I removed the code from the file. (as was
the case previously in 2.5.2). The problem disappeared! Make
it please in the next version.
LineSegmentIntersector.cpp
removed the code from the file: line 290 ..
double epsilon = 1e-8;
if ((s-e).length()epsilon)
{
osg::Vec3d delta_e_end = _end - e;
osg::Vec3d delta_s_start = _start - s;
double scale = 0.001;
s += (delta_s_start * scale);
e += (delta_e_end * scale);
}
code version 2.5.2:
s = _start;
e = _end;
The problem disappeared! Make it please in the next version.
28.07.08, 22:44, GMD GammerMaxyandex.ru [EMAIL PROTECTED]:
Here is the small example, where described problem
appeares. Example is modified example of osgpick (chenged
code which returns name of object and osg scene). To see this
problem you must go in the deep of room (way is showen in
00.jpeg). Then you need make several clicks in different
positions (movements bitween positions must be small) and you
will see that cursor often falls throught the object over
which cursor is (possible positions is showen on 11.jpg).
There is two archives in attachement (with textures and
without them). Code is in osgpick.zip file which taken from
example osgpick. I hope this is enough to illustrate
described problem. And I think it will be not good if this
error appeares in this release (2.6.0).
Thanks, Max.
files:
(download: enter number, click green button)
http://narod.ru/disk/171128/osgpick.zip.html
http://narod.ru/disk/1711073000/00.JPG.html
http://narod.ru/disk/1711279000/11.JPG.html
http://narod.ru/disk/1712663000/museum_with_textures.zip.html
Thanks, Max.
28.07.08, 10:47, GMD GammerMaxyandex.ru [EMAIL PROTECTED]:
Ok, I'll make small example and show where problem
occures. I'll try do this today.
28.07.08, 00:33, sherman wilcox [EMAIL PROTECTED]:
Can you make a small and simple prototype that
*reliably* reproduces
the problem? You have a better chance of getting
help that way.
On Sun, Jul 27, 2008 at 2:50 AM, GMD GammerMaxyandex.ru
[EMAIL PROTECTED] wrote:
Some offers of OSG 2.6.0( problems with new version).
Let's wait with OSG 2.6.0 release. I asked this
because I found a problem with
osgUtil::LineSegmentIntersector function.
In OSG v 2.5.5 version of OSG function
viewer-computeIntersections(x,y, hlist) works very strange -
when cursor movements over object is short it(cursor) falls
throught the object and function returns name of object which
is behind current(object over which cursor is). In
earlyer(less 2.5.2) versions of OSG this error has never
appeared. How can I solve this problem in this(2.5.5) version of OSG?
It is necessary to solve the problem until OSG
2.6.0 release.
Thanks in advance. Best regards, Max.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org
--
Яндекс.Открытки на все случаи жизни http://cards.yandex.ru/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
HI I can only go buy our low level masters and their profiling shows that the hand road asm'ed SSE code is significantly fasted than MS VS compiled code Obviously this our experience in our environments and we computationally heavily and moving and editing terra-bytes of data around in real-time -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Killian Sent: Tuesday, July 29, 2008 11:38 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Using SSE within OSG Sorry... I interpreted Gordon's response as follows: MS does a poor job (insert here with compiling SSE intrinsics), as a result most of his SSE is asm'ed. The asm'ed approach is where you don't trust the compiler to do the right thing with intrinsics, where it has the flexibility of scheduling and assigning registers etc. I disagree with MS does a poor job compiling intrinsic code, and that you should not *ever need to resort to __asm anymore. *this is not absolute, there was once a rare case where we found a strange anomaly, but later solved by doing an un-intuitive c code change Do you find that MS compilers will produce SSE vectorised code _without_ use of intrinsics or raw __asm? Ah this is a tricky question. There is in fact an option in VS 8 and VS 9 project settings to generate SSE or SSE2 code. What this does is that it will evaluate c code and try to use SSE for it. I was surprised to find that this actually lowered the performance of c code, especially c code for matrixf. I'm so glad that the project settings for osg do not turn this on, and I'd recommend not using that, but instead write intrisics ourselves for places that need it. I hope this clears things up. - Original Message - From: David Spilling [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, July 29, 2008 10:17 AM Subject: Re: [osg-users] Using SSE within OSG James, I have to disagree, using VS 7 and up to VS 9. Just to clarify - what are you disagreeing with? Do you find that MS compilers will produce SSE vectorised code _without_ use of intrinsics or raw __asm? David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using SSE within OSG
Thanks for the reply. We could resolve this argument if any one of the low level masters cares to email me offline [EMAIL PROTECTED], but I'd be open to believe an argument could be made for the context of moving around large amounts of data. In regards to moving data, SSE/SSE2 is really better suited for code which requires a lot of math like 3d computations. Perhaps the heart of SSE would be the packed multiply and add, where it can do 4 multiplies and 4 adds in one clock cycle (or a half cycle if paired properly). Thus, code which requires heavy math like many of the OSG matrix computations could really benefit from it. I would profile cases like this against hand written assembly since this is what OSG would care about. I looked at the assembly code produced by VS 9 for the optimized matrixf multiply, and I could not have scheduled it better myself by hand. - Original Message - From: Gordon Tomlinson [EMAIL PROTECTED] To: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Sent: Tuesday, July 29, 2008 2:58 PM Subject: Re: [osg-users] Using SSE within OSG HI I can only go buy our low level masters and their profiling shows that the hand road asm'ed SSE code is significantly fasted than MS VS compiled code Obviously this our experience in our environments and we computationally heavily and moving and editing terra-bytes of data around in real-time -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Killian Sent: Tuesday, July 29, 2008 11:38 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Using SSE within OSG Sorry... I interpreted Gordon's response as follows: MS does a poor job (insert here with compiling SSE intrinsics), as a result most of his SSE is asm'ed. The asm'ed approach is where you don't trust the compiler to do the right thing with intrinsics, where it has the flexibility of scheduling and assigning registers etc. I disagree with MS does a poor job compiling intrinsic code, and that you should not *ever need to resort to __asm anymore. *this is not absolute, there was once a rare case where we found a strange anomaly, but later solved by doing an un-intuitive c code change Do you find that MS compilers will produce SSE vectorised code _without_ use of intrinsics or raw __asm? Ah this is a tricky question. There is in fact an option in VS 8 and VS 9 project settings to generate SSE or SSE2 code. What this does is that it will evaluate c code and try to use SSE for it. I was surprised to find that this actually lowered the performance of c code, especially c code for matrixf. I'm so glad that the project settings for osg do not turn this on, and I'd recommend not using that, but instead write intrisics ourselves for places that need it. I hope this clears things up. - Original Message - From: David Spilling [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, July 29, 2008 10:17 AM Subject: Re: [osg-users] Using SSE within OSG James, I have to disagree, using VS 7 and up to VS 9. Just to clarify - what are you disagreeing with? Do you find that MS compilers will produce SSE vectorised code _without_ use of intrinsics or raw __asm? David -- -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow techniques status
ShadowMap does suffer from bad aliasing when the viewpoint is very near the shadow. The Orange book (GLSL shader) describes how to super-sample the depth buffer to mitigate aliasing. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] sky model tracking the camera...
Hello, I would like to have my sky model track the camera position so that as the camera moves, the sky model moves with it. To do this, would I add the sky model transform as a child of the cameraNode? Does anyone have any code snippets that may demonstrate how I might do this? Thanks in advance. -Shayne smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow techniques status
Thanks for the replies. I'll take a closer look at PSSM. Dan. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vpb on cluster example
I have another question for you JP. I have been playing with the osgdem tool and trying to create a terrain database with some aerial photos ( geotiffs ). After my database is generated using the command: Osgdem --geocentric --terrain -d DTED -t image.tif -l 4 -o test\test.ive I get something that looks about right except that the terrain around the image is blacked out. More area is blacked out when I'm viewing the higher layers. I'm attaching a small image so that you can see what I'm talking about. If you look near the top left corner of the black area you can barely make out my tiny little geotiff image. When I zoom out the black area becomes larger. When I zoom in it becomes smaller but never goes completely away. It seems that whichever tile ( I think that's the right term ) the image is located in is blacked out everywhere except where the image is. Is it not possible to use images that only cover a portion of your terrain or am I just missing some command line arguments or something? Thanks Greg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J.P. Delport Sent: Monday, July 28, 2008 11:49 PM To: OpenSceneGraph Users Subject: Re: [osg-users] vpb on cluster example Hi, Greg Myers wrote: Hi JP, I'm new and I'm a little fuzzy on the versioning between VPB and OSG. It looks like for the example you have provided, we need an older version (2.3.6) of OSG. Do you know if there are plans to upgrade VPB to work with the latest releases of OSG or am I totally missing something? Thanks for any info. Greg sorry, I should have made the versions I used more explicit. For the example I used OSG and VPB from svn around June. osgversion says 2.5.1. svn info gives: Revision: 8413 for OSG and Revision: 914 for VPB I'll add the info to the example page. regards jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org attachment: osg_test.JPG___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] render to texture - alpha blending
Hi guys - I'm using render to texture in one of my apps and I'm experiencing alpha blending issues. Here's what I have: simple RTT (render to texture) with two quads. Each quad has as a background an opaque black background (24-bit BMP). In front of that is a small (doesn't cover the entire background) 32-bit TGA with varying transparency. Here's the issue: on the portion of the quad that is covered by 32-bit TGA I can see right through. It appears as though OpenGL is doing what it's suppose to do - blending not only the RGB but also the alpha. For my blending function I'm using (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) - So, when this 32-bit TGA is blended against the opaque black background it's blending the alpha components as well which results in an overall decreased alpha value. Hence, that opaque black background is now semi-transparent. What I did to (hopefully) solve this is to premultiply the incoming fragments via a shader attached to each incoming node that is drawn into the RTT and use (GL_ONE, GL_ONE_MINUS_SRC_ALPHA) as my blending function for that node. Seems to solve it. At least now everything is blending the way I'd expect. The opaque parts are opaque and the semi-transparent are blending as expected against the opaque background, etc. My question is this: what other method might I employ to deal with these alpha blending issues? How do you guys recommend handling this? What's the recommend route to take? attachment: Untitled.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadow techniques status
No, i have no problem with the PSSM and all of the discussion about it. but i would like to pass the pssm through a review, because i am not computer graphics specialist, i am more computer vision guy. :-) this is the only raison why i am answering all of the emails people asking for enhanced shadow techniques, may there will be once a guy helping me in bug fixing the whole pssm shadow and others shadow techniques. i guess there are still some bugs inside. /adrian 2008/7/29 Jean-Sébastien Guay [EMAIL PROTECTED] Hello Adrian, Parallel Split Shadow Map: it's still under *beta* release :-) i wait for a review by a specialist, ... please review, test this algorithme, for terrain, ... it's once of the most robust algorithm, but it has to be tested. I knew any talk about PSSM would get a reply from you :-) I was not criticizing your work. Please don't take it so personally. I only gave my opinion of the current state of things. As for review, someone will need to have the knowledge of the algorithm to be able to review it, and that isn't my case personally... It's a very specialized and low-level thing to be able to review this kind of code. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] sky model tracking the camera...
Hi Shayne,
Add your sky node where-ever you want it in your scene-graph (not as child of
camera). Override the sky's transform node's traverse function and do something
like this:
void yourNode::traverse( osg::NodeVisitor nv )
{
switch( nv.getVisitorType() )
{
case osg::NodeVisitor::CULL_VISITOR:
setPosition( nv.getEyePoint() );
break;
}
}
Your node will be set to the camera position on each cull-traverse. It will
therefore work properly nomatter how many camera or render passes you add to
your scene.
Hope it helps,
Viggo
Date: Tue, 29 Jul 2008 18:14:25 -0600From: [EMAIL PROTECTED]: [EMAIL
PROTECTED]: [osg-users] sky model tracking the camera...
Hello,
I would like to have my sky model track the camera position so that as the
camera moves, the sky model moves with it. To do this, would I add the sky
model transform as a child of the cameraNode? Does anyone have any code
snippets that may demonstrate how I might do this?
Thanks in advance…
-Shayne
_
Hold kontakten med Windows Live Messenger.
http://clk.atdmt.com/GBL/go/msnnkdre001003gbl/direct/01/___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] sky model tracking the camera...
Forgot one thing...
At end of traverse function:
osg::Group::traverse( nv );
My sky is a osg::Group which hold a pointer to the postionTransfor object, so I
am therefore calling osg::Group::traverse and not something else :-)
Viggo
From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Wed, 30 Jul 2008 07:56:01
+0200Subject: Re: [osg-users] sky model tracking the camera...
Hi Shayne, Add your sky node where-ever you want it in your scene-graph (not as
child of camera). Override the sky's transform node's traverse function and do
something like this: void yourNode::traverse( osg::NodeVisitor nv ){
switch( nv.getVisitorType() ){case osg::NodeVisitor::CULL_VISITOR:
setPosition( nv.getEyePoint() );break;}} Your node will be set to
the camera position on each cull-traverse. It will therefore work properly
nomatter how many camera or render passes you add to your scene. Hope it
helps,Viggo
Date: Tue, 29 Jul 2008 18:14:25 -0600From: [EMAIL PROTECTED]: [EMAIL
PROTECTED]: [osg-users] sky model tracking the camera...
Hello,
I would like to have my sky model track the camera position so that as the
camera moves, the sky model moves with it. To do this, would I add the sky
model transform as a child of the cameraNode? Does anyone have any code
snippets that may demonstrate how I might do this?
Thanks in advance…
-Shayne
Få Hotmail du også. Windows Live Hotmail nå med 5000 MB gratis lagringsplass.
_
Hold deg oppdatert med MSN på mobilen.
http://info.mobile.no.msn.com/pc/default.aspx?ocid=30032___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
