[osg-users] Test post, very strange

[Chris 'Xenon' Hanson]

  I'm posting to see if this message shows up.

  Oddly, a message I've tried to send to the list three times over the past few 
weeks,
refuses to appear here. But my other replies seem to show up.

  Is there any sort of content-based filtering that might be eating my message?

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] OpenFlight plugin and static linking

[Chris 'Xenon' Hanson]

Gregory Jaegy wrote:
> Finally, in your own project, include the OpenFlight plugin "record.h" file, 
> and after the "USE_PLUGIN" macros add the following ones (one per record 
> type):
> Code:
> USE_FLTRECORD(Comment, COMMENT_OP);
...
> USE_FLTRECORD(NormalVertex, OLD_NORMAL_VERTEX_OP);

  This you'd definitely want to wrap up in a helper function somehow. Not sure 
how to best
accomplish this to make sure it is code in the host app, rather than the 
library.

> I am new to OSG, so I have no idea how to submit a patch. I guess it would be 
> useful to add this in the main trunk, as maintaining this record list at the 
> application level is quite painful (in the case new records are added in OSG).

http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol

> Cheers,
> Greg

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Accessing Texture Indices

[Paul Martz]

As a starter, you should probably read through the OSG Quick Start Guide to
become familiar with how OSG's Geometry class uses PrimitiveSets, or take a
look at many examples such as osggeometry.
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
+1 303 859 9466
 

  _  

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Omar Alvi
Sent: Tuesday, May 26, 2009 4:34 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Accessing Texture Indices


Hello guys, 

I am new to osg. I have loaded an obj file using osgDB but I don't know how
to access vertex and texture indices. I can get the vertex array from the
geometry using
pGeo.get()->getVertexArray()  method but pGeo.get()->getVertexIndices()
returns null.  I cant figure out how the indices are stored for the vertices
and the texture. The model is loaded and displayed fine so there is
definitely a problem in the way I am accessing the data. Would really
appreciate any help. 


Thanks


  _  

HotmailR has ever-growing storage! Don't worry about storage limits. Check
it out.
  
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Accessing Texture Indices

[Omar Alvi]

Hello guys,
I am new to osg. I have loaded an obj file using osgDB but I don't know how to 
access vertex and texture indices. I can get the vertex array from the geometry 
usingpGeo.get()->getVertexArray()  method but pGeo.get()->getVertexIndices() 
returns null.  I cant figure out how the indices are stored for the vertices 
and the texture. The model is loaded and displayed fine so there is definitely 
a problem in the way I am accessing the data. Would really appreciate any help. 

Thanks

_
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Stereo Problem

[Himar Carmona]

Thank you for the info. Certainly valuable. I'll dig a bit more about DDC
and sync. W.r.t. Nvidia shutter, it seems that nvidia's objective was to get
stereo "transparently" to the directx apps, not to be fully compliant with
stereoscopic standards. Mmm. Not to useful to general stereo software like
OSG (unless they add the announced support for quad buffer).

Best regards,
Himar.

2009/5/26 Jan Ciger 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Himar Carmona wrote:
>
> >> Don't know exactly how it works, but for sure the ir emitter use the USB
> >> connection also for data. In a "normal" configuration (i.e. without
> >> using the sync in plug), the ir emitter is connected to the pc only by
> >> the usb cable and does not need to be plugged to the VGA connector. So,
> >> i deduce that if it receives the DDC signal, then it is the driver that
> >> enroute that signal. I also suppose that it uses some sync protocol
> >> different than a simply square wave.
>
> That looks like some kind of NVIDIA proprietary solution :(
>
> EDIT: Scratch that. I have checked the link you have sent before
> (http://www.int03.co.uk/crema/hardware/stereo/) and looked at the
> schematics. LOL, that is certainly not anything USB-based :-p
>
> The whole device just gets your stereo sync from the VSYNC signal and
> the only thing it needs USB for is 5V power for the flip-flop chip
> inside. You could replace that with a standard wall-wart power adaptor
> or a battery if you do not want USB there.
>
>
> >>   If you plug the ir emitter without installing the drivers it doesn't
> >> work (blinks red), so i can't plug it in the first pc. I don't know
> >> other stereoscopic systems (glasses + ir emitters), how they work or how
> >> they are configured. This ones seems to be tightly integrated with the
> >> software drivers.
>
> The "normal" way of doing this (e.g. the CrystalEyes glasses originally
> used by SGI, "VESA" stereo) and all the Quadro line that supports stereo
> work in a much simpler way.
>
> As soon as the quad buffer stereo visual is enabled by the application,
>  the card starts producing the stereo sync signal which is just a simple
> 5V TTL level square wave output to the IR emitter. That is generated
> directly by the hardware, there is nothing for the driver to do, just
> turn it on - the signal flips depending on which framebuffer is selected
> for rendering in the application. The emitters are connected using the
> 3pin mini DIN plug - one pin 5V power for the emitter, one pin ground
> and one pin the TTL sync signal (http://geektechnique.org/images/1927.jpg
> ).
>
> Nvidia drivers require the stereo support being enabled in the settings
> (in Windows in the profile, in Linux in xorg.conf), but that is all. For
> Nvidia hardware you can also choose how to emit the signal - either
> through the VGA connector or via the mini DIN plug - e.g. HMDs need it
> on the VGA connector, like the popular eMagin Z800, despite having an
> USB plug, that one is used only for power and the built-in tracker.
>
> I even have an old pair of Asus shutter glasses that are using
> non-standard 3.5mm headphone jack, but the signals are the same 5V TTL
> level (measured it with a scope). Asus shipped these with some of their
> old GeForce 4 cards. On that card you had to use the old "consumer
> stereo" drivers from Nvidia to get a stereo effect in Windows, however
> the output is constantly on, there is nothing to enable or disable (the
> glasses are on all the time). Most likely they have simply wired the
> connector to the VSYNC signal. This has worked in Linux just fine
> (render left/right frames alternating), but you do not have any control
> over the sync, so sometimes the stereo polarity is wrong (eyes get
> swapped due to application latency, e.g. opening a menu).
>
> Regards,
>
> Jan
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iD8DBQFKHEzun11XseNj94gRAqZ3AKCfAbAFXry5bzXbNvdG0+sCkCug6wCfSHlE
> QVBedWVlC5oAOcQ40iZUcH0=
> =7lGQ
>  -END PGP SIGNATURE-
> ___
> 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] OpenThreads::Condition and spurious wakeups

[Cory Riddell]

The first reply to this question is pretty good:
 
http://stackoverflow.com/questions/625340/spurious-unblocking-in-boost-thread

Cory

J.P. Delport wrote:
> Hi all,
>
> I'm using OpenThreads in a cross-platform application and wanted to
> use the Condition implementation, specifically the wait(timeout)
> version. However, the pthread docs suggest that pthread_cond_timedwait
> (that is used by OT) can return without explicitly being signalled
> (so-called spurious wakeups [1]). Now if I used pthreads directly I
> can just put the wait in a while loop checking my condition, because
> pthread_cond_timedwait takes an absolute time as a parameter and not a
> relative time as OT::Condition does.
>
> With the current OT::Condition there is no way to easily restart the
> timed wait (one will have to keep track of time oneself and OT does
> not have functions for it).
>
> I've searched for places in OSG where the timed wait is used and it is
> not used much. It is used in block(timeout) too, but that is also not
> used much in OSG. However, in the new ffmpeg plugin there is also this
> comment before using the timed wait:
>
> ---8<---
> // We don't wait in a loop to avoid an infinite loop (as the ms
> timeout would not be decremented).
> // This means that timedPop() could return with (is_empty = true)
> before the timeout has been hit.
> ---8<---
>
> Does anyone have more information on how to handle this issue? Should
> I just write my code to cope with this limitation? Has anyone used
> boost threads (and associated sync utils) with OSG?
>
> rgds
> jp
>
>
> [1] see the pthread docs or
> http://en.wikipedia.org/wiki/Spurious_wakeup
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenThreads::Condition and spurious wakeups

[Cory Riddell]

I'm using boost::threads, but not any of the timed wait stuff. I run my
viewer in its own thread.

It is my understanding that for a timed wait, you do need to manually
track how much time has actually elapsed and restart the wait if necessary.

Cory

J.P. Delport wrote:
> Hi all,
>
> I'm using OpenThreads in a cross-platform application and wanted to
> use the Condition implementation, specifically the wait(timeout)
> version. However, the pthread docs suggest that pthread_cond_timedwait
> (that is used by OT) can return without explicitly being signalled
> (so-called spurious wakeups [1]). Now if I used pthreads directly I
> can just put the wait in a while loop checking my condition, because
> pthread_cond_timedwait takes an absolute time as a parameter and not a
> relative time as OT::Condition does.
>
> With the current OT::Condition there is no way to easily restart the
> timed wait (one will have to keep track of time oneself and OT does
> not have functions for it).
>
> I've searched for places in OSG where the timed wait is used and it is
> not used much. It is used in block(timeout) too, but that is also not
> used much in OSG. However, in the new ffmpeg plugin there is also this
> comment before using the timed wait:
>
> ---8<---
> // We don't wait in a loop to avoid an infinite loop (as the ms
> timeout would not be decremented).
> // This means that timedPop() could return with (is_empty = true)
> before the timeout has been hit.
> ---8<---
>
> Does anyone have more information on how to handle this issue? Should
> I just write my code to cope with this limitation? Has anyone used
> boost threads (and associated sync utils) with OSG?
>
> rgds
> jp
>
>
> [1] see the pthread docs or
> http://en.wikipedia.org/wiki/Spurious_wakeup
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Stereo Problem

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Himar Carmona wrote:

>> Don't know exactly how it works, but for sure the ir emitter use the USB
>> connection also for data. In a "normal" configuration (i.e. without
>> using the sync in plug), the ir emitter is connected to the pc only by
>> the usb cable and does not need to be plugged to the VGA connector. So,
>> i deduce that if it receives the DDC signal, then it is the driver that
>> enroute that signal. I also suppose that it uses some sync protocol
>> different than a simply square wave.

