Re: Extracted meshes and performance
Have you run any tests yourself in this respect? On Friday, November 01, 2013 10:58:56 AM, Sergio Mucino wrote: Simple, quick question. When dealing with extracting meshes from another one that is deforming (using Create - Poly Mesh - Extract Polygons (keep) ), what is a better approach to take, performance-wise? One single mesh with lots of polygons (relatively speaking), or several meshes with few polys? Thanks everyone! --
Re: Extracted meshes and performance
Historically Soft has dealt quite well with few objects with intense topology much better than thousands of low-res objects. Like Eric said, it wouldn't hurt to run some tests yourself. For example, you could make a very densely subdivided cube, extract each face to get a few thousand objects and test performance of that vs extract each side getting multiple polys. You enable the framerate counter in the viewport with Display-Visibility Options (All Cameras), then in the Stats tab, first option. On Fri, Nov 1, 2013 at 11:02 AM, Eric Thivierge ethivie...@hybride.comwrote: Have you run any tests yourself in this respect? On Friday, November 01, 2013 10:58:56 AM, Sergio Mucino wrote: Simple, quick question. When dealing with extracting meshes from another one that is deforming (using Create - Poly Mesh - Extract Polygons (keep) ), what is a better approach to take, performance-wise? One single mesh with lots of polygons (relatively speaking), or several meshes with few polys? Thanks everyone! --
Re: Extracted meshes and performance
I'd probably try not to keep that kind of operator live, as it has a tendency to get frozen off easily then you're stuck with a non-moving mesh again. For example, if the source mesh gets the modelling frozen it can freeze the operator. On 1 November 2013 15:02, Eric Thivierge ethivie...@hybride.com wrote: Have you run any tests yourself in this respect? On Friday, November 01, 2013 10:58:56 AM, Sergio Mucino wrote: Simple, quick question. When dealing with extracting meshes from another one that is deforming (using Create - Poly Mesh - Extract Polygons (keep) ), what is a better approach to take, performance-wise? One single mesh with lots of polygons (relatively speaking), or several meshes with few polys? Thanks everyone! -- -- www.matinai.com
Re: Extracted meshes and performance
Makes sense. With other apps its the same case. Unfortunately, I won't have time to test this thoroughly for our needs... I'll trust your experience and comments in this case :-) (I already have to come in for the weekend as it is), but I will keep an eye on how the scene feels as I progress. Thanks guys! On 01/11/2013 11:09 AM, Alan Fregtman wrote: Historically Soft has dealt quite well with few objects with intense topology much better than thousands of low-res objects. Like Eric said, it wouldn't hurt to run some tests yourself. For example, you could make a very densely subdivided cube, extract each face to get a few thousand objects and test performance of that vs extract each side getting multiple polys. You enable the framerate counter in the viewport with Display-Visibility Options (All Cameras), then in the Stats tab, first option. On Fri, Nov 1, 2013 at 11:02 AM, Eric Thivierge ethivie...@hybride.com wrote: Have you run any tests yourself in this respect? On Friday, November 01, 2013 10:58:56 AM, Sergio Mucino wrote: Simple, quick question. When dealing with extracting meshes from another one that is deforming (using Create - Poly Mesh - Extract Polygons (keep) ), what is a better approach to take, performance-wise? One single mesh with lots of polygons (relatively speaking), or several meshes with few polys? Thanks everyone! --
Re: Extracted meshes and performance
In this case, I won`t have to worry about that. The meshes I`m extracting from won`t see that happen to them, and nobody but me will be touching them. Good to know though! Thanks Matt! On 01/11/2013 11:10 AM, Matt Morris wrote: I'd probably try not to keep that kind of operator live, as it has a tendency to get frozen off easily then you're stuck with a non-moving mesh again. For example, if the source mesh gets the modelling frozen it can freeze the operator. On 1 November 2013 15:02, Eric Thivierge ethivie...@hybride.com wrote: Have you run any tests yourself in this respect? On Friday, November 01, 2013 10:58:56 AM, Sergio Mucino wrote: Simple, quick question. When dealing with extracting meshes from another one that is deforming (using Create - Poly Mesh - Extract Polygons (keep) ), what is a better approach to take, performance-wise? One single mesh with lots of polygons (relatively speaking), or several meshes with few polys? Thanks everyone! -- -- www.matinai.com
Re: Extracted meshes and performance
In theory, one mesh with more polys should be faster I think, because the scene has only one operator to update compared to many operators in case of multiple polys. But, if the number of polygons is too high, the overhead for each operator with single polygon may be less than processing the heavy poly data in one operator. This should be the case theoretically, but you have to do the tests to confirm as Eric said. On 11/1/2013 11:02 AM, Eric Thivierge wrote: Have you run any tests yourself in this respect? On Friday, November 01, 2013 10:58:56 AM, Sergio Mucino wrote: Simple, quick question. When dealing with extracting meshes from another one that is deforming (using Create - Poly Mesh - Extract Polygons (keep) ), what is a better approach to take, performance-wise? One single mesh with lots of polygons (relatively speaking), or several meshes with few polys? Thanks everyone! -- -- ALOK GANDHI / directeur technique senior- senior technical director alok.gan...@modusfx.com mailto:alok.gan...@modusfx.com T: *450 430-0010 x225 F: *450 430-0009 www.modusfx.com http://www.modusfx.com - MODUS FX 120 Rue Turgeon, Sainte-Therese (Quebec) CANADA J7E 3J1 Follow us on Facebook http://www.facebook.com/ModusFX Twitter https://twitter.com/Modusfx **
RE: Extracted meshes and performance
What the others said plus personally, one mesh would allow for more flexibility, in that case why not use the actual mesh instead of extracting it. You may be taking a big hit right there by extracting it and keeping it live. To test : On a second instance of Softimage Get a very dense sphere Deform it with a 3-4 bone chain extract Check the interaction by moving the effector on the chain Keep that scene open... That’s what I do. -manny From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Alok Gandhi Sent: Friday, November 01, 2013 11:15 AM To: softimage@listproc.autodesk.com Subject: Re: Extracted meshes and performance In theory, one mesh with more polys should be faster I think, because the scene has only one operator to update compared to many operators in case of multiple polys. But, if the number of polygons is too high, the overhead for each operator with single polygon may be less than processing the heavy poly data in one operator. This should be the case theoretically, but you have to do the tests to confirm as Eric said. On 11/1/2013 11:02 AM, Eric Thivierge wrote: Have you run any tests yourself in this respect? On Friday, November 01, 2013 10:58:56 AM, Sergio Mucino wrote: Simple, quick question. When dealing with extracting meshes from another one that is deforming (using Create - Poly Mesh - Extract Polygons (keep) ), what is a better approach to take, performance-wise? One single mesh with lots of polygons (relatively speaking), or several meshes with few polys? Thanks everyone! -- -- ALOK GANDHI / directeur technique senior- senior technical director alok.gan...@modusfx.commailto:alok.gan...@modusfx.com T: 450 430-0010 x225 F: 450 430-0009 www.modusfx.comhttp://www.modusfx.com - MODUS FX 120 Rue Turgeon, Sainte-Therese (Quebec) CANADA J7E 3J1 Follow us on Facebookhttp://www.facebook.com/ModusFX Twitterhttps://twitter.com/Modusfx attachment: winmail.dat
RE: Extracted meshes and performance
I completely agree with this. However I would like to add that any lack of performance regarding high object count is probably less an issue with the 3D app than an inherent processing limitation within most high end graphics systems. We see this same behavior in other applications including very expensive high end simulation software. At a basic level what most apps appear to be doing at each iteration, frame change, camera viewport change, other update, etc is cycling through each root level object and checking for updates or mods that need to be applied per the methodology within that application. One way you could think about this is that it starts at the top of the explorer(outliner in maya) and repetitively cycles through the explorer list over and over and over applying updates as it goes and as needed. We have scenes, simulations, and scenarios where we have processed hundreds of thousands of aircraft for example and these kinds of simulations can bring the most powerful computers to their knees even though each individual object is as simple as possible. It's been my personal opinion that the operating system and how it breaks things down for processing between core and interface may also be part of the issue. I've often wondered if it was an integer vs floating point issue. Even more shocking was that we often saw the same results on SGI and Windows simultaneously back when we were still using those beasts. One of our simulation software for example had a special flag that turned off the interface refresh and we would get all the performance back. They also provided us a special object container that acted like a mini scenario holding hundreds of thousands of objects within a root level multi-object. When using this special multi-object performance never skipped a beat but getting access to or from the objects within the root object was no longer as direct. The point being that if you have unreasonably high object counts, you might be able to break your scene down into a handful of Models with the objects distributed under the Models. I've never tried this with Soft and don't know if this would significantly affect Soft's performance, but it might be worth a shot. -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Alan Fregtman Sent: Friday, November 01, 2013 11:09 AM To: XSI Mailing List Subject: Re: Extracted meshes and performance Historically Soft has dealt quite well with few objects with intense topology much better than thousands of low-res objects. --
Re: Extracted meshes and performance
I agree with you, crunching floating points is and always will be an issue even for the most sophisticated processors. The demand for physically accurate simulations will always be more than what the cutting edge technology can offer. On 11/1/2013 11:46 AM, Ponthieux, Joseph G. (LARC-E1A)[LITES] wrote: I completely agree with this. However I would like to add that any lack of performance regarding high object count is probably less an issue with the 3D app than an inherent processing limitation within most high end graphics systems. We see this same behavior in other applications including very expensive high end simulation software. At a basic level what most apps appear to be doing at each iteration, frame change, camera viewport change, other update, etc is cycling through each root level object and checking for updates or mods that need to be applied per the methodology within that application. One way you could think about this is that it starts at the top of the explorer(outliner in maya) and repetitively cycles through the explorer list over and over and over applying updates as it goes and as needed. We have scenes, simulations, and scenarios where we have processed hundreds of thousands of aircraft for example and these kinds of simulations can bring the most powerful computers to their knees even though each individual object is as simple as possible. It's been my personal opinion that the operating system and how it breaks things down for processing between core and interface may also be part of the issue. I've often wondered if it was an integer vs floating point issue. Even more shocking was that we often saw the same results on SGI and Windows simultaneously back when we were still using those beasts. One of our simulation software for example had a special flag that turned off the interface refresh and we would get all the performance back. They also provided us a special object container that acted like a mini scenario holding hundreds of thousands of objects within a root level multi-object. When using this special multi-object performance never skipped a beat but getting access to or from the objects within the root object was no longer as direct. The point being that if you have unreasonably high object counts, you might be able to break your scene down into a handful of Models with the objects distributed under the Models. I've never tried this with Soft and don't know if this would significantly affect Soft's performance, but it might be worth a shot. -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. *From:*softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] *On Behalf Of *Alan Fregtman *Sent:* Friday, November 01, 2013 11:09 AM *To:* XSI Mailing List *Subject:* Re: Extracted meshes and performance Historically Soft has dealt quite well with few objects with intense topology much better than thousands of low-res objects. -- -- ALOK GANDHI / directeur technique senior- senior technical director alok.gan...@modusfx.com mailto:alok.gan...@modusfx.com T: *450 430-0010 x225 F: *450 430-0009 www.modusfx.com http://www.modusfx.com - MODUS FX 120 Rue Turgeon, Sainte-Therese (Quebec) CANADA J7E 3J1 Follow us on Facebook http://www.facebook.com/ModusFX Twitter https://twitter.com/Modusfx **
Re: Extracted meshes and performance
This may well me the case, but I can tell you with some certainty that in multi-thousand object scenes, Softimage handles simple operations like a total dog compared to some of its competitors. Especialy when there are tons of operators, Softimage can be absolutely painful to use. On Fri, Nov 1, 2013 at 3:46 PM, Ponthieux, Joseph G. (LARC-E1A)[LITES] j.ponthi...@nasa.gov wrote: I completely agree with this. However I would like to add that any lack of performance regarding high object count is probably less an issue with the 3D app than an inherent processing limitation within most high end graphics systems. ** **
RE: Extracted meshes and performance
I'm not arguing that Soft is immune, or that it does not have a problem, or that each application behaves exactly the same. We clearly see differences between apps, which in my opinion is due to the differences in what each application is trying to do during each refresh cycle OR how the developer insulates interface refresh from excess operations during the refresh cycle. And in the case of Softimage, I would expect it to be far more susceptible because of the underlying ICE evaluation structure. I saw similar issues with Maya, but most often saw it when we had expressions driving large numbers of objects in that software. The problem is similar to the refresh issue in Windows explorer for directories that have large numbers of files. Are the two conditions related? Not sure. The only point I was trying to make is that this phenomenon is not isolated strictly to Softimage and is potentially unavoidable due to factors beyond Softimage's control. Can it be mitigated? Absolutely. We've seen other developers implement unique tactics to mitigate the issue even while they can't remove it altogether. But there's usually always a trade-off in the mitigation as it's most often only a treatment and not a cure. Could Softimage be modified to mitigate the problem? I have no doubt. The question though is what will it change or what will be the trade-off? -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ciaran Moloney Sent: Friday, November 01, 2013 12:53 PM To: Softimage Mailing list Subject: Re: Extracted meshes and performance This may well me the case, but I can tell you with some certainty that in multi-thousand object scenes, Softimage handles simple operations like a total dog compared to some of its competitors. Especialy when there are tons of operators, Softimage can be absolutely painful to use. On Fri, Nov 1, 2013 at 3:46 PM, Ponthieux, Joseph G. (LARC-E1A)[LITES] j.ponthi...@nasa.govmailto:j.ponthi...@nasa.gov wrote: I completely agree with this. However I would like to add that any lack of performance regarding high object count is probably less an issue with the 3D app than an inherent processing limitation within most high end graphics systems.
