Re: [osg-users] OpenThreads/pthreads OpenMP on RHEL5.2

2008-10-16 Thread J.P. Delport

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?

2008-10-16 Thread Michal Turlik
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] OpenThreads/pthreads OpenMP on RHEL5.2

2008-10-16 Thread Robert Osfield
Hi Csaba,

On Wed, Oct 15, 2008 at 8:46 PM, Csaba Halász [EMAIL PROTECTED] wrote:
 Got it:

 int ViewerBase::run()
 {
if (!isRealized())
{
realize();
}

 But the isRealized() function doesn't really say if realize() has been
 called or not, it just checks if *any* of the gc's are realized. Our
 code happened to call realize on the gc, so the viewer's realize()
 never got called. Depending on whether it is allowed to realize gc's
 manually it is either a bug or not :)

Good detective work.  We'll need to tighten up the isRealize() function.

Robert.
___
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

2008-10-16 Thread Robert Osfield
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

2008-10-16 Thread Wojciech Lewandowski

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

2008-10-16 Thread Mathias Fröhlich

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

2008-10-16 Thread Robert Osfield
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

2008-10-16 Thread Roman Grigoriev
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

2008-10-16 Thread Jean-Sébastien Guay

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

2008-10-16 Thread Jean-Sébastien Guay

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

2008-10-16 Thread Andreas Lindmark
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

2008-10-16 Thread Juan Sebastian Casanueva
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?

2008-10-16 Thread Csaba Halász
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

2008-10-16 Thread Brede Johansen
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

2008-10-16 Thread Robert Osfield
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

2008-10-16 Thread Csaba Halász
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

2008-10-16 Thread Aitor Arrieta
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

2008-10-16 Thread Robert Osfield
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

2008-10-16 Thread Robert Osfield
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

2008-10-16 Thread Jean-Sébastien Guay

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

2008-10-16 Thread Jean-Sébastien Guay

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

2008-10-16 Thread Paul Martz
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

2008-10-16 Thread Paul Martz
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

2008-10-16 Thread Glenn Waldron
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

2008-10-16 Thread brettwiesner

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

2008-10-16 Thread Paul Martz
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

2008-10-16 Thread Jason Daly

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

2008-10-16 Thread Ortiz, Rodolfo
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