That looks like some kind of NVIDIA proprietary solution :(

EDIT: Scratch that. I have checked the link you have sent before
(http://www.int03.co.uk/crema/hardware/stereo/) and looked at the
schematics. LOL, that is certainly not anything USB-based :-p

The whole device just gets your stereo sync from the VSYNC signal and
the only thing it needs USB for is 5V power for the flip-flop chip
inside. You could replace that with a standard wall-wart power adaptor
or a battery if you do not want USB there.


>>   If you plug the ir emitter without installing the drivers it doesn't
>> work (blinks red), so i can't plug it in the first pc. I don't know
>> other stereoscopic systems (glasses + ir emitters), how they work or how
>> they are configured. This ones seems to be tightly integrated with the
>> software drivers.

The "normal" way of doing this (e.g. the CrystalEyes glasses originally
used by SGI, "VESA" stereo) and all the Quadro line that supports stereo
work in a much simpler way.

As soon as the quad buffer stereo visual is enabled by the application,
 the card starts producing the stereo sync signal which is just a simple
5V TTL level square wave output to the IR emitter. That is generated
directly by the hardware, there is nothing for the driver to do, just
turn it on - the signal flips depending on which framebuffer is selected
for rendering in the application. The emitters are connected using the
3pin mini DIN plug - one pin 5V power for the emitter, one pin ground
and one pin the TTL sync signal (http://geektechnique.org/images/1927.jpg).

Nvidia drivers require the stereo support being enabled in the settings
(in Windows in the profile, in Linux in xorg.conf), but that is all. For
Nvidia hardware you can also choose how to emit the signal - either
through the VGA connector or via the mini DIN plug - e.g. HMDs need it
on the VGA connector, like the popular eMagin Z800, despite having an
USB plug, that one is used only for power and the built-in tracker.

I even have an old pair of Asus shutter glasses that are using
non-standard 3.5mm headphone jack, but the signals are the same 5V TTL
level (measured it with a scope). Asus shipped these with some of their
old GeForce 4 cards. On that card you had to use the old "consumer
stereo" drivers from Nvidia to get a stereo effect in Windows, however
the output is constantly on, there is nothing to enable or disable (the
glasses are on all the time). Most likely they have simply wired the
connector to the VSYNC signal. This has worked in Linux just fine
(render left/right frames alternating), but you do not have any control
over the sync, so sometimes the stereo polarity is wrong (eyes get
swapped due to application latency, e.g. opening a menu).

Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFKHEzun11XseNj94gRAqZ3AKCfAbAFXry5bzXbNvdG0+sCkCug6wCfSHlE
QVBedWVlC5oAOcQ40iZUcH0=
=7lGQ
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Dynamically generating smooth camera rides?

[Christian Buchner]

Thanks,  your and Paul Martz kind pointers should get me started.

I did check try the Virtual Rome site also, but the graphics loaded
kind of slow through my HSDPA connection.

Christian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Dynamically generating smooth camera rides?

[Ismail Pazarbasi]

2009/5/25 Christian Buchner :
> Forgive my laziness - are there any utility classes within OSG that
> let the camera go on a smooth ride to a specific location and eyepoint
> vector from the current location?   I mean smooth in the sense of the
> camera accelerating and braking, instead of making a simple constant
> linear movement and rotation.
>
> If there is no ready made solution for camera paths - how difficult
> would it be to dynamically create a key frame animation for the camera
> for abitrary start and stop locations?
>
> Ideally I'd like the user to be able to quickly observe some points of
> interests within in my 3D simulation, without instantaneously zapping
> the camera to the new position. There should be some kind of "whoosh"
> effect where the camera travels from the current location to the
> destination quickly, within about second.   This may have the
> advantage that the user will be able to maintain a sense of
> orientation in space which would be lost by switching to the
> destination camera position instantly.
>
> Christian
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>

Hi Christian,

do you mean "continuity" (that's the technical term, AFAIK), as in
easing in and out of motion? Did you see osganimationnode example? It
uses bezier keyframes. That is, changes in variables (e.g. position x)
will not be linear but will be smooth.

Add your camera as a child of a MatrixTransform, then set the update
callback (that has a bezier keyframe container) of matrix transform.
osganimationnode is a very good example for this type of animations.

I am using similar technique in my animation (I move rectangles) and
works just fine.

Ismail
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Stereo Problem

[Himar Carmona]

2009/5/26 Jan Ciger 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Himar Carmona wrote:
> >Our impressions:
> >
> > Though the glasses are "VESA compatible", the ir emitter doesn't
> > work if it isn't connected to the pc via USB AND a DirectX application
> > is running fullscreen.
> > The ir emitter does not use the sync in signal if it is connected to
> > a "3d ready" display (either samsung 120Hz lcd and DepthQ projector). It
> > seems to prioritize the usb  signal in these cases.
>
> Isn't the USB connection used just to get the power for the signal
> converter? The stereo sync signal is normally emitted on the VGA
> connector directly.
>

Don't know exactly how it works, but for sure the ir emitter use the USB
connection also for data. In a "normal" configuration (i.e. without using
the sync in plug), the ir emitter is connected to the pc only by the usb
cable and does not need to be plugged to the VGA connector. So, i deduce
that if it receives the DDC signal, then it is the driver that enroute that
signal. I also suppose that it uses some sync protocol different than a
simply square wave.


>
> That it doesn't work right with the displays you mention could be due to
> the fact that they use the DDC signal for the original purpose -
> communicating the monitor properties to the PC and - and therefore would
> interfere with the stereo sync.
>


Working on windows, when you install the 3d vision driver, it installs a new
group of options in the nvidia control panel to configure the stereoscopic
display. It have a setup wizard and a test application to help in the
process. If the graphic card detects a "3d ready" monitor (like the lcd
samsung at 120Hz or the DepthQ projector), it disables the option to select
generic crt display and hdtv dlp. And the only configuration possible that i
found was to tell the driver to use one of these. In these cases, if you run
the test appication, it tells you with an onscreen  message that it does not
detect the sync signal, so it forces you to connect via vga 3 connector's
sync in plug. So, i supposed that:

   1. if the graphics card is connected to a 3d ready display, the ir
emitter will receive the sync via usb.
   2. (else) if the driver is configured with a crt or dlp, the it will use
the external sync in signal (another plug in the ir emitter).

  With the vertical sync of the vga connector injected through this plug
(with the circuitry i mentioned in my post) and the driver configured as 2,
the glasses works like a (VESA compatible?) ones.

   Notice also that we use 2 pcs: one with the quadro and osg installed (and
without 3d vision driver, because they don't install for a quadro card), and
the other with the vision driver and the ir emitter plugged.

  If you plug the ir emitter without installing the drivers it doesn't work
(blinks red), so i can't plug it in the first pc. I don't know other
stereoscopic systems (glasses + ir emitters), how they work or how they are
configured. This ones seems to be tightly integrated with the software
drivers.

Regards,
Himar.


>
> Regards,
>
> Jan
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
>
> iD8DBQFKG8tbn11XseNj94gRAsX2AKCXY57SRXgaNn8pWz+NPxHgcCfVdwCfXNwx
> RaKlxS06CKxziKwquvKpw5k=
> =25NN
>  -END PGP SIGNATURE-
> ___
> 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] Foring Trilinear Mipmaping

[Guy Volckaert]

Oooops. I forgot the set the visitor traversal mode to TRAVERSE_ALL_CHILDREN. 
That was tupid of me!!?!?

I'll let you know if it works.

Guy

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12986#12986





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Foring Trilinear Mipmaping

[Guy Volckaert]

Hi,

ok. I registered a osgDB::Registry::ReadFileCallback and I overidden the 
readNode() function. As Robert suggested, I added a node visitor to scan for 
all statesets (in nodes and drawables) for textures.  


Code:

void CGeTrilinearVisitor::apply( osg::Node& rNode )
{
osg::StateSet* pStateSet = rNode.getStateSet( );
if( pStateSet )
{
osg::StateSet::TextureAttributeList& rList = 
pStateSet->getTextureAttributeList( );
osg::Texture2D* pTex = dynamic_cast( 
pStateSet->getTextureAttribute( 0, osg::StateAttribute::TEXTURE ) );
if( pTex )
{
pTex->setFilter( osg::Texture::MIN_FILTER, 
osg::Texture::LINEAR_MIPMAP_LINEAR );
}
}

Inherited::apply( rNode );
}

void CGeTrilinearVisitor::apply( osg::Geode& rGNode )
{
const osg::Geode::DrawableList& rDrawables = rGNode.getDrawableList( );

for( int i = 0; i < rDrawables.size( ); ++i )
{
osg::ref_ptr pDrawable = rDrawables[i];
osg::StateSet* pStateSet = pDrawable->getStateSet( );
if( pStateSet )
{
osg::StateSet::TextureAttributeList& rList = 
pStateSet->getTextureAttributeList( );
osg::Texture2D* pTex = dynamic_cast( 
pStateSet->getTextureAttribute( 0, osg::StateAttribute::TEXTURE ) );
if( pTex )
{
pTex->setFilter( osg::Texture::MIN_FILTER, 
osg::Texture::LINEAR_MIPMAP_LINEAR );
}
}
}

Inherited::apply( rGNode );
}




What I discovered is that the nodes and drawables don't have any stateset 
allocated when loading an openflight file. Maybe the statesets get added later??

I am looking at the openflight plugin, but any suggestion would be appreciated.

Guy

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12985#12985





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.10 schedule?

[Martin Beckett]

Robert,
Is there are a bigger picture roadmap for OSG?
The direction it's heading and the kind of apps it is aimed at.

I know this depends on what code users submit but is there a master plan from 
the benevolent dictator?

Martin

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12983#12983





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.10 schedule?

[Robert Osfield]

Hi Paul,

On Tue, May 26, 2009 at 5:21 PM, Paul Martz  wrote:
> Hi Robert -- Do you have a functional spec and release schedule for 2.10? If
> so, please post it. I have a client who is currently on 2.6.1 and needs to
> know if they should port to 2.8.1 or wait for 2.10. It all depends on when
> 2.10 will be available.

I don't have a schedule for OSG-2.10 yet.  My current focus is getting
VPB-1.0 completed, once that is out I'll turn my attention to
OSG-2.10.

In terms of features in 2.10, the ffmpeg plugin has great promise but
isn't complete yet, and I'd like to get that working as well as the
quicktime + xine plugins for 2.10 so we can contemplate deprecating
these.  Other features that will make it into 2.10 will depend upon
the what the community will bring forward.

Personally I would recommend that users move to each stable point
releases as they come out, rather than skip ones as this will minimize
the chances of API changes in the OSG breaking builds.  So in this
instance 2.8.1 has to be the one to go for.  Going from 2.6.1 to 2.8.1
should be pretty painless, little more than a recompile of the OSG and
the 3rd party application.

> With SIGGRAPH just over 2 months away, I thought you might be targeting a
> release prior to SIGGRAPH. But I'm not sure what functionality you want in
> 2.10 that might be holding up the release.

Wow SIGGRAPH only 2 months away... who stole Spring?!?

Getting 2.10 out the door in time for SIGGRAPH should be doable, and
is certainly a good goal to aim for.  Perhaps aim for VPB-1.0 mid
June, OSG-2.10 mid July.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [vpb] LOD problem

[Robert Osfield]

HI Miroslav,

osgUtil::SceneView doesn't have support for the osgDB::DatabasePager,
and unless VRJuggler explictly adds this support in you won't be able
to read paged databases.

The osgViewer::Viewer library supports the database pager out of the
box, so if you could use this instead of the VRjugglers rendering
support then you'd automatically get paging.  There are other VR
toolkits out there as well the integrate with the OSG, and if they are
smart they will be using osgViewer rather than the low level and
feature light SceneView.

You could potentially add support for the DatabasePager into
VRJuggler, and perhaps others in the community have already done this.
  Personally I'd still recommend use osgViewer though as it provides
multi-threading and support for pbuffers, all things that are useful
to VR apps.

Robert.


On Tue, May 26, 2009 at 4:54 PM, Miroslav Andel  wrote:
> Hi,
>
> My models created in osgdem works fine in osgViewer but when I load them in 
> my application they only show the lowest level (L0_X0_Y0) of detail.
>
> I'm using the VR juggler framework which is based on sceneView. My version of 
> osg is 2.8.0 and vpb 0.9.10 (winXP).
>
> Can it be that the distance to the model from the camera cannot be 
> calculated? I'm just started to use osg to port some VR applications. Any 
> help is highly appreciated.
>
> One other question... What's the unit of the -v option in osgdem? I use 16 
> bit tiffs for the height map where the value represent the elevation in 
> meters (16 bit short). I use an ellipsoid model of the earth and need proper 
> scaling so I can place out GIS data on it's correct position and altitude.
>
> Thank you!
>
> Cheers,
> Miroslav Andel
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=12978#12978
>
>
>
>
>
> ___
> 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] 2.10 schedule?

[Paul Martz]

Hi Robert -- Do you have a functional spec and release schedule for 2.10? If
so, please post it. I have a client who is currently on 2.6.1 and needs to
know if they should port to 2.8.1 or wait for 2.10. It all depends on when
2.10 will be available.
 
With SIGGRAPH just over 2 months away, I thought you might be targeting a
release prior to SIGGRAPH. But I'm not sure what functionality you want in
2.10 that might be holding up the release.
 
Any info would be appreciated, thanks.
 
Paul Martz
Skew Matrix Software LLC
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] OpenGL ES 2.0 Support ?

[Craig Bosma]

Hi Robert,

> If you want to get involved in this effort I can pass your name on the
> groups currently looking at OpenGL ES.

Yes, please do. I'm by no means an expert on ES, but I'd like to help
move this effort forward.

Craig
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] [vpb] LOD problem

[Miroslav Andel]

Hi,

My models created in osgdem works fine in osgViewer but when I load them in my 
application they only show the lowest level (L0_X0_Y0) of detail.

I'm using the VR juggler framework which is based on sceneView. My version of 
osg is 2.8.0 and vpb 0.9.10 (winXP).

Can it be that the distance to the model from the camera cannot be calculated? 
I'm just started to use osg to port some VR applications. Any help is highly 
appreciated.

One other question... What's the unit of the -v option in osgdem? I use 16 bit 
tiffs for the height map where the value represent the elevation in meters (16 
bit short). I use an ellipsoid model of the earth and need proper scaling so I 
can place out GIS data on it's correct position and altitude.

Thank you!

Cheers,
Miroslav Andel

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12978#12978





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OpenThreads::Condition and spurious wakeups

[J.P. Delport]

Hi all,

I'm using OpenThreads in a cross-platform application and wanted to use 
the Condition implementation, specifically the wait(timeout) version. 
However, the pthread docs suggest that pthread_cond_timedwait (that is 
used by OT) can return without explicitly being signalled (so-called 
spurious wakeups [1]). Now if I used pthreads directly I can just put 
the wait in a while loop checking my condition, because 
pthread_cond_timedwait takes an absolute time as a parameter and not a 
relative time as OT::Condition does.


With the current OT::Condition there is no way to easily restart the 
timed wait (one will have to keep track of time oneself and OT does not 
have functions for it).


I've searched for places in OSG where the timed wait is used and it is 
not used much. It is used in block(timeout) too, but that is also not 
used much in OSG. However, in the new ffmpeg plugin there is also this 
comment before using the timed wait:


---8<---
// We don't wait in a loop to avoid an infinite loop (as the ms timeout 
would not be decremented).
// This means that timedPop() could return with (is_empty = true) before 
the timeout has been hit.

