Re: [osg-users] How to use color a mesh object using gradient colors

[Ulrich Hertlein]

Hello Oren,

oren david wrote:
> I've a mesh onject I've build from a .STL file. how do I get it colored
> using a gradient colors?? and how do I specify which color I want in the
> gradient ( I dont want all the range between blue and red).

The STL loader creates a Geometry with per-primitive (triangles) colours and no 
texture
coordinates (not available in STL).

You could use a fragment shader to assign colours based on world coordinate.
Or use a 1D gradient texture and (probably object-linear) TexGen to create 
texture
coordinates.

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

Re: [osg-users] BUG:osgPlugins\OpenFlight\ExportOptions.cpp

[Jean-Sébastien Guay]

Hi John,

Someone, please copy and paste the "_stripTextureFilePath( false )" line 
into the second constructor and add a comma after "_lightingDefault( 
true )". Don't forget the comma :)


You could have just sent the whole modified file to osg-submissions... 
That way no one would have to copy and paste anything, and there would 
be no chance to make the mistake of forgetting the comma...


And then you would be counted among the "Anyone else who likes to fix 
OSG" :-)


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] BUG:osgPlugins\OpenFlight\ExportOptions.cpp

[Argentieri, John-P63223]

Paul/Robert/Anyone else who likes to fix OSG,

There is a problem in the file: osgPlugins\OpenFlight\ExportOptions.cpp

The initialization of "_stripFileTexturePath" is missing in the second
constructor. It happens to be a bool. So, if you pass in
osgDB::ReaderWriter::Options with an option string to specify the
version of flt output you want/any other options besides stripping
paths, you're also implicitly choosing to strip file paths out of your
textures, because most of the time a bool with unspecified value is
initialized to non-zero(true) because that's what most numbers (garbage
or not) are.

What should happen, is it should default to false and if it's a token in
the option string it becomes true.

Someone, please copy and paste the "_stripTextureFilePath( false )" line
into the second constructor and add a comma after "_lightingDefault(
true )". Don't forget the comma :)

Thanks guys. Your pal,
John Argentieri

ExportOptions::ExportOptions()
  : _version( VERSION_16_1 ),
_units( METERS ),
_validate( false ),
_lightingDefault( true ),
_stripTextureFilePath( false )
{
}

ExportOptions::ExportOptions( const osgDB::ReaderWriter::Options* opt )
  : _version( VERSION_16_1 ),
_units( METERS ),
_validate( false ),
_lightingDefault( true )
{
if (opt)
{
const ExportOptions* fltOpt = dynamic_cast( opt );
if (fltOpt)
{
_version = fltOpt->_version;
_units = fltOpt->_units;
_validate = fltOpt->_validate;
_tempDir = fltOpt->_tempDir;
_lightingDefault = fltOpt->_lightingDefault;
}
setOptionString( opt->getOptionString() );
}
}


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

[osg-users] osgParticle and osgPPU not compatible

[alexandre amyot murray]

Hi,

I'm trying to use osgParticle in combinaison with osgPPU but it doesn't
work, my application crash at the beggining. If I dont use osgPPU,
everything work fine.

The error message I got in my console is :

*"osgParticle::ParticleSystemUpdater::traverse(NodeVisitor&) requires a
valid FrameStamp to function, particles not updated."

*Do you know why?

Thanks

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

Re: [osg-users] Which File Formats / Plugins support multi-texture?

[David Spilling]

Dear All,

Current observations:

1) The OSG 2.6 .obj loader loads two textures : a diffuse map, into texture
unit 0, and an "opacity map" into texture unit 1. The OBJ format supports a
variety of other texture maps (e.g "bump", "map_Ks", etc.). This
map-to-texture-unit correspondence is _hardcoded_ in the loader.

2) The 3DS loader has a bunch of potential map loads commented out
(ReaderWriter3DS.cpp, lines 828-842).

General question:

