Re: [osg-users] OpenThreads/pthreads OpenMP on RHEL5.2
Hi Ralph,
if you can make a small OT vs OpenMP test app that people can run on a
variety of Linux flavours, maybe something will jump out. E.g. how
standard is the pthread lib in RHEL5.2?
jp
Ralph R. Peters wrote:
Hi Robert all,
I did the simple thing to test if the call pthread_setaffinity_np(
pthread_self(), sizeof(cpumask), cpumask) was causing OpenMP problems.
A code snippet from the function SetProcessorAffinityOfCurrentThread in
PThread.c++ follows. Changing doit from true to false and recompiling
lets me test this call.
#if defined(HAVE_PTHREAD_SETAFFINITY_NP)
std::cout SetProcessorAffinityOfCurrentThread: cpunum=
cpunumsizeof(cpumask)= sizeof(cpumask) std::endl;
bool doit = true;
if(doit)
{
pthread_setaffinity_np( pthread_self(), sizeof(cpumask),
cpumask);
std::cout SetProcessorAffinityOfCurrentThread:
pthread_setaffinity_np( pthread_self(), sizeof(cpumask), cpumask)
called immediately before this printout std::endl;
}
else
std::cout SetProcessorAffinityOfCurrentThread:
pthread_setaffinity_np( pthread_self(), sizeof(cpumask), cpumask) NOT
called immediately before this printout result
std::endl;
#elif defined(HAVE_THREE_PARAM_SCHED_SETAFFINITY)
The result was what I suspected. If the call to pthread_setaffinity_np
is NOT made then OpenMP recognizes that there are 8 processors,
otherwise it thinks that there is only 1. In both cases I used strace
-f -e sched_setaffinity -e sched_getaffinity to keep an eye on system
calls. Output for both cases is listed below.
I am just trying to use OpenMP inside an application that uses
OpenSceneGraph. What needs to be done to fix this problem, wherever it
may be, is above my current paygrade. :-)
However, getting our application (umbra -
http://robotics.sandia.gov/UMBRA.html) to use OpenMP may be important to
many of us.
Thanks,
Ralph
Call pthread_setaffinity_np:
camera number: 0
SetProcessorAffinityOfCurrentThread: cpunum=0 sizeof(cpumask)=128
sched_getaffinity(32493, 128, { ff, 0, 0, 0 }) = 32
SetProcessorAffinityOfCurrentThread: pthread_setaffinity_np(
pthread_self(), sizeof(cpumask), cpumask) called immediately before
this printout
INFO navigation mode set to umbra
Warning: font file fonts/arial.ttf not found.
Setting savConfigCB to '::guiWrapper saveConfig'
sched_getaffinity(32493, 128, { 1, 0, 0, 0 }) = 32
sLoadFile filename:/home/vision_data/geometry_objects/test.cdf
fileType: lineRowCnt=-1 lineColCnt=-1
std::string UmbModCDFDataSet::LoadFile(const s
Enter test_openmp()
sched_getaffinity(32493, 128, { 1, 0, 0, 0 }) = 32
OPENMP is 200505 Number of processors available:1 MAX number of OpenMP
threads 1
GOMP_CPU_AFFINITY is unknown
Exit test_openmp()
do NOT call pthread_setaffinity_np:
camera number: 0
SetProcessorAffinityOfCurrentThread: cpunum=0 sizeof(cpumask)=128
SetProcessorAffinityOfCurrentThread: pthread_setaffinity_np(
pthread_self(), sizeof(cpumask), cpumask) NOT called immediately before
this printout result
INFO navigation mode set to umbra
Warning: font file fonts/arial.ttf not found.
Setting savConfigCB to '::guiWrapper saveConfig'
sched_getaffinity(1393, 128, { ff, 0, 0, 0 }) = 32
sLoadFile filename:/home/vision_data/geometry_objects/test.cdf
fileType: lineRowCnt=-1 lineColCnt=-1
std::string UmbModCDFDataSet::LoadFile(const s
Enter test_openmp()
sched_getaffinity(1393, 128, { ff, 0, 0, 0 }) = 32
OPENMP is 200505 Number of processors available:8 MAX number of OpenMP
threads 8
GOMP_CPU_AFFINITY is unknown
Exit test_openmp()
___
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
[osg-users] is it possible to compile osg with mingw?
Hi, I am trying to compile osg with mingw. After have compiled the cmake I obtein a message stating the M$ VS 6 is required. Sincerly I do not use VS nor any M$ software, I thought configure should work just by letting it check required deps. I found and outdated howto but I suppose it is no longer usefull. Thanks for any help. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] infinite block with CullThreadPerCameraDrawThreadPerContext
Hi Csaba, Given the provided details I don't have enough to provide an clues to what might be up. Try different threading models to see what results you get. Also try the standard OSG examples to see if any of them hang. Robert. On Wed, Oct 15, 2008 at 9:58 PM, Csaba Halász [EMAIL PROTECTED] wrote: Hi again, Now that I got threading running, I have run into this trouble: draw() 0xee0b20 draw() got SceneView 0xf18a80 end draw() 0xee0b20 draw() 0xda1f80 cull() cull() got SceneView 0xf03e90 end cull() 0xee0b20 cull() cull() got SceneView 0xf7b020 _clampProjectionMatrix not applied, invalid depth range, znear = 3.40282e+38 zfar = -3.40282e+38 end cull() 0xda1f80 draw() got SceneView 0xf7b020 end draw() 0xda1f80 draw() 0xee0b20 draw() got SceneView 0xf03e90 end draw() 0xee0b20 draw() 0xda1f80 cull() cull() got SceneView 0xf84a20 _clampProjectionMatrix not applied, invalid depth range, znear = 3.40282e+38 zfar = -3.40282e+38 end cull() 0xda1f80 draw() got SceneView 0xf84a20 cull() cull() got SceneView 0xf18a80 end cull() 0xee0b20 end draw() 0xda1f80 draw() 0xee0b20 draw() got SceneView 0xf18a80 end draw() 0xee0b20 draw() 0xda1f80 It stops here. (gdb) thr 5 [Switching to thread 5 (Thread 0x420a5950 (LWP 28584))]#0 0x2ae3f4c89b99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x2ae3f4c89b99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x2ae3f7a55c56 in OpenThreads::Condition::wait (this=value optimized out, mutex=value optimized out) at /home/hcs/src/OpenSceneGraph/src/OpenThreads/pthreads/PThreadCondition.c++:137 #2 0x2ae3f68d0bd3 in osgViewer::Renderer::TheadSafeQueue::takeFront (this=0x10f8a78) at /home/hcs/src/OpenSceneGraph/include/OpenThreads/Block:42 #3 0x2ae3f68d25de in osgViewer::Renderer::draw (this=0x10f8980) at /home/hcs/src/OpenSceneGraph/src/osgViewer/Renderer.cpp:340 #4 0x2ae3f772eac4 in osg::GraphicsContext::runOperations (this=0x10f99a0) at /home/hcs/src/OpenSceneGraph/src/osg/GraphicsContext.cpp:688 #5 0x2ae3f776c688 in osg::OperationThread::run (this=0x11cd6c0) at /home/hcs/src/OpenSceneGraph/src/osg/OperationThread.cpp:413 #6 0x2ae3f77351c0 in osg::GraphicsThread::run (this=0x11cd6c0) at /home/hcs/src/OpenSceneGraph/src/osg/GraphicsThread.cpp:38 #7 0x2ae3f7a55537 in OpenThreads::ThreadPrivateActions::StartThread (data=value optimized out) at /home/hcs/src/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:172 #8 0x2ae3f4c853f7 in start_thread () from /lib/libpthread.so.0 #9 0x2ae3f839497d in clone () from /lib/libc.so.6 #10 0x in ?? () Any ideas? -- Thanks, Csaba ___ 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] Advice on interacting with osgShadow
J-S and All, After a sleep I have taken another look at the subject and I would like to propose other approach: In general I doubt I will be able to foresee all types of problems and doubt I could add flags to suppress all responsible pieces of code. On the other hand all such problems could be solved by overriding proper shadow technique class. So as general recommedation I would suggest overriding one of the ViewDependentShadow classes and their associated ViewData class when defaults setttings not work. However, I understand that overridng proper Shadow class and their ViewData might be bit more complicated than overriding simpler things like node callback. So as a mid-solution for those lazy or those who don't know how to override a class, I would propose adding SetShadowMapCameraSettingsCallback. If added, this calback will be called whenever shadow camera stateset is filled, if not added default settings will be applied. This way if one needs to change some setings he may simply override calback and make it their way. Does it sound reasonable ? Wojtek -Original Message- From: Jean-Sébastien Guay [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2008 10:21 PM To: [EMAIL PROTECTED]; OpenSceneGraph Users Subject: Re: [osg-users] Advice on interacting with osgShadow Hi Wojtek, Turning on AlphaTest/AlphaFunc is not mutually exclusive with RenderBin override. I don't want to make decision that has to be its either this or that. I would like to leave RenderBin override as default. I would also add setShadowMapRenderingSettings/getShadowMapRenderingSettings methods to allow user turn it off if he decides. So my conclusion is I would like to add the submission as sent to the codebase. Excellent, I agree with this. I tested your code and it works for me, so you can send it to osg-submissions whenever you want. I could suggest that instead of using OVERRIDE_RENDER_BINS_WITH_OPAQUE_BIN = 1, SET_COLOR_MASK_TO_FALSE = 2, you use the bit shift notation, which I find easier to read and maintain (and please align the values... :-) ): OVERRIDE_RENDER_BINS_WITH_OPAQUE_BIN = 1 0, SET_COLOR_MASK_TO_FALSE = 1 1, SOME_OTHER_SETTING = 1 2, but that's just a style issue and subject to personal taste. Also you could add a doxygen comment for the ShadowMapRenderingSettings enum, which would explain what the values are useful for. Otherwise, it's pretty cryptic for users (unless they search the mailing lists and find this thread :-) ). 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with translparency in ac3d model loaded in OSG
Hi, On Thursday 16 October 2008 12:38, Robert Osfield wrote: It sounds like the ac3d loader hasn't placed your canopy in the transparent bin. I'm not the author of this loader, nor a user of ac3d so I can't really help on the low level details. You'll need to look at the ac3d plugin to see if there if what is going on w.r.t binning your data, or if you want others to ptich in a help solve the problem you'll need to provide an example dataset that illustrates the problem. Well, these objects are placed in the transparent bin by the ac3d loader. Common problems: * The objects are that big, that the by drawable depth sorting algorithm cannot fix these dept ordering problems. Note that the sorting is done per drawable and not per triangle. * Partly transparent textures on some objects will move that object into the transparent bin. If such objects are too huge then sorting might lead to strange effects. Avoid textures that have any transparent pixel if you do not need that. If these are not the case, please provide a test case ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] infinite block with CullThreadPerCameraDrawThreadPerContext
HI Csaba, On Thu, Oct 16, 2008 at 1:29 PM, Csaba Halász [EMAIL PROTECTED] wrote: The other threading models seem to work, and the osg camera example works with CullThreadPerCameraDrawThreadPerContext too. I wonder if the problem reported by Paul in the mail thread Please test SVN of OpenSceneGraph in prep for 2.7.3 dev release may be related to this one. I have been able to reproduce that with an older nvidia driver, but since I upgraded to 177.80 osgcamera works ok. I suspect the particular problem you are seeing is not directly driver related, but is an OSG bug, differences in drivers might change the timing slightly which leads to the problem not becoming visible, but may well still be lurking. If I read the code right, during a frame all threads enter through the _startRenderingBarrier, then the cull threads do the work while the matching draw threads are blocked, then finally the draw is done. The way I see it, one of the draw threads is still blocked waiting for the cull to happen. I'll try to add some more debug printouts, but I am still open to ideas :) CullThreadPerCameraDrawThreadPerContext is the most complex of all the osgViewer threading models, and with it the widest range of different thread/barrier combinations. It could be that you are using a combination of cameras/contexts that hasn't been tested before, or simply that the timing of threads in your case breaks the setup. Without being able to reproduce the problem at my end there isn't too much I can do to help out debug it. Could you have a bash at recreating the problem with an existing OSG example such as osgcamera or osgwindows? Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Event Handler
Good day! I'd like to ask about event handler I need to implement event handler that handles event, for example if event==true - open dialog box What is the best technique to loads dialogs using events? Thanx in advance Bye ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StateSet - newbie
Hello Sajjad, You seem to be confused on the usage of pointers and when you're required to make a copy of an object. I suggest you review a good C++ book to get a good grasp of these concepts, because writing good OSG code kind of requires that you know how to write good C++ code. ref_ptrShader capsuleVertexObject = new Shader(*(Shader::**readShaderFile(Shader::VERTEX,**shaderSRC/gooch.vert))); ref_ptrShader capsuleFragmentObject = new Shader(*(Shader::**readShaderFile(Shader::**FRAGMENT,shaderSRC/gooch.**vert))); This would be sufficient: osg::ref_ptrosg::Shader capsuleVertexObject = osg::Shader::readShaderFile(osg::Shader::VERTEX, shaderSRC/gooch.vert); or osg::ref_ptrosg::Shader capsuleVertexObject = new osg::Shader(osg::Shader::VERTEX); capsuleVertexObject-loadShaderSourceFromFile( shaderSRC/gooch.vert); In your original code, you were calling readShaderFile() (which creates the osg::Shader object and returns a pointer) and then creating a new (empty) shader, and copying the other shader into it. This is not only unnecessary, but it would probably introduce a memory leak because the shader returned by readShaderFile() is never put into a ref_ptr, so it will never be deleted. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi Wojtek, However, I understand that overridng proper Shadow class and their ViewData might be bit more complicated than overriding simpler things like node callback. So as a mid-solution for those lazy or those who don't know how to override a class, I would propose adding SetShadowMapCameraSettingsCallback. If added, this calback will be called whenever shadow camera stateset is filled, if not added default settings will be applied. This way if one needs to change some setings he may simply override calback and make it their way. I don't think it's being lazy to not want to override a shadow class. It's pretty specialized stuff, and if your overridden class does something wrong it's very easy to cause more problems than you fix. In essence, I think the number of users able to correctly derive from a shadow class to fix some behavior in the original class is pretty small. Not everyone is an experienced OpenGL / real-time graphics developer. Most just want to use OSG and want it to work without having to know the details. So I'm not sure if the callback mechanism is better than options as you suggested yesterday. One is very focused, the other is very general. Yes, the callback is more future-proof, but imagine someone who has the same problem as I do. They look at the shadow classes, and they see that they support a SetShadowMapCameraSettingsCallback. What do they do with that? What does the callback have to be? Plus, they will have to set all other settings (which they don't need to change) just to disable one setting... There's too much chance they might make a mistake. On the other hand, the options you suggested yesterday is much simpler for a user, and we can even document what each setting does, and when you might need to enable/disable it. I think this is more useful to a user who just has a problem and wants to solve it. I think it's important to keep in mind that OSG evolves with the needs of its users, so you don't have to predict all the settings that might need to be disabled. We can add others as they are needed. Finally, I'll also remind you that from my point of view, adding AlphaFunc into some statesets in my objects would be a good solution as well, so if you're not comfortable with the options and the callback mechanism, we can just drop the issue. I think my case was pretty specific to our models. If we ever get some other report of the same behavior, we can do something then... It's up to you. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgUtil::RenderStage for selective lighting
Hi, Im currently working on what is basically the same problem. We want to be able to have more than 8 lights in a scene and we want objects to be lit by the N most influential lights. We have decided not to support fixed function pipeline. Instead of osg::LightSource/osg::Light we have a single custom Light node that is registered with our LightManager. Each object that is lit queries the lightmanager for the N most influential lights, similar to what your doing. Uniforms are set based on the lights (gl_LightSource is not used) and the shader loops over lights. //Shader pseudo code for each light L in lights if L is directional do directional_light else if L is point do point_light else do spotlight The last part is not fully implemented yet and im a bit worried about how it will perform. Currently the uniforms are set during the cull traversal by using a callback on the drawables, but im not sure that this is the best or even a good way of doing it. Is it better to do a a separate traversal by implementing a NodeVisitor? /Andreas Lindmark 2008/10/13 Daniel Rowe [EMAIL PROTECTED] Hi everyone, This is my first post to osg-users, and I'd like to thank everyone who has contributed to OpenSceneGraph. I have found it to be indispensable. Currently I am modifying a Delta3D-based engine to select the most influential lights around an object, to allow our artists to place any number of lights in a scene without being restrained by the usual cap of 8 lights. The algorithm is as follows: Upon being added to the scene, LightSources register themselves with the LightManager. Each lit object queries the LightManager for the 4 most influential lights (based on proximity and light intensity) during the Update traversal and assigns the appropriate shader to the node, such as the 1 directional 1 spot 2 point light shader, the 2 directional 0 spot 1 point light shader, etc. The final problem I have to solve is to figure out how to get the correct lights into the correct order that the shaders will expect them in. I want to be able to ignore the default light number of the 4 light sources I'm using and be able to set them manually. However, this has proven difficult, since many lights will need multiple different indices, and assigning this in the update callback as I had originally planned would mean that every change except the last one would be overwritten. My first option is to write shaders with a list of uniforms for each light, and set the uniforms in the expected order. I have shied away from this approach for now to avoid bloated shaders, since GLSL has built-in uniforms for OpenGL lights. The second option, from what I've gathered, is to leverage osgUtil::RenderStage. As I see it, I'm going to need to clone the lights (managing them myself without adding them to the scene), re-number them appropriately, and add them to their own RenderStage, which also contains the lit object. I've dug extensively through past threads looking for information on RenderStage and selective lighting, but unfortunately I'm still somewhat clueless as to how the back end of the rendering works as a whole. How do RenderBins fit into this equation? Will I have to find a way to rip the lit object out of the default RenderStage and throw it into mine? Is this even a good approach, or is there a more elegant method I could use? Am I missing the point completely? Thanks in advance, everyone! - Daniel Rowe ___ 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] problem with translparency in ac3d model loaded in OSG
Hi, I am doing an aircraft 3d model, using the Ac3d modeller, and I am having problems with the transparent canopy in OSG. In Ac3d, the canopy is transparent and you can see the cockpit inside. This is achieved by puting the tranparent cockpit last in the object hierarchy. However, when I use osgviewer to load the ac3d model, some of the cockpit elements (pilot, seat, etc..) dissapear and reappear when you move the camera. Has anybody had this problem before? anybody know how to solve this problem? thanks very much Juan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] is it possible to compile osg with mingw?
On Thu, Oct 16, 2008 at 10:07 AM, Michal Turlik [EMAIL PROTECTED] wrote: Hi, I am trying to compile osg with mingw. After have compiled the cmake I obtein a message stating the M$ VS 6 is required. Yes, I have it working. Not sure what message you get and where. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DDS textures flipped on flt files
Hi Brett, Use the dds_flip reader option e.g. osgviewer -O dds_flip test.flt regards, Brede On Wed, Oct 15, 2008 at 4:38 PM, brettwiesner [EMAIL PROTECTED] wrote: Hi, I have a sample terrain that shows that DDS textures are incorrect on flt files. If you load up the flt file in osgviewer you should see a framed terrain. However, the textures are flipped (it seems only vertically). Thanks, Brett ___ 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] problem with translparency in ac3d model loaded in OSG
Hi Juan, It sounds like the ac3d loader hasn't placed your canopy in the transparent bin. I'm not the author of this loader, nor a user of ac3d so I can't really help on the low level details. You'll need to look at the ac3d plugin to see if there if what is going on w.r.t binning your data, or if you want others to ptich in a help solve the problem you'll need to provide an example dataset that illustrates the problem. Please note that the OSG the order in the scene graph makes no difference to rendering order as state sorting and bin assignment will dictate the rendering order. This means if you want a specific rendering order you'll need to use bins to order them. Robert. On Thu, Oct 16, 2008 at 10:35 AM, Juan Sebastian Casanueva [EMAIL PROTECTED] wrote: Hi, I am doing an aircraft 3d model, using the Ac3d modeller, and I am having problems with the transparent canopy in OSG. In Ac3d, the canopy is transparent and you can see the cockpit inside. This is achieved by puting the tranparent cockpit last in the object hierarchy. However, when I use osgviewer to load the ac3d model, some of the cockpit elements (pilot, seat, etc..) dissapear and reappear when you move the camera. Has anybody had this problem before? anybody know how to solve this problem? thanks very much Juan ___ 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] infinite block with CullThreadPerCameraDrawThreadPerContext
On Thu, Oct 16, 2008 at 2:42 PM, Robert Osfield [EMAIL PROTECTED] wrote: CullThreadPerCameraDrawThreadPerContext is the most complex of all the osgViewer threading models, and with it the widest range of different thread/barrier combinations. It could be that you are using a combination of cameras/contexts that hasn't been tested before, or simply that the timing of threads in your case breaks the setup. Without being able to reproduce the problem at my end there isn't too much I can do to help out debug it. Could you have a bash at recreating the problem with an existing OSG example such as osgcamera or osgwindows? I can bash all I want, those work :) My investigation seems to indicate that draw() is called twice for a camera: Start frame3 cull() for camera GUI 0xf15aa0 cull() for camera GUI 0xf15aa0 got SceneView 0xf12c00 cull() for camera unnamed1 0xf15fd0 cull() for camera unnamed1 0xf15fd0 got SceneView 0xf1aa50 cull() for camera GUI 0xf15aa0 done for SceneView 0xf12c00 end cull() for camera GUI 0xf15aa0 _clampProjectionMatrix not applied, invalid depth range, znear = 3.40282e+38 zfar = -3.40282e+38 cull() for camera unnamed1 0xf15fd0 done for SceneView 0xf1aa50 end cull() for camera unnamed1 0xf15fd0 draw() for camera unnamed1 0xf15fd0 draw() for camera unnamed1 0xf15fd0 got SceneView 0xf1aa50 glGetString(GL_RENDERER)==GeForce 8600M GT/PCI/SSE2 draw() for camera unnamed1 0xf15fd0 done for SceneView 0xf1aa50 end draw() for camera unnamed1 0xf15fd0 draw() for camera GUI 0xf15aa0 draw() for camera GUI 0xf15aa0 got SceneView 0xf12c00 draw() for camera GUI 0xf15aa0 done for SceneView 0xf12c00 end draw() for camera GUI 0xf15aa0 draw() for camera unnamed1 0xf15fd0 Huh, unnamed1 was already drawn during this frame. I guess that is not normal? I will try to get a backtrace now. -- Csaba ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes
Hi J-S and Paul Thanks a lot for your reply. I would like to be able to have a correct model from the beginning but unfortunately I must use a given obj file... So I don't have any option but trying to solve my problem by code. I have been doing some tests today and at this moment I'm able to separate the two geometries applying different textures for each of them and sharing the same vertex array but with different primitive sets. I'm still having some problems with the vertices near the neck but I think that I know how to solve them. Let's wait until tomorrow... I'm also having some strange problems with the light or something like that because I only see the textures from the back of the human figure. If I see the figure from the front everything is black... It's strange because when I had only a single geometry everything was ok and I have not set anything about lights after that... Maybe it could be a problem with the normals but if I remove the normal array from the geometries the problem is still there. Do you know what could be happenning? Thank you very much for your help. Regards, Aitor - Mensaje original De: Jean-Sébastien Guay [EMAIL PROTECTED] Para: OpenSceneGraph Users osg-users@lists.openscenegraph.org Enviado: miércoles, 15 de octubre, 2008 16:29:59 Asunto: Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes Hi Aitor, I can't use your code because I don't create new geometries. Instead of this, I get an osg::geode from an obj file. At this moment, I can only get a single geometry from the geode and apply a single texture to it. But this is not what I want. The obj file represents a human figure, and I would like to separate the head from the body because they have different textures. I know which vertices are from the head and which ones for the body so this won't be a problem in this case. The problem is that they must share the same vertex array, which is used to do some morph tasks. My question is, how can I create two different geometries starting from the same geode and sharing the same vertex array? Is this possible or not? Your life would be simpler if you could get a correct model as soon as you load it, instead of trying to massage it (and how you massage it might change from one model to the next). However, yes, what you ask is possible. You can traverse your model to the Geode which contains the Geometry, then create new Geometry objects, attach them to the Geode, and remove the original one. The new Geometry objects can reference the original one's vertex arrays, and then when you remove the original one from the Geode the vertex arrays won't be deleted because other Geometry objects reference them. Then on your new Geometry object(s), you can do what you want. So you could add primitive sets for the correct vertices to be used, you could add texture coordinate arrays (or reuse those from the original Geometry object), etc. As I said, it's a lot of trouble. If you can get a valid model right away, your life will be easier. It's not the kind of thing that's best done in code... Modeling tools are specialized in manipulating these kinds of things... 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes
Hi Aitor, Can't you use the a modelling tool yourself and fix the model? Robert. On Thu, Oct 16, 2008 at 4:59 PM, Aitor Arrieta [EMAIL PROTECTED] wrote: Hi J-S and Paul Thanks a lot for your reply. I would like to be able to have a correct model from the beginning but unfortunately I must use a given obj file... So I don't have any option but trying to solve my problem by code. I have been doing some tests today and at this moment I'm able to separate the two geometries applying different textures for each of them and sharing the same vertex array but with different primitive sets. I'm still having some problems with the vertices near the neck but I think that I know how to solve them. Let's wait until tomorrow... I'm also having some strange problems with the light or something like that because I only see the textures from the back of the human figure. If I see the figure from the front everything is black... It's strange because when I had only a single geometry everything was ok and I have not set anything about lights after that... Maybe it could be a problem with the normals but if I remove the normal array from the geometries the problem is still there. Do you know what could be happenning? Thank you very much for your help. Regards, Aitor - Mensaje original De: Jean-Sébastien Guay [EMAIL PROTECTED] Para: OpenSceneGraph Users osg-users@lists.openscenegraph.org Enviado: miércoles, 15 de octubre, 2008 16:29:59 Asunto: Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes Hi Aitor, I can't use your code because I don't create new geometries. Instead of this, I get an osg::geode from an obj file. At this moment, I can only get a single geometry from the geode and apply a single texture to it. But this is not what I want. The obj file represents a human figure, and I would like to separate the head from the body because they have different textures. I know which vertices are from the head and which ones for the body so this won't be a problem in this case. The problem is that they must share the same vertex array, which is used to do some morph tasks. My question is, how can I create two different geometries starting from the same geode and sharing the same vertex array? Is this possible or not? Your life would be simpler if you could get a correct model as soon as you load it, instead of trying to massage it (and how you massage it might change from one model to the next). However, yes, what you ask is possible. You can traverse your model to the Geode which contains the Geometry, then create new Geometry objects, attach them to the Geode, and remove the original one. The new Geometry objects can reference the original one's vertex arrays, and then when you remove the original one from the Geode the vertex arrays won't be deleted because other Geometry objects reference them. Then on your new Geometry object(s), you can do what you want. So you could add primitive sets for the correct vertices to be used, you could add texture coordinate arrays (or reuse those from the original Geometry object), etc. As I said, it's a lot of trouble. If you can get a valid model right away, your life will be easier. It's not the kind of thing that's best done in code... Modeling tools are specialized in manipulating these kinds of things... 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 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] Simplifier algorithm
Hi Paul, On Thu, Oct 16, 2008 at 5:01 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi all -- I've encountered several models recently that don't appear to simplify as I would expect. This makes me curious about the Simplifier, the algorithm it employs and what its limitations might be. The algorithm implemented is a basic edge collapse algorithm, where edges are collapsed according to which edges produce the least error when removed. There are number of online papers that I reviewed before writing the Simplifier, but I'm afraid I didn't keep the URL's around. The focus of the simplifier when I wrote it was in support of terrain simplification. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes
Hi Aitor, I'm also having some strange problems with the light or something like that because I only see the textures from the back of the human figure. If I see the figure from the front everything is black... It's strange because when I had only a single geometry everything was ok and I have not set anything about lights after that... Maybe it could be a problem with the normals but if I remove the normal array from the geometries the problem is still there. Do you know what could be happenning? Did you copy the other arrays from the original Geometry object to the new one(s)? The normal array and color arrays need to be copied, and normalBinding and colorBinding need to be set to BIND_PER_VERTEX. Actually, I think just cloning the original Geometry object, removing any PrimitiveSets it had, and then adding new ones would work best, least chance to make a mistake copying things yourself. 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] Sharing Vertex Arrays between Geometry Nodes
Hi Robert, Can't you use the a modelling tool yourself and fix the model? We've been over this with him (Paul and I mostly). We've explained why fixing the model directly in a modeling tool would be preferable, what the tradeoffs are, etc. If at this point he's decided to proceed this way, I think we have to have confidence that he's willing to accept the consequences, and help him to get it to work. Just my opinion of course. 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] Simplifier algorithm
Thanks, Robert -- It looked like you wrote it from the ChangeLog, but I wasn't sure, hence the general post to the list. -Paul Hi Paul, On Thu, Oct 16, 2008 at 5:01 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi all -- I've encountered several models recently that don't appear to simplify as I would expect. This makes me curious about the Simplifier, the algorithm it employs and what its limitations might be. The algorithm implemented is a basic edge collapse algorithm, where edges are collapsed according to which edges produce the least error when removed. There are number of online papers that I reviewed before writing the Simplifier, but I'm afraid I didn't keep the URL's around. The focus of the simplifier when I wrote it was in support of terrain simplification. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Simplifier algorithm
Robert -- Thanks for the previous explanation. I believe that the EdgeCollapse is confused about its definition of an error. I've attached two nearly identical models. To simplify them: osgconv --simplify .3 sgood.osg sgood-out.osg osgconv --simplify .3 sbad.osg sbad-out.osg sgood.osg simplifies as I would expect -- the center edge collapses, and the model retessellates. The model sbad.osg does not simplify at all. Note, however, that if the analogous center edge were removed from sbad.osg, and the model retessellated (as was done for sgood.osg), the resulting model would be identical in appearance to the original. Thus, collapsing sbad.osg's center edge would not introduce any error to the model. That right angle along the x-axis in sbad.osg appears to make the EdgeCollapse class incorrectly conclude that removing the center edge would introduce an error, when, in fact, it would not. I understand the Simplifier is used by VPB for terrain. However, I'm wondering if it could be enhanced to handle the sbad.osg model. I can probably spend a few hours digging in. I'd appreciate any pointers (yes, I know it's been a while since you coded it :-). Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 sbad.osg Description: Binary data sgood.osg Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer with 2 overlay nodes
Rodolfo, You probably need to set a different texture unit for each overlay; see OverlayNode::setOverlayTextureUnit(2) for the second overlay node. Just a guess.. -gw On Thu, Oct 16, 2008 at 1:48 PM, Ortiz, Rodolfo [EMAIL PROTECTED] wrote: Hello, This may be a silly question, but is it possible to have more than one OverlayNode in a scene? I ran a quick test using osganimate.cpp and I get strange results (see JPEG). I would expect to see two planes, each one projected to a different base. Instead, I get two planes, but with one plane projected to both bases (and no projection for the other one). By having 2 overlayNodes in my application, I can have the ability to highlight one node but not the other. My main changes to osganimate are: osgSim::OverlayNode* overlayNode = newosgSim::OverlayNode(technique); overlayNode-setContinuousUpdate(true); overlayNode-setOverlaySubgraph(movingModel); overlayNode-setOverlayBaseHeight(baseHeight-0.01); overlayNode-addChild(baseModel); root-addChild(overlayNode); osgSim::OverlayNode* overlayNode2 = newosgSim::OverlayNode(technique); overlayNode2-setContinuousUpdate(true); overlayNode2-setOverlaySubgraph(movingModel2); overlayNode2-setOverlayBaseHeight(baseHeight-0.01); overlayNode2-addChild(baseModel2); root-addChild(overlayNode2); Am I missing something in the code? I am using osg2.6.0 with WindowsXP SP3, thanks, -Rodolfo This e-mail, including any attachments, contains information intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and/or confidential or is otherwise protected by law. If you are not the intended recipient or agent or an employee responsible for delivering the communication to the intended recipient, you are hereby notified that any review, use, disclosure, copying and/or distribution of its contents is prohibited. If you have received this e-mail in error, please notify us immediately by reply to sender only and destroy the original. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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
[osg-users] Another case for extendable plugin loaders... Was Re: DDS textures flipped on flt files
Hey, Since most DDS textures are going to come in flipped (ie: directX style and not openGL style) I would like my application to always pass the dds_flip option to the DDS loader. If I could extend the DDS loader I could do that. Just another case for including the loaders as actual libs and the plugins themselves as smaller projects that just use the loaders api. Thanks, Brett Gordon Tomlinson wrote: This could be the way the DDS files have been generated, a lot of DDS creation tools by default start with 0,0 top left instead of top bottom (or the other way round) to the norm in vis-sim imagery, This has been covered before on the list and a search will most likely pop out how you can fix this, tools supplied with things like Creator /VegaPrime make sure the correct 0,0 is chosen, so check you DDS creation tool and re-gen with the 0,0 origin flipped __ Gordon Tomlinson [EMAIL PROTECTED] IM: [EMAIL PROTECTED] www.vis-sim.com www.gordontomlinson.com __ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of brettwiesner Sent: Wednesday, October 15, 2008 10:38 AM To: OpenSceneGraph Users Subject: [osg-users] DDS textures flipped on flt files Hi, I have a sample terrain that shows that DDS textures are incorrect on flt files. If you load up the flt file in osgviewer you should see a framed terrain. However, the textures are flipped (it seems only vertically). Thanks, Brett ___ 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] Simplifier algorithm
My investigation with the sbad.osg model reveals that the Simplifier is not removing the centermost edge because it thinks it is a boundary edge. It thinks this because the two vertices are repeated twice in the model, each time with a different normal. The Simplifier encounters the edge twice, each time with only one triangle. If I go in and hack the model to use the same normal everywhere (as in the sgood.osg model), then the Simplifier encounters the edge once, with two triangles (one on either side), and does not consider it a boundary edge, and proceeds to collapse it. I can see the value in not collapsing boundary edges for the purpose of generating terrain tiles. However, I wonder if there is some value in providing a mode that would allow boundary edges to be collapsed? I'll run some tests and see if I can obtain good results with some trivial changes. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Thursday, October 16, 2008 11:40 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] Simplifier algorithm Robert -- Thanks for the previous explanation. I believe that the EdgeCollapse is confused about its definition of an error. I've attached two nearly identical models. To simplify them: osgconv --simplify .3 sgood.osg sgood-out.osg osgconv --simplify .3 sbad.osg sbad-out.osg sgood.osg simplifies as I would expect -- the center edge collapses, and the model retessellates. The model sbad.osg does not simplify at all. Note, however, that if the analogous center edge were removed from sbad.osg, and the model retessellated (as was done for sgood.osg), the resulting model would be identical in appearance to the original. Thus, collapsing sbad.osg's center edge would not introduce any error to the model. That right angle along the x-axis in sbad.osg appears to make the EdgeCollapse class incorrectly conclude that removing the center edge would introduce an error, when, in fact, it would not. I understand the Simplifier is used by VPB for terrain. However, I'm wondering if it could be enhanced to handle the sbad.osg model. I can probably spend a few hours digging in. I'd appreciate any pointers (yes, I know it's been a while since you coded it :-). 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] Another case for extendable plugin loaders... Was Re:DDS textures flipped on flt files
brettwiesner wrote: Hey, Since most DDS textures are going to come in flipped (ie: directX style and not openGL style) I would like my application to always pass the dds_flip option to the DDS loader. If I could extend the DDS loader I could do that. Just another case for including the loaders as actual libs and the plugins themselves as smaller projects that just use the loaders api. It's easy enough to hard code a ReaderWriter option: options = new osgDB::ReaderWriter::Options(dds_flip); texImage = osgDB::readImageFile(filename, options); You might want to use a ref_ptr for the options object, but basically, the above should work. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer with 2 overlay nodes
That did the trick, thanks, -Rodolfo From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Waldron Sent: Thursday, October 16, 2008 12:09 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Viewer with 2 overlay nodes Rodolfo, You probably need to set a different texture unit for each overlay; see OverlayNode::setOverlayTextureUnit(2) for the second overlay node. Just a guess.. -gw On Thu, Oct 16, 2008 at 1:48 PM, Ortiz, Rodolfo [EMAIL PROTECTED] wrote: Hello, This may be a silly question, but is it possible to have more than one OverlayNode in a scene? I ran a quick test using osganimate.cpp and I get strange results (see JPEG). I would expect to see two planes, each one projected to a different base. Instead, I get two planes, but with one plane projected to both bases (and no projection for the other one). By having 2 overlayNodes in my application, I can have the ability to highlight one node but not the other. My main changes to osganimate are: osgSim::OverlayNode* overlayNode = new osgSim::OverlayNode(technique); overlayNode-setContinuousUpdate(true); overlayNode-setOverlaySubgraph(movingModel); overlayNode-setOverlayBaseHeight(baseHeight-0.01); overlayNode-addChild(baseModel); root-addChild(overlayNode); osgSim::OverlayNode* overlayNode2 = new osgSim::OverlayNode(technique); overlayNode2-setContinuousUpdate(true); overlayNode2-setOverlaySubgraph(movingModel2); overlayNode2-setOverlayBaseHeight(baseHeight-0.01); overlayNode2-addChild(baseModel2); root-addChild(overlayNode2); Am I missing something in the code? I am using osg2.6.0 with WindowsXP SP3, thanks, -Rodolfo This e-mail, including any attachments, contains information intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and/or confidential or is otherwise protected by law. If you are not the intended recipient or agent or an employee responsible for delivering the communication to the intended recipient, you are hereby notified that any review, use, disclosure, copying and/or distribution of its contents is prohibited. If you have received this e-mail in error, please notify us immediately by reply to sender only and destroy the original. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 This e-mail, including any attachments, contains information intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged and/or confidential or is otherwise protected by law. If you are not the intended recipient or agent or an employee responsible for delivering the communication to the intended recipient, you are hereby notified that any review, use, disclosure, copying and/or distribution of its contents is prohibited. If you have received this e-mail in error, please notify us immediately by reply to sender only and destroy the original.___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
