Re: [osg-users] Proximity Queries between objects
Hi, maybe you can use spheres to get an initial vector between the objects and then use this vector in the OSG intersection code to get more precision for where this vector intersects the two objects. jp On 16/08/10 19:00, Sanat Talmaki wrote: Hi Paul, That is the method I had initially thought of (i.e. the distance between centres of spheres obviously :) and not the other one !) I was building osgbullet and am able to build the projects in visual studio successfully. All my dependencies are built right as osgWorks' binaries run alright. But osgBullet's binaries hang on me when I try to run them. I will post that in a seperate thread as it will be misleading to discuss it in this one. Thanks. Sanat -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30798#30798 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] preFrame Callback available?
Hi Tim, thank you for this hint! I will look at it. Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30816#30816 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] Error when loading DirectX .x files
HI Tassilo, Could you post fixes to the osg-submissions list (I believe you can do it on the forum as well) and follow the submissions protocol: http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol Thanks, Robert. On Mon, Aug 16, 2010 at 6:08 PM, Tassilo Glander tassilo.glan...@hpi.uni-potsdam.de wrote: Hi all, as the bug is still in the reader, I would like to submit a fix that deals with 2 more cases of how to format the material names. The current version crashes when encountering materials as mentioned by Judy. I think, the format supported in the current version of mesh.cpp is not correct, as the DirectX-Viewer included in DirectX-SDK (August 2009) cannot read model files refering to materials without curly brackets. I would be happy, if someone could try the patch with other models. Thank you! Cheers, Tassilo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30800#30800 Attachments: http://forum.openscenegraph.org//files/fix_x_plugindiff_312.txt ___ 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] how to read back from the frame buffer
Hi Alice, On Mon, Aug 16, 2010 at 9:52 PM, Alice Yin yin...@ymail.com wrote: My only concern now is since I have two cameras now, one prerender, one normal, how can I control these two at the same time? There are a number of different ways to control slave cameras, or cameras in the scene graph. If you want to use the usual viewer CameraManipulator such as the TrackballManipulator then you should set up your slave Camera to inherit it's view and projection matrix from the viewer's master Camera by setting a RELATIVE_RF ReferenceFrame. For the slave Camera that is independent from the viewer's master Camera this you'd use an ABSOLUTE_RF ReferenceFrame and set the projection and view matrices on the Camera directly either at start up on on each new frame. The osgdistortion example does just this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Array
Hi Igor, On Tue, Aug 17, 2010 at 12:35 AM, Igor Lebedev alterra...@ya.ru wrote: In getPrimitiveSet() function there is pos argument. How should i use it? osg::Geometry contains a std::vector of PrimtiveSet, the pos argument is just an index into this vector. Geometry::getNumPrimitiveSets() returns the number of primitive sets in the vector. This type of question is pretty basic and answered directly by looking at the include/osg/Geometry header - there is a whole collection of PrimitiveSet related methods, one should be able to work out what the methods do as they are all one line methods. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Opengl ES 2.0 support
Hi, I have heard that OSG is coming with ES 2.0 support. PLease guys confirm status of ES 2.0 support. Thank you! Cheers, Rakesh -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30821#30821 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] why transform nodes give a big impact to cull time??
Hi all. thank you all for response. in my scene, stateset: 444(unique), 23682(instance) group: 531(u), 18505(instance) transform: 5107(u), 18112(instance) lod: 53(u), 1129(instance) geode:831(u),13840(instance) drawable:3065(u), 19279(instance) when roaming, about 120,000~150,000 (triangle + triangle_strip) can be seen, cull time: 100ms~200ms, draw time: 20~60ms, GPU time: 20~40ms. frame rate: 4~7/s I spent lots of time to optimize the scene; firstly I drop unique stateset numeber from 1200 to 444 because I think that the stateset give big influence to performance. speed increase a little. secondly, I use lod node( 4 level) to drop triangle(strip)' numbers from 300,000 to 120,000~150,000 when roaming . speed increate a little( draw time seem to drop down). thirdly, for banlance scene, I use quad-tree to organize all models in the scene, but I found that cull time only drop down when lots of models out of eyes'field( I think that quad-tree speed culling). but when field of eyes enlarge, more and more models can be seen, cull time increase very fast. my scene' models is very denseness in limited area like city. but difference with city is that these is no obvious big object as Occlusion node, so I give up use Occlusion node. from now, speed is still not good, and cull time also high. anything can I do now ?( cut down transform node ??) any advice, very appreciate~ Thank you! Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30823#30823 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Particle problem
Thanks for your input, I'll take a look to these posts. Each time we try to use osgParticle we have new problems, I think we'll going to look for another solution, we only need simple particles effects. Anyone has good reading about GPU based particle engines to share ? On Mon, Aug 16, 2010 at 9:24 PM, Jolley, Thomas P thomas.p.jol...@boeing.com wrote: Hi Serge, You may want to research the following posts and see if they are relevent to your particle problems. * http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-April/027011.html * http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-May/028435.html The above talks about a floating point precision bug that was introduced due to a change in 2008. The bug hasn't been resolved yet. I suspect it will wait until the osgParticle is refactored since not many see the problem. If the above describes your problem you will need to undo the 2008 change. http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-October/033416.html -- *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Serge Lages *Sent:* Monday, August 16, 2010 10:32 AM *To:* OpenSceneGraph Users *Subject:* [osg-users] osg::Particle problem Hi all, I am currently having some troubles with particles, I am trying to make them local to a model (for example, imagine a scene with the earth rotating around the sun, and a model moving on the earth, I don't want my particles to take into account the earth movement, only the model one). I've made it by putting everything related to particles (Emitter, ParticleSystemUpdater, the geode with the ParticleSystem...) under my model root instead of the whole scene root. But it doesn't work, my particles are still taking into account the main movement. It's weird because the same code was working one year ago, but I didn't use it again until today, and I don't find any other way to make my particles local. My particle effect is composed of : - a ParticleSystem inside a classic Geode - a ModularEmitter - a ParticleSystemUpdater - a FluidProgram Everything is attached into my graph under my model, and I set : emitter-setReferenceFrame(osgParticle::ParticleProcessor::RELATIVE_RF); particleSystem-setParticleScaleReferenceFrame(osgParticle::ParticleSystem::LOCAL_COORDINATES); It works without problem when nothing is moving in my scene, but if I enable movements on the model parents, my particles take them into account on their own movement. Any idea ? Cheers, -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Opengl ES 2.0 support
HI Rakesh, On Tue, Aug 17, 2010 at 8:56 AM, Rakesh Parmar rakes...@kpitcummins.com wrote: I have heard that OSG is coming with ES 2.0 support. PLease guys confirm status of ES 2.0 support. The OSG has had OpenGL ES 2.0 support since December last year. You have to use either svn/trunk or one of the 2.9.8 developer release to get access to it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] why transform nodes give a big impact to cull time??
Hi John, On Tue, Aug 17, 2010 at 9:37 AM, John Water akin...@hotmail.com wrote: from now, speed is still not good, and cull time also high. anything can I do now ?( cut down transform node ??) It very much sounds like your scene graph is too fine grained for performance. Batching geometry and state together will most likely give you a significant boost. You don't mention the number of vertices in your model, and the way you discussed the triangle/triangle strip is rather too open ended to make conclusions from, but at a guess it doesn't sound like vertex count is rather high. Modern graphics cards can comfortable handle a million vertices per frame at 60Hz, so at guess the numbers you have a way below this and shouldn't represent a bottleneck. Given that geometry complexity may well not be a performance issue then I'd guess that use of LOD's probably won't help much unless the LOD's are able to provided a simplified the subgraph and state associated for the lowest level of detail. Use of transforms should just limited to dynamically moving objects, for all static objects flatten the transforms, the Optimizer can do this for you but you must set the DataVariance on the Transform to STATIC to give it the hint that it can optimize it away. Use of the Optimizer should be seen as a last resort though - if you build a well balanced scene graph to start with then the optimizer won't have anything to do. The topic of optimization is huge topic, something that has been touched on many times over the years here so have a search through the archives for pointers. There really shouldn't be any reason why you shouldn't be able to hit a solid 60Hz with your app - you just need to build an efficient scene graph. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Opengl ES 2.0 support
@Robert :Thanks for your quick reply. I have just read this on OSG site . But still this is beta release. I will download and will try to run Opengl sample. Thank you! Cheers, Rakesh -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30826#30826 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Particle problem
Hi Serge, On Tue, Aug 17, 2010 at 10:28 AM, Serge Lages serge.la...@gmail.com wrote: Thanks for your input, I'll take a look to these posts. Each time we try to use osgParticle we have new problems, I think we'll going to look for another solution, we only need simple particles effects. Anyone has good reading about GPU based particle engines to share ? osgParticle is a bit of an awkward beast, rather long in tooth now - save for the PrecipitationEffect it's almost all the work is done the CPU. The best way to do particles systems these days is to use shaders - the PrecipitationEffect demonstrates that this approach really scales well. Wang Rui is currently working on new functionality for osgParticle, I don't know the details though. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Particle problem
Hi Robert, et al, My improvement this time is mainly about structure fixes and new operators. The bounce and sink (bounce or kill particles in specified domain) operators will be introduced to allow more particle features, as well as new orbiting points, explosion and damping operators. Other changes includes the customized particle shape, sorting by depth, visible distance, and a basic shader implementation. I myself prefer to use the geometry shader to generate particle primitives for rendering, but all other emitting and operating processes are still finished on the CPU. I wonder if we could make use of SSE or some other functionalities. The shader implementation will be set as optional at present. Also I'd like to see if Tim Moore's uniform buffer object submission can be used here (it is not merged yet, isn't it). All these is hoped to be finished during this week. :) Cheers, Wang Rui 2010/8/17 Robert Osfield robert.osfi...@gmail.com: Hi Serge, On Tue, Aug 17, 2010 at 10:28 AM, Serge Lages serge.la...@gmail.com wrote: Thanks for your input, I'll take a look to these posts. Each time we try to use osgParticle we have new problems, I think we'll going to look for another solution, we only need simple particles effects. Anyone has good reading about GPU based particle engines to share ? osgParticle is a bit of an awkward beast, rather long in tooth now - save for the PrecipitationEffect it's almost all the work is done the CPU. The best way to do particles systems these days is to use shaders - the PrecipitationEffect demonstrates that this approach really scales well. Wang Rui is currently working on new functionality for osgParticle, I don't know the details though. Robert. ___ 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] Transparent polygons render view angle dependent
Hi, I have a scene shown in osgViewer. Scene contains opaque and translucent polygons. Translucent polygons render significantly differently depending on the angle of viewing. Attachments show this. Color of the problematic polygons is Vec4(0.55,0.60,0.55,0.3). The whole scene consists of small triangles, even the large flat surfaces. Is this the expected behavior? And how do I fix it? Thank you! Cheers, Dženan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30833#30833 Attachments: http://forum.openscenegraph.org//files/viewangle3nt_143.png http://forum.openscenegraph.org//files/viewangle2nt_457.png http://forum.openscenegraph.org//files/viewangle1nt_146.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparent polygons render view angle dependent
Hi Dženan, The effect you are getting is typical of transparent scene that is not depth sorted in a sufficiently fine grained way. To render transparent objects in the standard way you need to depth sort the geometry and then render the transparent objects from back to front. There are lots of different techniques you can use to tackle them, which is ideal depends upon the particulars of your application and the types of models you will be tackling. The topic has been discussed lots in the OSG community over the years, and there is a lot of online resources on the issue of rendering transparent objects so I'd recommend doing some background research on the topic. Robert. 2010/8/17 Dženan Zukić dzen...@gmail.com: Hi, I have a scene shown in osgViewer. Scene contains opaque and translucent polygons. Translucent polygons render significantly differently depending on the angle of viewing. Attachments show this. Color of the problematic polygons is Vec4(0.55,0.60,0.55,0.3). The whole scene consists of small triangles, even the large flat surfaces. Is this the expected behavior? And how do I fix it? Thank you! Cheers, Dženan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30833#30833 Attachments: http://forum.openscenegraph.org//files/viewangle3nt_143.png http://forum.openscenegraph.org//files/viewangle2nt_457.png http://forum.openscenegraph.org//files/viewangle1nt_146.png ___ 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::Particle problem
Is there any roadmap about osgParticle ? Does it need to be completely rewritten or only improved to take advantage of more modern techniques ? On Tue, Aug 17, 2010 at 1:55 PM, Wang Rui wangra...@gmail.com wrote: Hi Robert, et al, My improvement this time is mainly about structure fixes and new operators. The bounce and sink (bounce or kill particles in specified domain) operators will be introduced to allow more particle features, as well as new orbiting points, explosion and damping operators. Other changes includes the customized particle shape, sorting by depth, visible distance, and a basic shader implementation. I myself prefer to use the geometry shader to generate particle primitives for rendering, but all other emitting and operating processes are still finished on the CPU. I wonder if we could make use of SSE or some other functionalities. The shader implementation will be set as optional at present. Also I'd like to see if Tim Moore's uniform buffer object submission can be used here (it is not merged yet, isn't it). All these is hoped to be finished during this week. :) Cheers, Wang Rui 2010/8/17 Robert Osfield robert.osfi...@gmail.com: Hi Serge, On Tue, Aug 17, 2010 at 10:28 AM, Serge Lages serge.la...@gmail.com wrote: Thanks for your input, I'll take a look to these posts. Each time we try to use osgParticle we have new problems, I think we'll going to look for another solution, we only need simple particles effects. Anyone has good reading about GPU based particle engines to share ? osgParticle is a bit of an awkward beast, rather long in tooth now - save for the PrecipitationEffect it's almost all the work is done the CPU. The best way to do particles systems these days is to use shaders - the PrecipitationEffect demonstrates that this approach really scales well. Wang Rui is currently working on new functionality for osgParticle, I don't know the details though. Robert. ___ 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 -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Particle problem
Hi Serge, I plan to keep full back-compatibility of previous osgParticle library. Its design and structure is still usable and easy-to-extend in my opinion. Wang Rui 2010/8/17 Serge Lages serge.la...@gmail.com: Is there any roadmap about osgParticle ? Does it need to be completely rewritten or only improved to take advantage of more modern techniques ? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparent polygons render view angle dependent
Hi, There is no quick fix - very useful information. Doing proper sorting of millions of triangles coming out of marching cubes algorithm is not the right way to do it due to performance reasons. Although it would give a proper rendering (more important with more complex datasets than this). Thank you! Cheers, Dženan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30838#30838 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Particle problem
OK, I agree with you, the main problems with the current library are precisions issues and performance, I hope you'll be able to handle them ! On Tue, Aug 17, 2010 at 3:05 PM, Wang Rui wangra...@gmail.com wrote: Hi Serge, I plan to keep full back-compatibility of previous osgParticle library. Its design and structure is still usable and easy-to-extend in my opinion. Wang Rui 2010/8/17 Serge Lages serge.la...@gmail.com: Is there any roadmap about osgParticle ? Does it need to be completely rewritten or only improved to take advantage of more modern techniques ? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Particle problem
A quick mail just to give more opinions on the subject. We stopped using osgParticle for performance reasons. osgParticle is a little bit overengineered for a real time particle system, the particle simulation loop is quite bloated with different layer of abstractions that are finally not so useful. Moreover, the particle class is quite big, with lot of informations that are not useful for all particle systems. It is really not suited for high performance particle systems (thousands of particles). Finally, doing the particle simulation on my own was easier, and give me more control. For exemple, the particle system must work with earth-like databases. I have several effects (explosion, reactor trail, dust trail), they just share the drawing code (convert particles to osg::Geometry) and some basic particles management, and it is sufficient... From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Serge Lages Sent: mardi 17 août 2010 15:26 To: OpenSceneGraph Users Subject: Re: [osg-users] osg::Particle problem OK, I agree with you, the main problems with the current library are precisions issues and performance, I hope you'll be able to handle them ! On Tue, Aug 17, 2010 at 3:05 PM, Wang Rui wangra...@gmail.com wrote: Hi Serge, I plan to keep full back-compatibility of previous osgParticle library. Its design and structure is still usable and easy-to-extend in my opinion. Wang Rui 2010/8/17 Serge Lages serge.la...@gmail.com: Is there any roadmap about osgParticle ? Does it need to be completely rewritten or only improved to take advantage of more modern techniques ? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email _ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to use osgvolume in an SDL application?
Hi, Can some one give an idea on how to use osgvolume in SDL application? Thank you! Cheers, Boubacar -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30829#30829 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Particle problem
Hi Fabien, Today's osgParticle already uses GLBeginEndAdapter for rendering particles, which is actually glDrawArray() at its low-level implementation. I wonder if this is not too inefficient comparing with the use of osg::Geometry. Of course, making use of shaders will be much better on modern graphics devices. To develop new features for osgParticle, I mainly refer to a good open-source project by David McAllister (http://www.particlesystems.org/). Any other ideas and usable source code are welcome and appreciated. Cheers, Wang Rui 2010/8/17 Fabien Lavignotte fabien.lavigno...@vegatechnologies.fr: A quick mail just to give more opinions on the subject. We stopped using osgParticle for performance reasons. osgParticle is a little bit overengineered for a real time particle system, the particle simulation loop is quite bloated with different layer of abstractions that are finally not so useful. Moreover, the particle class is quite big, with lot of informations that are not useful for all particle systems. It is really not suited for high performance particle systems (thousands of particles). Finally, doing the particle simulation on my own was easier, and give me more control. For exemple, the particle system must work with earth-like databases. I have several effects (explosion, reactor trail, dust trail), they just share the drawing code (convert particles to osg::Geometry) and some basic particles management, and it is sufficient... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Particle problem
You may also have a look at : http://spark.developpez.com/ Looking at the code, it seems well designed. Cheers, On Tue, Aug 17, 2010 at 4:25 PM, Wang Rui wangra...@gmail.com wrote: Hi Fabien, Today's osgParticle already uses GLBeginEndAdapter for rendering particles, which is actually glDrawArray() at its low-level implementation. I wonder if this is not too inefficient comparing with the use of osg::Geometry. Of course, making use of shaders will be much better on modern graphics devices. To develop new features for osgParticle, I mainly refer to a good open-source project by David McAllister (http://www.particlesystems.org/). Any other ideas and usable source code are welcome and appreciated. Cheers, Wang Rui 2010/8/17 Fabien Lavignotte fabien.lavigno...@vegatechnologies.fr: A quick mail just to give more opinions on the subject. We stopped using osgParticle for performance reasons. osgParticle is a little bit overengineered for a real time particle system, the particle simulation loop is quite bloated with different layer of abstractions that are finally not so useful. Moreover, the particle class is quite big, with lot of informations that are not useful for all particle systems. It is really not suited for high performance particle systems (thousands of particles). Finally, doing the particle simulation on my own was easier, and give me more control. For exemple, the particle system must work with earth-like databases. I have several effects (explosion, reactor trail, dust trail), they just share the drawing code (convert particles to osg::Geometry) and some basic particles management, and it is sufficient... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Particle problem
Hi Wang, It is just my personal experience that a simple to use and high performance generic particle system is a huge if not impossible task. Just see for exemple in osgParticle the PrecipitationEffect done by Robert, in fact it does not use osgParticle framework. I send you the ParticleSystemBuilder class i use to create my effects. Very basic but sufficient for my own needs. It covers particle drawing (using PointSprite), and basic particle management. It is a template class so that you can easily reuse it with different kind of particles. Too rough to be really useful for OSG, but it can give an idea of a lightweight solution. Then most of the code (particle simulation) is done in each effect and deals with various problems, like precision issues when dealing with earth-like databases. Cheers, Fabien -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Wang Rui Sent: mardi 17 août 2010 16:25 To: OpenSceneGraph Users Subject: Re: [osg-users] osg::Particle problem Hi Fabien, Today's osgParticle already uses GLBeginEndAdapter for rendering particles, which is actually glDrawArray() at its low-level implementation. I wonder if this is not too inefficient comparing with the use of osg::Geometry. Of course, making use of shaders will be much better on modern graphics devices. To develop new features for osgParticle, I mainly refer to a good open-source project by David McAllister (http://www.particlesystems.org/). Any other ideas and usable source code are welcome and appreciated. Cheers, Wang Rui 2010/8/17 Fabien Lavignotte fabien.lavigno...@vegatechnologies.fr: A quick mail just to give more opinions on the subject. We stopped using osgParticle for performance reasons. osgParticle is a little bit overengineered for a real time particle system, the particle simulation loop is quite bloated with different layer of abstractions that are finally not so useful. Moreover, the particle class is quite big, with lot of informations that are not useful for all particle systems. It is really not suited for high performance particle systems (thousands of particles). Finally, doing the particle simulation on my own was easier, and give me more control. For exemple, the particle system must work with earth-like databases. I have several effects (explosion, reactor trail, dust trail), they just share the drawing code (convert particles to osg::Geometry) and some basic particles management, and it is sufficient... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ParticleSystemBuilder.h Description: ParticleSystemBuilder.h ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] collada: use of bind_vertex_input
Hi, I've encoutered kmz files with dae files inside that look like that : Code: bind_material technique_common instance_material symbol=building_0 target=#building_0/instance_material instance_material symbol=building_1 target=#building_1 bind semantic=CHANNEL1 target=#b1-obj-tverts/bind /instance_material /technique_common /bind_material The texture coords are not loaded. If I add a bind_vertex_input element, textures works. Code: bind_material technique_common instance_material symbol=building_0 target=#building_0/instance_material instance_material symbol=building_1 target=#building_1 bind semantic=CHANNEL1 target=#b1-obj-tverts/bind bind_vertex_input semantic=CHANNEL1 input_semantic=TEXCOORD input_set=1/ /instance_material /technique_common /bind_material Do someone know what's happening ? Is it a problem in the file or the dae reader ? The file is opened correctly in GoogleEarth. Thank you! Cheers, Luc -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30846#30846 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Particle problem
Hi Fabien and Serge, Thanks for the useful information and code. I'll look into them and see if my work can be done better. :) Wang Rui 2010/8/17 Fabien Lavignotte fabien.lavigno...@vegatechnologies.fr: Hi Wang, It is just my personal experience that a simple to use and high performance generic particle system is a huge if not impossible task. Just see for exemple in osgParticle the PrecipitationEffect done by Robert, in fact it does not use osgParticle framework. I send you the ParticleSystemBuilder class i use to create my effects. Very basic but sufficient for my own needs. It covers particle drawing (using PointSprite), and basic particle management. It is a template class so that you can easily reuse it with different kind of particles. Too rough to be really useful for OSG, but it can give an idea of a lightweight solution. Then most of the code (particle simulation) is done in each effect and deals with various problems, like precision issues when dealing with earth-like databases. Cheers, Fabien ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to map an image to a long width object
Hi, there ... I have a problem on texture mapping. When the ratio of the rectangle is equal to the image . It is OK . But when the rectangle is very long , such as a road, the result is the image is stretched. how to achieve texture mapping using osg::Texture2D? Thank you! Cheers, Zhanglicheng -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30185#30185 Attachments: http://forum.openscenegraph.org//files/question_115.jpg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to use osgvolume in an SDL application?
Hi Boubacar, The osgvolume and osgsdl examples should how to use osgVolume NodeKit and SDL respectively, it's up to your app to mix and match to your pleasure. Robert. On Tue, Aug 17, 2010 at 11:39 AM, Boubacar TOURE boubacarto...@sante.gov.ml wrote: Hi, Can some one give an idea on how to use osgvolume in SDL application? Thank you! Cheers, Boubacar -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30829#30829 ___ 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::Particle problem
Hi Wang Rui, On Tue, Aug 17, 2010 at 3:25 PM, Wang Rui wangra...@gmail.com wrote: Today's osgParticle already uses GLBeginEndAdapter for rendering particles, which is actually glDrawArray() at its low-level implementation. I wonder if this is not too inefficient comparing with the use of osg::Geometry. Of course, making use of shaders will be much better on modern graphics devices. In my own testing I've found the GLBeginEndAdapter slightly slower than glBegin/glEnd, despite the use of OpenGL fast paths as the population of the arrays and emulation of the fixed functions is where the cost all comes from. One should still view this very much as a slow path. Using osg::Geometry and point sprites will be far more efficient than using GLBeginEndAdapter, both from a CPU overhead as well as the GPU costs. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] collada: use of bind_vertex_input
lucfrauciel wrote: Hi, I've encoutered kmz files with dae files inside that look like that : Code: bind_material technique_common instance_material symbol=building_0 target=#building_0/instance_material instance_material symbol=building_1 target=#building_1 bind semantic=CHANNEL1 target=#b1-obj-tverts/bind /instance_material /technique_common /bind_material The texture coords are not loaded. If I add a bind_vertex_input element, textures works. Code: bind_material technique_common instance_material symbol=building_0 target=#building_0/instance_material instance_material symbol=building_1 target=#building_1 bind semantic=CHANNEL1 target=#b1-obj-tverts/bind bind_vertex_input semantic=CHANNEL1 input_semantic=TEXCOORD input_set=1/ /instance_material /technique_common /bind_material Do someone know what's happening ? Is it a problem in the file or the dae reader ? The file is opened correctly in GoogleEarth. Thank you! Cheers, Luc The issue is similar to : http://forum.openscenegraph.org/viewtopic.php?t=2676 (more recent thread) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30855#30855 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [3rdparty] osg-cdb?
Hi, Has anyone written a osg nodekit for loading Common Database(cdb) terrains? http://www.presagis.com/products_services/standards/cdb/ Cheers, karl -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30857#30857 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to map an image to a long width object
Hi Zhanglicheng, osg::Texture2D is derived from osg::Texture and that class has a method called setWrap(). This allows you to set how the texture repeats over a polygon in each dimension. Have a look in the header file or the reference documentation for the details. Cheers, Tony -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30858#30858 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proximity Queries between objects
Hi, My 3d model is a number of nodes linked by PATs and a Group node right on top. So when I was going through the methods, I observed that the getBound() works only for nodes. Then I also came across the computeBound() which can be used with Group nodes. Code: virtual BoundingSphere osg::Group::computeBound () const [virtual] Compute the bounding sphere around Node's geometry or children. This method is automatically called by getBound() when the bounding sphere has been marked dirty via dirtyBound(). Reimplemented from osg::Node. So I wasn't sure which is the method to go ? If I compute bounding spheres for each node that makes up my 3d model, can I link all of them so that I can check for proximity between another 3d model and this one ? If any of the examples deal with something similar, I would be glad to go through that but I didn't know which one. Thank You Sincerely, Sanat -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30860#30860 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] why transform nodes give a big impact to cull time??
Hi, Thank you very much for your reply, robert. I will make try~ Cheers, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30862#30862 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