How should OSG cope with map-to-texture unit correspondence? For example, I
can modify the OBJ loader to support map_Ks, bump, etc. but the texture
units will still be hardcoded, and since I don't use an opacity map, the
original author's (Bob Kuehne) map_opacity change will break. A similar
question applied to the 3DS format; I can get it to load up other maps
(specular, opacity, bump etc.) but equally, end up hardcoding against
texture units.

Altenatively, the loader could increment texture units as it finds them in
the input file - this will work for OBJ; I'm not so familiar with 3DS for
this. Then it would be up to the shader to sort things out.

Even more alternatively, one could pass options into the loader that
dictated the correspondence.

Is there a general OSG wide recommended approach for this, or do people just
end up with their own personal customised loaders?

Advice appreciated,

David

(PS : shouldn't "map_opacity" be "map_d" in the obj loader?)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] How to use color a mesh object using gradient colors

[oren david]

 Hello all, I've a mesh onject I've build from a .STL file. how do I get it
colored using a gradient colors?? and how do I specify which color I want in
the gradient ( I dont want all the range between blue and red).
thank you
OrenDavd
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Vanishing Particles

[Charles Cossé]

Hi Bastion,
just a wild guess, but if you followed that last reply to your
previous post, then maybe you are no longer setting lifetime to -1?
Are you implementing that advice from previous thread ... ie where you
reset default_particle_template?
-Charles

On Tue, Sep 16, 2008 at 1:51 PM, b boltze <[EMAIL PROTECTED]> wrote:
> Hello everyone,
>
> I don't know whether it's considered rude to just appear and ask stupid
> questions on this list. But at the moment I don't know where else to go,
> so... well, I'll just ask my stupid question:
>
> I have setup a ParticleSystem. I store all the particles created for that
> system in a separate place; actually an array of particle pointers. Also, all
> particles have infinite lifetime, i.e. lifetime is set to 0.
>
> After some time, when I walk through my separate array, some of the particles
> have vanished from the system: looping over all particles using
> system->numParticles and system->getParticle, I can't find them anymore, and
> when I try to access them using my pointer, I get a segfault.
>
> Unfortunately, I have no idea, where those particles might get deleted.
>
> Could someone please give me a hint?
>
> TIA
>bastian
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
AsymptopiaSoftware | [EMAIL PROTECTED]
 www.asymptopia.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Vanishing Particles

[b boltze]

Hello everyone,

I don't know whether it's considered rude to just appear and ask stupid 
questions on this list. But at the moment I don't know where else to go, 
so... well, I'll just ask my stupid question:

I have setup a ParticleSystem. I store all the particles created for that 
system in a separate place; actually an array of particle pointers. Also, all 
particles have infinite lifetime, i.e. lifetime is set to 0.

After some time, when I walk through my separate array, some of the particles 
have vanished from the system: looping over all particles using 
system->numParticles and system->getParticle, I can't find them anymore, and 
when I try to access them using my pointer, I get a segfault.

Unfortunately, I have no idea, where those particles might get deleted. 

Could someone please give me a hint?

TIA
bastian



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

Re: [osg-users] 2.6.1 release

[Paul Martz]

Thanks, Jason. I've committed this change to the 2.6.1 branch. I've also
added the aforementioned occlusion query workaround, and I've bumped the
version number to 2.6.1 in anticipation of an upcoming release in the near
future.
 
Could you please verify that I added your fix correctly? (Take a look at the
code, or better yet, build the branch and test it.)
 
Thanks,
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason
Beverage
Sent: Monday, September 15, 2008 1:01 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] 2.6.1 release


Hi Paul,

I've got a small fix that I submitted as part of revision 8765 that I think
should be included that fixed a problem with the osgSim::OverlayNode.
http://www.openscenegraph.org/projects/osg/changeset/8765

Thanks!

Jason


On Mon, Sep 15, 2008 at 2:00 PM, Paul Martz <[EMAIL PROTECTED]> wrote:


Hi folks -- I intend to put out an OSG v2.6.1 release, targeting end of
month but early October is more likely.
 
