 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi All:
Here is a little animation I created while testing the Bullet Physics
Playground by Koppi. This tool generated 333 .pov scenes, which I
processed with Regexxer to replace the simple boxes by my own
block-letter objects. Apart from this, and setting up a simple room
environment, all I did was adding some trigonometry to the camera
transformations to get a "not-too-mechanical" movement.
http://www.youtube.com/watch?v=cFWYgB7S7tQ
Criticism is welcome, specially as this is my third animation ever...
--
Jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaime Vives Piqueres <jai### [at] ignorancia org> wrote:
> Here is a little animation I created while testing the Bullet Physics
> Playground by Koppi. This tool generated 333 .pov scenes, which I
> processed with Regexxer to replace the simple boxes by my own
> block-letter objects. Apart from this, and setting up a simple room
> environment, all I did was adding some trigonometry to the camera
> transformations to get a "not-too-mechanical" movement.
> http://www.youtube.com/watch?v=cFWYgB7S7tQ
> Criticism is welcome, specially as this is my third animation ever...
Quite cool, although it does show the still-existing limitations of
physics simulation engines. While the blocks are moving faster and there's
a lot of things going on, it looks realistic; however, when they are almost
still, they do not act naturally because they keep moving slowly, like they
were alive. In real life such blocks would settle rapidly and keep
completely still afterwards.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/09/12 13:27, Warp wrote:
> Quite cool, although it does show the still-existing limitations of
> physics simulation engines. While the blocks are moving faster and
> there's a lot of things going on, it looks realistic; however, when
> they are almost still, they do not act naturally because they keep
> moving slowly, like they were alive. In real life such blocks would
> settle rapidly and keep completely still afterwards.
>
Yes, that's seems at first glance, but I know still very little, and
I'm sure that it can be minimized by using correct values for mass,
friction, etc... I just used the defaults from Koppi's playground. So,
that's next thing to investigate...
--
Jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.09.2012 08:50, schrieb Jaime Vives Piqueres:
>
> Criticism is welcome, specially as this is my third animation ever...
From an longtime moviegoer perspective I would show the tower of blocks
at the beginning *much* longer to create some tension by the viewer on
what might happen - even if he already expects it to fall ;)
As Warp already mentioned the long "aftershock" movement looks
unrealistic but on the other hand I did find the "living blocks" quite
funny.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25/09/12 16:21, Ive wrote:
> From an longtime moviegoer perspective I would show the tower of
> blocks at the beginning *much* longer to create some tension by the
> viewer on what might happen - even if he already expects it to fall
> ;) As Warp already mentioned the long "aftershock" movement looks
> unrealistic but on the other hand I did find the "living blocks"
> quite funny.
Thanks, Ive... I did a new one, addressing the "living blocks" problem
(mitigated a bit by using proper mass, friction and restitution), and
also adding the "tension moment" you suggested. The base simulation is
different too, but this time the "radiosity flickering" seems more
noticeable... I used +HR, but still there is some randomness from frame
to frame. Any ideas?
http://www.youtube.com/watch?v=yjTmB9_mbzY
--
Jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> Thanks, Ive... I did a new one, addressing the "living blocks" problem
> (mitigated a bit by using proper mass, friction and restitution), and
> also adding the "tension moment" you suggested.
Now they somehow behave like they are made of rubber rather than wood.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/09/12 12:11, Warp wrote:
> Now they somehow behave like they are made of rubber rather than
> wood.
>
Perhaps I raised the friction too much, in an attempt to make them
settle soon...
--
Jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.09.2012 08:26, schrieb Jaime Vives Piqueres:
> Thanks, Ive... I did a new one, addressing the "living blocks" problem
> (mitigated a bit by using proper mass, friction and restitution), and
> also adding the "tension moment" you suggested. The base simulation is
> different too, but this time the "radiosity flickering" seems more
> noticeable... I used +HR, but still there is some randomness from frame
> to frame. Any ideas?
+HR doesn't help for frame-to-frame problems, it just makes sure that
the /same/ scene renders identically each time.
There's really only one way around radiosity flicker, and that's
higher-quality radiosity settings. (From my experience with static
scenes, a deeper pretrace often helps a lot.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/09/12 17:11, clipka wrote:
> +HR doesn't help for frame-to-frame problems, it just makes sure
> that the /same/ scene renders identically each time.
Admittedly, I didn't finish reading the description... :(
> There's really only one way around radiosity flicker, and that's
> higher-quality radiosity settings. (From my experience with static
> scenes, a deeper pretrace often helps a lot.)
Oh, no... I was trying to avoid raising the quality, as it renders
already somewhat slow.
But I had a wild idea... I think someone suggested it sometime ago,
but I don't know if anyone ever tested it: saving/loading radiosity from
one frame to frame, by using both +RFI and +RFO for every frame. I just
did a quick test, and the flickering seems much less noticeable... but
perhaps is my imagination: will render the final animation tonight and
report back.
--
Jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 27/09/12 17:11, clipka wrote:
>> +HR doesn't help for frame-to-frame problems, it just makes sure
>> that the /same/ scene renders identically each time.
>
> Admittedly, I didn't finish reading the description... :(
>
>> There's really only one way around radiosity flicker, and that's
>> higher-quality radiosity settings. (From my experience with static
>> scenes, a deeper pretrace often helps a lot.)
>
> Oh, no... I was trying to avoid raising the quality, as it renders
> already somewhat slow.
>
> But I had a wild idea... I think someone suggested it sometime ago,
> but I don't know if anyone ever tested it: saving/loading radiosity from
> one frame to frame, by using both +RFI and +RFO for every frame. I just
> did a quick test, and the flickering seems much less noticeable... but
> perhaps is my imagination: will render the final animation tonight and
> report back.
>
> --
> Jaime
>
>
>
>
I did try that once, but must have badly chosen my animation. It caused
a crash as the radiosity data kept growing to exceede the capacity of my
computer...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
