Approximate envelope deformations.

33 views
Skip to first unread message

Simon Pickard

unread,
Sep 15, 2009, 8:59:09 AM9/15/09
to soft...@listproc.autodesk.com
Hello all,

Just having a play with the trial of 2010 (32bit, vista).

Trying to get this new "Approximate envelope deformations" thing
working? I've got a simple rig that meets the conditions in the user
help but when I toggle the setting in prefs->display I can't see any
difference in playback.

Is there something else I'm meant to be doing to see this gain?

Regards,
Simon

Grahame Fuller

unread,
Sep 15, 2009, 4:38:13 PM9/15/09
to soft...@listproc.autodesk.com
Are you displaying a shaded view? Otherwise the normals aren't being calculated either way.

gray

winmail.dat

Malcolm Zaloon

unread,
Sep 15, 2009, 4:43:46 PM9/15/09
to soft...@listproc.autodesk.com
it´s automatic if your envelope is in top of all other operations, and not in modeling.
here works, and is Very very fasssst!  (1.2 milion polys enveloped object playing at 25fps!)
Thanks SI team!
--
__________________
Malcolm Zaloon - Lighting TD - XSI Generalist

Simon Pickard

unread,
Sep 15, 2009, 7:20:38 PM9/15/09
to soft...@listproc.autodesk.com
Yep I've got that here as well, but not seeing any differences really.

When you say it "works" have you tried toggling it off and on? What
differences in speed are you seeing when you change this setting?

2009/9/16 Malcolm Zaloon <mzal...@gmail.com>:

Steven Caron

unread,
Sep 15, 2009, 7:33:37 PM9/15/09
to ma...@simonpickard.co.uk, soft...@listproc.autodesk.com
you said you have a simple rig, but maybe its too simple?

what is the mesh density? number of deformers?

for our rigs with final resolution to send to lighting we are getting 20% - 30% increases.

s

Simon Pickard

unread,
Sep 15, 2009, 7:41:04 PM9/15/09
to Steven Caron, soft...@listproc.autodesk.com
I've tested it with a few rigs, I'm guessing roughly around the same
density and number of deformers as in the siggy demo. And also with a
very hi res tube with 4 bones.

But I'm not seeing any difference in fps.

Maybe it's a bottleneck somewhere else.

Regards,
Simon


2009/9/16 Steven Caron <car...@gmail.com>:

Joe Williamsen

unread,
Sep 15, 2009, 10:34:19 PM9/15/09
to ma...@simonpickard.co.uk, soft...@listproc.autodesk.com
I'm seeing an almost 3X frame rate increase when it's turned on (40fps to 112 fps), but I'm also seeing a few errant points - i.e. the mesh can look messed up in places with the approximation turned on, but it's OK if it's turned off, or if you render.  A little disconcerting, but if you're just wanting to scrub through the animation, I think it's going to be pretty useful (spoken by someone who's only played with the feature for about 20 minutes).

Steven Caron

unread,
Sep 15, 2009, 10:39:34 PM9/15/09
to soft...@listproc.autodesk.com
errant points? like lagging behind? we haven't experienced this at all...

s

Raffaele Fragapane

unread,
Sep 15, 2009, 10:41:05 PM9/15/09
to soft...@listproc.autodesk.com
Not that disconcerting really.
The main optimization is that instead of updating the normals every evaluation they are updated once at end of playback, that's where most of the performance gain comes from afaik.
Of course it doesn't look double awesome if you need to render it or after pleasant shading continuity across a mesh where angles between elements change dramatically.

Similarly, if you run a heavily subDed mesh or have shape animation in abundance, those things will most likely bottleneck your CPU cycles well before the lack of normal updating has a chance to make a difference in fps.

Joe Williamsen

unread,
Sep 15, 2009, 10:57:14 PM9/15/09
to soft...@listproc.autodesk.com
No, not lagging - points in the wrong place:



It's not a huge deal - as long as it renders OK and I can fix it by shutting it off, I'm good with that - but it DID freak me out at first because I couldn't figure out what the hell was going on.  If all this discussion of the feature hadn't been going on, I don't know if or when I would have figured it out - so for that, I'm grateful ;)