---8<---

Does anyone have more information on how to handle this issue? Should I 
just write my code to cope with this limitation? Has anyone used boost 
threads (and associated sync utils) with OSG?


rgds
jp


[1] see the pthread docs or
http://en.wikipedia.org/wiki/Spurious_wakeup

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] problem with blending when using floating point FBO

[Jonathan Richard]

Ok thank you for the advice. I'm not very familiar with the shader
programming yet, but I'm suppose to get into it soon. The problem that I see
is how to get access to the facet from the shader. If I'm into a fragment
shader I'll probably have no idea from which facet come each fragment. Is it
right? Maybe I have to use a geometry shader? Or maybe I can perform the
blending by myself into a fragment shader? You can tell me if you have any
clue about that.


I'll give you a little more of precision about my problem. The blending
seems to be working when the alpha of the front facet is different from 1.
For exemple if I define

Rd = (2e-3,  0.0,   0.0,   1.0) // RGBA

Rs = (6e-9, 0.0,   0.0,   0.4) //RGBA


In theory:

Rd = Rs + (1-As)Rd

Rd = 6e-9 + (1-0.4)*2e-3 = 1.26e-3

In practice I get: 0.001259


For now, the problem seems to occur only when As =1.


Thanks,
Jonathan









2009/5/26 J.P. Delport 

> Hi,
>
> Jonathan Richard wrote:
> >
> > |// Tell to sort the mesh before displaying it
> > |AFAIK OSG does not sort at the triangle level, there is an option to
> > make the sorting happen at a primitive level, but I think the default is
> > sorting on bounding sphere.
> >
> > I take this line (and the comment) from the osgblendequation example.
> > You think that I should not do this call?
>
> No, the call is fine. What I'm saying is that blending and transparency
> is (depending on the blend equation) dependent on the order in which
> things are rendered, so one cannot assume (when making off-line
> calculations) that all the geometry is perfectly sorted (think e.g.
> intersecting objects).
>
> >
> > |offscreenTexture->setSourceType( GL_UNSIGNED_BYTE);
> > |Should this not also be GL_FLOAT?
> >
> > yes sorry it is a "copy paste" error. I call
> > offscreenTexture->setSourceType(GL_FLOAT) and
> > offscreenTexture->setInternalFormat(GL_FLOAT_RGBA32_NV).
> >
> > |I can also not see from the code if OpenGL lighting is enabled. Do you
> > disable lighting in your app?
> >
> > No I wasn't but I disable it now and I see no change in the result
>
> OK.
>
> I'm running out of ideas to try help. I cannot from just reading the
> code see any more problems. I'd suggest using the ARB modes and trying a
> few other machines. I'll also try find some of our test code for float
> blending.
>
> Another option is to use shaders to explicitly set the colours of two
> facets (to eliminate any fixed function interference) and see how they
> blend.
>
> jp
>
>
> >
> >
> > Here a update of the code with the correction in yellow:
> >
> >
> > The colors are attached by setting the ColorArray of the drawables of
> > each Geode like this:
> >
> >
> >
> > int geodesNb = m_entityVectorOfGeodeVector[0].size();
> >
> >
> >
> > osg::Geode* aGeode;
> >
> > int drawablesNb;
> >
> > osg::Drawable* aDrawable;
> >
> > osg::Geometry* aDrawableGeometry;
> >
> > osg::Vec4Array* aDrawableColor;
> >
> > for (int geodesLoop = 0; geodesLoop < geodesNb; geodesLoop++)
> >
> > {
> >
> > aGeode = m_entityVectorOfGeodeVector[0][geodesLoop];
> >
> > drawablesNb = aGeode->getNumDrawables();
> >
> >
> >
> > // Update color for each facet (drawable) of a geode
> >
> > for (int i = 0; i < drawablesNb; i++)
> >
> > {
> >
> > aDrawable = aGeode->getDrawable(i);
> >
> > aDrawable->dirtyDisplayList();  //
> > Force color update on next draw
> >
> >
> >
> > aDrawableGeometry =
> > dynamic_cast(aDrawable);
> >
> >
> >
> > aDrawableColor =
> > dynamic_cast(aDrawableGeometry>getColorArray());
> >
> >
> >
> >
> > std::string geodeName=aGeode->getName();
> >
> >
> >
> > if(!geodeName.compare("p1"))
> >
> > {
> >
> > // Set the facet color
> > and transparency (0=invisible)
> >
> > (*aDrawableColor)[0] =
> > m_facet1Color;
> >
> >
> >
> > …
> >
> > }
> >
> > }
> >
> > }
> >
> >
> >
> > Where the /entityVectorOfGeodeVector/ is the list of visible geodes that
> > I maintain by using a cull callback.
> >
> >
> >
> >
> >
> > Here a snapshot of my code to setup the viewer and the camera.
> >
> >
> >
> > m_viewer = new osgViewer::Viewer;
> >
> > m_viewer->setUpViewOnSingleScreen();
> >
> > osg::Camera *camera = m_viewer->getCamera();
> >
> >
> >
> > osgViewer::Renderer * renderer =
> > static_cast(camera->getRenderer());
> >
> > // Reading back the FBO does not work when it is disabled after render
> > --> set this property of the
> >
> > // renderStage to false.
> >
> >
> renderer->getSceneView(0)->getRenderStage()->setDisableFboAfterRender(false);
> >
> >
> renderer->getSceneView(1)->getRenderStage()->setDisableFboAfter

Re: [osg-users] problem with blending when using floating point FBO

[J.P. Delport]

Hi,

Jonathan Richard wrote:
> 
> |// Tell to sort the mesh before displaying it
> |AFAIK OSG does not sort at the triangle level, there is an option to 
> make the sorting happen at a primitive level, but I think the default is 
> sorting on bounding sphere.
> 
> I take this line (and the comment) from the osgblendequation example. 
> You think that I should not do this call?

No, the call is fine. What I'm saying is that blending and transparency
is (depending on the blend equation) dependent on the order in which
things are rendered, so one cannot assume (when making off-line
calculations) that all the geometry is perfectly sorted (think e.g.
intersecting objects).

> 
> |offscreenTexture->setSourceType( GL_UNSIGNED_BYTE);
> |Should this not also be GL_FLOAT?
> 
> yes sorry it is a "copy paste" error. I call 
> offscreenTexture->setSourceType(GL_FLOAT) and 
> offscreenTexture->setInternalFormat(GL_FLOAT_RGBA32_NV).
> 
> |I can also not see from the code if OpenGL lighting is enabled. Do you 
> disable lighting in your app?
> 
> No I wasn't but I disable it now and I see no change in the result

