[osg-users] Accessing floating point textures in Fragment Shader

2008-10-17 Thread Harash Sharma
Hi all,
 
    I am facing a problem in accessing the floating point texture within a 
fragment shader. I have some 2D floating point array that I wish to access 
within the Fragment Shader. For the purpose, 
1. I have created an image with the pixel format GL_LUMINANCE and data type of 
GL_FLOAT. 
2. The Array data is copied to the Image data array.
3. The image is bound to a texture and this texture passed as uniform to the 
Fragment Shader.
 
The output is a totally white screen.
 
However, if I modify the Pixel format to GL_RGBA and the datatype to 
GL_UNSIGNED_BYTE and convert the values to integer and split the 4 bytes of 
unsigned int into R,G,B,A, I am able to reconstruct the values within the 
shader and process the fragment accordingly. 
 
I am using nVidia Quadro Fx 4500 graphics card on Intel Xeon 5160 processor. 
 
Please Guide
 
Regards
 
Harash.


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


[osg-users] Viewports and actions on window resize

2008-10-17 Thread Alexander Löffler
Hi,

I would like to use an osgViewer::Viewer which should render to a constant
aspect ratio and fill the rest of any rendering window with black in any case;
also on resizing.

For that matter, I have implemented an updateViewport() method that resizes my
Viewport centered in the correct aspect ratio and according to my current window
size. This works in general, but two questions remain:

- I have called this method both as an event handler on window resize events,
and as a ResizeCallback in my GraphicsContext. Where is the correct place to put
this? If I replace the ResizeCallback of the Context, do I have to take care of
more things than just setting the viewport correctly?

- On resize in either case, ghost images of the rendering to the former window
size remain. What do I have to do to flush anything that happened before, and
just render black in the surrounding area of my viewport? Also interesting: if I
render to texture in my application, and use the frame buffer as target, those
areas that are not overwritten by the actual rendering viewport still show the
texture that is rendered to in RTT. In all cases, what I want is just plain
black. ;)

Thanks a lot,
Alex.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Strips on AnimatedTexturing on Terrain by GLSL

2008-10-17 Thread Ümit Uzun
Hi All,

I had created animated texturing on terrain with using shaders but I have
already realized some artifacts on the terrain as you see from that
VIDEOhttp://www.fileden.com/files/2007/9/10/1423182/AnimetedTexturing.wmv.
Why have this strips created on the terrain in each loop?
Any advices to get rid of them ?

Note : In vertex shader I only iterate the caustics texture x coordinate by
the way,

causticsCoords = gl_MultiTexCoord0.xy;;
causticsCoords.x = fract( causticsCoords.x + float( timeValue *
causticsSpeed ) );

All of the important pattern about animating texture on terrain is preceeded
dodes.

Best Regards.

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


Re: [osg-users] Accessing floating point textures in Fragment Shader

2008-10-17 Thread Robert Osfield
Hi Harash,

floating point formats are not available for all pixel formats.  Have
a look at the OpenGL specs/extension registry on the topic of float
textures to see what floating point formats are supported.

Robert.

On Fri, Oct 17, 2008 at 8:28 AM, Harash Sharma [EMAIL PROTECTED] wrote:
 Hi all,

 I am facing a problem in accessing the floating point texture within a
 fragment shader. I have some 2D floating point array that I wish to access
 within the Fragment Shader. For the purpose,
 1. I have created an image with the pixel format GL_LUMINANCE and data type
 of GL_FLOAT.
 2. The Array data is copied to the Image data array.
 3. The image is bound to a texture and this texture passed as uniform to the
 Fragment Shader.

 The output is a totally white screen.

 However, if I modify the Pixel format to GL_RGBA and the datatype to
 GL_UNSIGNED_BYTE and convert the values to integer and split the 4 bytes of
 unsigned int into R,G,B,A, I am able to reconstruct the values within the
 shader and process the fragment accordingly.

 I am using nVidia Quadro Fx 4500 graphics card on Intel Xeon 5160 processor.

 Please Guide

 Regards

 Harash.

 ___
 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] Viewports and actions on window resize