Steven Caron

unread,
Sep 15, 2009, 11:02:48 PM9/15/09
to soft...@listproc.autodesk.com
well lets log that! i expect display issues but they are related to normals not vertices.

before you do that, remove the geo approx and see if its the same.
steven

On Tue, Sep 15, 2009 at 7:57 PM, Joe Williamsen <j...@joewilliamsen.com> wrote:
No, not lagging - points in the wrong place:



Joe Williamsen

unread,
Sep 15, 2009, 11:04:52 PM9/15/09
to soft...@listproc.autodesk.com
Well, yeah - it CAN be disconcerting if you can't figure out why part of your mesh looks twisted (like the weighting is whacked - but it's not) but then it renders OK. 

Like I said, just a little bit of "WTF?"

I'm just glad I know what's causing it - I'm so used to seeing new versions of Softimage do weird display things I was dreading having to run through the "display driver minefield" again :)

Joe Williamsen

unread,
Sep 15, 2009, 11:16:39 PM9/15/09
to soft...@listproc.autodesk.com
Yeah - it's there whether the mesh is subdivided or not - that was one of the first things I checked.

Strangely enough, I may also be seeing the same thing that Simon is seeing - i.e. that Approximation sometimes isn't making any difference, or very little.  When I reloaded the scene where I was seeing a big jump - 40 to 112fps, I'm now seeing no performance difference with it toggled on OR off - weird.

Steven Caron

unread,
Sep 15, 2009, 11:33:32 PM9/15/09
to soft...@listproc.autodesk.com
psst, dont forget to log this

s

Joe Williamsen

unread,
Sep 15, 2009, 11:45:51 PM9/15/09
to soft...@listproc.autodesk.com
Anyone else seeing a significant lag when selecting enveloped meshes and/or bones?  The same scene, same mesh, when opened in 7.5 selects instantly - in 2010 selection takes 2-4 seconds!  Even meshes without envelopes select a *tiny* bit slower than 7.5....

Anyone?  Anyone? Beuller?.....

Simon Pickard

unread,
Sep 15, 2009, 11:44:17 PM9/15/09
to soft...@listproc.autodesk.com
"When I reloaded the scene where I was seeing a big jump - 40 to
112fps, I'm now seeing no performance difference with it toggled on OR
off - weird."

I see the change in display (i.e. the normals changing) but in terms
of playback nothing.

I had a chat with Raf about this and he explained there could be other
bottlenecks which I'll check tonight, but I'm sure I tried muting
everything else at one point and couldn't see any difference either.

Is there anything else that needs to be set to see this gain?

Regards,
Simon

Joe Williamsen

unread,
Sep 15, 2009, 11:57:30 PM9/15/09
to ma...@simonpickard.co.uk, soft...@listproc.autodesk.com
Like I said - it worked when I originally opened one of my scenes - and
then when I re-opened it a few minutes later, it didn't work any longer
(I stopped seeing any difference between Approximation ON and
Approximation OFF - other than the messed up geometry).

After restarting Softimage and reloading the scene, still no difference
- weird. My meshes only have envelope operators on them - really basic
stuff....

Joe Williamsen

unread,
Sep 16, 2009, 12:14:16 AM9/16/09
to soft...@listproc.autodesk.com
OK - just what I was afraid of - it looks like the selection lag is video card/ video driver related..... which is not good news... sigh. 

Minefield, here I come.....

Simon Pickard

unread,
Sep 16, 2009, 12:19:19 AM9/16/09
to Joe Williamsen, soft...@listproc.autodesk.com
Yikes.

If you work out how to get it back please let me know! :)

Regards,
Simon

2009/9/16 Joe Williamsen <j...@joewilliamsen.com>:

Stefan Andersson

unread,
Sep 16, 2009, 4:28:18 AM9/16/09
to soft...@listproc.autodesk.com
ATI or nVidia card?

/s

--
[ protector of penguins - abuser of pixels ]