OK.

I'm running out of ideas to try help. I cannot from just reading the
code see any more problems. I'd suggest using the ARB modes and trying a
few other machines. I'll also try find some of our test code for float
blending.

Another option is to use shaders to explicitly set the colours of two
facets (to eliminate any fixed function interference) and see how they
blend.

jp


> 
> 
> Here a update of the code with the correction in yellow:
> 
> 
> The colors are attached by setting the ColorArray of the drawables of 
> each Geode like this:
> 
>  
> 
> int geodesNb = m_entityVectorOfGeodeVector[0].size();
> 
>  
> 
> osg::Geode* aGeode;
> 
> int drawablesNb;
> 
> osg::Drawable* aDrawable;
> 
> osg::Geometry* aDrawableGeometry;
> 
> osg::Vec4Array* aDrawableColor;
> 
> for (int geodesLoop = 0; geodesLoop < geodesNb; geodesLoop++)
> 
> {
> 
> aGeode = m_entityVectorOfGeodeVector[0][geodesLoop];
> 
> drawablesNb = aGeode->getNumDrawables();
> 
>  
> 
> // Update color for each facet (drawable) of a geode
> 
> for (int i = 0; i < drawablesNb; i++)
> 
> {
> 
> aDrawable = aGeode->getDrawable(i);
> 
> aDrawable->dirtyDisplayList();  // 
> Force color update on next draw
> 
>  
> 
> aDrawableGeometry = 
> dynamic_cast(aDrawable);
> 
>  
> 
> aDrawableColor = 
> dynamic_cast(aDrawableGeometry>getColorArray()); 
> 
> 
>
> 
> std::string geodeName=aGeode->getName();
> 
>
> 
> if(!geodeName.compare("p1"))
> 
> {
> 
> // Set the facet color 
> and transparency (0=invisible)
> 
> (*aDrawableColor)[0] = 
> m_facet1Color;
> 
>
> 
> …
> 
> }
> 
> }
> 
> }
> 
>  
> 
> Where the /entityVectorOfGeodeVector/ is the list of visible geodes that 
> I maintain by using a cull callback.
> 
>  
> 
>  
> 
> Here a snapshot of my code to setup the viewer and the camera.
> 
>  
> 
> m_viewer = new osgViewer::Viewer;
> 
> m_viewer->setUpViewOnSingleScreen();
> 
> osg::Camera *camera = m_viewer->getCamera();
> 
>
> 
> osgViewer::Renderer * renderer = 
> static_cast(camera->getRenderer());
> 
> // Reading back the FBO does not work when it is disabled after render 
> --> set this property of the
> 
> // renderStage to false.
> 
> renderer->getSceneView(0)->getRenderStage()->setDisableFboAfterRender(false);
> 
> renderer->getSceneView(1)->getRenderStage()->setDisableFboAfterRender(false);
> 
>
> 
> m_scene=new osg::Group();
> 
>  
> 
> std::string modelName="C:\\_JO\\LTI\\SIS\\Models\\test_IR\\carre.flt";
> 
>
> 
> LoadModel(modelName); // call m_viewer->SetSceneData
> 
>  
> 
> osg::StateSet* state = m_scene->getOrCreateStateSet();
> 
>  
> 
> // Disable Lighting effects
> 
> state->setMode(GL_LIGHTING, osg::StateAttribute::OVERRIDE | 
> osg::StateAttribute::OFF);
> 
>  
> 
> // Enable transparency
> 
> state->setMode(GL_BLEND, osg::StateAttribute::OVERRIDE | 
> osg::StateAttribute::ON);
> 
> // Tell to sort the mesh before displaying it
> 
> state->setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
> 
>
> 
> // Set the blend function (related to the transparency)
> 
> osg::BlendFunc* selectedBlendFunction = new osg::BlendFunc();
> 
> selectedBlendFunction->setDestination(GL_ONE_MINUS_SRC_ALPHA);
> 
> selectedBlendFunction->setSource(GL_ONE);
> 
>
> 
> state->setAttribute(selectedBlendFunction, osg

Re: [osg-users] Remote execution and OSG

[paul1492]

Let me ask a slightly different question... Why do I only get half a cow (see 
attachment on my original post) even when I run on just a local machine.  Seems 
I get more "cow" showing when I decrease the resolution of my video display...

Paul P. 



- Original Message 
From: "paul1...@yahoo.com" 
To: OpenSceneGraph Users 
Sent: Friday, May 22, 2009 8:03:36 AM
Subject: Re: [osg-users] Remote execution and OSG

Let me also add that I see the same problem (program seg faults when running on 
a LINUX machine and shooting the display to a PC using Hummingbird Exceed 3D) 
when running:
% osgviewerQT --QOSGWidget cow.osg

with OSG 2.9.3 and 2.8.

It also produces the following X error:
X Error: BadMatch (invalid parameter attributes) 8
  Extension:    134 (Uknown extension)
  Minor opcode: 5 (Unknown request)
  Resource id:  0x2c1

In addition, when I run this command on a (single) LINUX machine, I only get 
half a cow...

Is this a problem with OSG or is this an Exceed 3D problem?  I know another 
person recently resolved a crash on the same example by updating the video 
driver.  I assume this isn't my problem here.

Paul P.


- Original Message 
From: "paul1...@yahoo.com" 
To: OpenSceneGraph Users 
Sent: Thursday, May 21, 2009 7:17:36 PM
Subject: Re: [osg-users] Remote execution and OSG


Thanks Robert.. That helped... 

But I'm having way too much fun interfacing OSG to Qt to stop there:-).  I seem 
to be able to get it to work now but I'm having trouble running on a LINUX 
machine but shooting my display to a PC running Hummingbird Exceed 3D (my 
actual requirement). I'm logged into the PC and then use exceed to 
remotely login to a LINUX machine.  I seem to have trouble switching to a valid 
Graphics Context (i.e. glGetString(GL_VERSION) returns null string within OSG) 
and causes OSG to seg fault... Logging remotely into a LINUX machine and 
shooting the display to another LINUX machine works fine.

Am I setting up my graphics context incorrectly?  I'm not using the 
AdapterWidget from the example. I'm also having trouble getting 
GraphicsWindowEmbedded to work...

So, here is what I'm doing:

myViewer::myViewer(void)
{
   mViewer = new osgViewer::Viewer;
   mViewer->setThreadingModel(osgViewer::Viewer::SingleThreaded);
   mViewer->setCameraManipulator(new osgGA::TrackballManipulator);
   mCamera = mViewer->getCamera();
}

void myViewer::initialize(int height, int width)
{
   osg::ref_ptr traits =
  new osg::GraphicsContext::Traits;
   
   traits->readDISPLAY();   
   traits->doubleBuffer = true;
   traits->useCursor    = false;
   traits->x    = 0;
   traits->y    = 0;
   traits->width    = width;
   traits->height   = height;
   
   osg::ref_ptr windata =
  new osgViewer::GraphicsWindowX11::WindowData(mGLWindow);
   
   traits->inheritedWindowData = windata;
   
   osg::GraphicsContext* gc;

   gc = osg::GraphicsContext::createGraphicsContext(traits.get());
   mCamera->setGraphicsContext(gc);

   mCamera->setClearColor(osg::Vec4(0.5235, 0.8745, 1.0, 1.0));
   mCamera->setViewport(traits->x,
    traits->y,
    traits->width,
    traits->height);
   mViewer->setCamera(mCamera.get());
   mViewer->setSceneData(osgDB::readNodeFile("cow.osg"));
}

I am calling the myViewer->initialize() method in another class derived from a 
QGLWidget and where it is called in its first paintGL callback. I'm also 
calling the myViewer->frame() call in this callback which simply calls 
mViewer->frame().

I'm using Qt's QGLWidget's window ID (i.e. winId() stored in mGLWindow) to set 
the inheritedWindowData.  Is this okay to do it? If I don't do this 
initialization of the inheritedWindowData data, my widget DOES appear (in all 
cases) except it is detached from my Qt application.

I'm not sure if this is my programming problem, an Hummingbird Exceed problem 
or a Qt problem.

Can anybody help?  I've been working on this for weeks...

Thanks,
Paul P.


 
- Original Message 
From: Robert Osfield 
To: OpenSceneGraph Users 
Sent: Friday, May 15, 2009 4:24:08 AM
Subject: Re: [osg-users] Remote execution and OSG

HI Paul, J.P, et. al,

On Fri, May 15, 2009 at 8:56 AM, J.P. Delport  wrote:
> Not sure, but it looks like some code ignores the $DISPLAY setting and just
> tries to open :0.0.
>
> I can confirm that I get the same behaviour between two Debian machines:
> osgviewer cow.osg runs at a staggering 2fps
>
> osgkeyboardmouse fails with:
> No protocol specified
> Error: Unable to open display ":0.0".
> Error: unable to create graphics window.

The GraphicsContext::Traits structure is used to control how the
graphics window is created, and in it's default state the display and
screen settings (see osg::GraphicsContext::ScreenIndentifier) are 0:0.
  To override this default one needs to explictly call readDISPLAY()
which reads the DISPLAY env variable to set the display and screen
number.

Now the osgView::setUp

Re: [osg-users] VRML testing call

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jan Ciger wrote:
> Hello everyone,
> 
> I have updated the VRML plugin to use the latest OpenVRML 0.17.12 and
> Boost 1.38. Could the VRML users, test this, once Robert merges it, please?
> 
> It works fine for me on Linux, but I didn't have a chance to test on
> other platforms.
> 
> Regards,
> 
> Jan


Here is a temporary location of the updated plugin sources before Robert
manages to put them into subversion:

http://www.aaue.dk/~janoc/files/download/vrml.zip

I am interested in people testing this on Windows and Mac - I do not
have these platforms available.

Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFKG9wmn11XseNj94gRAvBOAKCRdgrij1E4RJQWRyaM1X9a6RGuTwCdFAHY
8VirDdCoMYuDGFC3H9sXH2M=
=Mmet
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Unreadable endian error while reading file

[Santosh]

Hi Robert

Yes actually file is corrupted.

Thanks
-Santosh

Santosh Gaikwad
MTS Design
Darshan Solutions Limited
www.darshan3d.com 
# +91-99530-99053



Robert Osfield wrote:

HI Santosh,

Most likely is that the file is corrupted, or a very old .ive file
that is not compatible with the present verision of the OSG you are
using.

Robert.

On Sat, May 23, 2009 at 5:55 PM, Santosh  wrote:
  

Hi All

I am getting error while reading a ive file which is generated by osgdem.
It throws an error that "Error reading file:
DataInputStream::DataInputStream(): This file has an unreadable endian
type."
Do any one know why this error occurs ?

Thanks & Regards
Santosh
--

Santosh Gaikwad
MTS Design
Darshan Solutions Limited
www.darshan3d.com
# +91-99530-99053

___
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] Stereo Problem

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Himar Carmona wrote:
>Our impressions:
>  
> Though the glasses are "VESA compatible", the ir emitter doesn't
> work if it isn't connected to the pc via USB AND a DirectX application
> is running fullscreen.
> The ir emitter does not use the sync in signal if it is connected to
> a "3d ready" display (either samsung 120Hz lcd and DepthQ projector). It
> seems to prioritize the usb  signal in these cases.