I'm creating this release because I have a client that requires at least two
of the bug fixes that have been submitted post-2.6. My intention is to
primarily include changes that will actually be needed, so if you are
content to stay on the version of OSG you're currently on, or content to
stay on the SVN head, then you will probably not use 2.6.1 and you can now
delete this post and go back to work. :-)
 
I'm also not fond of doing a lot of testing, so this is a reason to keep the
change set minimal.
 
If you actually might use the 2.6.1 release, then I'm interested in
soliciting your change requests. Have there been any submissions post-2.6
that you'd like to see in the 2.6.1 branch? Please let me know. I intend to
read over the ChangeLog to look for desirable changes and low-hanging fruit,
but I'd like input from the community to guide my search.
 
The SVN for 2.6.1 development is here:
 
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph
-2.6
 
Currently, this is identical to 2.6 plus the following changes:
 * A fix to the FLT exporter to support PositionAttitudeTransform.
 * A fix to the Simplifier to support shared vertex arrays.
 
The latter breaks binary compatibility by changing the Geometry interface,
so 2.6.1 will require a recompile.
 
I will put in the OcclusionQueryNode workaround for a suspected NVIDIA
driver issue, and I'm also considering an issue with BIND_PER_PRIMITIVE in
the FLT exporter (this issue is currently not resolved).
 
Thoughts and input appreciated.
 
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




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

Re: [osg-users] Paul, Another FLT Export BUG.

[Paul Martz]

Hi John -- This is definitely a bug that needs to be fixed. and I'm sorry it
is impacting your work.

What I'm getting at is that it would really be nice if the FLT writer could
export the output of osgUtil::DelaunayTriangulator without having to put a
normal vector generator on top of it. 

FLT only supports normal per vertex, so there will need to be some type of
normal generation (at least duplication) in order for the exporter to
support BIND_PER_PRIMITIVE.
 
To me, BIND_PER_PRIMITIVE implies that the same normal is used at each
vertex of the component primitive (quad/triangle/line segment/whatever). So,
for example, given an array of 4 vertices to render 2 triangles, there would
be 2 normals, one for each triangle. The correct output in FLT would be 6
entries in the vertex palette, 3 with one normal and 3 with the other, and
the 2 shared vertices would have xyz values duplicated. (This is for Face
record usage; Mesh might be different.)
 
Currently, the structure of the FLT exporter is as simple as possible; when
it encounters a Geometry, it blindly adds the data to the vertex palette
without even looking at the primitive modes, and it currently depends on the
binding being PER_VERTEX (as you have discovered). This is clearly wrong and
needs to be fixed. To handle things correctly, either the data needs to be
preprocessed up front to fit this usage before being added to the
VertexPaletteManager, or the VertexPaletteManager itself needs to be smart
enough to handle it. In either case the process would be as follows:
 
We essentially need to change the Geometry data so that color and normal
bindings are per vertex (this is a FLT requirement). This would involve
iterating over all PrimitiveSets and doing a switch/case on the primitive
mode, then copying existing data into new arrays.
 
Also, we need to special case BIND_OVERALL color, because FLT files have the
concept of a single color specified in the Face record. So we don't want to
expand that out to BIND_PER_VERTEX.
 
Then we also need to be sure to handle the "sharing" feature correctly. The
current code is optimized to support two Geometry objects sharing the same
vertex arrays; if the address of the arrays match, the code assumes the data
is already in the vertex palette and simply indexes into the existing data.
However, if we have to preprocess the data and generate new arrays on the
fly to support BIND_PER_PRIMITIVE, then we must instruct the
VertexPaletteManager to disable sharing for those arrays. I believe there is
already a flag for this, as I had to do something similar for light points.
 
All this is doable but tedious. I won't get to it in the next few weeks; I
might not get to it until early next year (yes, I'm booked pretty solid
these days).
   -Paul
 
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Change particle color !

[Carlos Sanches]

hey man I did it .
look the example particle
cor is the float that is variable of alpha to me , but can be r g or b

and using the code in the principal loop:

  initial_color   =   osg::Vec4(R, G, B, cor);
  final_color   =   osg::Vec4(fR, fG, fB, 0.0);