Brent McPherson

unread,
Sep 16, 2009, 5:27:10 AM9/16/09
to soft...@listproc.autodesk.com
Joe,

Are you able to log this?

If not you can email me the scene privately and I will log it for you since this doesn't look right.

Thanks.
--
Brent

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Joe Williamsen
Sent: Wednesday, September 16, 2009 3:57 AM
To: soft...@listproc.autodesk.com
Subject: Re: Approximate envelope deformations.

No, not lagging - points in the wrong place:

[cid:image0...@01CA36B8.3F98C7A0]

It's not a huge deal - as long as it renders OK and I can fix it by shutting it off, I'm good with that - but it DID freak me out at first because I couldn't figure out what the hell was going on. If all this discussion of the feature hadn't been going on, I don't know if or when I would have figured it out - so for that, I'm grateful ;)


Steven Caron wrote:
errant points? like lagging behind? we haven't experienced this at all...

s


On Tue, Sep 15, 2009 at 7:34 PM, Joe Williamsen <j...@joewilliamsen.com<mailto:j...@joewilliamsen.com>> wrote:
I'm seeing an almost 3X frame rate increase when it's turned on (40fps to 112 fps), but I'm also seeing a few errant points - i.e. the mesh can look messed up in places with the approximation turned on, but it's OK if it's turned off, or if you render. A little disconcerting, but if you're just wanting to scrub through the animation, I think it's going to be pretty useful (spoken by someone who's only played with the feature for about 20 minutes).

Simon Pickard wrote:

Yep I've got that here as well, but not seeing any differences really.

When you say it "works" have you tried toggling it off and on? What

differences in speed are you seeing when you change this setting?

2009/9/16 Malcolm Zaloon <mzal...@gmail.com><mailto:mzal...@gmail.com>:

it´s automatic if your envelope is in top of all other operations, and not

in modeling.

here works, and is Very very fasssst! (1.2 milion polys enveloped object

playing at 25fps!)

Thanks SI team!

On Tue, Sep 15, 2009 at 5:38 PM, Grahame Fuller

<Grahame...@autodesk.com><mailto:Grahame...@autodesk.com> wrote:

Are you displaying a shaded view? Otherwise the normals aren't being

calculated either way.

gray

-----Original Message-----

From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com>

[mailto:softimag...@listproc.autodesk.com] On Behalf Of Simon Pickard

Sent: Tuesday, September 15, 2009 08:59 AM

To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>

Subject: Approximate envelope deformations.

Hello all,

Just having a play with the trial of 2010 (32bit, vista).

Trying to get this new "Approximate envelope deformations" thing

working? I've got a simple rig that meets the conditions in the user

help but when I toggle the setting in prefs->display I can't see any

difference in playback.

Is there something else I'm meant to be doing to see this gain?

Regards,

Simon

--

__________________

Malcolm Zaloon - Lighting TD - XSI Generalist


________________________________
Autodesk Limited
Registered Office: 1 Meadow Gate Avenue, Farnborough, Hampshire GU14 6FG
Registered in England and Wales, No. 1839239

image001.jpg

André Adam

unread,
Sep 16, 2009, 5:43:30 AM9/16/09
to soft...@listproc.autodesk.com
We have frequently seen that with ATI consumer cards. We have dropped
them entirely for our workstations. I doubt ATI will *ever* get OpenGL
right.

-André

>>>>>> 2009/9/16 Malcolm Zaloon <mzal...@gmail.com> <mailto:mzal...@gmail.com>:

Joe Williamsen

unread,
Sep 16, 2009, 12:27:54 PM9/16/09
to soft...@listproc.autodesk.com
It's an ATI card - Radeon 4870 - strange thing is that there are NO problems with the same scene in V7...

After messing with it for a while, the problem appears to be tied to specific models built in previous versions, and I get dramatically slower selections in Wireframe than I do in Shaded mode - but only on those models (so far).

When I create a new mesh and envelope it in 2010, I don't see any lag at all when selecting bones or the mesh.  Adding clusters also has no detrimental effect on selection.

