Particle Playground in RAM preview

[R***@adobeforums.com]

Using AE CS3 I've built a sequence involving the explosion effect of Particle Playground. I adjusted the Velocity Dispersion parameter to get a good expansion rate for the particles, using RAM preview at 50 percent resolutiion as a test bed. To my surprise, when I rendered the project, the particles flew at many time the rate seen in RAM preview. Any ideas as to why this happened or how to get the RAM preview to faithfully reflect the real render?

[M***@adobeforums.com]

Never preview at half res, I suppose. ;-) The issue you are probably facing is, that when doing such stuff at half res, you effectively make the plug-in work on a quarter of the pixels (assuming you refer to the layer exploder) which can look drastically different. likewise, sampling of layer maps will be based on the reduced resolution, resulting in different values. I really do think only full res previews will ever give a proper, predictable result.

Mylenium

[T***@adobeforums.com]

tough, not having the ability working at half res with correct preview is a thing that has to be considered from the developers very well.
most effects are impossible to render-preview in full, impossible!

[R***@adobeforums.com]

I did some experimentation which confirms Mylenium's analysis. I am using layer exploder with subsequent particle behavior determined by the Velocity Dispersion and some interparticle Repel. Both the Velocity Dispersion and the Repel Force Radius are dimensioned in pixels, so when you lower resolution, pixels get bigger as a fractiion of screen size and the effects change. Dispersion Velocity is faster and the Repel force extends over a wider range giving even more dispersal. I have enough RAM that I can preview the critical frames at full-res. But Thomas is right, AE should be fixed so that when previewing at lower res effects with parameters dimensioned in pixels are adjusted so their effect is the same as measured in fractions of screen width. I think a linear scaling based on the resolution reduction should do it.

[M***@adobeforums.com]

Hehe, technically nothing needs to be fixed, but of course it would be desirable to work in relative sizes/ units in such cases (and several others). On that I can agree. ;-)

Mylenium

[T***@adobeforums.com]

desirable???

it's essential!!

so, what do you mean by "technically nothing needs to be fixed"?

what you are exactly talking about?

[R***@adobeforums.com]

I agree with Thomas. When RAM preview gives results at odds with the production render for a known and correctable reason, it "needs to be fixed". The alternative of warning the user is lousy. The alternative of doing nothing is a signal the company places low priority on this product.

I've submitted a bug report / feature request on this issue.

[T***@adobeforums.com]

a signal the company places low priority on this product

thank you Richard. Now all my thoughts about CS4 make sense.

I'm a motion graphics designer and i rarely have do work in photoshop but strangely some certain power lead me to be highly concentrated on every corner of photoshop development in the last couple of months (lets say 12).

that's sad, because Ae still feels to me working with version 7.

sorry folks...

[M***@adobeforums.com]

desirable??? it's essential!! so, what do you mean by "technically nothing
needs to be fixed"




Not really. Working with relative units has disadvantages, too (think of the million people whose brain will explode when suddenly they have to set positions or item sizes in fractions of percent...). And technically nothing needs to be fixed - the current behavior is correct in terms of the underlying math and predictable by the user, the only real problem is that Adobe does a pretty poor job of communicating it to the user. If you get my meaning - you will want to work at reduced resolutions all the time to speed up interactivity, but you usually do not want it to make your work less predictable. They are still two different things, though. One could also argue that the flaw is simply in the effect/ plug-in. By all means, within the ranks of the AE API (as I understand it), it could just as well request the full resolution buffer, but then again, I don't know enough of that nor do I know anything about the licensing stuff that futzing with the code may touch upon, as apparently the effect originated outside Adobe a long time ago...

Mylenium

[T***@adobeforums.com]