smokeParticle->setColorRange(osgParticle::rangev4(initial_color,final_color
) );
psa->setDefaultParticleTemplate(*smokeParticle);








On Tue, Sep 16, 2008 at 1:31 PM, b boltze <[EMAIL PROTECTED]> wrote:

> Hi Mattias,
>
> On Monday 18 August 2008 22:42:04 Mattias Helsing wrote:
> > On Mon, Aug 18, 2008 at 8:44 PM, Carlos Sanches <[EMAIL PROTECTED]>
> wrote:
> > > to do this I need to change the color of particles after your creation
> > > only when I press the key.
> >
> > yes it is possible. You need an EventHandler and a osg::Timer.
> > Set the color in EventHandler::handle(osgGA::FRAME).
> >
> > There is probably 10 other ways to do this also.
>
> I have a similar problem and I fear I don't understand how this is supposed
> to
> work. Creating an EventHandler and a Timer is easy of course, but actually
> changing the particles' colors seems problematical to me:
>
> Since the _current_* (alpha, color, etc.) attributes are protected in
> Particle
> and there are no setter functions, I can not change these values directly.
> I
> can only change the ranges, using set*Range.
>
> If the particles have limited lifetime, I can setColorRange or
> setAlphaRange
> on them, so they will fade out. But since they have already lived a portion
> of their lifetime, they won't start at the beginning of the given interval,
> but jump right into it, to the value corresponding to the percentage of
> their
> lifetime they have already spent.
>
> For example: A particle has already lived 9 seconds out of 10. Alpha range
> before the change was 1 to 1, so the particles alpha was 1. Then I set the
> alpha to range from 1 to 0, and the particle will immediately take an alpha
> value of 1+(0-1)*(9/10) = 0.1, assuming linear interpolation.
>
> If, on the other hand, the particle has infinite lifetime, I can't change
> its
> color or alpha at all, because immortal particles retrieve their current
> values from the interpolators only once, at their first rendering pass
> ever.
> So changing the ranges has no effect on them.
>
> Did I miss something?
>
> Thanks for your help
>bastian
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Carlos Sanches
Analista de Sistemas e computação gráfica
Tel: 55 11 3816 2888
Cel: 55 11 9650 7137

Somar Meteorologia
www.somarmeteorologia.com.br
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Paul, Another FLT Export BUG.

[Argentieri, John-P63223]

Paul,
 
We are using osgUtil::DelaunayTriangulator in a real-time package from
which we'd like to export FLT.
 
I was able to use the workaround we discussed for geometry created by
osgUtil::DelaunayConstraint.
 
However, the DelaunayTriangulator itself uses BIND_PER_PRIMITIVE as a
means to bind normals to its output geometry. I could take the output
normal array and generate a new one by iterating through all the
vertices, but remember I said "real-time". If I change a simple road
constraint, then no one will notice me generating a normal array. But it
I regenerate the normal array for an entire terrain on every update in a
real-time application, the user is definitely going to notice the
difference. 
 
What I'm getting at is that it would really be nice if the FLT writer
could export the output of osgUtil::DelaunayTriangulator without having
to put a normal vector generator on top of it.
 
I understand the reasons why you don't like BIND_PER_PRIMITIVE -- a
vertex can be a part of any number of primitives (consider
TRIANGLE_FAN). So how do you determine the normal of a single vertex?
Well, the way I did it is this:

// types used for computing normal vectors
struct SVertexData
{
unsigned int m_unNumPrimitives;
osg::Vec3f m_vNormal;
};
typedef std::map< osg::Vec3f, SVertexData > TMVertexToDataMap;

Using this type of data structure, if we can find the vertex in that
map, we multiply the two struct members together, add the normal of the
current triangle, and divide by the struct member for the number of
primitives plus one. Then we increment the number of primitives struct
member.
If it's not in the map, we insert a mapping from the vertex to a struct
with this triangle's normal and a 1 for the number of primitives.
After we've seen every triangle, then the map is fully populated and we
can build the normal Vec3Array.
 