When I delete the clusters off of the "problem" models, selection speed improves dramatically, but still isn't instantaneous, and is still much slower in wireframe.  If I recreate a cluster on that model, selection speed slows way down again. 

Selecting the models/meshes in the Explorer is instantaneous, and using Ctrl-Shift-A deselects instantly as well, but selecting in the viewport - especially in wireframe - can take upwards of 8 seconds.

Duplicating the model, exporting it as an OBJ and reimporting it, exporting as a emdl, merging scenes - none of these seem to fix it.  I even tried going back out as an OBJ and into Lightwave and using an awesome script there called "uModelCleaner" - but that didn't fix it either.  Very weird.

It's times like these I wish Softimage had a geometry cleanup function.  Anyone know of a "Make Compatible with v2010 Script?" - lol.  I don't know what they changed, but it's weird that in previous versions with the exact scenes and models, I have no issues whatsoever....

Joe Williamsen

unread,
Sep 16, 2009, 12:38:53 PM9/16/09
to soft...@listproc.autodesk.com
I've seen this with both ATI and nVidia - just depends on the application, the system, the driver, and the phase of the moon ;)  At the last place I worked for, we brought in new brand new QuadroFX cards - very expensive - and they had horrible problems in Maya - selection lag, geometry "fly-away", severe clipping issues, texture flipping and substitution - super strange behavior.  Out of the 10 cards we brought in for testing, none of them worked properly no matter what driver we tried - so I stuck my "old" Radeon 4870 back in and didn't have any more problems.  We ended up sending them all back and using ATI 4870 X2's.

I will agree that there are some things that ATI does pretty poorly - and the same goes for nVidia.  Kind of makes me wonder what's going to happen with the Intel "integrated" video systems that are coming down the pipe - a blessing, or a curse?

Luc-Eric Rousseau

unread,
Sep 16, 2009, 5:42:20 PM9/16/09
to soft...@listproc.autodesk.com
The problem occurs when the newer OpenGL features, for example vertex
buffers, are not supported by the classic OpenGL API for the selection
buffer. nVidia is usually pro active in implementing this for us, the
problem has been as AFAIK been with ATI. They want the app developers
to just re-write their CAD apps another way and abandon the older
OpenGL API, because they're not really an optimal use of the hardware

To work-around your problem, you could try to force XSI to not use
newer OpenGL API with the
XSI_EMULATE_OPENGL environment variable
http://softimage.wiki.softimage.com/history/xsidocs_whatwasnew/new_Version701.htm#Rab87680

for example try 1.5 and go down to 1.4 if needed

Simon Pickard

unread,
Sep 16, 2009, 8:49:56 PM9/16/09
to soft...@listproc.autodesk.com
Just to close up this thread.. The rigs I was quickly testing also
were from an older xsi version.

After reading the "playback speed" thread. I saved out my weights,
deleted the old env op added one from within 2010 and loaded the
weights back on and I'm seeing the improvements now.

Great stuff! :)
This along with the fantastic improvements with the fcurve editors
speeds have made Simon a very happy bunny!

Regards,
Si

Steven Caron

unread,
Sep 16, 2009, 8:52:25 PM9/16/09
to ma...@simonpickard.co.uk, soft...@listproc.autodesk.com
glad to hear it, but it makes me question whats going on here. we are rigging in an older version and animating in 2010.

s

Matt Lind

unread,
Sep 16, 2009, 8:58:25 PM9/16/09
to ma...@simonpickard.co.uk, soft...@listproc.autodesk.com
yeah, but the $64,000 question that's burning in my head is why we have
to delete the existing envelope and rebuild it ourselves to get the
improvement?

If we're loading data from a file, XSI has to build the scene anyway.
So why doesn't it just build the envelope using the 2010 version? As it
stands now, we'd have to go through our entire inventory of characters
(hundreds) in order to make this improvement useful for us. Real
bummer.


Matt


