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 <[EMAIL PROTECTED]> > Send osg-users mailing list submissions to > [email protected] > > 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 > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > 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" <[EMAIL PROTECTED]> > Subject: Re: [osg-users] Change particle color ! > To: "OpenSceneGraph Users" <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > 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 <[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 > > [email protected] > > > 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" <[EMAIL PROTECTED]> > Subject: Re: [osg-users] Paul, Another FLT Export BUG. > To: "'OpenSceneGraph Users'" <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> > Subject: Re: [osg-users] 2.6.1 release > To: "'OpenSceneGraph Users'" <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > 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: [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<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 > [email protected] > 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 <[EMAIL PROTECTED]> > Subject: [osg-users] Vanishing Particles > To: OpenSceneGraph Users <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > 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? " <[EMAIL PROTECTED]> > Subject: Re: [osg-users] Vanishing Particles > To: "OpenSceneGraph Users" <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > 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 <[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 > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > -- > AsymptopiaSoftware | [EMAIL PROTECTED] > www.asymptopia.org > > > ------------------------------ > > Message: 6 > Date: Tue, 16 Sep 2008 22:18:02 +0300 > From: "oren david" <[EMAIL PROTECTED]> > Subject: [osg-users] How to use color a mesh object using gradient > colors > To: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> > Subject: Re: [osg-users] Which File Formats / Plugins support > multi-texture? > To: "OpenSceneGraph Users" <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> > Subject: [osg-users] osgParticle and osgPPU not compatible > To: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > 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 > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > End of osg-users Digest, Vol 15, Issue 44 > ***************************************** >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
