[osg-users] A problem related to the ive file size and loading speed
Hi all, I convert some existing 3ds models to ive format through the following two steps: 1) call osgDB::writeNodeFile func to save the loaded 3ds model into osg format; 2) run osgconv to convert osg to ive format. But I find that the size of ive file I finally get is much larger than the original 3ds file. (3ds: 10 M, ive: 100 M) And it cost me much time to load ive file (about 15 s) into the program. It is said on internet that reading ive files is quite fast. So something wrong? Is there any way to improve (ive size and loading speed)? Much appreciation to any comment. With best regards, Fangqin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PAT and getWorldMatrices difference
Hi All, Working on a way to find the good world matrix for a node, I've encountered some problems : My structure is this one : -root |-Node...(not osg::Tranform) |-PAT (osg::PositionAtitudeTransform) If I get the PAT translation and rotation, I've a vector and a Quat, which looks good, if I consider pat as a node and use _node-getWorldMatrices()[0] and get Rotation and Translation, the results are not the same... What can do this ? How to get real world coordinate form a node (Transform or not) ? thanks, Regards, Vincent. ___ 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...
Look in the osghandglide example for MoveEarthySkyWithEyePointTransform; you will need to add the z-coordinate transform as well (currently 0.0 in the code). 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
James, The most obvious problem: Group::traverse ... Is one of the visitors you use a TRAVERSE_ALL_CHILDREN visitor? If so, the Group::traverse profile makes sense. Make sure that you do traverse only this subgraphps you need to traverse. You can then minimize that calls too. Will help overall!!! Ok, so the PositionAttitudeTransform is the matrix multiplication problem. Try that specialized transform patch I have sent to you. That will help a bit here. But you might do even better: You are talking about a game. So I expect that you have transform nodes to animate parts of the scenegraph. I agree that you will need the full PositionAttitudeTransform in some cases. But I can well imagine to have special transforms in such a game where you can make use of specialized implementations. Specialized with respect to: * The kind of the transform. Often you just have to rotate around the origin. Nothing more. Or you might have some linear transform to make something move but no rotation and no scaling. For this case implement you own say LinearTransform or RotationTransform nodes derived from osg::Transform and reimplement the the computeLocalToWorldMatrix and computeWorldToLocalMatrix and computeBound methods with something more optimized. May be use that specialized preMultTranslate or equivalent methods from the patch I sent. You can avoid many matrix multiplications for that. * Recomputation of the bounding sphere. Sometimes with such special transforms, you do not need to dirty the bounding sphere. Take a rotation. Say you have a leg that can rotate around the knee. Just compute the bounding sphere for all possible rotation values of that rotation. With that you will have slightly worse bounding spheres, but You do not need to walk large scenegraphs to invalidate the bound and you do not need to recompute the bound for large parts of the scene again and again. If you have a human body for example with many transform nodes for arms legs and fingers and so on. Your human body bounding sphere will not be much larger with that kind of bounding box compared to the exact case. The interresting cull case is to cull away the *whole* human body which will happen about the same as with the exact bounding spheres. Translations along an axis for example are a bit more difficult in this case since they would blow up the sphere to infinity if you want to catch any translation value. But if you have a translation axis, a maximum scalar value a minimum scalar value and a current scalar translation value, you can do about the same. Hope this helps. Greetings Mathais -- 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] osg make error in mingw
sorry! I was following some mistakes。 Linking CXX shared library ../../lib/libosg.dll Creating library file: ../../lib/libosg.dll.a [ 11%] Built target osg Scanning dependencies of target osgDB [ 11%] Building CXX object src/osgDB/CMakeFiles/osgDB.dir/Archive.obj f:/OpenSceneGraph/OpenSceneGraph-2.2.0/OpenSceneGraph/src/osgDB/Archive.cpp:51: internal compiler error: in maybe_emit_vtables, at cp/decl2.c:1678 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [src/osgDB/CMakeFiles/osgDB.dir/Archive.obj] Error 1 make[1]: *** [src/osgDB/CMakeFiles/osgDB.dir/all] Error 2 make: *** [all] Error 2 what can i do? thank! 在2008-07-29，songbo_1220 [EMAIL PROTECTED] 写道： 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] A problem related to the ive file size and loading speed
Fangqin, Can't comment about your file size, but you could save yourself a step by doing osgconv My3DSFile.3ds MyIVEFile.ive directly... David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] A problem related to the ive file size and loading speed
David Spilling wrote: Fangqin, Can't comment about your file size, but you could save yourself a step by doing osgconv My3DSFile.3ds MyIVEFile.ive directly... The increase in size might be because of textures that get included in the .ive, while the .3ds refered to them by file name only. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 回复: help me!
Thank for you all! osgExp is REALLY NOT surport Texture UV repeat! But I have make it run ok through change its code! Thank you very much! -- 原始邮件 -- 发件人: GMD GammerMaxyandex.ru[EMAIL PROTECTED]; 发送时间: 2008年7月29日(星期二) 凌晨02:59 收件人: osg-usersosg-users@lists.openscenegraph.org; 主题: Re: [osg-users] help me! osgExp is not surport Texture UV repeat? Yes :( 28.07.08, 14:43, Alberto Luaces [EMAIL PROTECTED]: Hi, Sorry, I have no expertise with 3DSMax and/or osgExp, so I cannot help you further. Nevertheless, here is the osgExp code download page address: http://sourceforge.net/svn/?group_id=148454 I suppose there are compilation instructions within the source. El Viernes 25 Julio 2008ES 07:00:08 monkeymonkey escribió: hi!Thank you for your answer! I try it as you say, but not right also,i think because Texture Coord output of osgExp is not right,they are between 0 and 1,it should be 0 to 3. i change it , it is OK!, so it is the really reason. I must change osgExp scource code,and recompile it? how to do it? From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Date: Wed, 23 Jul 2008 09:57:33 +0200 Subject: Re: [osg-users] help me! Hi, El Miércoles 23 Julio 2008ES 08:48:19 monkeymonkey escribió: hi! i use Texture UV repeat 3.0 in 3dsMax8,but when i output it to ive,then use osgViewer to look,texture is not right. it seem that repeat is not work! why? osgExp is not surport Texture UV repeat? how to make it? Convert your .ive to .osg with osgconv, then look for the wrap parameter in the file like wrap_s,t,... REPEAT If there is something other word than REPEAT, change it. Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Много спама? Пользуйтесь Яндекс.Почтой http://mail.yandex.ru/nospam ___ 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] ??: help me!
Could you submit your code changes to the community? Thanks, Daniel From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of monkey Sent: Wednesday, July 30, 2008 10:47 AM To: OpenSceneGraph Users Subject: [osg-users] ??: help me! Thank for you all! osgExp is REALLY NOT surport Texture UV repeat! But I have make it run ok through change its code! Thank you very much! -- 原始邮件 -- 发件人: GMD GammerMaxyandex.ru[EMAIL PROTECTED]; 发送时间: 2008年7月29日(星期二) 凌晨02:59 收件人: osg-usersosg-users@lists.openscenegraph.org; 主题: Re: [osg-users] help me! osgExp is not surport Texture UV repeat? Yes :( 28.07.08, 14:43, Alberto Luaces [EMAIL PROTECTED]: Hi, Sorry, I have no expertise with 3DSMax and/or osgExp, so I cannot help you further. Nevertheless, here is the osgExp code download page address: http://sourceforge.net/svn/?group_id=148454 I suppose there are compilation instructions within the source. El Viernes 25 Julio 2008ES 07:00:08 monkeymonkey escribió: hi!Thank you for your answer! I try it as you say, but not right also,i think because Texture Coord output of osgExp is not right,they are between 0 and 1,it should be 0 to 3. i change it , it is OK!, so it is the really reason. I must change osgExp scource code,and recompile it? how to do it? From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Date: Wed, 23 Jul 2008 09:57:33 +0200 Subject: Re: [osg-users] help me! Hi, El Miércoles 23 Julio 2008ES 08:48:19 monkeymonkey escribió: hi! i use Texture UV repeat 3.0 in 3dsMax8,but when i output it to ive,then use osgViewer to look,texture is not right. it seem that repeat is not work! why? osgExp is not surport Texture UV repeat? how to make it? Convert your .ive to .osg with osgconv, then look for the wrap parameter in the file like wrap_s,t,... REPEAT If there is something other word than REPEAT, change it. Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Много спама? Пользуйтесь Яндекс.Почтой http://mail.yandex.ru/nospam ___ 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] A problem related to the ive file size and loading speed
Paul Melis wrote: Can't comment about your file size, but you could save yourself a step by doing osgconv My3DSFile.3ds MyIVEFile.ive directly... The increase in size might be because of textures that get included in the .ive, while the .3ds refered to them by file name only. And you can disable this behaviour by specifying the 'noTexturesInIVEFile' option: osgconv -O noTexturesInIVEFile file.3ds file.ive /ulrich ___ 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, sorry, I can only guess at potential problems... I am assuming you are viewing the data with osgviewer so that I can discard other cases where blending might not be set up correctly. The black portions normally indicate that something is up with the blending of data. E.g. sometimes the geotiffs have transparent areas that have to be blended with other tiles. This occurs e.g. when the tiles are not square. Since the dted data has no colour data, I'm not sure what the image data will blend with. What I would try is to use one of the BMNG tiles as a backdrop. See on the wiki for a link. The BMNG tile covers a wide area and would be used for places in the terrain where you do not supply your own higher res image data. jp Greg Myers wrote: 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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
Re: [osg-users] render to texture - alpha blending
Hi Sherman, sherman wilcox schrieb: 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? have you tried using osg::ColorMask and disable writing to the alpha-channel? You'll get nicely blended RGB, but the alpha-channel remain untouched. I used this with some RTT-code where I experienced similar problems. HTH, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] transparency becomes dark
Thanks Ulrich and Dimi I supposed that it has s.th to do with the missing material paramters; my idea was to change the original material of the node, therefore I set: osg::StateSet *ss = loadedModel -getOrCreateStateSet(); osg::Material* blendMaterial = (osg::Material*)(ss-getAttribute(osg::StateAttribute::MATERIAL)); but the material is always NULL so I don't have the original material Is this the wrong function call ? Dieter Unclassified Mail -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ulrich Hertlein Sent: Saturday, 26 July, 2008 08:08 To: OpenSceneGraph Users Subject: Re: [osg-users] transparency becomes dark Hi Dieter, Dieter Pfeffer wrote: I am trying to set the object transparency from 1.0 - 0.0 and vice versa; but when I start changing the alpha of the material the object becomes dark. I have changed the material parameters but without success; when I look in the loaded model (for example cow.osg) for material, the material is always null. I have modified the osgviewer example and attached it. Could s.o. give me a hint what I am doing wrong ? You're creating a new Material that overrides the material of the node you're fading. However, you're not setting the Material properties (ambient, diffuse, specular, emissive, shininess) and the default values for Material are unlikely to match that of the node you're trying to blend. Hence when you override the original material it will switch from the original settings to the default Material. For an experiment, have a look at any .osg file and look at the material properties. Then set those values on the 'blendMaterial' node you're creating and it should look smooth. You're probably better off modifying the original Material(s) of the node hierarchy. Or try another approach, like using blendcolor. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Disclaimer: This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Considering the inherent risks of the use of e-mail communication, Thales Nederland BV shall not be liable for any damage derived from it. Thales Nederland BV is seated in Hengelo (Ov.), the Netherlands, and registered at the Chamber of Commerce under number 06061578. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] View Frutrum Culling
I did the following:
class CullCallback : public osg::NodeCallback
{
public:
bool isVisible;
CullCallback():isVisible(false){}
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
traverse(node,nv);
if (!((osgUtil::CullVisitor*) nv)-isCulled(*node))
this-isVisible=true;
}
};
I installed this to every node where I want to know if its currently
visible or not with setCullCallback
Then I question somewhere else the flag like this:
return ((CullCallback*)this-node-getCullCallback())-isVisible;
Even if my camera is far away and facing somewhere, where nothing is
visible.
Everything is said to be visible.
Please help me. I really don't get it.
Greeting
Hagen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] View Frutrum Culling
Hi Hagen,
Kaiser, Hagen (CT) wrote:
I did the following:
class CullCallback : public osg::NodeCallback
{
public:
bool isVisible;
CullCallback():isVisible(false){}
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
traverse(node,nv);
if (!((osgUtil::CullVisitor*) nv)-isCulled(*node))
this-isVisible=true;
}
};
I installed this to every node where I want to know if its currently
visible or not with setCullCallback
Then I question somewhere else the flag like this:
return ((CullCallback*)this-node-getCullCallback())-isVisible;
Even if my camera is far away and facing somewhere, where nothing is
visible.
Everything is said to be visible.
Please help me. I really don't get it.
Could it be that the cull callback is only called for objects that are
NOT culled, i.e. whose bounding spheres overlap with the frustum?
Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] transparency becomes dark
OGL sets up a default material , you may be picking this up -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dieter Pfeffer Sent: Wednesday, July 30, 2008 8:09 AM To: OpenSceneGraph Users Subject: Re: [osg-users] transparency becomes dark Thanks Ulrich and Dimi I supposed that it has s.th to do with the missing material paramters; my idea was to change the original material of the node, therefore I set: osg::StateSet *ss = loadedModel -getOrCreateStateSet(); osg::Material* blendMaterial = (osg::Material*)(ss-getAttribute(osg::StateAttribute::MATERIAL)); but the material is always NULL so I don't have the original material Is this the wrong function call ? Dieter Unclassified Mail -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ulrich Hertlein Sent: Saturday, 26 July, 2008 08:08 To: OpenSceneGraph Users Subject: Re: [osg-users] transparency becomes dark Hi Dieter, Dieter Pfeffer wrote: I am trying to set the object transparency from 1.0 - 0.0 and vice versa; but when I start changing the alpha of the material the object becomes dark. I have changed the material parameters but without success; when I look in the loaded model (for example cow.osg) for material, the material is always null. I have modified the osgviewer example and attached it. Could s.o. give me a hint what I am doing wrong ? You're creating a new Material that overrides the material of the node you're fading. However, you're not setting the Material properties (ambient, diffuse, specular, emissive, shininess) and the default values for Material are unlikely to match that of the node you're trying to blend. Hence when you override the original material it will switch from the original settings to the default Material. For an experiment, have a look at any .osg file and look at the material properties. Then set those values on the 'blendMaterial' node you're creating and it should look smooth. You're probably better off modifying the original Material(s) of the node hierarchy. Or try another approach, like using blendcolor. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Disclaimer: This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Considering the inherent risks of the use of e-mail communication, Thales Nederland BV shall not be liable for any damage derived from it. Thales Nederland BV is seated in Hengelo (Ov.), the Netherlands, and registered at the Chamber of Commerce under number 06061578. ___ 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
Hello Jim, 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. Indeed, aliasing is a big problem with vanilla shadow mapping in almost all real-world cases. What you describe can easily be done by client code, using the osgShadow::ShadowMap::clearShaderList() and osgShadow::ShadowMap::addShader() methods with the appropriate shaders. One thing that you need to be careful about when replacing the default shaders is to use the same uniform names to access the shadow map sampler and other variables. 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] Qt + non-continuous draw + pagedLOD: Random loss of detail??
John, I have run into the same issue. PagedLOD children expire after a certain period of time (default is something like 5 seconds?) If a PagedLOD child has not been visited in the last N seconds, the pager will discard it and revert to a lower LOD. OSG updates the time-last-visited during the cull traversal in order to check for expiration. So, if you are not continuously running the frame loop, PagedLOD's will think their children have expired and will drop to the lowest LOD. I used to refer to the technique you're using as lazy rendering (i.e. only render a frame when something has changed) ... try searching the archives ... but at the time I never did find a good way to do this in OSG without confusing the pager. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Wed, Jul 30, 2008 at 8:39 AM, John Vidar Larring [EMAIL PROTECTED]wrote: Hi all, Background: --- In our application the user can set up scenes ( or sequences as we call them) for playback on a timeline (e.g. seq.1 - transition - seg.2 - transition ... seq.N). Some scenes are too complex to render real-time and are recorded to movies before playback. Hence, when scenes are edited by the user all scenes are redrawn as needed rather than continuously to avoid sluggish GUI response. Problem: _Sometimes_ when the scene is redrawn in edit mode (i.e. redraw only if needed), the pagedLOD DB (osgTerrain) drops to the lowest detail level (Ref. osg_original.jpg and osg_problem.jpg). This behavior seems to appear at randomly. In playback mode (i.e. when frame rate is constant) the problem never occurs. Reproduce / Code example: -- The problem has been reproduces in a small test program (osgtest_source_code.tgz) derived from the osgviewerQT example (since we are using Qt 4.x in our application). To reproduce: run the compiled application: 'osgtest -t your osgTerrain db' . To trigger refreshes, occlude parts of the window with another window. The problem typically reveals itself when at a redraw or when the window looses focus (be patient, since this happens randomly it may take some time before the problem occurs). Since I'm still quite new to OSG, I'm not sure where to look for a solution. Hopefully someone will spot the obvious error in the sample code. Any advice is highly appreciated. Versions: - OSG svn rev 8700 Qt 4.2.3 Best regards, John Larring -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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 Status
Hi Robert / all Thanks for the info on vpbmaster again, finally got around to trying it out. My data is in the ecw format and after some initial problems the trick about transforming them into vrt which is recommentet in another thread worked like a charm. Im currently building what will be a roughly 600 gig database 14 levels deep. I cant wait to see how it runs in my sim. :-) During my investigations I tried specifying different output formats like jpeg, I expected a jpeg database to be smaller than what is currently generatet, but it wassent. Is there no way of generating a database containing more compressed data than the default? I know it would propably hurt paging performance, but it might be worth it in may case. Brgs. Ralf ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Behaviour of function osg::Image-getPixelSizeInBits() is strange.
Behaviour of function osg::Image-getPixelSizeInBits() is strange. After loadind OSG-file, I tryed get count bits by pixel (several different images was examinated)? and function returns 64! After changing image of texture by its copy: osg::Image* dest =dynamic_castosg::Image* (MyImage-clone(osg::CopyOp::DEEP_COPY_ALL)); MyTexture-setImage(dest); function osg::Image-getPixelSizeInBits() returns correct values 24/32. Is any ideas? System: OSG 2.6.0 rc1, WinXp / Vista, VS 2008 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Win32 keyboard bug
Hello Robert, all, As for fixing this in an osg application one idea for Win32 could be to add a WM_ACTIVATE handler in GraphicWindowWin32::handleNativeWindowingEvent. Note that this method is virtual so the message can be handled by just deriving a class from GraphicWindowWin32 so you do not have to modify any code inside the osg library for this fix. When the application get focus some calls to GetAsyncKeyState can be made to check the status of the modifier keys and calls can be made to EventQueue::keyPress/keyRelease to update the osg modifier key mask accordingly. If you need to keep track of other keys that might have been released or pressed when your application did not have focus you have to call GetAsyncKeyState for them as well. I am currently testing out a pretty small patch to osgViewer::GraphicsWindowWin32 that will fix this issue. I decided to fix it in the core, because otherwise I'd have to construct all my GraphicsWindow objects myself (using a derived class) instead of using the factory methods (which create a GraphicsWindowWin32 directly). And fixing the problem at the root just seems like the right thing to do. I'll submit the fix to osg-submissions once I'm done, hopefully this will be considered a bug fix and will be integrated into 2.6. Just a heads up. 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
[osg-users] Win32 window resize mouse cursors
Hello all, Along with another Win32 fix I'll be submitting soon (see the Win32 keyboard bug message I just sent), I'd like to fix another issue that's been nagging me a bit, which is that when you move the mouse cursor to the edge of an osgViewer window, they don't change to the resize arrows. You can resize the window just fine, but the visual hint that you can is not present. I'm not extremely familiar with low-level Win32 windowing, but I'm willing to code up the fix if someone can point me in the right direction. Where should this happen? Is there a check based on mouse position in which if the position is near an edge of the window I can make the cursor change? Help from a Win32 guru would be appreciated, just to get me started. Thanks in advance, 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] somewhat off-topic: sources of real-world lidar point cloud data?
I don't know any publicly available real-world LIDAR data, though I know Velodyne has some pretty nice datasets they were passing about fairly freely to DARPA Urban Challenge teams. Their sensor is a 360 degree, ~1 million points/second sensor, so it produces some beautiful point clouds of real world scenes. Jason On Jul 29, 2008, at 12:42 PM, Lucas wrote: 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Lazy Rendering with pagedLOD databases
Hi Glenn, Thanks for your quick reply as always:) Changing topic title to use more appropriate terms. See comments below: I used to refer to the technique you're using as lazy rendering (i.e. only render a frame when something has changed) ... try searching the archives ... When searching the archives for lazy rendering through Google Groups and Gmain, I only found to posting on the subject, of which this one comments the former: http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/8859/match=lazy+rendering I have run into the same issue. PagedLOD children expire after a certain period of time (default is something like 5 seconds?) If a PagedLOD child has not been visited in the last N seconds, the pager will discard it and revert to a lower LOD. OSG updates the time-last-visited during the cull traversal in order to check for expiration. So, if you are not continuously running the frame loop, PagedLOD's will think their children have expired and will drop to the lowest LOD. [snip]... but at the time I never did find a good way to do this in OSG without confusing the pager. Hmmm... that's what I feared. Ok, I am just thinking aloud here since this is a problem I really need to get solved: For real-time rendering paging out children on expery time is a good idea to keep memory consumption at minimum. However, this obvious does not work for lazy rendering. What if the pager could be configured in the following way for lazy rendering: * Set a maximum memory size osgDB::DatabasePager can occupy. * When a new page/sub-graph is added, osgDB::DatabasePager::removeExpiredSubgraphs() will remove the oldest pages if the maximum limit is exceeded. Would this be a feasible strategy? Or are there better ways/strategies to support lazy rendering of pagedLOD databases? Best regards, John Larring Glenn Waldron wrote: John, I have run into the same issue. PagedLOD children expire after a certain period of time (default is something like 5 seconds?) If a PagedLOD child has not been visited in the last N seconds, the pager will discard it and revert to a lower LOD. OSG updates the time-last-visited during the cull traversal in order to check for expiration. So, if you are not continuously running the frame loop, PagedLOD's will think their children have expired and will drop to the lowest LOD. I used to refer to the technique you're using as lazy rendering (i.e. only render a frame when something has changed) ... try searching the archives ... but at the time I never did find a good way to do this in OSG without confusing the pager. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Wed, Jul 30, 2008 at 8:39 AM, John Vidar Larring [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi all, Background: --- In our application the user can set up scenes ( or sequences as we call them) for playback on a timeline (e.g. seq.1 - transition - seg.2 - transition ... seq.N). Some scenes are too complex to render real-time and are recorded to movies before playback. Hence, when scenes are edited by the user all scenes are redrawn as needed rather than continuously to avoid sluggish GUI response. Problem: _Sometimes_ when the scene is redrawn in edit mode (i.e. redraw only if needed), the pagedLOD DB (osgTerrain) drops to the lowest detail level (Ref. osg_original.jpg and osg_problem.jpg). This behavior seems to appear at randomly. In playback mode (i.e. when frame rate is constant) the problem never occurs. Reproduce / Code example: -- The problem has been reproduces in a small test program (osgtest_source_code.tgz) derived from the osgviewerQT example (since we are using Qt 4.x in our application). To reproduce: run the compiled application: 'osgtest -t your osgTerrain db' . To trigger refreshes, occlude parts of the window with another window. The problem typically reveals itself when at a redraw or when the window looses focus (be patient, since this happens randomly it may take some time before the problem occurs). Since I'm still quite new to OSG, I'm not sure where to look for a solution. Hopefully someone will spot the obvious error in the sample code. Any advice is highly appreciated. Versions: - OSG svn rev 8700 Qt 4.2.3 Best regards, John Larring -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is
Re: [osg-users] Lazy Rendering with pagedLOD databases
John, Digging into my memories on the subject... One issue is, like you said, keeping data from paging out when the renderer is idle. One approach might be to force a cull traversal every so often, or to visit the scene graph and manually update the timestamps on your PagedLODs. There may be more to it however. The other issue is making sure the pager completes all the tasks it has queued up. The pager does a little slice of work each frame in order to avoid frame rate hiccups. So when you go to render on demand, you have to keep looping until the pager goes idle ... i.e. its queues empty out. You can query the state with requiresUpdateSceneGraph(), getFileRequestListSize(), et al. Now, my experimentation in this area was with an older version of OSG and Robert has refactored the pager since then. It ended up being a much more complex task than I anticipated. Glenn On Wed, Jul 30, 2008 at 10:12 AM, John Vidar Larring [EMAIL PROTECTED]wrote: Hi Glenn, Thanks for your quick reply as always:) Changing topic title to use more appropriate terms. See comments below: I used to refer to the technique you're using as lazy rendering (i.e. only render a frame when something has changed) ... try searching the archives ... When searching the archives for lazy rendering through Google Groups and Gmain, I only found to posting on the subject, of which this one comments the former: http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/8859/match=lazy+rendering I have run into the same issue. PagedLOD children expire after a certain period of time (default is something like 5 seconds?) If a PagedLOD child has not been visited in the last N seconds, the pager will discard it and revert to a lower LOD. OSG updates the time-last-visited during the cull traversal in order to check for expiration. So, if you are not continuously running the frame loop, PagedLOD's will think their children have expired and will drop to the lowest LOD. [snip]... but at the time I never did find a good way to do this in OSG without confusing the pager. Hmmm... that's what I feared. Ok, I am just thinking aloud here since this is a problem I really need to get solved: For real-time rendering paging out children on expery time is a good idea to keep memory consumption at minimum. However, this obvious does not work for lazy rendering. What if the pager could be configured in the following way for lazy rendering: * Set a maximum memory size osgDB::DatabasePager can occupy. * When a new page/sub-graph is added, osgDB::DatabasePager::removeExpiredSubgraphs() will remove the oldest pages if the maximum limit is exceeded. Would this be a feasible strategy? Or are there better ways/strategies to support lazy rendering of pagedLOD databases? Best regards, John Larring Glenn Waldron wrote: John, I have run into the same issue. PagedLOD children expire after a certain period of time (default is something like 5 seconds?) If a PagedLOD child has not been visited in the last N seconds, the pager will discard it and revert to a lower LOD. OSG updates the time-last-visited during the cull traversal in order to check for expiration. So, if you are not continuously running the frame loop, PagedLOD's will think their children have expired and will drop to the lowest LOD. I used to refer to the technique you're using as lazy rendering (i.e. only render a frame when something has changed) ... try searching the archives ... but at the time I never did find a good way to do this in OSG without confusing the pager. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Wed, Jul 30, 2008 at 8:39 AM, John Vidar Larring [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi all, Background: --- In our application the user can set up scenes ( or sequences as we call them) for playback on a timeline (e.g. seq.1 - transition - seg.2 - transition ... seq.N). Some scenes are too complex to render real-time and are recorded to movies before playback. Hence, when scenes are edited by the user all scenes are redrawn as needed rather than continuously to avoid sluggish GUI response. Problem: _Sometimes_ when the scene is redrawn in edit mode (i.e. redraw only if needed), the pagedLOD DB (osgTerrain) drops to the lowest detail level (Ref. osg_original.jpg and osg_problem.jpg). This behavior seems to appear at randomly. In playback mode (i.e. when frame rate is constant) the problem never occurs. Reproduce / Code example: -- The problem has been reproduces in a small test program (osgtest_source_code.tgz) derived from the osgviewerQT example (since we are using Qt 4.x in our application). To reproduce: run the compiled application: 'osgtest -t your osgTerrain db' . To trigger refreshes, occlude parts of the window with another
[osg-users] osgViewer on MFC
Hi all,
Sorry for simple question, but I am new on MFC windowing toolkit. I have
looked at the mail-archive and web-site but there was no more sample except
osgviewerMFC. I want to open my project on MFC window. At normal, I am using
code as below.
osgViewer::Viewer viewer;
viewer.setSceneData( root.get() );
viewer.realize();
while( !viewer.done() )
{
viewer.frame();
}
But for using MFC, how can I create my window. Am I using
osg::GraphicsContext ? And how can I use osg::GraphicsContext for opening
MFC mod? I mean, How can a manage open my project in mfc?
Thanks so much. Best regards.
Umit UZUN
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Threading models on startup - win32
Hi everyone, I am noticing something strange with osgviewer. When I start up osgviewer (with any old terrain model), and turn on the stats, I see DrawThreadPerContext mode with an unusually long draw time. In one case, it's 22 ms and pretty much pegging one of my cores. If I cycle though the threading modes with the 'm' key, all the way back to DrawThreadPerContext, now I get a draw time of 0.3 ms and a virtually idle CPU. Almost seems like it's starting in single-threaded mode. Has anyone noticed this? I see the same behavior on OSG 2.6 and 2.4. Win32, 4-core intel, GeForce 880 GT, Forceware 169.21. Thanks, Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting a TextureObject into a Texture2D
Hi Steffen, I also didn't find anything on the API, so I'm afraid you'll have to dive into the code and find if you can get this functionality by subclassing or if you have to modify OSG instead. Alberto El Martes 29 Julio 2008ES 17:28:09 Steffen Kim escribió: Hi, I'm a little lost on creating an osg::Texture2D from an OpenGL-texture-ID I have. I tried to do this by creating an TextureObject with osg::Texture::TextureObject* tObject = new osg::Texture::TextureObject(_ilaceData.renderTextureID, GL_TEXTURE_2D); But now I'm stuck when it comes to putting this TextureObject into the Texture2D I want to use to display it. The usage of getTextureObject wasn't successful (I get a blank texture) so I would be very happy if anyone can give me a hint on how to do this. It seems like a quite strange questions to me and I guess I'm overlooking some simple function but I cannot find anything in the documentation. Thanks a lot, Steffen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Changes on the 2.6 branch
Hi all -- Now that the write permission issues have been resolved, I've checked in a few changes on the 2.6 branch in Robert's absence. http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph -2.6/ The 2.6 branch could definitely benefit from testing; please do so when you get a chance. There are currently two submitted changes remaining that I'm aware of: - problem with osgUtil::LineSegmentIntersector - Matrixf multiply Optimization I'm not inclined to commit these changes, as I feel obligated to fully understand the changes before committing them, and due to prior obligations this week, I'm unable to give them the attention they require. Eric, Jeremy, Bob, Paul Melis -- you all have write permission, so if any of you would like to take a look at these remaining changes and commit them, be my guest. Otherwise, they can wait for Robert to return. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ 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
Hey JP, First of all I want you to know that I really appreciate your help. :) I tried the BMNG image that covers my area of interest and that worked like a charm. No more black areas. Now, I only ran the data using a level setting of 10. When I zoom in on the high res image that I provided, it is not high res at all. Does the level setting need to be cranked way up in order to be able to see the details in the high res image? Do I need to specify layer options for my high res image like you did in your example? And one more question, what is the purpose of the archive file output type ( the -a option ) ? Thanks Greg On Jul 30, 3:33 am, J.P. Delport [EMAIL PROTECTED] wrote: Hi, sorry, I can only guess at potential problems... I am assuming you are viewing the data with osgviewer so that I can discard other cases where blending might not be set up correctly. The black portions normally indicate that something is up with the blending of data. E.g. sometimes the geotiffs have transparent areas that have to be blended with other tiles. This occurs e.g. when the tiles are not square. Since the dted data has no colour data, I'm not sure what the image data will blend with. What I would try is to use one of the BMNG tiles as a backdrop. See on the wiki for a link. The BMNG tile covers a wide area and would be used for places in the terrain where you do not supply your own higher res image data. jp GregMyerswrote: 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, GregMyerswrote: 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 ___ osg-users mailing list [EMAIL PROTECTED] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph... -- 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 athttp://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 [EMAIL PROTECTED]://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph... ___ 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, I would just remove the -l command line and let vpb run as long as it needs to. Depending on the level of your data, it might need to go higher than level 10. Thanks, Jason On Wed, Jul 30, 2008 at 1:33 PM, Greg Myers [EMAIL PROTECTED] wrote: Hey JP, First of all I want you to know that I really appreciate your help. :) I tried the BMNG image that covers my area of interest and that worked like a charm. No more black areas. Now, I only ran the data using a level setting of 10. When I zoom in on the high res image that I provided, it is not high res at all. Does the level setting need to be cranked way up in order to be able to see the details in the high res image? Do I need to specify layer options for my high res image like you did in your example? And one more question, what is the purpose of the archive file output type ( the -a option ) ? Thanks Greg On Jul 30, 3:33 am, J.P. Delport [EMAIL PROTECTED] wrote: Hi, sorry, I can only guess at potential problems... I am assuming you are viewing the data with osgviewer so that I can discard other cases where blending might not be set up correctly. The black portions normally indicate that something is up with the blending of data. E.g. sometimes the geotiffs have transparent areas that have to be blended with other tiles. This occurs e.g. when the tiles are not square. Since the dted data has no colour data, I'm not sure what the image data will blend with. What I would try is to use one of the BMNG tiles as a backdrop. See on the wiki for a link. The BMNG tile covers a wide area and would be used for places in the terrain where you do not supply your own higher res image data. jp GregMyerswrote: 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, GregMyerswrote: 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 ___ osg-users mailing list [EMAIL PROTECTED] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. .. -- 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 athttp:// 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 [EMAIL PROTECTED]:// lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] vpb on cluster example
Hey Jason, Thanks for the reply. I guess I'm going to have to bite the bullet and try that out. It just takes a substantial amount of time so I hate to do it without knowing if I'm doing it right in the first place. Tell me this though, is it possible to add new images to an existing ive file? For instance, if I ran osgdem against just some plain old DTED data without images and output the results to dted.ive, could I then run another osgdem command and pass in image data using the same dted.ive file? Would it just add in the images to the terrain or would it start fresh and blow away my existing terrain? Thanks Greg On Jul 30, 10:43 am, Jason Beverage [EMAIL PROTECTED] wrote: Hi Greg, I would just remove the -l command line and let vpb run as long as it needs to. Depending on the level of your data, it might need to go higher than level 10. Thanks, Jason On Wed, Jul 30, 2008 at 1:33 PM, Greg Myers [EMAIL PROTECTED] wrote: Hey JP, First of all I want you to know that I really appreciate your help. :) I tried the BMNG image that covers my area of interest and that worked like a charm. No more black areas. Now, I only ran the data using a level setting of 10. When I zoom in on the high res image that I provided, it is not high res at all. Does the level setting need to be cranked way up in order to be able to see the details in the high res image? Do I need to specify layer options for my high res image like you did in your example? And one more question, what is the purpose of the archive file output type ( the -a option ) ? Thanks Greg On Jul 30, 3:33 am, J.P. Delport [EMAIL PROTECTED] wrote: Hi, sorry, I can only guess at potential problems... I am assuming you are viewing the data with osgviewer so that I can discard other cases where blending might not be set up correctly. The black portions normally indicate that something is up with the blending of data. E.g. sometimes the geotiffs have transparent areas that have to be blended with other tiles. This occurs e.g. when the tiles are not square. Since the dted data has no colour data, I'm not sure what the image data will blend with. What I would try is to use one of the BMNG tiles as a backdrop. See on the wiki for a link. The BMNG tile covers a wide area and would be used for places in the terrain where you do not supply your own higher res image data. jp GregMyerswrote: 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, GregMyerswrote: 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 ___ osg-users mailing list [EMAIL PROTECTED] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. .. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF)
Re: [osg-users] vpb on cluster example
Hi Greg, I don't believe it is currently possible to modify a database with new imagery or terrain once a database is created. That is something that I know Robert was planning on working out at some point for osgTerrain/VPB but I'm not sure what its status is. Using the --terrain option should make things run pretty quick though depending on how much data you're throwing at it. Also, try replacing the osgdem command line with vpbmaster as it supports multiple cores and thankfully takes the exact same command line optoins as osgdem. Good luck! Jason On Wed, Jul 30, 2008 at 2:10 PM, Greg Myers [EMAIL PROTECTED] wrote: Hey Jason, Thanks for the reply. I guess I'm going to have to bite the bullet and try that out. It just takes a substantial amount of time so I hate to do it without knowing if I'm doing it right in the first place. Tell me this though, is it possible to add new images to an existing ive file? For instance, if I ran osgdem against just some plain old DTED data without images and output the results to dted.ive, could I then run another osgdem command and pass in image data using the same dted.ive file? Would it just add in the images to the terrain or would it start fresh and blow away my existing terrain? Thanks Greg On Jul 30, 10:43 am, Jason Beverage [EMAIL PROTECTED] wrote: Hi Greg, I would just remove the -l command line and let vpb run as long as it needs to. Depending on the level of your data, it might need to go higher than level 10. Thanks, Jason On Wed, Jul 30, 2008 at 1:33 PM, Greg Myers [EMAIL PROTECTED] wrote: Hey JP, First of all I want you to know that I really appreciate your help. :) I tried the BMNG image that covers my area of interest and that worked like a charm. No more black areas. Now, I only ran the data using a level setting of 10. When I zoom in on the high res image that I provided, it is not high res at all. Does the level setting need to be cranked way up in order to be able to see the details in the high res image? Do I need to specify layer options for my high res image like you did in your example? And one more question, what is the purpose of the archive file output type ( the -a option ) ? Thanks Greg On Jul 30, 3:33 am, J.P. Delport [EMAIL PROTECTED] wrote: Hi, sorry, I can only guess at potential problems... I am assuming you are viewing the data with osgviewer so that I can discard other cases where blending might not be set up correctly. The black portions normally indicate that something is up with the blending of data. E.g. sometimes the geotiffs have transparent areas that have to be blended with other tiles. This occurs e.g. when the tiles are not square. Since the dted data has no colour data, I'm not sure what the image data will blend with. What I would try is to use one of the BMNG tiles as a backdrop. See on the wiki for a link. The BMNG tile covers a wide area and would be used for places in the terrain where you do not supply your own higher res image data. jp GregMyerswrote: 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, GregMyerswrote: 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
Re: [osg-users] vpb on cluster example
Hi again Greg, Forgot to mention this previously... You should also try building overviews for all of your geospatial data files using the gdal utility gdaladdo if they don't already have them. Doing so can result in pretty dramatic increases in speed. Jason On Wed, Jul 30, 2008 at 2:44 PM, Jason Beverage [EMAIL PROTECTED]wrote: Hi Greg, I don't believe it is currently possible to modify a database with new imagery or terrain once a database is created. That is something that I know Robert was planning on working out at some point for osgTerrain/VPB but I'm not sure what its status is. Using the --terrain option should make things run pretty quick though depending on how much data you're throwing at it. Also, try replacing the osgdem command line with vpbmaster as it supports multiple cores and thankfully takes the exact same command line optoins as osgdem. Good luck! Jason On Wed, Jul 30, 2008 at 2:10 PM, Greg Myers [EMAIL PROTECTED] wrote: Hey Jason, Thanks for the reply. I guess I'm going to have to bite the bullet and try that out. It just takes a substantial amount of time so I hate to do it without knowing if I'm doing it right in the first place. Tell me this though, is it possible to add new images to an existing ive file? For instance, if I ran osgdem against just some plain old DTED data without images and output the results to dted.ive, could I then run another osgdem command and pass in image data using the same dted.ive file? Would it just add in the images to the terrain or would it start fresh and blow away my existing terrain? Thanks Greg On Jul 30, 10:43 am, Jason Beverage [EMAIL PROTECTED] wrote: Hi Greg, I would just remove the -l command line and let vpb run as long as it needs to. Depending on the level of your data, it might need to go higher than level 10. Thanks, Jason On Wed, Jul 30, 2008 at 1:33 PM, Greg Myers [EMAIL PROTECTED] wrote: Hey JP, First of all I want you to know that I really appreciate your help. :) I tried the BMNG image that covers my area of interest and that worked like a charm. No more black areas. Now, I only ran the data using a level setting of 10. When I zoom in on the high res image that I provided, it is not high res at all. Does the level setting need to be cranked way up in order to be able to see the details in the high res image? Do I need to specify layer options for my high res image like you did in your example? And one more question, what is the purpose of the archive file output type ( the -a option ) ? Thanks Greg On Jul 30, 3:33 am, J.P. Delport [EMAIL PROTECTED] wrote: Hi, sorry, I can only guess at potential problems... I am assuming you are viewing the data with osgviewer so that I can discard other cases where blending might not be set up correctly. The black portions normally indicate that something is up with the blending of data. E.g. sometimes the geotiffs have transparent areas that have to be blended with other tiles. This occurs e.g. when the tiles are not square. Since the dted data has no colour data, I'm not sure what the image data will blend with. What I would try is to use one of the BMNG tiles as a backdrop. See on the wiki for a link. The BMNG tile covers a wide area and would be used for places in the terrain where you do not supply your own higher res image data. jp GregMyerswrote: 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, GregMyerswrote: Hi JP, I'm new and
Re: [osg-users] sky model tracking the camera...
Viggo,
Thanks much...:)
-Shayne
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Viggo Løvli
Sent: Tuesday, July 29, 2008 11:56 PM
To: OpenSceneGraph Users
Subject: 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 -0600
From: [EMAIL PROTECTED]
To: osg-users@lists.openscenegraph.org
Subject: [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.
http://clk.atdmt.com/GBL/go/msnnkdre001005gbl/direct/01/
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] sky model tracking the camera...
David, Thanks for your help as well... -Shayne -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Spilling Sent: Wednesday, July 30, 2008 1:31 AM To: OpenSceneGraph Users Subject: Re: [osg-users] sky model tracking the camera... Look in the osghandglide example for MoveEarthySkyWithEyePointTransform; you will need to add the z-coordinate transform as well (currently 0.0 in the code). David 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
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. Indeed, aliasing is a big problem with vanilla shadow mapping in almost all real-world cases. What you describe can easily be done by client code, using the osgShadow::ShadowMap::clearShaderList() and osgShadow::ShadowMap::addShader() methods with the appropriate shaders. One thing that you need to be careful about when replacing the default shaders is to use the same uniform names to access the shadow map sampler and other variables. Doh! I wrote shadow map code from scratch but was based on osg::ShadowMap. My shader used 9x9 sampling (IIRC) which produced little aliasing with a slight loss of speed. Of course, 1x1 sampling can be used if the VP isn't near the shadowed object. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] transparency becomes dark
Hi Dieter, Dieter Pfeffer wrote: I supposed that it has s.th to do with the missing material paramters; my idea was to change the original material of the node, therefore I set: osg::StateSet *ss = loadedModel -getOrCreateStateSet(); osg::Material* blendMaterial = (osg::Material*)(ss-getAttribute(osg::StateAttribute::MATERIAL)); but the material is always NULL so I don't have the original material Is this the wrong function call ? The function call is correct, you're probably looking in the wrong spot ;-) I assume 'loadedModel' is the Node returned from 'readNodeFile'? If this is the case than most likely this is only a Group node that contains the rest of the scene graph. If you take a look at e.g. 'cow.osg' (or most of the examples) you'll see that the Material isn't actually attached to the top node. What you'll need to do is traverse the scene graph and find the Material node(s) you're looking for. For example you could look for a Node with a certain name and fetch it's Material. Also keep in mind that Materials are attached to StateSets which may be attached to Nodes *or* Drawables (attached to Geodes). Cheers! /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Converting a Drawable object to a Geometry object
Dear All, I would like to turn a Drawable object into a Geometry counterpart in order to retrieve its texture coordinates. I have tried to use both the asGeometry method of the Drawable class and the dynamic cast operator but both attempts ended up delivering a NULL pointer. I am not sure if there is another way of doing it. Here is a code snippet. osg::Geode myGeode = new osg::Geode; myGeode-addDrawable(new osg::ShapeDrawable(new osg::Box(osg::Vec3(),1,1,1))); osg::Drawable* myDrawable = myGeode-getDrawable(0); osg::Geometry* myGeom = myDrawable-asGeometry(); //This returns NULL! osg::Geometry* myGeom2 = dynamic_castosg::Geometry *(myDrawable); Unfortunately both myGeom and myGeom3 are both NULL at this point. What to do then, anyone to save me from embarrasment? Anxiously waiting for your reply. Franclin. - Envoyé avec Yahoo! Mail. Une boite mail plus intelligente. ___ 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 with osgUtil::LineSegmentIntersector) Make it please in the next version.
Hello stranger,
GMD GammerMaxyandex.ru wrote:
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);
}
...
The problem disappeared! Make it please in the next version.
I don't believe simply removing the code is the right answer. Although it might
solve the problem in your case it may create a problem for somebody else. The
case was put there for a purpose, namely (from svn log r8539) Added handling of
co-incident start and end points.
There were a number of other changes in that area, maybe they're causing
trouble?
Cheers,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Converting a Drawable object to a Geometry object
Franclin Foping wrote: I would like to turn a Drawable object into a Geometry counterpart in order to retrieve its texture coordinates. I have tried to use both the asGeometry method of the Drawable class and the dynamic cast operator but both attempts ended up delivering a NULL pointer. I am not sure if there is another way of doing it. Here is a code snippet. osg::Geode myGeode = new osg::Geode; myGeode-addDrawable(new osg::ShapeDrawable(new osg::Box(osg::Vec3(),1,1,1))); osg::Drawable* myDrawable = myGeode-getDrawable(0); osg::Geometry* myGeom = myDrawable-asGeometry(); //This returns NULL! osg::Geometry* myGeom2 = dynamic_castosg::Geometry *(myDrawable); Unfortunately both myGeom and myGeom3 are both NULL at this point. Sorry, but what you're trying to do is impossible, the class hierarchy isn't setup that way. What you have is: - ShapeDrawable is-a Drawable, and - Geometry is-a Drawable and what you're attempting is to cast a ShapeDrawable to a Geometry. This can never work since they don't have a parent-child relationship. The fact that they're both derived from Drawable is irrelevant for what you're attempting. Cheers! /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] glGetString returning NULL
Running latest version of OSG in SVN, calling glGetString(...) from
main render loop (single threaded osgViewer). Like this:
while(viewer.done() == false)
{
viewer.frame();
char* extensions = (char*)glGetString(GL_EXTENSIONS);
}
extensions is always NULL. Am I doing something wrong here? Could
someone else test this?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RE : Re: Converting a Drawable object to a Geometry object
Hi Ulrich, I am not sure if you have understood the code snippet I provided. I am also unsure about your C++ knowledge but I think it is better than mine. From the code (and the title of the post), it is easy to see that I am downcasting from a Drawable object to a Geometry one. The shapeDrawable is stuck to the Geode, which is not a concern here. Downcasting from a derived class to a parent class is possible with the dynamic_cast operator. From what you have written in your mail, it looks like the snippet won't compile at all, I can bet something it will as I tried it a couple of hours ago. Try it yourself and let me know. My concern in this post is not about shapedrawable. Of course, downcasting from shapedrawable to geometry would have not worked and even worse would have not compiled at all. Please have a look again at my mail and get back to me. I am sure you can find out what is going on. Regards, Franclin. Ulrich Hertlein [EMAIL PROTECTED] a écrit : Franclin Foping wrote: I would like to turn a Drawable object into a Geometry counterpart in order to retrieve its texture coordinates. I have tried to use both the asGeometry method of the Drawable class and the dynamic cast operator but both attempts ended up delivering a NULL pointer. I am not sure if there is another way of doing it. Here is a code snippet. osg::Geode myGeode = new osg::Geode; myGeode-addDrawable(new osg::ShapeDrawable(new osg::Box(osg::Vec3(),1,1,1))); osg::Drawable* myDrawable = myGeode-getDrawable(0); osg::Geometry* myGeom = myDrawable-asGeometry(); //This returns NULL! osg::Geometry* myGeom2 = dynamic_cast(myDrawable); Unfortunately both myGeom and myGeom3 are both NULL at this point. Sorry, but what you're trying to do is impossible, the class hierarchy isn't setup that way. What you have is: - ShapeDrawable is-a Drawable, and - Geometry is-a Drawable and what you're attempting is to cast a ShapeDrawable to a Geometry. This can never work since they don't have a parent-child relationship. The fact that they're both derived from Drawable is irrelevant for what you're attempting. Cheers! /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org - Envoyé avec Yahoo! Mail. Une boite mail plus intelligente. ___ 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
hi Philip Lowman! my mingw version is binutils 2.18.50 gcc 4.3.0 runtime 3.14 w32api 3.11 gdb 6.8 my msys version is core 1.0.11 thanks!!! 在2008-07-30，Philip Lowman [EMAIL PROTECTED] 写道： 2008/7/30 songbo_1220 [EMAIL PROTECTED] sorry! I was following some mistakes。 Linking CXX shared library ../../lib/libosg.dll Creating library file: ../../lib/libosg.dll.a [ 11%] Built target osg Scanning dependencies of target osgDB [ 11%] Building CXX object src/osgDB/CMakeFiles/osgDB.dir/Archive.obj f:/OpenSceneGraph/OpenSceneGraph-2.2.0/OpenSceneGraph/src/osgDB/Archive.cpp:51: internal compiler error: in maybe_emit_vtables, at cp/decl2.c:1678 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [src/osgDB/CMakeFiles/osgDB.dir/Archive.obj] Error 1 make[1]: *** [src/osgDB/CMakeFiles/osgDB.dir/all] Error 2 make: *** [all] Error 2 what can i do? thank! What version of MinGW are you using? -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RE : Re: Converting a Drawable object to a Geometry object
Hi Franclin, Downcasting from a derived class to a parent class is possible with the dynamic_cast operator. From what you have written in your mail, it looks like the snippet won't compile at all, I can bet something it will as I tried it a couple of hours ago. Try it yourself and let me know. The code is correct and will compile, it's just that the casts won't work as you expect. Okay, let's see: osg::Geode myGeode = new osg::Geode; myGeode-addDrawable(new osg::ShapeDrawable(new osg::Box(osg::Vec3(),1,1,1))); osg::Drawable* myDrawable = myGeode-getDrawable(0); myDrawable is a Drawable* to a ShapeDrawable This is fine since Drawable is a base class of ShapeDrawable. (I assume there aren't any other Drawables in myGeode and the first one is actually the ShapeDrawable you added.) osg::Geometry* myGeom = myDrawable-asGeometry(); If you take a look at 'osg::Drawable' you'll see that this actually *always* returns 0 and ShapeDrawable doesn't override it (Geometry is the only class that overrides it). However, even doing what the comment says (and what you're doing for 'myGeom2'): osg::Geometry* geom = dynamic_castosg::Geometry*(this) This cannot succeed since the *object* is-a ShapeDrawable (even though the pointer is Drawable*). Of course, downcasting from shapedrawable to geometry would have not worked and even worse would have not compiled at all. Agreed. But introducing a Drawable* doesn't help because it doesn't change the type of the object the pointer is pointing to. ShapeDrawable* shape = new ShapeDrawable(...) Drawable* drawable = dynamic_castDrawable*(shape); // OK, is a base class Geometry* geom = dynamic_castGeometry*(drawable); // is always 0 I'm probably not explaining this as clearly as possible but try to think of it this way: you have a base class 'Vehicle' and two derived classes 'Car' and 'Plane'. You can create a 'Plane' and have a 'Vehicle' pointer to it but you can't cast that pointer to a 'Car'. Hope this helps. Cheers, /ulrich ___ 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
hi Philip Lowman! You really a good man！ I have read this page, on the mingw osg compiled, http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/Mingw but feel it's too low osg version, so i didn't do that, first, i creat msys-osg using cmake, then, I made osg directness using msys-make, whether or not to do some things before makeing? thank you for your help! 在2008-07-30，Philip Lowman [EMAIL PROTECTED] 写道： 2008/7/30 songbo_1220 [EMAIL PROTECTED] sorry! I was following some mistakes。 Linking CXX shared library ../../lib/libosg.dll Creating library file: ../../lib/libosg.dll.a [ 11%] Built target osg Scanning dependencies of target osgDB [ 11%] Building CXX object src/osgDB/CMakeFiles/osgDB.dir/Archive.obj f:/OpenSceneGraph/OpenSceneGraph-2.2.0/OpenSceneGraph/src/osgDB/Archive.cpp:51: internal compiler error: in maybe_emit_vtables, at cp/decl2.c:1678 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [src/osgDB/CMakeFiles/osgDB.dir/Archive.obj] Error 1 make[1]: *** [src/osgDB/CMakeFiles/osgDB.dir/all] Error 2 make: *** [all] Error 2 what can i do? thank! What version of MinGW are you using? -- Philip Lowman ___ 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
2008/7/30 songbo_1220 [EMAIL PROTECTED] hi Philip Lowman! You really a good man！ I have read this page, on the mingw osg compiled, http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/Mingw but feel it's too low osg version, so i didn't do that, first, i creat msys-osg using cmake, then, I made osg directness using msys-make, whether or not to do some things before makeing? thank you for your help! Yes, that page is out of date. I will update it if I can figure out how to edit the darn wiki. Anyways, to compile the OSG using MinGW (with no external dependencies) here is what I do. These directions are for MinGW makefiles though and not MSYS I think. 1. Run CMake, point to source and build directory 2. Configure for MinGW Makefiles 3. Set CMAKE_BUILD_TYPE as desired 4. If and ONLY if you have OSG 2.0,2.2, or 2.4 binary packages installed you must modify JPEG_LIBRARY, TIFF_LIBRARY, etc. to blank them 4a. If you are using CMake 2.6.0, there is a bug preventing you from blanking JPEG_LIBRARY (fix in 2.6.1 or search CMake bugtracker for 2 line patch) 5. Generate 6. Run command prompt, cd to build directory 7. C:\MinGW\bin\mingw32-make If you need external dependencies presumably you'd have to obtain or compile all of the various libraries yourself. -- Philip Lowman ___ 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
2008/7/30 songbo_1220 [EMAIL PROTECTED] hi Philip Lowman! my mingw version is binutils 2.18.50 gcc 4.3.0 runtime 3.14 w32api 3.11 gdb 6.8 my msys version is core 1.0.11 thanks!!! Songbo, The GCC 4.3.0 release for MinGW is listed as alpha quality software (which could explain the internal compiler error you got). I would suggest using the current stable release of MinGW which includes GCC 3.4.5 and see if that works better. -- Philip Lowman ___ 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
Thank you very much for help, I will follow you try to do that, thank you once again ^-^ ! 在2008-07-31，Philip Lowman [EMAIL PROTECTED] 写道： 2008/7/30 songbo_1220 [EMAIL PROTECTED] hi Philip Lowman! You really a good man！ I have read this page, on the mingw osg compiled, http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/Mingw but feel it's too low osg version, so i didn't do that, first, i creat msys-osg using cmake, then, I made osg directness using msys-make, whether or not to do some things before makeing? thank you for your help! Yes, that page is out of date. I will update it if I can figure out how to edit the darn wiki. Anyways, to compile the OSG using MinGW (with no external dependencies) here is what I do. These directions are for MinGW makefiles though and not MSYS I think. 1. Run CMake, point to source and build directory 2. Configure for MinGW Makefiles 3. Set CMAKE_BUILD_TYPE as desired 4. If and ONLY if you have OSG 2.0,2.2, or 2.4 binary packages installed you must modify JPEG_LIBRARY, TIFF_LIBRARY, etc. to blank them 4a. If you are using CMake 2.6.0, there is a bug preventing you from blanking JPEG_LIBRARY (fix in 2.6.1 or search CMake bugtracker for 2 line patch) 5. Generate 6. Run command prompt, cd to build directory 7. C:\MinGW\bin\mingw32-make If you need external dependencies presumably you'd have to obtain or compile all of the various libraries yourself. -- Philip Lowman ___ 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
Jason, Thanks for the vpbmaster tip. I thought it only applied to multiple systems... I guess I need to read things a little better ;) My database creation times went down dramatically now that all 8 cores are being utilized. I went ahead and launched a build with a decent amount of imagery and DTED data before I left work. Hopefully my hard drive doesn't fill up before it gets done. I'm having another hard drive installed tomorrow so that I can run a bigger set of data over the weekend. I haven't tried creating the overviews yet. How do they help increase speed? If the explanation is more of a class than a simple response then don't worry about responding, I understand ;) Thanks for all your help! Greg On Jul 30, 11:46 am, Jason Beverage [EMAIL PROTECTED] wrote: Hi again Greg, Forgot to mention this previously... You should also try building overviews for all of your geospatial data files using the gdal utility gdaladdo if they don't already have them. Doing so can result in pretty dramatic increases in speed. Jason On Wed, Jul 30, 2008 at 2:44 PM, Jason Beverage [EMAIL PROTECTED]wrote: Hi Greg, I don't believe it is currently possible to modify a database with new imagery or terrain once a database is created. That is something that I know Robert was planning on working out at some point for osgTerrain/VPB but I'm not sure what its status is. Using the --terrain option should make things run pretty quick though depending on how much data you're throwing at it. Also, try replacing the osgdem command line with vpbmaster as it supports multiple cores and thankfully takes the exact same command line optoins as osgdem. Good luck! Jason On Wed, Jul 30, 2008 at 2:10 PM, Greg Myers [EMAIL PROTECTED] wrote: Hey Jason, Thanks for the reply. I guess I'm going to have to bite the bullet and try that out. It just takes a substantial amount of time so I hate to do it without knowing if I'm doing it right in the first place. Tell me this though, is it possible to add new images to an existing ive file? For instance, if I ran osgdem against just some plain old DTED data without images and output the results to dted.ive, could I then run another osgdem command and pass in image data using the same dted.ive file? Would it just add in the images to the terrain or would it start fresh and blow away my existing terrain? Thanks Greg On Jul 30, 10:43 am, Jason Beverage [EMAIL PROTECTED] wrote: Hi Greg, I would just remove the -l command line and let vpb run as long as it needs to. Depending on the level of your data, it might need to go higher than level 10. Thanks, Jason On Wed, Jul 30, 2008 at 1:33 PM, Greg Myers [EMAIL PROTECTED] wrote: Hey JP, First of all I want you to know that I really appreciate your help. :) I tried the BMNG image that covers my area of interest and that worked like a charm. No more black areas. Now, I only ran the data using a level setting of 10. When I zoom in on the high res image that I provided, it is not high res at all. Does the level setting need to be cranked way up in order to be able to see the details in the high res image? Do I need to specify layer options for my high res image like you did in your example? And one more question, what is the purpose of the archive file output type ( the -a option ) ? Thanks Greg On Jul 30, 3:33 am, J.P. Delport [EMAIL PROTECTED] wrote: Hi, sorry, I can only guess at potential problems... I am assuming you are viewing the data with osgviewer so that I can discard other cases where blending might not be set up correctly. The black portions normally indicate that something is up with the blending of data. E.g. sometimes the geotiffs have transparent areas that have to be blended with other tiles. This occurs e.g. when the tiles are not square. Since the dted data has no colour data, I'm not sure what the image data will blend with. What I would try is to use one of the BMNG tiles as a backdrop. See on the wiki for a link. The BMNG tile covers a wide area and would be used for places in the terrain where you do not supply your own higher res image data. jp GregMyerswrote: 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
Re: [osg-users] osg make error in mingw
Hi Philip, Yes, that page is out of date. I will update it if I can figure out how to edit the darn wiki. Pretty easy: go to http://www.openscenegraph.org/projects/osg/wiki/Community/WikiLogIn Click the Login link at the top-right of any page and use the username and password on the page linked above. Then, at the bottom of pages which that user is allowed to edit, you will have an Edit this page button. 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