2008-10-17 Thread Robert Osfield
Hi Alex,

On Fri, Oct 17, 2008 at 9:29 AM, Alexander Löffler [EMAIL PROTECTED] wrote:
 For that matter, I have implemented an updateViewport() method that resizes my
 Viewport centered in the correct aspect ratio and according to my current 
 window
 size. This works in general, but two questions remain:

 - I have called this method both as an event handler on window resize events,
 and as a ResizeCallback in my GraphicsContext. Where is the correct place to 
 put
 this? If I replace the ResizeCallback of the Context, do I have to take care 
 of
 more things than just setting the viewport correctly?

Have a browse through the GraphicsContext::resizedImplementation(..)
method in src/osg/GraphicsContext.cpp as it's this implementation that
you are overriding.  See what it does w.r.t viewpors and aspect
ratios.  You may be able to ignore all of it, but it's better to
ignore all of it in knowledge of what you are leaving out than miss
something.

 - On resize in either case, ghost images of the rendering to the former window
 size remain. What do I have to do to flush anything that happened before, and
 just render black in the surrounding area of my viewport? Also interesting: 
 if I
 render to texture in my application, and use the frame buffer as target, those
 areas that are not overwritten by the actual rendering viewport still show the
 texture that is rendered to in RTT. In all cases, what I want is just plain
 black. ;)

The GraphicsContext has a clear colour colour and clear mask methods
that you can use to clear the graphics context on each new frame.  By
default the GraphicsContext has a clear mask of 0 so does nothing, as
the Camera's normally cover the whole screen, but in your case you'll
need the GraphicsContext clear.  The methods are:

/** Sets the clear color. */
inline void setClearColor(const Vec4 color) { _clearColor = color; }

/** Returns the clear color. */
inline const Vec4 getClearColor() const { return _clearColor; }

/** Set the clear mask used in glClear(..).
  * Defaults to GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT. */
inline void setClearMask(GLbitfield mask) { _clearMask = mask; }

/** Get the clear mask.*/
inline GLbitfield getClearMask() const { return _clearMask; }

I vaguely recall that I might have tested this in the osgcamera
example, so have a look at this.

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


Re: [osg-users] Another case for extendable plugin loaders... Was Re:DDS textures flipped on flt files

2008-10-17 Thread Robert Osfield
HI Brett,

All you need to do is set the Registry's Options object for the default setting.

osgDB::ReaderWriter::Options* options = new
osgDB::ReaderWriter::Options;
options-setOptionString(str);
osgDB::Registry::instance()-setOptions(options);

Robert.

On Fri, Oct 17, 2008 at 1:25 AM, brettwiesner [EMAIL PROTECTED] wrote:

 brettwiesner wrote:

 Hey,

 Since most DDS textures are going to come in flipped (ie: directX style
 and not openGL style) I would like my application to always pass the
 dds_flip option to the DDS loader. If I could extend the DDS loader I
 could do that. Just another case for including the loaders as actual
 libs and the plugins themselves as smaller projects that just use the
 loaders api.


 It's easy enough to hard code a ReaderWriter option:

 options = new osgDB::ReaderWriter::Options(dds_flip);
 texImage = osgDB::readImageFile(filename, options);


 You might want to use a ref_ptr for the options object, but basically, the
 above should work.

 --J

 I think you're misunderstanding. I'm not loading the texture myself. Other
 loaders are... the flt loader, the 3ds loader, etc. Surely you don't mean to
 change all of them to pass that option? I'm actually trying to avoid
 changing OSG source (otherwise I could just have the DDS loader always use
 that option).

 I'm suggesting two things...

 1) that the DDS loader be fixed (ie: DDS is a directX file format and it's
 coordinate system is directX. OSG should expect that DDS files come in that
 coordinate system and flip them automatically).
 2) And that I should be able to derive MyDdsLoader from a osgDB::ddsLoader
 and register that with the osgDB_dds plugin so that my loader is used.

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

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


Re: [osg-users] Strips on AnimatedTexturing on Terrain by GLSL

2008-10-17 Thread David Spilling
Umit,

It's a well known gotcha with texture repeats.