I don't know what the FLT writer does, but osgUtil::DelaunayTriangulator
is giving us back full triangles -- not a strip or fan. Depending on the
GL_MODE, you might have to iterate differently to get to the triangles.
 
John
 


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Argentieri, John-P63223
Sent: Monday, September 15, 2008 10:27 AM
To: [EMAIL PROTECTED]
Subject: Re: [osg-users] Paul, Another FLT Export BUG.


Paul,
 
No, I was not aware of this. However, I am using BIND_PER_PRIMITIVE with
osgUtil::DelaunayTriangulator/DelaunayConstraint as in the osgdelaunay
example. Since I can quickly get the triangles, I just have to
cross-multiply and normalize to get each primitive normal.
 
The other thing that I could to is calculate the normals in the same way
as above, but assign one to each vertex in a map. Then if a vertex is a
part of two triangles, I could add the new triangle's normal and divide
by two.
 
In fact, I'll probably use the strategy above. Thank you for your help
and your time, Paul.
 
Have a great week! Your pal,
John
 


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Martz
Sent: Sunday, September 14, 2008 4:36 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] Paul, Another FLT Export BUG.


By the way, are you aware that BIND_PER_PRIMITIVE is the least efficient
way to render in OSG? There is no OpenGL vertex arrays equivalent for
this, so the best OSG can do to support it is specify slow path
glBegin/glEnd calls stored in a display list. If you can fix your data
to not use BIND_PER_PRIMITIVE, not only would you avoid this issue in
the FLT exporter, but you'd also potentially experience a performance
boost (depending on where your bottleneck is).
 
In fact, the reason this bug is in the exporter is probably because I
didn't test BIND_PER_PRIMITIVE, thinking that no one really uses that
binding anyway. (At least, no one who cares about performance uses it.)
   -Paul
 




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Argentieri, John-P63223
Sent: Friday, September 12, 2008 2:49 PM
To: [EMAIL PROTECTED]
Subject: [osg-users] Paul, Another FLT Export BUG.



Paul, 

We've found another FLT export BUG which happens when geometry
normal bind mode is BIND_PER_PRIMITIVE. It looks like it's trying to
convert the normal array to BIND_PER_VERTEX, but it fails. Here's our
example:

<> 
In osgviewer, look at the surface and toggle both lighting
modes. Then convert and do the same. 

I hope that helps! Your pal, 

John Argentieri 
General Dynamics C4 Systems 
Battle Management Systems Division 
Software Engineer 

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

Re: [osg-users] Culling problem

[Judd Tracy]

Try using PolygonOffset.

Judd

Vincent Bourdier wrote:

Hi Paul

It is exactly the problem.
I've done some tests with the depth test, and I'm sure that what you 
think is the problem.
So now, how to solve it ? If I put "depth = new 
osg::Depth(osg::Depth::ALWAYS, 0.0, 1.0);" My plane are always 
visible, but nothing can hide them (mountains for example...)


Any suggestion or Idea ?

Thanks
Regards,

Vincent.

2008/9/16 Paul Martz <[EMAIL PROTECTED] 
>


If the polygons are very close to the ground and your eye is quite
distant, then it sounds like it's losing the depth test.
   -Paul
 



*From:* [EMAIL PROTECTED]

[mailto:[EMAIL PROTECTED]
] *On
Behalf Of *Vincent Bourdier
*Sent:* Tuesday, September 16, 2008 5:22 AM
*To:* osg
*Subject:* [osg-users] Culling problem

Hi all,

I have a strange problem : Nodes are moving
(PAT->LOD->Node.ive) depending on a PAT and all the PATs have
the same group for parent.
Theses nodes (planes) have the ground under them but,
sometimes the planes are hidden under the ground.

It happens when the camera it on a top-position (not side or
face ) of the planes and it depend on the point looked by the
camera. Just modifying camera's orientation make then appear.
If the camera if near of the plane nothing happen.

I have checked Z position, but it do not changed anormaly. I
only see a culling problem to have this problem.

