[tom]

no i noticed that if you're rendering with maxwell, your life is getting shorter...
at least with the actual version

[hdesbois]

For example, now we must say 10 sec of anim shot at 1/25 shutter.

That's what we are doing already, aren't we?
When you set up a scene in your animation package, and change your mind about fps, your keys get rescaled, but the total time doesn't change. Even if you use frames as a reference, the only thing taken in account for calculation is time (at least that's LW way, but I guess this is the same with other apps, kind of logical). I suppose Maxwell does read the time information from the package's plugin, and the fps, and the shutter speed.
The problem now, if you try to do a motion blur with Maxwell corresponding to a 2 second shutter speed in an animation set at 25 fps, for given frame Maxwell calculates MB by taking current frame, current frame - 50 (for the 2 seconds@25 fps), and interpolates between the two. It should rather take current frame, current frame - 50, all frames between these two, and interpolate inter frame motion. And yes, the interframe sampling must be more than two to give good results.
HD

[tom]

yes this is what i'm also talking about....
but i'm afraid it's not taking care of the application's fps setting so the time...
what did you do there... you calculated the seconds with fps and had 50 frames for 2 secs @ 25 fps...
but if the plugin is not telling the application's fps to mxcl then it must be telling a constant number.
this is what i am curious about...

[tom]

i suppose it's not taking care of fps in the application setting because then the resulting motion blur must be changed when not resizing animation while changing fps.

[hdesbois]

At least, the SDK allow for separate fps and shutter speed reading, along with a few other interesting parameters :

createCamera(
dword nCameras, // num of cameras ( >1 camera Motion Blur )
real shutter, // aperture time (1/60 sec)
real filmWidth, // film width (0.036)
real filmHeight, // film height (0.024)
real iso, // iso (100.0)
const *char diaphragmType, // diaphragm type {“CIRCULAR”, “POLYGONAL”}
real angle, // if polygonal, angle (0-365º)
dword nBlades, // if polygonal, number of blades
dword fps, // frames per second
dword xRes, // screen xres
dword yRes, // screen yres
real pixelAspect ); // píxel aspect ratio (1.0 for square pixels)

If think it' working now, and that the problem is mainly with interpolation method.
HD

[tom]

thank you hdesbois, i understand very well but i'm still not sure about maxll
let me make some sort of tests and see if it's working for real...

[Julien Confalonierie]

Ok i've made some tests:

-A ball animated along a one meter path (from x=-0,5 to x=0,5) and from key 0 to key 50 at 50 fps for a total frame of 100, a maxwell camera with a shutter speed of 1 sec. Result, a straight line from -0,5 to 0,5.

-Same animation but with fps set to 25 and the same total frames (100) so that there are the same number of frames for the animation of the ball ( which duration is now 1/2 sec), same parameters for the camera (SS=1 sec). Result, a straight line from -0,5 to 0.

Conclusion, maxwell take into account the fps.

So that was what I was saying, for Maxwell, fps is taken for the relation between time and distance of the animated objects, motion blur and his subframes interpolation is calculated only based on the shutter speed which is considered by maxwell as only 1 frame.

Perhaps tom, I'm missing something you are looking for, but for me it's quite simple.

[DELETED]

DELETED

[JDHill]

[DELETED]

DELETED

[Frances]

I saw Elvis at Be-Lo.

[Hervé]

hey Betty.... incroyable... welcome back..

[rivoli]

guess who's back..

[Hervé]

Buffos....

[hdesbois]

A one year old thread resurecting, 8etty coming back... I can read the signs, something is about to happen.
HD