Each vertex has increasing causticsCoord.x. Imagine the vertices with coord
0.0, 0.1, 0.2, 0.3 etc. The fragments in between any of these coords have
_interpolated_ texcoords i.e. a fragment halfway betwen 0.0 and 0.1 vertex
has a texcoord of 0.05.

For the end vertices, you have 0.8,0.9,1.0, 1.1. The fract function turns
this into 0.8, 0.9, 0.0, 0.1

Hence a fragment half way between 0.9 and 1.0 interpolates the texcoord
between 0.9 and 0.0, giving 0.45, not 0.95 as you would want. Between 0.9
and 1.0, then the actual texcoord used decreases rapidly from 0.9 to 0.0.

The artifact you see is all of your caustics texture, mirrored, and shoved
into the last vertex gap.

To get rid if it, try losing the fract instruction. There may also be
dependencies on your texture mode (REPEAT, MIRROR, CLAMP) that you might
need to play with depending on what your texture looks like.

Hope that helps,

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


Re: [osg-users] Another case for extendable plugin loaders... Was Re:DDS textures flipped on flt files

2008-10-17 Thread Robert Osfield
Hi David,

On Fri, Oct 17, 2008 at 10:24 AM, David Spilling
[EMAIL PROTECTED] wrote:
 Ah! I learn something every day...

 Is there any system-wide check (other than by eye, at checkin) that makes
 sure that all of the options are unique to each loader? e.g. there isn't a
 dds_flip option in, say, the .ac3d loader?

There is only one default Options obejct attached to the Registry,
this is passed to all plugins if you don't pass your own Options
object to the readNode/Image/etc call.  The plugins themselves just
need to pick out what parts of the options string that make sense to
them - so the ac3d plugin wouldn't care about dds_flip.

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


[osg-users] Simple sunlight shadow technqiue

2008-10-17 Thread Roger James




I am experimenting with a simple sunlight shadow technique using the
osgShadow model and basic depth shadows. I would like to set up the
shadow casting camera so that I end up with a shadow texture that is a
near as possible "filled" with the shadow casting objects as culled by
the LOD nodes in the scene using the the inherited viewpoint. It seems
to me that the best place to set up this bounding information is during
the main scene cull traverse that is done in my(most) shadow technique
prior to the render to shadow texture cull traverse. I want to avoid
having to manage the placing and removing of cull call backs on every
shadow casting geode, which may be different as the user manipulates
the scene. The only way I can think of doing this is to derive my own
CullVisitor and override the Geode apply function. Have I missed
something here? Is there a better way to do it? I know the LISP shadow
techniques have a number of complex ways of doing this but I am trying
to implement something simple that uses inbuilt OpenGL functionality
wherever possible.

Roger


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


Re: [osg-users] Another case for extendable plugin loaders... Was Re:DDS textures flipped on flt files

2008-10-17 Thread David Spilling
Ah! I learn something every day...

Is there any system-wide check (other than by eye, at checkin) that makes
sure that all of the options are unique to each loader? e.g. there isn't a
dds_flip option in, say, the .ac3d loader?

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


[osg-users] compilation problem on mac os x

2008-10-17 Thread Stephan Ohl

Hello,

 I have problems to get osg running on Mac OSX using the standard  
unix way.
The problem is due to the freetype library because the headers can't  
be found.
So freetype2 is installed on my system, but I saw that #include  
doesn't use   system

includes. I wasn't able to figure out where to put the freetype sources.

How does the osg build system locates the freetype2 sources? What is  
the standard

way to use them?

Thanks for your help,
 Stephan

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


Re: [osg-users] Advice on interacting with osgShadow

2008-10-17 Thread Wojciech Lewandowski

Hi J-S,

Ok, then lets postpone any changes to the moment we hear additional requests 
from others. Once you managed to solve your blending issue this discussion 
seems purely academic. Lets wait for some practical problems to appear. I 
think this is actually best choice. With every piece we add, we make some 
fuctionality easier to use,  but we also make already complex code even more 
complicated.