> -----Original Message-----
> From: softimag...@listproc.autodesk.com
> [mailto:softimag...@listproc.autodesk.com] On Behalf Of
> Simon Pickard
> Sent: Wednesday, September 16, 2009 5:50 PM
> To: soft...@listproc.autodesk.com
> Subject: Re: Approximate envelope deformations.
>

Steven Caron

unread,
Sep 16, 2009, 9:03:13 PM9/16/09
to soft...@listproc.autodesk.com
in my experience this is not true, we have been taking advantage of the speed improvements for many weeks now. all while rigging in 6.5 and animating in 2010.

the optimization is deforming the normal vectors inside the envelope rather then recomputing them each frame. this doesn't require new weights or a new operator.

simon could be experiencing a bug that can be fixed.

steven

Graham D Clark

unread,
Sep 16, 2009, 9:19:02 PM9/16/09
to soft...@listproc.autodesk.com
On Wed, Sep 16, 2009 at 5:58 PM, Matt Lind <ml...@carbinestudios.com> wrote:
yeah, but the $64,000 question that's burning in my head is why we have
to delete the existing envelope and rebuild it ourselves to get the
improvement?

If we're loading data from a file, XSI has to build the scene anyway.
 
AFAIK XSI save is a binary dump of its state, and so load is not a complete scene builder like Maya ma or the XSI XML scn system we built that made scenes often way smaller.
 Luc-Eric or other may correct me here... 
--
Graham D Clark, telephone: fad-take-two,
http://www.linkedin.com/in/grahamclark | http://www.xsibase.com/articles.php?detail=117

Simon Pickard

unread,
Sep 16, 2009, 9:33:12 PM9/16/09
to soft...@listproc.autodesk.com
Yeah to be honest my test might not be the best case for anything.
It's a rig that has been moved through many versions of Xsi so could
have all kinds of baggage. :)


2009/9/17 Steven Caron <car...@gmail.com>:

Matt Lind

unread,
Sep 16, 2009, 9:59:40 PM9/16/09
to ma...@simonpickard.co.uk, soft...@listproc.autodesk.com
Actually it's a great test case because it's the norm for long term
projects like feature films and online games such as MMOs.

We have stuff dragged through versions of XSI dating back to v3.5
(albeit those cases are rare). The majority of our stuff was saved in
XSI 6.01 which had a laundry list of issues. We've had a lot of
problems getting XSI 6.01 data into XSI 7.x thus far.

This is an area where I'd like to see improvement moving forward as it
seems like we always have to retrofit content coming from previous
versions of XSI which is a real time consuming task that shouldn't be.
We've got a gigantic asset catalog and can't afford to run through the
entire inventory of assets each time we upgrade to get them up to date.
We like to upgrade to newer versions of XSI to get the new features and
bug fixes, but there's something to be said about having a smooth
upgrade path. At some point upgrading becomes a penalty, not a benefit.

Matt Lind

unread,
Sep 16, 2009, 10:08:58 PM9/16/09
to soft...@listproc.autodesk.com
Maybe it explains why we've had so many problems upgrading....and probably confirms I'll have to come up with some batch processing system to update our content to take advantage of whatever improvements are coming in SI 2010 (ugh).
 
I can see why saving a state of the scene may be more efficient in load/save.  But when a particular version of the software is saving data improperly and corrupting it (XSI 6.01, for example), it sets up so many problems for whatever version has to inherit that state.  As we've experienced, properly working versions trying to import this data just go kaboom without much recourse to salvage data.  This forces us to keep the older software licenses running just to access our data, which further becomes a burden in keeping tools/plugins compatible for use as our plugin environment is very dynamic.  I've been investing a lot of my free time trying to come up with a generic file format to load/save our data to get around this very problem.  not fun.
 
Matt
 
 
 


From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Graham D Clark
Sent: Wednesday, September 16, 2009 6:19 PM

To: soft...@listproc.autodesk.com
Subject: Re: Approximate envelope deformations.

Raffaele Fragapane

unread,
Sep 16, 2009, 10:18:36 PM9/16/09
to soft...@listproc.autodesk.com
Actually if you have a half decent pipeline your assets will be built and reassembled dynamically and you won't be moving scenes around :)