Isn't the USB connection used just to get the power for the signal
converter? The stereo sync signal is normally emitted on the VGA
connector directly.

That it doesn't work right with the displays you mention could be due to
the fact that they use the DDC signal for the original purpose -
communicating the monitor properties to the PC and - and therefore would
interfere with the stereo sync.

Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFKG8tbn11XseNj94gRAsX2AKCXY57SRXgaNn8pWz+NPxHgcCfVdwCfXNwx
RaKlxS06CKxziKwquvKpw5k=
=25NN
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help. KeyboardEventHandler and native keyboard layout bug in Linux

[Maxim Gammer]

ок)

2009/5/26 Robert Osfield :
> Hi Maxim,
>
> 2009/5/26 Maxim Gammer :
>> hope to see my name in that list next release :)
>
> We'll you'll need to get a submission accepted first :-)
>
> For this particular fix I just used your submission as a point of
> reference, it didn't work as is when I tested it due to problems with
> case, so I wrote the final solution myself.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Maxim Gammer
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] OpenFlight plugin and static linking

[Gregory Jaegy]

OK, I found a way to solve this issue:

in src/osgPlugins/OpenFlight/Registry.h add the following lines before the 
closing namespace bracket:


Code:
extern "C"
{
typedef void (* CRecordFunction) (void);
}

struct RecordFunctionProxy
{
RecordFunctionProxy(CRecordFunction function) { (function)(); }
};

#define USE_FLTRECORD(recname, opcode) \
extern "C" void osgfltrec_##recname_##opcode(void); \
static flt::RecordFunctionProxy 
proxy_fltrecord_##recname_##opcode(osgfltrec_##recname_##opcode);

#define REGISTER_FLTRECORD(recname, opcode) \
extern "C" void osgfltrec_##recname_##opcode(void) {} \
static flt::RegisterRecordProxy 
g_proxy_fltrecord_##recname_##opcode(opcode);




Then, in the OpenFlight plugin .cpp files, replace all "RegisterRecordProxy..." 
declaration with the following lines:

Code:
//RegisterRecordProxy g_PushAttribute(PUSH_ATTRIBUTE_OP);
REGISTER_FLTRECORD(PushAttribute, PUSH_ATTRIBUTE_OP);




Finally, in your own project, include the OpenFlight plugin "record.h" file, 
and after the "USE_PLUGIN" macros add the following ones (one per record type):


Code:
USE_FLTRECORD(Comment, COMMENT_OP);
USE_FLTRECORD(LongID, LONG_ID_OP);
USE_FLTRECORD(Matrix, MATRIX_OP);
USE_FLTRECORD(Multitexture, MULTITEXTURE_OP);
USE_FLTRECORD(UVList, UV_LIST_OP);
USE_FLTRECORD(Replicate, REPLICATE_OP);
USE_FLTRECORD(DummyRecord, OLD_TRANSLATE2_OP);
USE_FLTRECORD(DummyRecord, OLD_ROTATE_ABOUT_POINT_OP);
USE_FLTRECORD(DummyRecord, OLD_ROTATE_ABOUT_EDGE_OP);
USE_FLTRECORD(DummyRecord, OLD_SCALE_OP);
USE_FLTRECORD(DummyRecord, OLD_TRANSLATE_OP);
USE_FLTRECORD(DummyRecord, OLD_NONUNIFORM_SCALE_OP);
USE_FLTRECORD(DummyRecord, OLD_ROTATE_ABOUT_POINT2_OP);
USE_FLTRECORD(DummyRecord, OLD_ROTATE_SCALE_TO_POINT_OP);
USE_FLTRECORD(DummyRecord, OLD_PUT_TRANSFORM_OP);
USE_FLTRECORD(DummyRecord, OLD_BOUNDING_BOX_OP);
USE_FLTRECORD(DummyRecord, INDEXED_STRING_OP);
USE_FLTRECORD(DummyRecord, ROAD_ZONE_OP);
USE_FLTRECORD(DummyRecord, ROTATE_ABOUT_EDGE_OP);
USE_FLTRECORD(DummyRecord, TRANSLATE_OP);
USE_FLTRECORD(DummyRecord, NONUNIFORM_SCALE_OP);
USE_FLTRECORD(DummyRecord, ROTATE_ABOUT_POINT_OP);
USE_FLTRECORD(DummyRecord, ROTATE_SCALE_TO_POINT_OP);
USE_FLTRECORD(DummyRecord, PUT_TRANSFORM_OP);
USE_FLTRECORD(DummyRecord, GENERAL_MATRIX_OP);
USE_FLTRECORD(DummyRecord, VECTOR_OP);
USE_FLTRECORD(DummyRecord, BOUNDING_BOX_OP);
USE_FLTRECORD(DummyRecord, BOUNDING_SPHERE_OP);
USE_FLTRECORD(DummyRecord, BOUNDING_CYLINDER_OP);
USE_FLTRECORD(DummyRecord, BOUNDING_CONVEX_HULL_OP);
USE_FLTRECORD(DummyRecord, BOUNDING_HISTOGRAM);
USE_FLTRECORD(DummyRecord, BOUNDING_VOLUME_CENTER_OP);
USE_FLTRECORD(DummyRecord, BOUNDING_VOLUME_ORIENTATION_OP);
USE_FLTRECORD(DummyRecord, HISTOGRAM_BOUNDING_VOLUME_OP);
USE_FLTRECORD(PushLevel, PUSH_LEVEL_OP);
USE_FLTRECORD(PopLevel, POP_LEVEL_OP);
USE_FLTRECORD(PushSubface, PUSH_SUBFACE_OP);
USE_FLTRECORD(PopSubface, POP_SUBFACE_OP);
USE_FLTRECORD(PushExtension, PUSH_EXTENSION_OP);
USE_FLTRECORD(PopExtension, POP_EXTENSION_OP);
USE_FLTRECORD(PushAttribute, PUSH_ATTRIBUTE_OP);
USE_FLTRECORD(PopAttribute, POP_ATTRIBUTE_OP);
USE_FLTRECORD(Face, FACE_OP);
USE_FLTRECORD(VertexListRecord, VERTEX_LIST_OP);
USE_FLTRECORD(MorphVertexList, MORPH_VERTEX_LIST_OP);
USE_FLTRECORD(Mesh, MESH_OP);
USE_FLTRECORD(LocalVertexPool, LOCAL_VERTEX_POOL_OP);
USE_FLTRECORD(MeshPrimitive, MESH_PRIMITIVE_OP);
USE_FLTRECORD(LightPoint, LIGHT_POINT_OP);
USE_FLTRECORD(IndexedLightPoint, INDEXED_LIGHT_POINT_OP);
USE_FLTRECORD(LightPointSystem, LIGHT_POINT_SYSTEM_OP);
USE_FLTRECORD(VertexPalette, VERTEX_PALETTE_OP);
USE_FLTRECORD(ColorPalette, COLOR_PALETTE_OP);
USE_FLTRECORD(NameTable, NAME_TABLE_OP);
USE_FLTRECORD(MaterialPalette, MATERIAL_PALETTE_OP);
USE_FLTRECORD(OldMaterialPalette, OLD_MATERIAL_PALETTE_OP);
USE_FLTRECORD(TexturePalette, TEXTURE_PALETTE_OP);
USE_FLTRECORD(EyepointAndTrackplanePalette, EYEPOINT_AND_TRACKPLANE_PALETTE_OP);
USE_FLTRECORD(LinkagePalette, LINKAGE_PALETTE_OP);
USE_FLTRECORD(SoundPalette, SOUND_PALETTE_OP);
USE_FLTRECORD(LightSourcePalette, LIGHT_SOURCE_PALETTE_OP);
USE_FLTRECORD(LightPointAppearancePalette, LIGHT_POINT_APPEARANCE_PALETTE_OP);
USE_FLTRECORD(LightPointAnimationPalette, LIGHT_POINT_ANIMATION_PALETTE_OP);
USE_FLTRECORD(LineStylePalette, LINE_STYLE_PALETTE_OP);
USE_FLTRECORD(TextureMappingPalette, TEXTURE_MAPPING_PALETTE_OP);
USE_FLTRECORD(ShaderPalette, SHADER_PALETTE_OP);
USE_FLTRECORD(Header, HEADER_OP);
USE_FLTRECORD(Group, GROUP_OP);
USE_FLTRECORD(DegreeOfFreedom, DOF_OP);
USE_FLTRECORD(LevelOfDetail, LOD_OP);
USE_FLTRECORD(OldLevelOfDetail, OLD_LOD_OP);
USE_FLTRECORD(Switch, SWITCH_OP);
USE_FLTRECORD(ExternalReference, EXTERNAL_REFERENCE_OP);
USE_FLTRECORD(InstanceDefinition, INSTANCE_DEFINITION_OP);
USE_FLTRECORD(InstanceReference, INSTANCE_REFERENCE_OP);
USE_FLTRECORD(Extension, EXTENSION_OP);
USE_FLTRECORD(Object, OBJECT_OP);
USE_FLTRECORD(LightSource, LIGHT_SOURCE_OP);
USE_FLTRECORD(DummyRecord, 103);
USE_FLTRECORD(DummyRecord, 104);
USE_FLTRECORD(DummyRecord, 117)

Re: [osg-users] Coloring problems with basic geometry

[Robert Osfield]

On Tue, May 26, 2009 at 9:59 AM, Robert Osfield
 wrote:
>   
> http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/BasicGeometry
>
> I'll have a bash at updating it.

I've now updated this example to remove the colour indices mention,
and I've also updated the source file attached to this page to not use
colour indices either.   I also had to disable the lighting to get the
colouring to work appropriately.

I'm not the author of these tutorials don't know the original intent
w.r.t lighting, it's odd that no normals are attached but lighting is
still enabled.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help. KeyboardEventHandler and native keyboard layout bug in Linux

[Robert Osfield]

Hi Maxim,