However ;-) there is one little tweak I will submit. I will add default 
AlphaFunc/AlphaTest to shadow camera stateset. That way I will avoid 
transparency with typical models (which started discussion ;-). I should 
have done it in the first place to be consistent with render bin override 
policy. But I have neglected it beacuse our models had this attribute set.


Cheers,
Wojtek




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


Re: [osg-users] Strips on AnimatedTexturing on Terrain by GLSL

2008-10-17 Thread Ümit Uzun
Hi David,

I unattached the fract math function and all strips gone away :) I haven't
thought it was a simple bug :)

Thanks so much.
Best regards.

Umit Uzun

2008/10/17 David Spilling [EMAIL PROTECTED]

 Umit,

 It's a well known gotcha with texture repeats.

 Each vertex has increasing causticsCoord.x. Imagine the vertices with coord
 0.0, 0.1, 0.2, 0.3 etc. The fragments in between any of these coords have
 _interpolated_ texcoords i.e. a fragment halfway betwen 0.0 and 0.1 vertex
 has a texcoord of 0.05.

 For the end vertices, you have 0.8,0.9,1.0, 1.1. The fract function turns
 this into 0.8, 0.9, 0.0, 0.1

 Hence a fragment half way between 0.9 and 1.0 interpolates the texcoord
 between 0.9 and 0.0, giving 0.45, not 0.95 as you would want. Between 0.9
 and 1.0, then the actual texcoord used decreases rapidly from 0.9 to 0.0.

 The artifact you see is all of your caustics texture, mirrored, and shoved
 into the last vertex gap.

 To get rid if it, try losing the fract instruction. There may also be
 dependencies on your texture mode (REPEAT, MIRROR, CLAMP) that you might
 need to play with depending on what your texture looks like.

 Hope that helps,

 David


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


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


[osg-users] [osg-submissions] AC3D Texture clamping

2008-10-17 Thread Csaba Halász
Hi!

The texrep parsing change that went into the plugin about 2 weeks ago
is against the ac3d spec, that says:

*texrep %f %f

Optional - default 1.0,1.0 .  The texture repeat values for the tiling
of a texture
on an object's surfaces.

(http://www.inivis.com/ac3d/man/ac3dfileformat.html)

I believe this means the default behavior should be texture repeat
(assuming texrep 0 0 would disable repeat, which I am not sure of).
Can we please change it or at least have an option for it? In
flightgear a lot of models are suddenly broken because of this.

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


Re: [osg-users] Simple sunlight shadow technqiue

2008-10-17 Thread Wojciech Lewandowski
Roger,

I had similar dilemma at some point. I was thinking about overridding cull 
visitor but had problem how to substitute original cull visitor with my class 
in the middle of cull traversal. Finally I adopted other approach. Once Cull 
Visitor traverses the scene all drawbles land in render bins. Instead of 
overriding cull visitor I scan generated render bins and compute Bounding box 
around drawables that landed in renderd bins. If you are interested in details  
look at MinimalCullBoundShadowMap code. Its there. 

Cheers,
Wojtek

  - Original Message - 
  From: Roger James 
  To: OpenSceneGraph Users 
  Sent: Friday, October 17, 2008 12:55 PM
  Subject: [osg-users] Simple sunlight shadow technqiue


  I am experimenting with a simple sunlight shadow technique using the 
osgShadow model and basic depth shadows. I would like to set up the shadow 
casting camera so that I end up with a shadow texture that is a near as 
possible filled with the shadow casting objects as culled by the LOD nodes in 
the scene using the the inherited viewpoint. It seems to me that the best place 
to set up this bounding information is during the main scene cull traverse that 
is done in my(most) shadow technique prior to the render to shadow texture cull 
traverse. I want to avoid having to manage the placing and removing of cull 
call backs on every shadow casting geode, which may be different as the user 
manipulates the scene. The only way I can think of doing this is to derive my 
own CullVisitor and override the Geode apply function. Have I missed something 
here? Is there a better way to do it? I know the LISP shadow techniques have a 
number of complex ways of doing this but I am trying to implement something 
simple that uses inbuilt OpenGL functionality wherever possible.

  Roger



--


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


Re: [osg-users] Advice on interacting with osgShadow

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

Hi Wojtek,

Ok, then lets postpone any changes to the moment we hear additional 
requests from others. Once you managed to solve your blending issue this 
discussion seems purely academic. Lets wait for some practical problems 
to appear. I think this is actually best choice. With every piece we 
add, we make some fuctionality easier to use,  but we also make already 
complex code even more complicated.


I totally agree.

However ;-) there is one little tweak I will submit. I will add default 
AlphaFunc/AlphaTest to shadow camera stateset. That way I will avoid 
transparency with typical models (which started discussion ;-). I should 
have done it in the first place to be consistent with render bin 
override policy. But I have neglected it beacuse our models had this 
attribute set.


