I could be wrong, and it could already be supported, but wouldn't it be nice to be able to use gravity and other dynamic properties while rendering movies? I don't know if anyone has thought of this, but it's a nice idea for an upgrade.

--Malcolm

Just to add on to my last message, I just found a python script that should do this at the elysiun forum, but it does not seem to work for windows...

I realize this isn't a complete or elegant solution to dynamics in Blender, but 6 months ago I released a python script for Blender that allows for dynamic motion of objects caused by user defined forces in Blender. It was quite interesting. I'm still kinda working on it.

Strictly speaking, dynamics is an animation feature, and therefore has nothing to do with rendering.

Blender's dynamics for the real-time engine had to be hacked out by NaN due to licensing issues, but preliminary support for ODE has already been checked into the CVS repository! For non-programmers, this means that the real-time engine almost already has physics back.

Once ODE support is fully implemented and merged into the main tree, it will be largely an interface issue to get dynamics into "normal" Blender (i.e. for animation). For this reason, I think now is not a good time to put too much effort into any Python scripts for this.

I certainly think dynamics is a very important feature, and I don't think it will be long before Blender has it supported 100%. Perhaps there will be a new "Dynamics Editor" with (eventual) support for other kinds of Physical animation (fluid dynamics, cloth dynamics, soft-body dynamics ...). If this is done right, it could also be applied to characters to achieve the "Character Dynamics" that was requested in another thread (I think it was on Elysiun, actually..).

So just be patient if you're an artist and be working if you're a programmer! Cheers!

But dynamics was never supported in non-realtime. If you make a particle stream fall with a Z force, that stream will take the same number of FRAMES to fall reguardless of the grav setting or even the framerate. So particle animations have to be completely reworked if you render once in PAL and once in NTSC.

In general the x axis of the IPO's should be in units of time, not frames. You can display both, but if you change framerate, you should have the option of which to keep fixed.

I think this is what he's talking about.

This of course poses serious backwards compatability problems...

Bob

rwenzlaff wrote:

So particle animations have to be completely reworked if you render once in PAL and once in NTSC.

No! the framerate shouldnt affect the amount of frames! It merely takes less time, such as any part of any animation.
Also there is a script on the elysuin forums that supporst windows (i use it at the moment).

Ian

graphicsteam wrote:

rwenzlaff wrote: So particle animations have to be completely reworked if you render once in PAL and once in NTSC. No! the framerate shouldnt affect the amount of frames! It merely takes less time, such as any part of any animation. Also there is a script on the elysuin forums that supporst windows (i use it at the moment). Ian

I know I'm late in replying, but - What?

If I pour a stream of water off a high shelf, it takes x seconds to fall (lets say 3). This means it takes 90 NTSC frames or 75 PAL frames. This is ruled only by the height of the shelf, and the value of gravitational acceleration (t=sqrt(2*h/g)).

However, under Blender's current rules, I set up a particle system up to represent the stream of water that take 90 NTSC frames (3 seconds) to fall. This ends up being independant of the value I enter g or the framerate I select. So the water still takes 90 frames to fall in PAL. But 90 frames of PAL is 3.6 seconds. Is gravity weaker in Europe or something?

I was just saying the way it is. Not that it was correct to do it this way.

Bob

Hi
I have used the "convert the game engine dynamics into an IPO" python script with Windows 98. With a little bit of jigery pockery - the odd angle has to be changed - I have rendered animations with excellent rigid body dynamics.
So it can be done.

rwenzlaff:
If you can turn the gravity animations into IPO's, then you can easily convert PAL to NTSC and vice-versa.

In the animation buttons just change "Map Old" and "Map New" - to convert PAL to NTSC, put 25 for "Map Old" and 30 for "Map New". I think you've got to manually adjust the ending frame though. (it would be OldValue * 30/25)