Graham D Clark

unread,
Sep 16, 2009, 10:26:47 PM9/16/09
to soft...@listproc.autodesk.com
Guessing thats what hes already doing in his "free time"
Not everyone has that time

Joe Williamsen

unread,
Sep 16, 2009, 10:43:56 PM9/16/09
to soft...@listproc.autodesk.com
Hi Luc-Eric,

That worked!  I had to go back down to OpenGL 1.4, but the selection lag is gone and I've not seen any hit in performance.  I think sub-d's are a little slower than before, but that's just a subjective observation.

Two questions:  Did previous versions of SI just default to 1.4 (because I've never seen the problems I was having)?  - What is lost by going back to V1.4? - i.e. are there performance gains to be had with OpenGL 2.1?

Thanks again for the help :)

Joe Williamsen

unread,
Sep 16, 2009, 10:52:27 PM9/16/09
to mailgrah...@gmail.com, soft...@listproc.autodesk.com
Pardon my ignorance, but shouldn't merging a scene into a new one "rebuild" everything that's being merged in - or does that not happen in SI?

Matt Lind

unread,
Sep 16, 2009, 11:07:20 PM9/16/09
to soft...@listproc.autodesk.com
I never understood the logic of this workflow.  Why should you merge a scene to fix it?  In my experience it's only caused more problems.
 
When you smack the fender of your car, do you merge it with a another car to rebuild it?  No, you replace the broken parts.  I use the old SI3D remedy of duplicating the object without history because it forces XSI to evaluate the mesh and build it properly through all it's mesh validation and whatever else is under the hood.  Then again, it might not, but I've had more success with this than merging.
 
Matt
 
 


From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Joe Williamsen
Sent: Wednesday, September 16, 2009 7:52 PM
To: mailgrah...@gmail.com; soft...@listproc.autodesk.com

Subject: Re: Approximate envelope deformations.

Luc-Eric Rousseau

unread,
Sep 16, 2009, 11:11:39 PM9/16/09
to soft...@listproc.autodesk.com
Models, loading scenes, merging.. it's all the same thing. It's just
branches or leaves instead of whole trees. In any case, this is a rat
hole.
We'd need to look at the reason why the user didn't get the
performance boost. The approx optimization kicks short-circuits
evaluation depending on a number of conditions. By re-applying the
operator, any number of things might have changed.

Joe Williamsen

unread,
Sep 16, 2009, 11:25:00 PM9/16/09
to soft...@listproc.autodesk.com
I've also used duplicate without history - that's usually what I'll try first - but it doesn't always work.  Maya, especially, leaves a TON of hidden trash in it's scenes, and merging is often the only way that I know of to get it to re-evaluate the scene and discard what it doesn't need.

I'm only mentioning merging because it sometimes *works* - not so much in XSI, but in some other applications I've used merging can make a non-functional scene into a working scene again, and if you don't have time to disassemble every piece of your scene to try to figure out exactly what's going wrong and which tiny piece might have become corrupted, it can get you up and running again.  Is it the perfect solution? No.  Does it get you back in the game, sometimes, yes - and if you're trying to meet a deadline it can be a lifesaver.

Bradley Gabe

unread,
Sep 16, 2009, 11:34:10 PM9/16/09
to soft...@listproc.autodesk.com
Models, loading scenes, merging.. it's all the same thing. It's just
branches or leaves instead of whole trees.  
 
 
In any case, this is a rat
hole.
 
 
<OT>
This list has been an amazing educational source for multicultural information over the years. I had to look up the "rat hole" idiom to see if it's different in British English, or derived from French. In American English, one would use the term "rat hole" to describe a location, such as a filthy motel or very low-grade restaurant, the kind of place you'd prefer were nice and clean. "Don't eat at that diner, it's a rathole!" I had to check because it just seemed out of place.
 
According to a site on British idioms:
[from the English idiom “down a rathole” for a waste of money or time] A technical subject that is known to be able to absorb infinite amounts of discussion time without more than an infinitesimal probability of arrival at a conclusion or consensus.
 