What would be the parameters for this default AlphaFunc? I suggested 
before that we add an AlphaFunc with GREATER 0.0 as parameters, and I 
thought you had rejected the idea... Perhaps that was just a 
misunderstanding on my part. If that's what you intend to do, I'm all 
for it.


Thanks,

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] change material of a node but not its children

2008-10-17 Thread Vincent Bourdier
Hi,

I'm currently on a problem :

I change the color of a node (osg::PAT) but I don't want its child osg::text
to have the same color...

On the PAT I do a
node-getOrCreateStateSet()-setAttributeAndModes(mat.get(),osg::StateAttribute::ON);

On the text :

osg::ref_ptrosg::Material mat =
(osg::Material*)text-getOrCreateStateSet()-getAttribute(osg::StateAttribute::MATERIAL);
if(!mat.valid())
mat = new osg::Material;


mat-setAmbient(osg::Material::FRONT_AND_BACK,osg::Vec4(0.0,0.0,0.0,1.0));

mat-setDiffuse(osg::Material::FRONT_AND_BACK,osg::Vec4(0.0,0.0,0.0,1.0));

node-getOrCreateStateSet()-setAttributeAndModes(mat.get(),osg::StateAttribute::ON
| osg::StateAttribute::PROTECTED);


The text is in a geode, under the PAT.


Any idea ? thanks a lot.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Advice on interacting with osgShadow

2008-10-17 Thread Wojciech Lewandowski

Hi J-S,

Ok, then lets postpone any changes to the moment we hear additional 
requests from others. Once you managed to solve your blending issue this 
discussion seems purely academic. Lets wait for some practical problems 
to appear. I think this is actually best choice. With every piece we add, 
we make some fuctionality easier to use,  but we also make already 
complex code even more complicated.


I totally agree.


Then we both agree ;-)

However ;-) there is one little tweak I will submit. I will add default 
AlphaFunc/AlphaTest to shadow camera stateset. That way I will avoid 
transparency with typical models (which started discussion ;-). I should 
have done it in the first place to be consistent with render bin override 
policy. But I have neglected it beacuse our models had this attribute 
set.


What would be the parameters for this default AlphaFunc? I suggested 
before that we add an AlphaFunc with GREATER 0.0 as parameters, and I 
thought you had rejected the idea... Perhaps that was just a 
misunderstanding on my part. If that's what you intend to do, I'm all for 
it.


Yes. Pixels pass when alpha is GREATER than 0. Simplest ideas do not always 
come first ;-).
Maybe it was me who got it wrong. I understood that we should have added 
this to osgShadow::ShadowedScene instance - which is beyond my realm. I will 
be happy to add this to StandardShadowMap shadow camera stateset, though 
;-)


Cheers,
Wojtek


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


[osg-users] Loss of Precision in .osg files

2008-10-17 Thread Martins Innus

Hello,

I was having trouble getting my models lined up when converting 
them to .osg format.  Attached are just the tops of the files from doing a:


osgconv cow0.osg cow1.osg

You can see that the one element of Matrix loses precision.

Any thoughts on increasing the default precision for output of some of 
these fields?


I assume a change to osgDB::Output is required?

This is under OSG 2.7.3, Redhat x86_64

Thanks