Do you have already encountered something similar ?
How to solve this problem ?


See attached files to understand better what it looks like.

thanks,

Regards

Vincent.


___
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] Culling problem

[Paul Martz]

Look at CullSettings::setComputeNearFarMode() and see if any of the modes
works for you. If they don't, then set it to DO_NOT_COMPUTE_NEAR_FAR and
manually set the near plane to a larger value (further from the eye).
 
Search the archives for "computeNearFar" or "Z fighting" for more info.
   -Paul
 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vincent
Bourdier
Sent: Tuesday, September 16, 2008 8:24 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Culling problem


Hi Paul

It is exactly the problem.
I've done some tests with the depth test, and I'm sure that what you think
is the problem.
So now, how to solve it ? If I put "depth = new
osg::Depth(osg::Depth::ALWAYS, 0.0, 1.0);" My plane are always visible, but
nothing can hide them (mountains for example...)

Any suggestion or Idea ?

Thanks
Regards,

Vincent.


2008/9/16 Paul Martz <[EMAIL PROTECTED]>


If the polygons are very close to the ground and your eye is quite distant,
then it sounds like it's losing the depth test.
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vincent
Bourdier
Sent: Tuesday, September 16, 2008 5:22 AM
To: osg
Subject: [osg-users] Culling problem


Hi all,

I have a strange problem : Nodes are moving (PAT->LOD->Node.ive) depending
on a PAT and all the PATs have the same group for parent.
Theses nodes (planes) have the ground under them but, sometimes the planes
are hidden under the ground.

It happens when the camera it on a top-position (not side or face ) of the
planes and it depend on the point looked by the camera. Just modifying
camera's orientation make then appear.
If the camera if near of the plane nothing happen.

I have checked Z position, but it do not changed anormaly. I only see a
culling problem to have this problem.

Do you have already encountered something similar ?
How to solve this problem ?


See attached files to understand better what it looks like.

thanks,

Regards

Vincent.



___
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] OSG 2.6 on Linux, CMake 2.4.7, no osg/Config generated?

[Jean-Sébastien Guay]

Hi all,

Thanks for testing, this confirms that you can't reproduce the problem. 
So I'll continue looking on my side. 


Yeah, this ended up being a mistake on my end (of course), when checking 
in OSG 2.6 to our repository at work I checked in all subdirectories but 
not the files in the top-level source directory, so the top-level 
CMakeLists.txt was still the one from OSG 2.4... *sheepish grin*


Maybe I should start drinking coffee... :-)

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

Re: [osg-users] Change particle color !

[b boltze]

Hi Mattias,

On Monday 18 August 2008 22:42:04 Mattias Helsing wrote:
> On Mon, Aug 18, 2008 at 8:44 PM, Carlos Sanches <[EMAIL PROTECTED]> wrote:
> > to do this I need to change the color of particles after your creation
> > only when I press the key.
>
> yes it is possible. You need an EventHandler and a osg::Timer.
> Set the color in EventHandler::handle(osgGA::FRAME).
>
> There is probably 10 other ways to do this also.

I have a similar problem and I fear I don't understand how this is supposed to 
work. Creating an EventHandler and a Timer is easy of course, but actually 
changing the particles' colors seems problematical to me:

Since the _current_* (alpha, color, etc.) attributes are protected in Particle 
and there are no setter functions, I can not change these values directly. I 
can only change the ranges, using set*Range. 

If the particles have limited lifetime, I can setColorRange or setAlphaRange 
on them, so they will fade out. But since they have already lived a portion 
of their lifetime, they won't start at the beginning of the given interval, 
but jump right into it, to the value corresponding to the percentage of their 
lifetime they have already spent. 

For example: A particle has already lived 9 seconds out of 10. Alpha range 
before the change was 1 to 1, so the particles alpha was 1. Then I set the 
alpha to range from 1 to 0, and the particle will immediately take an alpha 
value of 1+(0-1)*(9/10) = 0.1, assuming linear interpolation. 