The idiom an American might use to describe this situation is "red herring", as in "We could argue about this for hours but it's a red herring."  I would imagine if that idiom is foreign to someone else, it would sound pretty silly as well.
</OT>

Bradley Gabe

unread,
Sep 16, 2009, 11:44:46 PM9/16/09
to soft...@listproc.autodesk.com
Merging works nicely in XSI to fix certain classes of problems. I've seen many times in a production where a scene that had been stable suddenly becomes unstable. If the unknown issue has anything to do with the scene cameras or display settings (and quite often it does), then merging into a new scene is all it takes to repair the problem, and stability returns without a further hitch. This technique goes all the way back to si3d, incidentally.
 
If the merge technique doesn't fix the issue, then the problem is likely unrelated to cameras and display. Then we move to the next step of rebuilding components. In my experience at Janimation so far, the merge technique has repaired the instability more often than not. I've had very few scenes that have required rebuilding, and those that did were caused by issues of reference models overlapping with animation layers.
 
I'm not going to argue that this will be everyone's experience, I'm sure stability issues vary widely from one pipeline to the next based on a particular mix and match of addons, customization, and production particulars. But I will say it is worth a shot, and one to take pretty early on the road to recovery.

Luc-Eric Rousseau

unread,
Sep 17, 2009, 12:16:55 AM9/17/09
to soft...@listproc.autodesk.com
My apologies, I should not have used that expression. "going down a
rat holes" is used in some Americain tech company to describe what
happens in meeting when the conversion veers off into debating in
depth a side detail. For example you could have two programmers
debate for 15 minutes an implementation detail in a meeting about the
schedule. A managers can declare "Rathole!" to get the conversation
back onto the agenda. They were doing this at Avid.

Bradley Gabe

unread,
Sep 17, 2009, 12:30:55 AM9/17/09
to soft...@listproc.autodesk.com
Don't apologize, it's a useful idiom. Every now and then languages cross, and you get fun distortions in translation. This was one of them, for me at least. :-)
 
Sorry for the OT, back to the rathole!

Luc-Eric Rousseau

unread,
Sep 17, 2009, 2:01:56 PM9/17/09
to soft...@listproc.autodesk.com
I don't have details of the changes to the display pipeline. The best
thing you should do is make sure you're running the latest driver from
ATI. I don't think we have problems with our ATIs.. but we all mostly
running nVidia Quadros

--
Luc-Eric Rousseau
Autodesk Softimage Team Leader

Joe Williamsen

unread,
Sep 17, 2009, 3:04:48 PM9/17/09
to soft...@listproc.autodesk.com
I am running the latest - I downloaded them yesterday to see if they would fix it (no joy).

Interesting thing, though: I don't see the lag under XP 32 with *exactly* the same card (different machine) - just under XP64 - so I guess it has something to do with ATI's XP64 driver. 

I also didn't see the lag on any models that were created/enveloped in 2010 - just "older" models.

I also tried an old ATI 1950XTX running under Win7 64-bit using a Vista driver that I had to manually install - it seems to work fine - no appreciable lag.   

At this point, it seems to be a fairly isolated case... which is good to know :)  At least the environment variable took care of it - Thanks again for that :)

Brent McPherson

unread,
Sep 30, 2009, 8:42:22 AM9/30/09
to soft...@listproc.autodesk.com
A quick update for those of you who have seen the problem below...

I looked at the scene that Joe kindly provided and the affected points have weights that are not normalized. (i.e. sum of weights is not 100)

Opening up the weight editor with the mesh points selected will highlight the weights in red. (and there is an error message that will show up if the first column is widened)

The difference arises because the approx op is expecting normalized weights while the regular operator is more forgiving. The solution is to fix the bad weights. Ideally we would like to know how the weights became non-normalized but modifying the approx op is another possibility depending on the severity of this problem.

Thanks.
--
Brent

From: Brent McPherson
Sent: Wednesday, September 16, 2009 10:27 AM
To: soft...@listproc.autodesk.com
Subject: RE: Approximate envelope deformations.