2009/5/26 Maxim Gammer :
> hope to see my name in that list next release :)

We'll you'll need to get a submission accepted first :-)

For this particular fix I just used your submission as a point of
reference, it didn't work as is when I tested it due to problems with
case, so I wrote the final solution myself.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help. KeyboardEventHandler and native keyboard layout bug in Linux

[Maxim Gammer]

Thanks again,

hope to see my name in that list next release :)

Max Gammer

26 мая 2009 г. 14:09 пользователь Robert Osfield
 написал:
> Hi Maxim,
>
> 2009/5/26 Maxim Gammer :
>> I've cheсked the GraphicsWindowX11.cpp and it worked fine in OSG 2.8.1
>> and SVN. Thank you for your help. I hope this change will be included
>> in the next stable version.
>
>
> Yes it'll be in the next stable version.  Personally I'll be
> concentrating on OSG 2.10 now.  Others in the community with write
> permission to the branches are welcome to look at doing a 2.8.2.
>
>> Robert, I wonder what should be done to deserve being in the AUTHORS.txt? :)
>
> If I merge a code submission then I put a From FirstName SecondName at
> the beginning of the submission message, this is then parsed by
> osgversion to generate the AUTHORS.txt file from the ChangeLog.  Prior
> to each dev or stable release I run osgversion on the ChangeLog.  I
> never update the AUTHORS.txt file by hand, so it only updates at
> release point.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Maxim Gammer
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] share SDL OpenGL context, create offscreen rendering context

[Ulrich Hertlein]

Hi Robert,

sorry, I really didn't mean to pester you (or anybody else) with this stuff as much as I 
did :-}


Yes, SDL has limitations with multi context apps.  But since I'm plugging into existing 
code I can't very well say: it's too hard/impossible, switch to osgViewer (or Producer or 
whatever else does handle multi context apps properly).


Thanks for the advice, I guess we can put the topic to rest :-)

Cheers,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Coloring problems with basic geometry

[Robert Osfield]

Hi Lenlin,

On Tue, May 26, 2009 at 9:21 AM, Lelin ZHANG  wrote:
> Hi, Robert,
>
> Thanks for your reply. I am using the online scene graph tutorial at the 
> following link:
>
> http://www.openscenegraph.org/projects/osg/attachment/wiki/Support/Tutorials/BasicGeometry/BasicGeometry.cpp

Thanks for the link.  For future reference here's the link to the
original tutorial:

   
http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/BasicGeometry

I'll have a bash at updating it.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Coloring problems with basic geometry

[Ümit Uzun]

Hi Lelin,

More recent tutorial to study. (
http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials#YetAnotherSetofBeginnerTutorials
)

Regards.

2009/5/26 Lelin ZHANG 

> Hi, Robert,
>
> Thanks for your reply. I am using the online scene graph tutorial at the
> following link:
>
>
> http://www.openscenegraph.org/projects/osg/attachment/wiki/Support/Tutorials/BasicGeometry/BasicGeometry.cpp
>
> There are codes for adding texture to the pyramid. Even I have commented
> all texture related codes, leaving only simple vertex and color information,
> the colors are not showing up.
>
> By the way, do you know if there is any tutorials that might be much more
> up to date? Thanks very much.
>
> Lelin
>
>
> robertosfield wrote:
> > Hi Lelin,
> >
> > I don't know why your model turns out grey, there is just too small a
> > code fragment to know why.
> >
> > A general note, the uses of vertex indices is now deprecated, and will
> > eventually be dropped, so this tutorual is very out of date.  Could
> > you provide the url of the tutorial so we can look at getting the
> > reference to vertex indices removed to avoid further confusion.
> >
> > Robert.
> >
> > On Tue, May 26, 2009 at 1:34 AM, Lelin ZHANG <> wrote:
> >
> > > Hi,
> > >
> > > I am running the example code for 'basic geometry' of the tutorials. It
> seems that whatever I tried, the colors of the geometry do not show up.
> Everything just turns to be grey. It is frustrating that even I do not make
> any changes of the example codes at all, the colors still do not work. Could
> anyone give me a hint of the problem on this?
> > >
> > > Here are the codes for coloring:
> > >
> > >  osg::Vec4Array* colors = new osg::Vec4Array;
> > >  colors->push_back(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f) ); //index 0 red
> > >  colors->push_back(osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f) ); //index 1 green
> > >  colors->push_back(osg::Vec4(0.0f, 0.0f, 1.0f, 1.0f) ); //index 2 blue
> > >  colors->push_back(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f) ); //index 3 white
> > >
> > > osg::TemplateIndexArray
> > >   *colorIndexArray;
> > >   colorIndexArray =
> > > new osg::TemplateIndexArray osg::Array::UIntArrayType,4,4>;
> > > colorIndexArray->push_back(0);
> > > colorIndexArray->push_back(1);
> > > colorIndexArray->push_back(2);
> > > colorIndexArray->push_back(3);
> > > colorIndexArray->push_back(0);
> > >
> > > pyramidGeometry->setColorArray(colors);
> > > pyramidGeometry->setColorIndices(colorIndexArray);
> > > pyramidGeometry->setColorBinding(osg::Geometry::BIND_PER_VERTEX);
> > > ...
> > >
> > > Thank you!
> > >
> > > Cheers,
> > > Lelin
> > >
> > > --
> > > Read this topic online here:
> > > http://forum.openscenegraph.org/viewtopic.php?p=12933#12933
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > osg-users mailing list
> > >
> > >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > >
> > >
> > ___
> > osg-users mailing list
> >
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> >  --
> > Post generated by Mail2Forum
>
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=12948#12948
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Ümit Uzun
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] OpenFlight plugin and static linking

[Gregory Jaegy]

Hi,

the issue is, I would need to modify the PrimaryRecords.cpp file.

The plugins are instanced using static variable + a "extern C" function. This 
function is used in the project using OSG, which I guess forces the linker to 
include this function + the static variable defined in the same file...

Any help would be welcome ;)

Cheers,
Gregory

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12951#12951





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Setting camera target object

[Ümit Uzun]

Hi Sergey;

NodeTracker can be good starting point for you. Search and try to implement.
You can look at osgsimulation example. It use this tecnique for tracking
aircraft.

Regards.

2009/5/26 Sergey Bocharov 

> Hi, Robert.
>
> I searched for, but has not found.
>
> Sergey.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=12949#12949
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Ümit Uzun
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Setting camera target object

[Sergey Bocharov]

Hi, Robert.

I searched for, but has not found.

Sergey.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12949#12949





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Coloring problems with basic geometry

[Lelin ZHANG]

Hi, Robert,

Thanks for your reply. I am using the online scene graph tutorial at the 
following link:

http://www.openscenegraph.org/projects/osg/attachment/wiki/Support/Tutorials/BasicGeometry/BasicGeometry.cpp

There are codes for adding texture to the pyramid. Even I have commented all 
texture related codes, leaving only simple vertex and color information, the 
colors are not showing up.

By the way, do you know if there is any tutorials that might be much more up to 
date? Thanks very much.

Lelin


robertosfield wrote:
> Hi Lelin,
> 
> I don't know why your model turns out grey, there is just too small a
> code fragment to know why.
> 
> A general note, the uses of vertex indices is now deprecated, and will
> eventually be dropped, so this tutorual is very out of date.  Could
> you provide the url of the tutorial so we can look at getting the
> reference to vertex indices removed to avoid further confusion.
> 
> Robert.
> 
> On Tue, May 26, 2009 at 1:34 AM, Lelin ZHANG <> wrote:
> 
> > Hi,
> > 
> > I am running the example code for 'basic geometry' of the tutorials. It 
> > seems that whatever I tried, the colors of the geometry do not show up. 
> > Everything just turns to be grey. It is frustrating that even I do not make 
> > any changes of the example codes at all, the colors still do not work. 
> > Could anyone give me a hint of the problem on this?
> > 
> > Here are the codes for coloring:
> > 
> >  osg::Vec4Array* colors = new osg::Vec4Array;
> >  colors->push_back(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f) ); //index 0 red
> >  colors->push_back(osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f) ); //index 1 green
> >  colors->push_back(osg::Vec4(0.0f, 0.0f, 1.0f, 1.0f) ); //index 2 blue
> >  colors->push_back(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f) ); //index 3 white
> > 
> > osg::TemplateIndexArray
> >       *colorIndexArray;
> >   colorIndexArray =
> > new osg::TemplateIndexArray;
> > colorIndexArray->push_back(0);
> > colorIndexArray->push_back(1);
> > colorIndexArray->push_back(2);
> > colorIndexArray->push_back(3);
> > colorIndexArray->push_back(0);
> > 
> > pyramidGeometry->setColorArray(colors);
> > pyramidGeometry->setColorIndices(colorIndexArray);
> > pyramidGeometry->setColorBinding(osg::Geometry::BIND_PER_VERTEX);
> > ...
> > 
> > Thank you!
> > 
> > Cheers,
> > Lelin
> > 
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=12933#12933
> > 
> > 
> > 
> > 
> > 
> > ___
> > osg-users mailing list
> > 
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > 
> > 
> ___
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  --
> Post generated by Mail2Forum


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12948#12948





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] what's the value of RIGHT_MOUSE_BUTTON?

[Lingyun Yu]

I got it, thank you all!

On Mon, May 25, 2009 at 11:53 PM, Chris 'Xenon' Hanson  wrote:

> Lingyun Yu wrote:
> > I see, thank you paul. So if I want to judge which botton is pressed, I
> > should use ea->getButton(). But what's ea->getButtonMask() use for?
>
>   A mask value like that is usually used so it can indicate that multiple
> buttons are
> pressed simultaneously. The bits in the mask don't overlap.
>
> --
> Chris 'Xenon' Hanson, omo sanza lettere  Xenon
> AlphaPixel.com
> PixelSense Landsat processing now available!
> http://www.alphapixel.com/demos/
> "There is no Truth. There is only Perception. To Perceive is to Exist." -
> Xen
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Cheers,
Yun
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Setting camera target object

[Robert Osfield]

Hi Sergey,

There are a number of different ways to do this, have a look through
the archives as this topic has been discussed rather often.

Robert.

On Tue, May 26, 2009 at 9:06 AM, Sergey Bocharov  wrote:
> Hi, All
> Can I set target object for the camera, and when object will move, camera 
> will follow object?
>
> Thank you!
>
> Cheers,
> Sergey
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=12944#12944
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help. KeyboardEventHandler and native keyboard layout bug in Linux

[Robert Osfield]

Hi Maxim,

2009/5/26 Maxim Gammer :
> I've cheсked the GraphicsWindowX11.cpp and it worked fine in OSG 2.8.1
> and SVN. Thank you for your help. I hope this change will be included
> in the next stable version.