If, on the other hand, the particle has infinite lifetime, I can't change its 
color or alpha at all, because immortal particles retrieve their current 
values from the interpolators only once, at their first rendering pass ever. 
So changing the ranges has no effect on them.

Did I miss something? 

Thanks for your help
bastian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgdem segmentation fault

[Robert Osfield]

Hi Ben,

I'm afraid there is wy too little info about your setup to provide
any real guidance.  VPB should just compile against an installed OSG
without need for configuration.

You don't mention which VPB or OSG version your are using, you also
make no mention of the platform or compilers.  All this is important
to understanding what might go wrong and how to fix it.

Robert.

On Tue, Sep 16, 2008 at 12:57 PM, benben <[EMAIL PROTECTED]> wrote:
> Hi everyone!
>
> I am trying to use osgdem from VPB. But after I ./configure make make
> install it gives me segmentation fault when I tried to run osgdem.
>
> Is there anything I need to configure before installation?
>
> Regards,
> Ben
>
> ___
> 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] Culling problem

[Vincent Bourdier]

Hi Paul

It is exactly the problem.
I've done some tests with the depth test, and I'm sure that what you think
is the problem.
So now, how to solve it ? If I put "depth = new
osg::Depth(osg::Depth::ALWAYS, 0.0, 1.0);" My plane are always visible, but
nothing can hide them (mountains for example...)

Any suggestion or Idea ?

Thanks
Regards,

Vincent.

2008/9/16 Paul Martz <[EMAIL PROTECTED]>

>  If the polygons are very close to the ground and your eye is quite
> distant, then it sounds like it's losing the depth test.
>-Paul
>
>
>  --
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Vincent
> Bourdier
> *Sent:* Tuesday, September 16, 2008 5:22 AM
> *To:* osg
> *Subject:* [osg-users] Culling problem
>
>  Hi all,
>
> I have a strange problem : Nodes are moving (PAT->LOD->Node.ive) depending
> on a PAT and all the PATs have the same group for parent.
> Theses nodes (planes) have the ground under them but, sometimes the planes
> are hidden under the ground.
>
> It happens when the camera it on a top-position (not side or face ) of the
> planes and it depend on the point looked by the camera. Just modifying
> camera's orientation make then appear.
> If the camera if near of the plane nothing happen.
>
> I have checked Z position, but it do not changed anormaly. I only see a
> culling problem to have this problem.
>
> Do you have already encountered something similar ?
> How to solve this problem ?
>
>
> See attached files to understand better what it looks like.
>
> thanks,
>
> Regards
>
> Vincent.
>
>
> ___
> 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] Memory Problem on Producer

[Robert Osfield]

For questions about Producer please subscribe to the Producer mailing list.

On Tue, Sep 16, 2008 at 11:46 AM, ufuk gun <[EMAIL PROTECTED]> wrote:
> Hi,
>
> i have memory problem on producer. whenever i move the mouse on the screen,
> memory increases 4kb per second.
> It happens all the applications using producer even the examples of
> producer.
> i dont know if you met such a problem but if you know, please help me to
> solve..
>
> Ufuk.
>
>
> ___
> 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] Culling problem

[Paul Martz]

If the polygons are very close to the ground and your eye is quite distant,
then it sounds like it's losing the depth test.
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vincent
Bourdier
Sent: Tuesday, September 16, 2008 5:22 AM
To: osg
Subject: [osg-users] Culling problem


Hi all,

I have a strange problem : Nodes are moving (PAT->LOD->Node.ive) depending
on a PAT and all the PATs have the same group for parent.
Theses nodes (planes) have the ground under them but, sometimes the planes
are hidden under the ground.

It happens when the camera it on a top-position (not side or face ) of the
planes and it depend on the point looked by the camera. Just modifying
camera's orientation make then appear.
If the camera if near of the plane nothing happen.

I have checked Z position, but it do not changed anormaly. I only see a
culling problem to have this problem.

Do you have already encountered something similar ?
How to solve this problem ?


See attached files to understand better what it looks like.

thanks,

Regards

Vincent.


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