:( Thanks for the attempt to explain Mylenium.

[R***@adobeforums.com]

Mylenium - Either you or I are missing the point. In my view there need not be any change in how a user would input parameters into an effect. For example, Force Radius would still be entered as a number measured in pixels, not a percent of screen size. The change would be "behind the scenes". If Ae was asked to do a RAM preview at half-resolution, for example, for that preview it would multiple the number in original pixels by two to get the number of 2x pixels which gives the same fraction of screen size. My experiments show hat this would give the same (or very nearly the same) behavior in the preview as will be seen in the final rendering. The same behind-the-scenes temporary conversion must be made in speeds expressed as pixels per frame or any other parameter with pixel dimensions. This is just a matter of the RAM preview engine knowing which effect parameters are dimensioned in pixels and what resolution it is being asked to use - both easily knowable. Again, the parameter values entered by the user would be unchanged. No need for relative units as far as the user is concerned.
I agree that the current behavior does what the coders intended, but giving misleading previews is a serious weakness if fixing it has no negative side effects. I do not agree that if Adobe warns users of this weakness, all is hunk-dory.
Am I missing something?

[M***@adobeforums.com]

Mylenium - Either you or I are missing the point.




No, actually not. We are both right and both helpless in changing the matter. ;-) You are both not considering, that AE's internal measure is pixels. It has no such thing as an abstract "world unit" as one can setup in 3D programs. Therefore, any physics are based either on absolute pixels or percentages of those pixels, at best quantized to the sub-pixel precision grid and that is dependent on the comp resolution/ size. For "predictable" behavior independent of the resolution, you would basically have to treat everything as a procedural 3D item, so the sampling is based on testing the 3D intersection, e.g. with a procedurally defined ramp "texture".... It's really more complex than it looks on first sight, so for the time being, we will probably have to live with these limitations.

Mylenium

[T***@adobeforums.com]

we will probably have to live with these limitations.




no we don't.

[M***@adobeforums.com]

Why am I not surprised about your answer? 8-O

Mylenium

[T***@adobeforums.com]

coz you're an old stager in this biz :P

[A***@adobeforums.com]

The limitations with Particle Playground have existed since it's arrival in AE - version 5 0r 6, I think. It has always been a rather cumbersome and hard to use tool, in my opinion. It's always struck me as slightly experimental.

There are, of course, other particle generators within AE, including CC Particle World. But personally, Trapcode Particular is the third party plugin I use more than any other - it is quite simply the most useful plugin I've ever bought for AE, and worth every cent.

[T***@adobeforums.com]

Trapcode Particular is the third party plugin I use more than any other
- it is quite simply the most useful plugin I've ever bought for AE,




and worth every cent.

if you have the dime, everything will be fine...

just a note for the guys from the dev-team who probably may stumble over this thread: i'm not paying for Ae using it on a "experimental basis".
There are two presumptions: you are not capable of properly coding or lets say, having your software-development under control, or you are simply NOT WILLED to take a look into your code to see what else can be managed because you're so distracted by having this app work in somewhat future of Apples somewhat architecture?

i'm in serious anger with Ae every day using it. i don't think i need a higher degree in mathematics just to be able to control a pretty self-explanatory software. if software lacks in usability thus lacking in performance, why someone should spend any future dime on it?

I believe it has all to do with bureaucracy and fund, just to enhance a software systematically from version to version, not pushing the features at once whilst having in the top drawer since ages.

it's pure business. it has nothing to do with customer satisfaction nor with customer experience.

though, this forums and all it's peoples input from all aspects did had an impact on development. without it, we still would stuck in the middle 90ies.

Thanks for sharing.

personally i got tired of all this technical drawbacks. it caused me a lot of damage to my health, non billable hours and suffering in my
profession as a digital artist which i've started with pure passion.

I will quit my job and start doing something that makes really sense to me and my fellow men rather than hanging around for days/nights in front of a screen filled with problems.

I release myself from this forum. i wish you all good luck for the future and keep pounding.

cheers,
Thomas

[A***@adobeforums.com]

Richard: Would you like to send a project in which this behavior is really evident? No need for source files or anything like that.
If you would, this is my address: ***@adolforozenfeld.com

Adolfo Rozenfeld - Adobe

[R***@adobeforums.com]

A reply by direct email was sent to Aldolfo enclosing the project file which generated the original post of this thread.