[osg-users] osg-users Digest, Vol 15, Issue 44

Claudio Arduino hard1880 at gmail.com
Wed Sep 17 01:08:33 PDT 2008


Hi,
is it possibile with osgUtil::IntersectionVisitor, know what is intersected
polygon (example the number 2 or the named "ad32") and which texture is
mapped to this polygon?(the name of file which contains the texture)
thanks!!



2008/9/17 <osg-users-request at lists.openscenegraph.org>

> Send osg-users mailing list submissions to
>        osg-users at lists.openscenegraph.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> or, via email, send a message with subject or body 'help' to
>        osg-users-request at lists.openscenegraph.org
>
> You can reach the person managing the list at
>        osg-users-owner at lists.openscenegraph.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of osg-users digest..."
>
>
> Today's Topics:
>
>   1. Re: Change particle color ! (Carlos Sanches)
>   2. Re: Paul, Another FLT Export BUG. (Paul Martz)
>   3. Re: 2.6.1 release (Paul Martz)
>   4. Vanishing Particles (b boltze)
>   5. Re: Vanishing Particles ( Charles Coss? )
>   6. How to use color a mesh object using gradient colors (oren david)
>   7. Re: Which File Formats / Plugins support multi-texture?
>      (David Spilling)
>   8. osgParticle and osgPPU not compatible (alexandre amyot murray)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 16 Sep 2008 13:03:33 -0300
> From: "Carlos Sanches" <carlos at met.com.br>
> Subject: Re: [osg-users] Change particle color !
> To: "OpenSceneGraph Users" <osg-users at lists.openscenegraph.org>
> Message-ID:
>        <5773c4a0809160903q21a3b6c6uecf14bac9d79d30d at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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 <con at bspot.de> 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 <cesmsp at gmail.com>
> > 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 at 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080916/387ae2e6/attachment.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 16 Sep 2008 10:41:36 -0600
> From: "Paul Martz" <pmartz at skew-matrix.com>
> Subject: Re: [osg-users] Paul, Another FLT Export BUG.
> To: "'OpenSceneGraph Users'" <osg-users at lists.openscenegraph.org>
> Message-ID: <DEAAEF80568F4BFEAA65ABB124A99920 at Supreme>
> Content-Type: text/plain; charset="us-ascii"
>
> 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
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080916/71927887/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 16 Sep 2008 10:58:28 -0600
> From: "Paul Martz" <pmartz at skew-matrix.com>
> Subject: Re: [osg-users] 2.6.1 release
> To: "'OpenSceneGraph Users'" <osg-users at lists.openscenegraph.org>
> Message-ID: <4EDE1EBE12EB4B33834ECE7E7BBAE122 at Supreme>
> Content-Type: text/plain; charset="us-ascii"
>
> 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: osg-users-bounces at lists.openscenegraph.org
> [mailto:osg-users-bounces at lists.openscenegraph.org] 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 <pmartz at skew-matrix.com>
> 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<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 <http://www.skew-matrix.com/>
> +1 303 859 9466
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080916/44b49c90/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 4
> Date: Tue, 16 Sep 2008 19:51:39 +0000
> From: b boltze <con at bspot.de>
> Subject: [osg-users] Vanishing Particles
> To: OpenSceneGraph Users <osg-users at lists.openscenegraph.org>
> Message-ID: <200809161951.39541.con at bspot.de>
> Content-Type: text/plain;  charset="utf-8"
>
> 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
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 16 Sep 2008 12:20:07 -0600
> From: " Charles Coss? " <ccosse at gmail.com>
> Subject: Re: [osg-users] Vanishing Particles
> To: "OpenSceneGraph Users" <osg-users at lists.openscenegraph.org>
> Message-ID:
>        <fb87ba070809161120i224b736ao407caa64fab81949 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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 <con at bspot.de> 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 at lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
>
>
>
> --
> AsymptopiaSoftware | Software at theLimit
>  www.asymptopia.org
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 16 Sep 2008 22:18:02 +0300
> From: "oren david" <orendavd at gmail.com>
> Subject: [osg-users] How to use color a mesh object using gradient
>        colors
> To: osg-users at lists.openscenegraph.org
> Message-ID:
>        <ca710ce80809161218q58f4edfaj4b681b12ecb626f8 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
>  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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080916/baa919c6/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 7
> Date: Tue, 16 Sep 2008 21:36:54 +0100
> From: "David Spilling" <david.spilling at gmail.com>
> Subject: Re: [osg-users] Which File Formats / Plugins support
>        multi-texture?
> To: "OpenSceneGraph Users" <osg-users at lists.openscenegraph.org>
> Message-ID:
>        <3bb9d0610809161336k81b032y228b27462a4ea2a1 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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?)
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080916/98bf7af5/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 8
> Date: Tue, 16 Sep 2008 16:57:11 -0400
> From: "alexandre amyot murray" <alex.amyotmurray at gmail.com>
> Subject: [osg-users] osgParticle and osgPPU not compatible
> To: osg-users at lists.openscenegraph.org
> Message-ID:
>        <265b66b30809161357q31453a49gf06670184dbbd19c at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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*
> *
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080916/c6c1bea6/attachment-0001.htm
> >
>
> ------------------------------
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> End of osg-users Digest, Vol 15, Issue 44
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080917/475403a8/attachment-0002.htm>


More information about the osg-users mailing list