Joe,

Are you able to log this?

If not you can email me the scene privately and I will log it for you since this doesn't look right.

Thanks.
--
Brent

From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Joe Williamsen
Sent: Wednesday, September 16, 2009 3:57 AM
To: soft...@listproc.autodesk.com
Subject: Re: Approximate envelope deformations.

No, not lagging - points in the wrong place:

[cid:image0...@01CA41D3.D6870C00]

It's not a huge deal - as long as it renders OK and I can fix it by shutting it off, I'm good with that - but it DID freak me out at first because I couldn't figure out what the hell was going on. If all this discussion of the feature hadn't been going on, I don't know if or when I would have figured it out - so for that, I'm grateful ;)


Steven Caron wrote:
errant points? like lagging behind? we haven't experienced this at all...

s
On Tue, Sep 15, 2009 at 7:34 PM, Joe Williamsen <j...@joewilliamsen.com<mailto:j...@joewilliamsen.com>> wrote:
I'm seeing an almost 3X frame rate increase when it's turned on (40fps to 112 fps), but I'm also seeing a few errant points - i.e. the mesh can look messed up in places with the approximation turned on, but it's OK if it's turned off, or if you render. A little disconcerting, but if you're just wanting to scrub through the animation, I think it's going to be pretty useful (spoken by someone who's only played with the feature for about 20 minutes).

Simon Pickard wrote:

Yep I've got that here as well, but not seeing any differences really.

When you say it "works" have you tried toggling it off and on? What

differences in speed are you seeing when you change this setting?

2009/9/16 Malcolm Zaloon <mzal...@gmail.com><mailto:mzal...@gmail.com>:

it´s automatic if your envelope is in top of all other operations, and not

in modeling.

here works, and is Very very fasssst! (1.2 milion polys enveloped object

playing at 25fps!)

Thanks SI team!

On Tue, Sep 15, 2009 at 5:38 PM, Grahame Fuller

<Grahame...@autodesk.com><mailto:Grahame...@autodesk.com> wrote:

Are you displaying a shaded view? Otherwise the normals aren't being

calculated either way.

gray

-----Original Message-----

From: softimag...@listproc.autodesk.com<mailto:softimag...@listproc.autodesk.com>

[mailto:softimag...@listproc.autodesk.com] On Behalf Of Simon Pickard

Sent: Tuesday, September 15, 2009 08:59 AM

To: soft...@listproc.autodesk.com<mailto:soft...@listproc.autodesk.com>

Subject: Approximate envelope deformations.

Hello all,

Just having a play with the trial of 2010 (32bit, vista).

Trying to get this new "Approximate envelope deformations" thing

working? I've got a simple rig that meets the conditions in the user

help but when I toggle the setting in prefs->display I can't see any

difference in playback.

Is there something else I'm meant to be doing to see this gain?

Regards,

Simon

--

__________________

Malcolm Zaloon - Lighting TD - XSI Generalist


________________________________
Autodesk Limited
Registered Office: 1 Meadow Gate Avenue, Farnborough, Hampshire GU14 6FG
Registered in England and Wales, No. 1839239

image001.jpg

Joe Williamsen

unread,
Sep 30, 2009, 11:40:46 AM9/30/09
to soft...@listproc.autodesk.com
Thanks for figuring it out, Brent. As my Dad can attest to, if you ever
want something broken, or, forced to work in a way it's not supposed to
work, give it to me - lol.

> it愀 automatic if your envelope is in top of all other operations, and not

Brent McPherson

unread,
Sep 30, 2009, 12:21:42 PM9/30/09
to soft...@listproc.autodesk.com
The good news is it is actually a bug in the approx envelope op and it should be handling the weights the same as the regular envelope op.

In the meantime Alan's suggestion of smoothing with a large brush radius and an opacity of 0.001 is a great way to re-normalize your weights. ;-)

Thanks.
--
Brent

> it´s automatic if your envelope is in top of all other operations, and not

winmail.dat
Reply all
Reply to author
Forward
0 new messages