Yes it'll be in the next stable version.  Personally I'll be
concentrating on OSG 2.10 now.  Others in the community with write
permission to the branches are welcome to look at doing a 2.8.2.

> Robert, I wonder what should be done to deserve being in the AUTHORS.txt? :)

If I merge a code submission then I put a From FirstName SecondName at
the beginning of the submission message, this is then parsed by
osgversion to generate the AUTHORS.txt file from the ChangeLog.  Prior
to each dev or stable release I run osgversion on the ChangeLog.  I
never update the AUTHORS.txt file by hand, so it only updates at
release point.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Setting camera target object

[Sergey Bocharov]

Hi, All
Can I set target object for the camera, and when object will move, camera will 
follow object?

Thank you!

Cheers,
Sergey

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12944#12944





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Coloring problems with basic geometry

[Robert Osfield]

Hi Lelin,

I don't know why your model turns out grey, there is just too small a
code fragment to know why.

A general note, the uses of vertex indices is now deprecated, and will
eventually be dropped, so this tutorual is very out of date.  Could
you provide the url of the tutorial so we can look at getting the
reference to vertex indices removed to avoid further confusion.

Robert.

On Tue, May 26, 2009 at 1:34 AM, Lelin ZHANG  wrote:
> Hi,
>
> I am running the example code for 'basic geometry' of the tutorials. It seems 
> that whatever I tried, the colors of the geometry do not show up. Everything 
> just turns to be grey. It is frustrating that even I do not make any changes 
> of the example codes at all, the colors still do not work. Could anyone give 
> me a hint of the problem on this?
>
> Here are the codes for coloring:
>
>  osg::Vec4Array* colors = new osg::Vec4Array;
>  colors->push_back(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f) ); //index 0 red
>  colors->push_back(osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f) ); //index 1 green
>  colors->push_back(osg::Vec4(0.0f, 0.0f, 1.0f, 1.0f) ); //index 2 blue
>  colors->push_back(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f) ); //index 3 white
>
> osg::TemplateIndexArray
>       *colorIndexArray;
>   colorIndexArray =
> new osg::TemplateIndexArray;
> colorIndexArray->push_back(0);
> colorIndexArray->push_back(1);
> colorIndexArray->push_back(2);
> colorIndexArray->push_back(3);
> colorIndexArray->push_back(0);
>
> pyramidGeometry->setColorArray(colors);
> pyramidGeometry->setColorIndices(colorIndexArray);
> pyramidGeometry->setColorBinding(osg::Geometry::BIND_PER_VERTEX);
> ...
>
> Thank you!
>
> Cheers,
> Lelin
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=12933#12933
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Help. KeyboardEventHandler and native keyboard layout bug in Linux

[Maxim Gammer]

Hello Robert,

I've cheсked the GraphicsWindowX11.cpp and it worked fine in OSG 2.8.1
and SVN. Thank you for your help. I hope this change will be included
in the next stable version.

Robert, I wonder what should be done to deserve being in the AUTHORS.txt? :)


Max Gammer.

2009/5/25 Robert Osfield :
> Hi Maxim,
>
> Good to hear that it's now working.  I've now checked in the fix to
> svn/trunk and the OSG-2.8 branch.  Alas it missed 2.8.1 though...
>
> Robert.
>
>
> On Mon, May 25, 2009 at 5:14 PM, Maxim Gammer  wrote:
>> Hi Robert,
>> If the keyboard layout is English (USA) or Russian then
>> KeyboardEventHandler works fine!
>> Thank you very much.
>>
>> p.s. OSG 2.8.1
>> (and Nvidia PhysX 2.8.1 ) )
>>
>> 2009/5/25 Robert Osfield :
>>> Hi Maxim,
>>>
>>> Argg... I modified the GraphicsWindowX11.cpp in svn/trunk and you are
>>> obviously using a prior version of the OSG.  Attached is the svn/trunk
>>> version of GraphicsWindow that has the Hand definition.  Hopefully
>>> this will be enough, if not you might need to grab the svn/trunk
>>> version of the OSG.
>>>
>>> Which version of the OSG are you using?
>>>
>>> Robert.
>>>
>>>
>>>
>>> On Mon, May 25, 2009 at 4:37 PM, Maxim Gammer  wrote:
 Hi Robert,

 I replace GraphicsWindowX11.cpp and run make 

 .
 [ 25%] Built target osgText
 Scanning dependencies of target osgViewer
 [ 25%] Building CXX object
 src/osgViewer/CMakeFiles/osgViewer.dir/CompositeViewer.o
 [ 25%] Building CXX object 
 src/osgViewer/CMakeFiles/osgViewer.dir/HelpHandler.o
 [ 25%] Building CXX object 
 src/osgViewer/CMakeFiles/osgViewer.dir/Renderer.o
 [ 25%] Building CXX object src/osgViewer/CMakeFiles/osgViewer.dir/Scene.o
 [ 25%] Building CXX object
 src/osgViewer/CMakeFiles/osgViewer.dir/ScreenCaptureHandler.o
 [ 25%] Building CXX object 
 src/osgViewer/CMakeFiles/osgViewer.dir/StatsHandler.o
 [ 26%] Building CXX object src/osgViewer/CMakeFiles/osgViewer.dir/Version.o
 [ 26%] Building CXX object src/osgViewer/CMakeFiles/osgViewer.dir/View.o
 [ 26%] Building CXX object src/osgViewer/CMakeFiles/osgViewer.dir/Viewer.o
 [ 26%] Building CXX object 
 src/osgViewer/CMakeFiles/osgViewer.dir/ViewerBase.o
 [ 26%] Building CXX object
 src/osgViewer/CMakeFiles/osgViewer.dir/ViewerEventHandlers.o
 [ 26%] Building CXX object
 src/osgViewer/CMakeFiles/osgViewer.dir/GraphicsWindowX11.o
 /home/maximum2000/DEVELOP/OpenSceneGraph-2.8.1/src/osgViewer/GraphicsWindowX11.cpp:
 In member function 'Cursor
 osgViewer::GraphicsWindowX11::getOrCreateCursor(osgViewer::GraphicsWindow::MouseCursor)':
 /home/maximum2000/DEVELOP/OpenSceneGraph-2.8.1/src/osgViewer/GraphicsWindowX11.cpp:555:
 error: no declaration 'HandCursor'
 make[2]: *** [src/osgViewer/CMakeFiles/osgViewer.dir/GraphicsWindowX11.o]
 error 1
 make[1]: *** [src/osgViewer/CMakeFiles/osgViewer.dir/all] error 2
 make: *** [all] Error 2
 maximum2...@maximum2000-desktop:~/DEVELOP/OpenSceneGraph-2.8.1/tempo$


 2009/5/25 Robert Osfield :
> Hi Maxim,
>
> I've tried out your suggestion of just using the remappedKey value as
> the returned keySymbol but found that it lost the case of characters
> that I was typing, so this alone won't be sufficient for a cross
> locale solution.
>
> Further investigation revealed that the GraphicsWindowX11.cpp class
> X11KeyboardMap which does the remapping to OSG specific control keys
> was receiving a keyboard symbol with the correct case, but then
> remapping the XK_a etc. to 'A' rather than 'a', so it was the
> cultprit.  Changing the mapping of the lower case XK_a to 'a' etc.
> solved the problem and has allow me to use the remappedKey directly in
> all cases, like you've done on your system.
>
> I've attached my modified GraphicsWindowX11.cpp, could you try it out
> on your system to see if it works OK, if it does then I'll merged this
> into svn/trunk.
>
> Thanks,
> Robert.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



 --
 Maxim Gammer
 ___
 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
>>>
>>>
>>
>>
>>
>> --
>> Maxim Gammer
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
> _

Re: [osg-users] share SDL OpenGL context, create offscreen rendering context

[Robert Osfield]

Hi Ulrich,

On Mon, May 25, 2009 at 8:44 PM, Ulrich Hertlein  wrote:
>> Basically SDL can't do multiple context work.
>
> Okay, but OSG can, right?  So if SDL thinks it's only dealing with a single
> context and OSG does the context work (make pbuffer context current, render,
> release) wouldn't that work?

No.  If you have a single thread you have to make one context current
do stuff, then release the context, then make the new context current,
do stuff, then release the second context, then make the first context
current again.

>> The best you can do in your position is try to use the OSG's FBO
>> support at least then you could do everything from a single graphics
>> context.
>
> But OSG and SDL would still get in each others way w.r.t. OpenGL state
> handling.

No.  SDL doesn't do any OpenGL state work as far as I'm aware, it just
sets up the context and then your app does everything else.

> I was (still am) hoping that I can get OSG to create and manage a separate
> context alongside the SDL OpenGL context.  Worst case the only linkage would
> be via glReadPixels from the OSG context and uploading to another context.

Man you're making this hard for yourself.  Stop expecting SDL to be
your friend on this stuff.  It's designed for simple OpenGL apps that
just need a single context and to run it single threaded - for this
it's great, go outside this scope and your on going to waste your time
and everybody elses.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Foring Trilinear Mipmaping

[Robert Osfield]

Hi Guy,

As Chris suggested the best tool for doing this job automatically is a
custom osgDB::Registry::ReadFileCallback that loads the models using
the standard Registry::readNodeImplementation() method and then run a
custom NodeVisitor that locates all the textures and changes their
filter settings appropriately.

Robert.

On Mon, May 25, 2009 at 7:47 PM, Guy Volckaert
 wrote:
> Hi,
>
> I have several openflight terrain database that use bilinear mipmaping (which 
> look ugly). Is there a easy way to force all terrains to use trilinear 
> mipmapping upon loading the terrain? Obviously I can change the openflight 
> plugin to check if a trilinear flag is set, but I would like to avoid 
> changing any OSG file.
>
> Thank you!
>
> Cheers,
> Guy
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=12925#12925
>
>
>
>
>
> ___
> 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] OpenGL ES 2.0 Support ?

[Robert Osfield]

Hi Craig,

On Mon, May 25, 2009 at 7:31 PM, Craig Bosma  wrote:
> Sorry to resurrect this dead thread, but can you elaborate at all on
> the current status of OpenGL ES support in OSG? You mentioned that
> there are ports to ES already that aren't yet open source; is there
> something preventing them from being opened at this time, even in a
> (possibly) incomplete form?

The current OpenGL ES 1.x ports are test ports that are a proof of
concept.  I don't yet have a timeline on when these might turn into
full ports.

No OpenGL ES 2.0 port has been attempted yet as far as I'm aware.
OpenGL ES 2.0 and OpenGL 3.0 support are related as neither of these
libs have any fixed function pipeline support.

