Re: [osg-users] Performance decrease with 2.4.0
Hi Robert, Yes. I am using Release builds. The load times differ significantly. I have not been able to pin it down exactly. I'm curious if anyone else has experienced this. Chris. - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Wednesday, May 07, 2008 4:41 AM Subject: Re: [osg-users] Performance decrease with 2.4.0 Hi Chris, There isn't any major changes to rendering in 2.4.0, so you should get pretty well the same performance profile from 2.4.0. Perhaps it's an issue as simply as build options - are you compiling under Release build under 2.4? Robert. On Tue, May 6, 2008 at 8:59 PM, DC Fennell <[EMAIL PROTECTED]> wrote: Hi everybody, Our application is loading IVEs and DDS textures. With OSG 2.4.0, the load times seem to have been increased significantly and the framerate in our scenes has decreased around 10%. It's quite difficult to figure out what exactly has caused this based on the changes from 2.2.0 to 2.4.0. Does anyone have any possible explanations for this behavior? Thanks Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Performance decrease with 2.4.0
Hi everybody, Our application is loading IVEs and DDS textures. With OSG 2.4.0, the load times seem to have been increased significantly and the framerate in our scenes has decreased around 10%. It's quite difficult to figure out what exactly has caused this based on the changes from 2.2.0 to 2.4.0. Does anyone have any possible explanations for this behavior? Thanks Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG Static Libraries
I don't believe it's a memory issue. I'm using Visual Studio 9. The performance improved quite a bit when I set the Buffer Security Check to "No" in the Code Generation, and with default Release optimizations. Setting other optimizations does not show any improvement. Using Whole Program Optimization increases the size of the libraries to an unusable size. - Original Message - From: Zach Deedler To: OpenSceneGraph Users Sent: Monday, May 05, 2008 4:47 PM Subject: Re: [osg-users] OSG Static Libraries Are you running out of memory, and starting to use virtual memory? -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DC Fennell Sent: Monday, May 05, 2008 12:33 PM To: Public OpenSceneGraph Users discussion list. Subject: [osg-users] OSG Static Libraries Hello, I've built OSG core and plug-in libraries statically. The performance I get is quite a bit slower than using DLLs. It would seem that the performance should be equal, if not better using the static libraries. I followed the instructions from the link below. http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/Win32StaticLink Besides the OSG_LIBRARY_STATIC preprocessor command added using CMAKE, I had to add OPENTHREADS_EXPORTS to the core and plug-in libraries to avoid compile warnings/errors in the main application. Has anyone else gone the static library route? If so, was there any noticeable differences in performance? Any ideas on what I am doing wrong to get such poor performance. I'm talking about less than half the performance as with the DLLs. Thanks. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG Static Libraries
Hello, I've built OSG core and plug-in libraries statically. The performance I get is quite a bit slower than using DLLs. It would seem that the performance should be equal, if not better using the static libraries. I followed the instructions from the link below. http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/Win32StaticLink Besides the OSG_LIBRARY_STATIC preprocessor command added using CMAKE, I had to add OPENTHREADS_EXPORTS to the core and plug-in libraries to avoid compile warnings/errors in the main application. Has anyone else gone the static library route? If so, was there any noticeable differences in performance? Any ideas on what I am doing wrong to get such poor performance. I'm talking about less than half the performance as with the DLLs. Thanks. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] get_random
Hi Scott, Yes, the function, as it is written, is [min, max]sorry about my typo. If the intent of this function is, as you say, is [min, max], then the comment needs to change so there is no ambiguity. It's nit-picking, but I always assume a get_random is [min, max), which can be used for indexing arrays randomly. (That's how I discovered this on a crash). Chris. - Original Message - From: "Scott" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Thursday, January 31, 2008 10:14 AM Subject: Re: [osg-users] get_random > On Jan 31, 2008 11:09 AM, Alberto Luaces <[EMAIL PROTECTED]> wrote: >> I think it was more important for the original writer to get high quality >> random numbers than to match the exact range. Maybe the documentation >> should >> be changed in order to say that it returns min < x <= max, or the >> function, >> decrementing the max arg passed one unit, so the value returned could be >> min >> < x <= max-1 which would mean min < x < max when dealing with integers. >> > > Matching the exact range is extremely important, as otherwise you can > get weird bugs when you get the values outside, which will happen > exceeding rarely, making them very hard to debug. > > Also, if the implementation really is >> minimum + (maximum - minimum) * rand() / RAND_MAX; > then the range is neither (min,max] nor (min,max) -- it's [min,max] > ___ > 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] get_random
The comment says between min and max (min < x < max), but the function will return (min <= x <= max) I'm just trying to clarify the actual intent of this function. Was the author intending the former, or latter? Chris - Original Message - From: "Alberto Luaces" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Thursday, January 31, 2008 10:09 AM Subject: Re: [osg-users] get_random > El Thursday 31 January 2008 16:41:55 DC Fennell escribió: >> Hello everybody, >> >> I believe the get_random() function in range under osgParticle should be: >> minimum + (maximum - minimum) * rand() / (RAND_MAX + 1); >> It is written as: >> >> minimum + (maximum - minimum) * rand() / RAND_MAX; >> >> If you expect the values returned (as specified in the comments) to be >> between min and max (min < x < max), then this function could give >> incorrect results, since there are instances where rand() returns >> RAND_MAX. >> >> Is the intent of this function, in mathematical terms, to return (min, >> max) >> or (min, max] ? >> >> This question applies to get_random_sqrtf() as well. >> >> Thanks. >> >> Chris. > > I think it is taken directly from a known recomendation from the > book "Numerical Recipes in C: The Art of Scientific Computing". It is > mentioned in the man page of the rand() function: > > "If you want to generate a random integer between 1 and 10, you should > always > do it by using high-order bits, as in > > > j = 1 + (int) (10.0 * (rand() / (RAND_MAX + 1.0))); > > > and never by anything resembling > > > j = 1 + (rand() % 10); > > > (which uses lower-order bits)." > > I think it was more important for the original writer to get high quality > random numbers than to match the exact range. Maybe the documentation > should > be changed in order to say that it returns min < x <= max, or the > function, > decrementing the max arg passed one unit, so the value returned could be > min > < x <= max-1 which would mean min < x < max when dealing with integers. > > ___ > 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] get_random
Hello everybody, I believe the get_random() function in range under osgParticle should be: minimum + (maximum - minimum) * rand() / (RAND_MAX + 1); It is written as: minimum + (maximum - minimum) * rand() / RAND_MAX; If you expect the values returned (as specified in the comments) to be between min and max (min < x < max), then this function could give incorrect results, since there are instances where rand() returns RAND_MAX. Is the intent of this function, in mathematical terms, to return (min, max) or (min, max] ? This question applies to get_random_sqrtf() as well. Thanks. Chris. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] glActiveTexture / glClientActiveTexture state changes
Hello, I am curious as to why OSG never resets glActiveTexture or glClientActiveTexture back to GL_TEXTURE0 after usage. In my opinion, this should always be done. Specifically since glClientActiveTexture is set quite often in display lists. As a test, I modified osg and osgUtil to reset these states back to GL_TEXTURE0 after any usage of glActiveTexture and glClientActiveTexture. With this change, all my known issues went away. Was there a specific reason why these states are not reset? Or am I just doing it wrong? Thanks.___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] isImageTranslucent
Hello, Is there anything planned on making Image::isImageTranslucent work for compressed textures? I'm not sure how long it's been there, but I see the TODO comment regarding this feature in ReaderWriterDDS.cpp. Thanks.___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particle Sorting
Hello, The settings you mentioned below have been set. These are set by default within the osg particle system. The problem still exists when I create another bin. I wish I could be of help with the polygon sorting, but I have never implemented it with osg. - Original Message - From: "Michele Bosi" <[EMAIL PROTECTED]> To: "Public OpenSceneGraph Users discussion list." Sent: Wednesday, September 05, 2007 5:14 PM Subject: Re: [osg-users] Particle Sorting > Hi, > I am also dealing with transparencies and sorting, in your case maybe > it's enough to mask off z-buffer writing for all the particle systems > using something like: > > osg::Depth* depth = new osg::Depth(); > depth->setWriteMask(false); > > your_geode->getOrCreateStateSet()->setAttribute(depth, > osg::StateAttribute::OVERRIDE | osg::StateAttribute::ON); > > also be sure that all the rest is ok, like > your_geode->getOrCreateStateSet()->setRenderingHint(osg::StateSet::TRANSPARENT_BIN); > > usually for particle systems using this little trick you don't need to > sort at all. > The method has some flaws since the result is not really correct as if > you sorted your particles but since they are moving this shouldn't be > a problem. > > Theoretically transparent object that don't write on the z-buffer > should be rendered after the transparent ones that do write on it so > in order to obtain more correct results for your particles you should > create another BIN (I know you can do it but have no idea how) and > schedule it after TRANSPARENT_BIN. > > I just posted a question about polygon sorting, have you ever > implement it with osg or do you have any particular advice share? > > Regards, > Mike > ___ > 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] Particle Sorting
Hello, What if you have several smoke grenades go off in one area, where the smoke of each intermingles with the smoke of the other? When moving around, one smoke grenade takes priority (because the drawable is sorted back to front in the transparent bin). All particles in that drawable are drawn and overlay other smoke which may be intermingled from the other smoke grenades. I'm not sure if my example makes sense or not. I trust you on the bin number, but I would rather not have to create separate bins if possible. In a large battle scene, explosions, smoke grenades, etc. can get messy trying to determine priorities. Having one particle system works, but it just seems like the wrong way to go about this. - Original Message - From: Zach Deedler To: 'Public OpenSceneGraph Users discussion list.' Sent: Wednesday, September 05, 2007 5:39 PM Subject: Re: [osg-users] Particle Sorting Playing around with bin number of your model may help you in this case. The default bin number of models is 10. If you set your explosion to 11 then your explosion will have priority when they are at the same position. This will get rid of the anomalies, and will look better. Trust me. You can take a look at osglogo for what to set in code, but I find it easier to do it inside the osg model (if that is what you are using). Models are prioritized by their group and not by polygon. I don't know of any better way to 'blend' particle systems. -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DC Fennell Sent: Wednesday, September 05, 2007 12:20 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Particle Sorting Hello, I have several particle systems, which may be close to each other. Unless all particles emitted are grouped and sorted as one bucket, then drawn, I get visual anomalies. For example. If I have 3 smoke stacks (each a separate particle system) close together, and if an explosion occurs in the middle of the smoke stacks, it looks odd, i.e., the smoke effect may appear in front of the explosion instead if intermingled when the smoke overlaps, depending on your view. Running double pass does not help with this. The only solution I can think of is to use one particle system for all effects, then sort back to front. Anyone have any other suggestions? Thanks in advance -- ___ 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] Particle Sorting
Hello, I have several particle systems, which may be close to each other. Unless all particles emitted are grouped and sorted as one bucket, then drawn, I get visual anomalies. For example. If I have 3 smoke stacks (each a separate particle system) close together, and if an explosion occurs in the middle of the smoke stacks, it looks odd, i.e., the smoke effect may appear in front of the explosion instead if intermingled when the smoke overlaps, depending on your view. Running double pass does not help with this. The only solution I can think of is to use one particle system for all effects, then sort back to front. Anyone have any other suggestions? Thanks in advance___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