Martins
Group {
  DataVariance STATIC
  name cow.osg
  nodeMask 0x
  cullingActive TRUE
  num_children 1
MatrixTransform {
DataVariance UNSPECIFIED
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
  1 0 0 0
  0 1 0 0
  0 0 1 0
  123456 1234567 0 1
}
Group {
  DataVariance STATIC
  name cow.osg
  nodeMask 0x
  cullingActive TRUE
  num_children 1
  MatrixTransform {
DataVariance UNSPECIFIED
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
  1 0 0 0
  0 1 0 0
  0 0 1 0
  123456 1.23457e+006 0 1
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] change material of a node but not its children

2008-10-17 Thread Vincent Bourdier
a little UP..

Sorry for the convenience, but I would be very useful to solve this problem
now...

Thanks.

Regards,
   Vincent.


2008/10/17 Vincent Bourdier [EMAIL PROTECTED]

 Hi,

 I'm currently on a problem :

 I change the color of a node (osg::PAT) but I don't want its child
 osg::text to have the same color...

 On the PAT I do a

 node-getOrCreateStateSet()-setAttributeAndModes(mat.get(),osg::StateAttribute::ON);

 On the text :

 osg::ref_ptrosg::Material mat =
 (osg::Material*)text-getOrCreateStateSet()-getAttribute(osg::StateAttribute::MATERIAL);
 if(!mat.valid())
 mat = new osg::Material;


 mat-setAmbient(osg::Material::FRONT_AND_BACK,osg::Vec4(0.0,0.0,0.0,1.0));

 mat-setDiffuse(osg::Material::FRONT_AND_BACK,osg::Vec4(0.0,0.0,0.0,1.0));

 node-getOrCreateStateSet()-setAttributeAndModes(mat.get(),osg::StateAttribute::ON
 | osg::StateAttribute::PROTECTED);


 The text is in a geode, under the PAT.


 Any idea ? thanks a lot.

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


Re: [osg-users] Simple sunlight shadow technqiue

2008-10-17 Thread Roger James




Wojciech,

Thanks for the pointer, that code looks interesting. I can override the
CullVisitor at the scene root so I don't have quire the same problem. I
must admit this is not first time I have wished for a general per node
cull callback in osgUtil::CullVisitor. It would also be a way to apply
receives shadow state in a more specific fashion.

Roger

Wojciech Lewandowski wrote:

  
  
  
  Roger,
  
  I had similar dilemma at some point.
I was thinking about overridding cull visitor but had problem how to
substitute original cull visitor with my classin the middle of
culltraversal. Finally I adopted other approach. Once Cull Visitor
traverses the scene all drawbles land in render bins. Instead of
overriding cull visitor I scangenerated render bins and compute
Bounding box around drawables that landed in renderd bins. If you are
interested in details look at MinimalCullBoundShadowMap code. Its
there. 
  
  Cheers,
  Wojtek
  
  
-
Original Message - 
From:
Roger James 
To:
OpenSceneGraph Users

Sent:
Friday, October 17, 2008 12:55 PM
Subject:
[osg-users] Simple sunlight shadow technqiue


I am experimenting with a simple sunlight shadow technique using the
osgShadow model and basic depth shadows. I would like to set up the
shadow casting camera so that I end up with a shadow texture that is a
near as possible "filled" with the shadow casting objects as culled by
the LOD nodes in the scene using the the inherited viewpoint. It seems
to me that the best place to set up this bounding information is during
the main scene cull traverse that is done in my(most) shadow technique
prior to the render to shadow texture cull traverse. I want to avoid
having to manage the placing and removing of cull call backs on every
shadow casting geode, which may be different as the user manipulates
the scene. The only way I can think of doing this is to derive my own
CullVisitor and override the Geode apply function. Have I missed
something here? Is there a better way to do it? I know the LISP shadow
techniques have a number of complex ways of doing this but I am trying
to implement something simple that uses inbuilt OpenGL functionality
wherever possible.

Roger
 
 ___
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] infinite block with CullThreadPerCameraDrawThreadPerContext

2008-10-17 Thread Csaba Halász
On Thu, Oct 16, 2008 at 2:42 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
 HI Csaba,

 I suspect the particular problem you are seeing is not directly driver
 related, but is an OSG bug, differences in drivers might change the
 timing slightly which leads to the problem not becoming visible, but
 may well still be lurking.

Hi Robert,

Huh, took me two days, but I think I have traced this to a race condition.
Apparently the _endDynamicDrawBlock was already reached by a graphics
thread before the viewer got a chance to reset it.
So then that draw thread was released (and subsequently blocked on the
sceneview queue) and the viewer has gone to infinite wait on the
_endDynamicDrawBlock later.
This simpe patch (that doesn't even hint at how difficult it is to
trace such bugs) seems to fix the issue here:

Index: src/osgViewer/ViewerBase.cpp
===
--- src/osgViewer/ViewerBase.cpp(revision 9034)
+++ src/osgViewer/ViewerBase.cpp(working copy)
@@ -674,14 +674,14 @@

 bool doneMakeCurrentInThisThread = false;

-// dispatch the the rendering threads
-if (_startRenderingBarrier.valid()) _startRenderingBarrier-block();
-
 if (_endDynamicDrawBlock.valid())
 {
 _endDynamicDrawBlock-reset();
 }

+// dispatch the the rendering threads
+if (_startRenderingBarrier.valid()) _startRenderingBarrier-block();
+
 // reset any double buffer graphics objects
 for(Cameras::iterator camItr = cameras.begin();
 camItr != cameras.end();

I am not even sure why the _endDynamicDrawBlock has to be reset. Comments?

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


[osg-users] Poor paging performance with osgViewer

2008-10-17 Thread Chung, James - AES
Hello All,

I am using osgViewer::Viewer to display a scenegraph that contains an 
OssimPlanet planet object as a node. From messages in the archive I understand 
that osgViewer::Viewer has DatabasePager built into it, so I expected to see 
good performance in the changing through the levels of details of the planet. 
Instead, the performance is so slow that I suspect there may not be any 
DatabasePager thread running. Is the DatabasePager built into osgViewer::Viewer 
truly automatic, or do I still need to tickle it somehow to get it going?

As a comparison, the sample viewer program distributed by the OssimPlanet folks 
changes levels (with the same dataset I'm using) in a matter of seconds, 
whereas my app is taking minutes. Their sample program uses SceneView with 
DataPager.

I'd greatly appreciate it if anybody could shed some light on what might be 
causing my performance problem, as I'm not very familiar with OSG. Is there a 
sample program that demonstrates the use and benefit of DatabasePager?

Thanks in advance.

-Jim



James Chung, Ph.D.
Principal Computer Scientist
ITT - Advanced Engineering  Sciences
22446 Davis Drive
Sterling, VA 20164
mailto:[EMAIL PROTECTED][EMAIL PROTECTED]mailto:[EMAIL PROTECTED]
703-668-6287 (ofc) - 703-430-9157 (fax)



This e-mail and any files transmitted with it may be proprietary and are 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely 
those of the author and do not necessarily represent those of ITT Corporation. 
The recipient should check this e-mail and any attachments for the presence of 
viruses. ITT accepts no liability for any damage caused by any virus 
transmitted by this e-mail.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Poor paging performance with osgViewer

2008-10-17 Thread Robert Osfield
HI James,

You don't have to do anything special to use the DatabasePager in
osgViewer, just load a dataset with PagedLOD nodes in it and it'll
automatically start paging.  There isn't any examples that just
demonstrate the database pager use as there really isn't any you need
to do, the hard part is the database preparation.

There won't be shouldn't be performance delta between using SceneView
+ DatabasePager vs osgViewer, in fact the later if anything should be
faster is it has better threading support.

I am not familiar with OssimPlanet so can't guess at what might be up.
 Could it be as simple as you have compiled your own OSG version with
debug but run a release version of an OssimPlanet demo?

Robert.

On Fri, Oct 17, 2008 at 5:44 PM, Chung, James - AES [EMAIL PROTECTED] wrote:
 Hello All,



 I am using osgViewer::Viewer to display a scenegraph that contains an
 OssimPlanet planet object as a node. From messages in the archive I
 understand that osgViewer::Viewer has DatabasePager built into it, so I
 expected to see good performance in the changing through the levels of
 details of the planet. Instead, the performance is so slow that I suspect
 there may not be any DatabasePager thread running. Is the DatabasePager
 built into osgViewer::Viewer truly automatic, or do I still need to tickle
 it somehow to get it going?



 As a comparison, the sample viewer program distributed by the OssimPlanet
 folks changes levels (with the same dataset I'm using) in a matter of
 seconds, whereas my app is taking minutes. Their sample program uses
 SceneView with DataPager.



 I'd greatly appreciate it if anybody could shed some light on what might be
 causing my performance problem, as I'm not very familiar with OSG. Is there
 a sample program that demonstrates the use and benefit of DatabasePager?



 Thanks in advance.



 -Jim







 James Chung, Ph.D.

 Principal Computer Scientist

 ITT – Advanced Engineering  Sciences

 22446 Davis Drive

 Sterling, VA 20164

 [EMAIL PROTECTED]

 703-668-6287 (ofc) – 703-430-9157 (fax)



 
 This e-mail and any files transmitted with it may be proprietary and are
 intended solely for the use of the individual or entity to whom they are
 addressed. If you have received this e-mail in error please notify the
 sender.
 Please note that any views or opinions presented in this e-mail are solely
 those of the author and do not necessarily represent those of ITT
 Corporation. The recipient should check this e-mail and any attachments for
 the presence of viruses. ITT accepts no liability for any damage caused by
 any virus transmitted by this e-mail.

 ___
 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] osgWidget::CameraSwitchHandler

2008-10-17 Thread Jeremy Moles
Hello folks! It's Friday, so here's a cool video. :)

http://the-bob.org/~jlmoles/osgWidget-3d.wmv

This demonstrates a new ViewerEventHandler object in osgWidget that lets
you switch between a 2D ortho view and 3D perspective view of your
scene. You'll notice when I switch the WindowManager isn't positioned
properly, so if anyone has any advice on how to best position the camera
(I'm using osgGA::MatrixManipulator::setHomePosition()), let me know. :)

Otherwise, I'll keep poking at it for a bit...

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


Re: [osg-users] Re osg::getGlyphQuads

2008-10-17 Thread Jeremy Moles
On Tue, 2008-10-14 at 21:25 +0800, yang zhiyuan wrote:
 Hi:
 I have solved the problem how to get one char's position inside a
 osgText::Text;
 The purpose is to move cursor when input text.
 
 Here is my code:
updateCursorPos(const std::string string, int position)
 {
   osg::Vec3 cursor_position = m_inputText-getPosition();
   //get the font resolution
osgText::FontResolution fr;
 fr.first = FONT_RES_X;
 fr.second = FONT_RES_Y;
 
 //m_inputText is the osg::Text from which you want to get the last
 char's position
  const osgText::Font* font = m_inputText-getFont();
  osgText::Font* font1 = const_castosgText::Font*(font);
 //get total size of input parameter string
//string is the the std::string inside the m_inputText
 unsigned int size = string.size();
 osgText::Font::Glyph* glyph = font1-getGlyph(fr,size-1);
 osgText::Font::GlyphTexture* glyphTexture = glyph-getTexture();

 const osgText::Text::GlyphQuads * glyph_quads =
 m_inputText-getGlyphQuads( glyphTexture );
 if( glyph_quads )
 {
 int coord_size = glyph_quads-getTransformedCoords(0).size();
 int input_text_size = string.size(); // # chars on line.
 if( position  0 )
 {
 // Get position of character under cursor
 // There are 4 coords per character, BottomLeft, TopLeft,
 //   BottomRight, TopRight. We want the BottomRight.
 osg::Vec3 glyph_pos =
 glyph_quads-getTransformedCoords(0)[ position * 4 - 2 ];
 cursor_position[0] = glyph_pos[0];  // Use only the X
 position
 }
 }
  
 }

I'm going to try and adapt this to osgWidget::Input. Right now I use a
much different method for calculating the cursor position of my Input
object (which doesn't work), so perhaps this will help. I will, of
course, post more info soon. :)

On a different note--are you writing your own widget library?

 ___
 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