I'm keen to see OpenGL ES 1.x and 2.x supported, but as I have limited
time and resources available personally I can only act as a mentor for
this work.  Once the heavy lifted begins I'll provide branch access to
the OSG' svn repository to allow development work to carry on as
OpenGL ES 1.x and OpenGL ES 2.x branches, once these branches solidify
then I'll work to pull OpenGL ES support into the core OSG.

If you want to get involved in this effort I can pass your name on the
groups currently looking at OpenGL ES.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Stereo Problem

[Himar Carmona]

Hi,

   interesting thread. Recently my team started experimentation with Stereo
and the new Nvidia glasses. We use of course OSG, and we were wonder how we
could use the glasses with OpenGL.

   Here are our impressions and results (for those of you who are
interested):

   We have a Quadro FX 370 (i think this is the worst one for the Quadro
series) and it has Stereo support (activation required via control panel),
i.e. OSG can use QUAD_BUFFER, but it does not have the stereo plug, so we
use this vga stereo adapter to generate the sync signal (
http://www.int03.co.uk/crema/hardware/stereo/) (use pin 10 and 14 of vga
DB15, that is vertical sync). Recently i discovered that Lightspeed
(DepthQ's vendor) sells an vga stereo adapter. I suppose there must be other
vendors thats provides those, aren't they?

   Of course (thanks Nvidia), the 3d vision driver does not like Quadro
drivers, so it does not install. Therefore we use another pc with a Geforce
card, where we install the driver and the ir emitter. In this pc we
configure the driver to use a HDTV DLP or a generic crt, otherwise the ir
emitter neglects to use the minijack sync in signal. Also, for the ir
emitter to work, it must have a fullscreen directx application running  (we
use the test from the control panel because we run on windows), otherwise it
will be in standby mode. After some experimentation we achieved it and we
were able to "see" in stereo with OSG in the other pc with the quadro.

   Our impressions:

Though the glasses are "VESA compatible", the ir emitter doesn't work if
it isn't connected to the pc via USB AND a DirectX application is running
fullscreen.
The ir emitter does not use the sync in signal if it is connected to a
"3d ready" display (either samsung 120Hz lcd and DepthQ projector). It
seems to prioritize the usb  signal in these cases.
The glasses doesn't work  for us at 75Hz display vertical sync. We used
60Hz and all went ok, but with a 75Hz refresh rate we experimented sync
problems.
Rivatuner and 3d vision drivers aren't compatible with each other. You
can't install them both (again, windows platform).

Only one question without answer: Will the Nvidia shutter glasses work with
a standalone DLP TV with 3d support? Where will the ir emitter be connected,
via sync in signal to the tv or via usb cable to a pc? Will never know, the
glasses are a bit of disappoinment.

So, although we were able to make it work, it seems that there are only two
options: Either Nvidia adds supports for quad buffer in their drivers (as
stated here http://www.nvidia.com/object/quadro_stereo_technology.html) or
we better stand with the "professional" shutter glasses and forgets about
the Nvidia "only for games" ones.

Ah, maybe someone out there with a Quadro FX with the stereo plug and the
nvidia shutter glasses can reply me: Does the glasses work with it?

Best Regards,
Himar.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Coloring problems with basic geometry

[Lelin ZHANG]

Hi,

I am running the example code for 'basic geometry' of the tutorials. It seems 
that whatever I tried, the colors of the geometry do not show up. Everything 
just turns to be grey. It is frustrating that even I do not make any changes of 
the example codes at all, the colors still do not work. Could anyone give me a 
hint of the problem on this? 

Here are the codes for coloring:

 osg::Vec4Array* colors = new osg::Vec4Array;
 colors->push_back(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f) ); //index 0 red
 colors->push_back(osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f) ); //index 1 green
 colors->push_back(osg::Vec4(0.0f, 0.0f, 1.0f, 1.0f) ); //index 2 blue
 colors->push_back(osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f) ); //index 3 white

osg::TemplateIndexArray
   *colorIndexArray;
   colorIndexArray = 
new osg::TemplateIndexArray;
colorIndexArray->push_back(0);
colorIndexArray->push_back(1);
colorIndexArray->push_back(2);
colorIndexArray->push_back(3);
colorIndexArray->push_back(0);

pyramidGeometry->setColorArray(colors);
pyramidGeometry->setColorIndices(colorIndexArray);
pyramidGeometry->setColorBinding(osg::Geometry::BIND_PER_VERTEX);
... 

Thank you!

Cheers,
Lelin

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=12933#12933





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] problem with blending when using floating point FBO

[J.P. Delport]

Hi,

I've quickly looked through the code, two lines bugged me:

// Tell to sort the mesh before displaying it

AFAIK OSG does not sort at the triangle level, there is an option to 
make the sorting happen at a primitive level, but I think the default is 
sorting on bounding sphere.


offscreenTexture->setSourceType( GL_UNSIGNED_BYTE);

Should this not also be GL_FLOAT?

---

I can also not see from the code if OpenGL lighting is enabled. Do you 
disable lighting in your app?


jp



jonathan.richa...@gmail.com wrote:

Hi,

The colors are attached by setting the ColorArray of the drawables of 
each Geode like this:


int geodesNb = m_entityVectorOfGeodeVector[0].size();

osg::Geode* aGeode;
int drawablesNb;
osg::Drawable* aDrawable;
osg::Geometry* aDrawableGeometry;
osg::Vec4Array* aDrawableColor;
for (int geodesLoop = 0; geodesLoop < geodesNb; geodesLoop++)
{
aGeode = m_entityVectorOfGeodeVector[0][geodesLoop];
drawablesNb = aGeode->getNumDrawables();

// Update color for each facet (drawable) of a geode
for (int i = 0; i < drawablesNb; i++)
{
aDrawable = aGeode->getDrawable(i);
aDrawable->dirtyDisplayList(); // Force color update on next draw

aDrawableGeometry = dynamic_cast(aDrawable);

aDrawableColor = 
dynamic_cast(aDrawableGeometry>getColorArray());


std::string geodeName=aGeode->getName();

if(!geodeName.compare("p1"))
{
// Set the facet color and transparency (0=invisible)
(*aDrawableColor)[0] = m_facet1Color;

…
}
}
}

Where the entityVectorOfGeodeVector is the list of visible geodes that I 
maintain by using a cull callback.



Here a snapshot of my code to setup the viewer and the camera.

m_viewer = new osgViewer::Viewer;
m_viewer->setUpViewOnSingleScreen();
osg::Camera *camera = m_viewer->getCamera();

osgViewer::Renderer * renderer = 
static_cast(camera->getRenderer());
// Reading back the FBO does not work when it is disabled after render 
--> set this property of the

// renderStage to false.
renderer->getSceneView(0)->getRenderStage()->setDisableFboAfterRender(false);
renderer->getSceneView(1)->getRenderStage()->setDisableFboAfterRender(false);

m_scene=new osg::Group();

std::string modelName="C:\\_JO\\LTI\\SIS\\Models\\test_IR\\carre.flt";

LoadModel(modelName); // call m_viewer->SetSceneData

osg::StateSet* state = m_scene->getOrCreateStateSet();

// Enable transparency
state->setMode(GL_BLEND, osg::StateAttribute::OVERRIDE | 
osg::StateAttribute::ON);

// Tell to sort the mesh before displaying it
state->setRenderingHint(osg::StateSet::TRANSPARENT_BIN);

// Set the blend function (related to the transparency)
osg::BlendFunc* selectedBlendFunction = new osg::BlendFunc();
selectedBlendFunction->setDestination(GL_ONE_MINUS_SRC_ALPHA);
selectedBlendFunction->setSource(GL_ONE);

state->setAttribute(selectedBlendFunction, osg::StateAttribute::OVERRIDE 
| osg::StateAttribute::ON);


osg::Image* offscreenImage = new osg::Image;
osg::ref_ptr offscreenTexture = new 
osg::TextureRectangle;


// Allocate the image
offscreenImage->allocateImage(WIDTH, HEIGHT, 1, GL_RGBA, GL_FLOAT);

// Set the 32 bits texture
offscreenTexture->setImage(offscreenImage);
offscreenTexture->setSourceFormat(GL_RGBA);
offscreenTexture->setSourceType( GL_UNSIGNED_BYTE);
offscreenTexture->setTextureSize(WIDTH, HEIGHT);

// Initialize the background
camera->setClearColor(osg::Vec4f(0.0f,0.0f,0.0f,1.0f));

camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
camera->attach(osg::Camera::COLOR_BUFFER0,offscreenTexture.get());
camera->setFinalDrawCallback(new MyCameraDrawCallback(precision));

m_viewer->realize();

// Set the colors R G B A
m_facet1Color = osg::Vec4( 0.2, 0.0, 0.0, 1.0 );
m_facet2Color = osg::Vec4( 0, 0.1, 0.0, 1.0 );
m_facet3Color = osg::Vec4( 4e-6, 0.0, 0.1, 1.0 );
m_facet4Color = osg::Vec4( 5e-5, 0.5, 0.5, 1.0 );
m_facet5Color = osg::Vec4( 6e-9, 0.1, 0.0, 1);

…

// Code of my camera Drawcallback
void MyCameraDrawCallback::operator() (osg::RenderInfo& renderInfo) const
{
glReadBuffer(GL_COLOR_ATTACHMENT0_EXT);
m_image->readPixels(0,0,WIDTH,HEIGHT, GL_RGBA,GL_FLOAT);
}

I hope it can help you to help me ;) I could provide you my testing 
project is you want.

Thank you
Jonathan




On 2009-05-25 10:59am, "J.P. Delport"  wrote:
 > Hi,
 >
 >
 >
 > posting some code would prob be best. How are you attaching the 
colours to your "facets"? Texture? Shader?

 >
 >
 >
 > A few things on my checklist normally:
 >
 > Lighting off
 >
 > Background
 >
 > Render order
 >
 > MRT enabled
 >
 > gl_FragData in shaders
 >
 > Texture mode
 >
 >
 >
 > jp
 >
 >
 >
 > jonathan.richa...@gmail.com wrote:
 >
 >
 > Hi,
 >
 >
 >
 > my card is a Nvidia geforce 8800 gtx: 
http://www.nvidia.com/page/8800_tech_specs.html

 >
 >
 >
 >
 >
 > It say "32-bit per component floating point texture filtering and 
blending".

 >
 >
 >
 > Jonathan
 >
 >
 >
 >
 >
 > On 2009-05-25 10:26am, "J.P. Delport" jpdelp...@csir.co.za> wrote:
 >
 >  > Hi,
 >
 >  >
 >
 >  >
 >
 >  >
 >
 >  > are you sure your hardware supports 32-bit blen