Hi,

Seeing the latest mechsim animations I just could not resist
and made a domino sequence without using the mech-sim patch.

Although I admire the funny cartoonesk way the spring powered blocks
behave and I cannot even imagine how much it took to program this into
a raytracer (a great job !!), I think this is not a good solution for
doing mechnical simulations.

You can do these kind of things much faster, more accurate and without
the risk of crashing your raytracer with external modellers and
simulators. 

But the main reason for me is speed and reliability,
because I am lazy : I made this in 5 minutes with Xaero 
and it took another 5 minutes to trace 140 frames at 640x480 A0.3
and to compile a movie.

Mechanical simulators can be found at:
www.q12.org : ODE  Status: Alive and active
http://www.aero-simulation.de/ Status: Dead ??

Willem

Post a reply to this message

Post a reply to this message

Attachments:
Download 'dom_mjpeg_320.m1v.mpg' (775 KB)

Post a reply to this message

Attachments:
Download 'dom_mjpeg_320.m1v.mpg' (462 KB) Download 'domstack2.world.txt' (8 KB)

Why does the pyramid of dominos seem to take a breath at the beginning?

-DJ

Post a reply to this message

>Why does the pyramid of dominos seem to take a breath at the beginning?
>
>-DJ

Because it is afraid of what is coming...
  or
My fault, I probably did not stack all the dominos at the correct
position, so they fall to their correct position, or are pushed up by
the modeller if the two blocks are overlapping
Willem

Post a reply to this message

Looks nice, but if it's not done with POV, I doubt it's faster and more
flexible. Only if you don't need POV's features!

I see the link you gave to the "ODE" is freeware and that's very nice, but
worlds in POV-Ray are rarely made of polygons and therefore can't be
exported to other programs. A POV-Ray user usually tries to visualise things
in his head, and then write the code. This is entirely different from
actually seeing the visualisation and trying to understand what's going on.

Generally, it's not easier for me to switch between several programs.. It
complicates the process a lot.. I think the mechsim in POV-Ray is going to
be a key feature in the future.. However, if the "ODE" is really free maybe
it's features could be ported to POV.


Regards,
Hugo

Post a reply to this message

On Mon, 10 Feb 2003 14:38:44 +0100, Christoph Hormann
<chr### [at] gmxde> wrote:



> I cannot even imagine how much it took to program this into
> a raytracer (a great job !!),
I mean this, a complement well deserved.

>Feel free to think whatever you want to think but i see no argument in
>your writing that would support this extremely general statement.
Ok, might be too general, see more nuance below

>> You can do these kind of things much faster, more accurate and without
>> the risk of crashing your raytracer with external modellers and
>> simulators.
>
>This strongly indicates that you don't really know what you are talking
>about.  
Statements like this will not really engage people in a
discussion..... Plenty of managers in high tech company's pay loads of
money to send their engineers to courses in order to train them not to
make this kind of statements. Trust me on this.

>First of all the mechsim patch is not any more likely to crash
>POV-Ray than any other experimental feature.  
True, but I am not comparing with other POV features, I am comparing
with mechanical simulation systems which have, as you know, lots of
mathematical appoximations and in this case "spring & damper" systems
which are inherently unstable when used without extreme caution.
These should not be part of a renderer which should just render any
datafile whe feed it.

>And then i have serious
>doubts that Aero is substantially faster or more accurate simulating the
>same system than the mechsim patch.
From an end-user perspective it certainly was :), it really took
me just a couple of minutes. You give the reason below; I did have the
need the build objects from point masses and to apply the "correct"
stiffness factors. Wooden domino blocks do not bend or deform
when they fall. That is what triggered me in the first place.

Could we compare ? i.e. create a sample scene, a sort of a skyvase
for mechsim and compare on speed an accuracy ? See where the limits
are ?

>What probably makes Aero more appealing to you is the ability to simulate
>the movement of a few basic shapes like boxes and cylinders without the
>necessity to build them from  point masses like in mechsim.  
Look what it is used for by the other users; they use it for modelling
the behaviour of in-flexible masses, like domino blocks, or balls
falling down a wall filled with obstacles.  

Yes I like the simplification approach. Simulation simplified models
correctly gives i.m.h.o. better results than larger, unstable, models.
But maybe recent models and CPU power are catching up on me.

>have a look at the Aero documentation you will recognize that there is a
>serious number of tricks necessary to make this work.  This might produce
>reasonable results for falling domino stones but will break into pieces as
>soon as you try a simulation of more complex shapes and deformable bodies.
I know the limitations of aero and the tricks. Deformable bodies are
the holy grail of course. Can you do this ?  Can you make a cube which
falls on a corner and actually deforms permanently ?



>BTW animations posted in several pieces will be difficult to view for a
>lot of people.  
>Christoph

Post a reply to this message

> These should not be part of a renderer which should
> just render any datafile whe feed it.

In other words, we could remove half of POV-Ray because it's not very
useful? On the other hand, this is what makes POV-Ray unique.

I predict that in 10 years, Hollywood will use POV-Ray to model and raytrace
everything in their films. The studios will even use it to make coffee.
Moreover, it will replace ICQ and people will communicate through POV-Ray.
The operating system on most computers will be POV based.. well you get the
idea.. ;o)  It might be overdriven but POV-Ray is not just a raytracer. It's
already being developed as a programming language, and no experiments are
really useless. It will be interesting to see where the mechsim will go.

But thanks for your input. Of course there will be different opinions, and
we can probably learn something from everyone.

Regards,
Hugo

Post a reply to this message

>But thanks for your input. Of course there will be different opinions, and
>we can probably learn something from everyone.

That why they are opinions :)

Just one example: MsWord used to fit on a couple of floppies.....
It has much more functionality now, but is it better ?

Willem

Post a reply to this message

On Mon, 10 Feb 2003 16:45:37 +0100, Willem
<willem_dot_de_dot_wilde_at_xs4all.nl> wrote:
> Just one example: MsWord used to fit on a couple of floppies.....
> It has much more functionality now, but is it better ?

Actually MegaPOV 1.0 for DOS fits perfectly on one 1,44 floppy :-)
http://megapov.inetart.net/download.html

ABX

Post a reply to this message

>Actually MegaPOV 1.0 for DOS fits perfectly on one 1,44 floppy :-)
>http://megapov.inetart.net/download.html

Ouch. I give up, MegaPov was great and a welcome addition
at the time.

Post a reply to this message

Willem wrote:
> 
> > I cannot even imagine how much it took to program this into
> > a raytracer (a great job !!),
> I mean this, a complement well deserved.

I read this but to be frank - how can you know it is a great job if you
did not actually use it.

> These should not be part of a renderer which should just render any
> datafile whe feed it.

I am not going to discuss the decision to integrate mechsim into POV-Ray. 
If you don't understand the extremely obvious reasons for this you should
probably  either use POV-Ray more intensively or have a look at the
mechsim source.

I don't want to sound selfish so again, if you prefer to use a different
tool i am the last one preventing you from doing so but your arguments are
rather weak.

> Could we compare ? i.e. create a sample scene, a sort of a skyvase
> for mechsim and compare on speed an accuracy ? See where the limits
> are ?

That's a great idea - just take one of the sample scenes.  'bar.pov' and
'tshirt.pov' are good test cases for this.  The 'tutorial06.pov' scene
from the tutorial would be worth trying too.  Good luck!

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

I only see 473 kb of this:
M/^]/^]/^\11S_O3_O3_O3_O$4<_[T_[T_[T_[Q%!#/^_7S^;Q_%T_[]?/YO'
M\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^
M_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7
MS^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'
M\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^

Post a reply to this message

if you use Outlook express, highlight both messages, and right click select
combine and decode, you will get both attachments

Kruger

"Apache" <apa### [at] yahoocom> wrote in message
news:3e47de05@news.povray.org...
> I only see 473 kb of this:
> M/^]/^]/^\11S_O3_O3_O3_O$4<_[T_[T_[T_[Q%!#/^_7S^;Q_%T_[]?/YO'
> M\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^
> M_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7
> MS^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'
> M\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^
>
>

Post a reply to this message

>I am not going to discuss the decision to integrate mechsim into POV-Ray. 
>If you don't understand the extremely obvious reasons for this you should
>probably  either use POV-Ray more intensively or have a look at the
>mechsim source.

Hmm, I have looked at the Mechsim source, but that is not where the
answer is. The answer is in the architecture of the software we use.
Look for instance at the Pixar  & ILM world where modelling &
animation is separated from the rendering. This have two advantages,
you can concentrate on the modelling using low(er) quality real-time
output i.e OpenGL and later achieve maximum quality output by batch
rendering the output of the modeller. 

With POV the solution has always been to incorporate all features into
one single appl. I am still interested to know why you decided to
incorporate simulation features into the POV code base as opposed to
writing a separate modeller. I can think of one big advantage which
pleads for incorporation; objects can interact with almost all other
obejcts within POV, whereas with an external modeller they usually
interact only with blocks, ball and planes :(

What happens if somebody invents a beter and faster
rendering/raytracer algorithm ? All our modelling and simulation
tools, hardcoded into povray become worthless ? It feels like a
marriage without the possibility if divorce.
 
>I don't want to sound selfish so again, if you prefer to use a different
>tool i am the last one preventing you from doing so but your arguments are
>rather weak.
>
>> Could we compare ? i.e. create a sample scene, a sort of a skyvase
>> for mechsim and compare on speed an accuracy ? See where the limits
>> are ?
>
>That's a great idea - just take one of the sample scenes.  'bar.pov' and
>'tshirt.pov' are good test cases for this.  The 'tutorial06.pov' scene
>from the tutorial would be worth trying too.  Good luck!

Nice examples. I rendered them already and they are indeed very
interesting. Look for instance at the "chair" example. A object falls
down, land on a "chair" bends and flexes and is later shoved off.
The object is stiff enough to holds it shape, but flexible enough to
bend, yet when pushed sideways it show no friction effects. The same
with the "snake" like behaviour  from the other object which slides
over a block. 

The objects behave like they are made from rubber, rubbed with a lot
of oil. Flexible, reacting on impact, full recovery afterwards (no
deformation) and able to slide over sharp edges without showing
friction effects or little shocks in movements. So they do not appear
"normal" to me. I like the images and animations though, and I found
the series of dominos falling like wet pieces of cake very amusing but
I am unsure whether whe are really simulating natural behaviour ..

As for the challenge of comparison, it would be very hard to model
this behaviuor in another tool, I could try maybe with a series of
boxes connected with lots of springs and dampers, to create a
harmonica effect. But somehow I've got the feeling you have tried this
already and know the answer :)

Happy coding

Post a reply to this message

Sorry for this behaviuor from the times the internet was slow
and postings had to be small in order to reach the newsservers.

Most newsreaders can "join sections"

I'll do a repost if want me to.

W

On Mon, 10 Feb 2003 18:14:44 +0100, "Apache"
<apa### [at] yahoocom> wrote:

>I only see 473 kb of this:
>M/^]/^]/^\11S_O3_O3_O3_O$4<_[T_[T_[T_[Q%!#/^_7S^;Q_%T_[]?/YO'
>M\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^
>M_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7
>MS^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'
>M\73_OU\_F\?Q=/^_7S^;Q_%Q%'/^_7S^;Q_%T_[]?/YO'\73_OU\_F\?Q=/^
>

Post a reply to this message

On Tue, 11 Feb 2003 12:22:36 +0100, Willem
<willem_dot_de_dot_wilde_at_xs4all.nl> wrote:
> Hmm, I have looked at the Mechsim source, but that is not where the
> answer is.

There can be. While I'm not the author of mechsim I can guess a lot of
advantages just from one source becouse there is only _one_ file. Have you
seen parser written in mechsim code? Have you seen io stuff written there?
Separated engine for functions to describe environment dependicies? Everything
this is builded in POV-Ray. If you want to concern of algorithm there is no
need to write whole application with parser, image types support, expression
evaluator etc. Being alone coder and heving POV-Ray sources available is
veeeery comfortable situation. And future users will be comfortable becouse
they use new feature without learning whole new scene description language,
knowing adventages and limitations of other features used around simulation
etc.

> The answer is in the architecture of the software we use.
> Look for instance at the Pixar  & ILM world where modelling &
> animation is separated from the rendering.

Look for instance at Moray & POV-Ray where modelling & animation is separated
from the rendering. IIRC there was a plugin for 3ds to support POV-Ray.
Addition of Mechsim does not limits external modellers usages. Not talking
that writing something for POV-Ray makes it available at once for whole
variety of all supported platforms.

> This have two advantages,
> you can concentrate on the modelling using low(er) quality real-time
> output i.e OpenGL and later achieve maximum quality output by batch
> rendering the output of the modeller. 

see Moray.

> With POV the solution has always been to incorporate all features into
> one single appl.

That's exactly opposite. You have to incorporate only necessary features
becouse whole application background is already written and supported
separately by community.

> I can think of one big advantage which
> pleads for incorporation; objects can interact with almost all other
> obejcts within POV, whereas with an external modeller they usually
> interact only with blocks, ball and planes :(

Also. Using mechsim applied to POV-Ray core you can use the same "tools" to
describe geometry and dependiscies, flow and texturing.

> What happens if somebody invents a beter and faster
> rendering/raytracer algorithm ?

I hope he will share it :-)

> All our modelling and simulation
> tools, hardcoded into povray become worthless ?

Once something is published it is no more worthless :-)

> It feels like a
> marriage without the possibility if divorce.

No. You can apply as many mechanical simulations into POV-Ray as you wish. As
long as it does not use the same keyword for block it can cooperate. Moreover
I can imagine animation where two objects are holded by different engines. You
can even mix mechsim-driven object with objects imported from external
sources.

I suggest to continue discussion at povray.unofficial.patches group.

ABX

Post a reply to this message

> animation is separated from the rendering. This have two
> advantages, you can concentrate on the modelling using
> low(er) quality real-time output i.e OpenGL and later
> achieve maximum quality output by batch rendering the
> output of the modeller.

This is a matter of coding the POV script to deal with 2 situations: A final
render, and test render.. I've begun to do this.. This means that I build
the world so that I can switch between the two modes, with one global
boolean variable.. It doesn't mean that I code 2 variants of every object,
but that I switch off the most cpu intensive tasks, until I want a the final
rendering.

Regards,
Hugo

Post a reply to this message

>I suggest to continue discussion at povray.unofficial.patches group.

Yeah,

No binaries in sight :)

But is fun and educational to discuss these topics

WdW

Post a reply to this message

>This is a matter of coding the POV script to deal with 2 situations: A final
>render, and test render.. I've begun to do this.. This means that I build
>the world so that I can switch between the two modes, with one global
>boolean variable.. It doesn't mean that I code 2 variants of every object,
>but that I switch off the most cpu intensive tasks, until I want a the final
>rendering.

Which leads to question: did you solve the problem or did you
create a work-around ?

I did the same b.t.w. 

WdW

Post a reply to this message

> Which leads to question: did you solve the problem or did you
> create a work-around ?

It's not a work around, but the logical way to work for a coder. I admit
there are situations where I'd like a real time preview that responds to
movements of the mouse, for example. A graphical interface would be very
helpful, sometimes. But so far, that means I would have to switch entirely
to work within a triangle based application, using POV merely as a renderer
(unless I find a better choice, that are easier integrated in that
application), thereby giving up lots of POV facilities... I like to code;
this is usually more fun, and easier for me than working with programs like
3dsmax, rhino, maya, etc..

Regards,
Hugo

Post a reply to this message

I must really say that I like those mechsim's. Also the way it was
implemented by Christoph
is very logical (so far i can understand as a non mathematician).

I see no other or better way to implement it directly in POV-Ray.

The other thing is a diffrent thing:
A separate program. These are clearly two diffrent ideas with diffrent
potential.

However we should not compare apples with oranges. A bultin system has other
advantages (shorter
description-code etc.) and other disadvantages (see below) then an complete
external system.

I've tested all ways supported by POV 3.5/MegaPOV 1.0  (without patching)
and I did not find any way
to render mech sims on "multiple CPU's" at the same time.

So, while writing this posting, I 've distributed  "bar.pov"  to another PC
(using SMPOV)  so I can work here while the 700 frames get rendered on one
CPU. :-)

If we had an Animation-"pre-compiler" (Willem's idea) which would (sounds
phantastic?) output in the same way 700 "static" POV-Scenes, for the
"Mech-Sim" - THEN I could render a lot of them "parallel" on many CPU's or
even render then "in tiles" (each does not work with the current system).

For people with only 1 CPU no Argument, but for those who 'd like to speed
things up, this is a point.

The builtin mechsim-system is fine and is perfect as it is. To make mech
sims that can be rendered parallel, it may be necessary to make other steps
on a higher level and distribute static scenens to the renderer, like Willem
said.

At least so far from what I found out till now. If someone has an idea how
to render these mechsims parallel,
I'd like to hear it.

--Theo
----------------------------------------------------------------------------
---------------------------------
Distributed Network-Rendering or Local SMP-Rendering on all CPU's you have.
With SMPOV und
POV-Ray 3.5. & NEW: Mega-POV 1.0 * Download free at:
http://www.it-berater.org/smpov.htm

Post a reply to this message

I suppose this is not on Christoph's top priority list, but an animation
pre-compiler would be helpful. No doubt that speed will continue to be a big
problem for many years to come. The only solution is multiple CPU's in a
local network, or spread on the Internet. I'm quite sure commercial software
will reach a level of fully supported multi rendering. Currently POV-Ray
misses it. When radiosity doesn't work, I have no benefit in using multiple
computers, and when animation is limited, the method isn't so attractive
either. But whatever solution that might come up now, will be like fixing a
old wheel. The issue probably won't be solved until POV 4, with a new
engine.

By the way... I have 2 computers and I've tried your program some months
ago, but it wouldn't start rendering.. I followed your description, but it's
not clear to me wether both instances of SMPOV should be tied to the same
directory, on only 1 computer.. I tried it, along with having 2 copies of
the entire software (one on each computer) but anyway it didn't start
rendering, after I pressed go and those ... files ... were written..

Sorry, I gave up, but maybe I'll try again sometime.. I support your project
at least by word of mouth, despite the limitations, that are difficult to
overcome.

Best regards,
Hugo

Post a reply to this message

Theo Gottwald * wrote:
> [...]
> At least so far from what I found out till now. If someone has an idea how
> to render these mechsims parallel,

ABX already told you recently that that the sequential nature is an
intrinsic property of such simulations - this is nothing specific to
mechsim.  You will hardly find a program - not even for 10000$ - that
distributes such s simulation on a set of networked computers.  

And it's of course perfectly possible to first calculate the whole
simulation and then do the render in Megapov.  How to do this should be
obvious from the mechsim syntax (save_file/load_file).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Sun, 16 Feb 2003 17:06:34 +0100, "Theo Gottwald *"
<The### [at] t-onlinede> wrote:
> If we had an Animation-"pre-compiler" ...

BTW, If the problem is the time of rendering frame, not the mechsim
precalculation time, there is workaround different than save_file/load_file.
AFAIK mechsim calculations are done before rendering. The workaround is to
decrease rendering time for some frames on some machines. At the end (because
last camera is used) of main script write one additional line:

  #include "remove_frame.inc"

on first machine create "remove_frame.inc" file as:

  #declare Location=10000*x;
  #if(odd(frame_number))
    camera{location Location}
    sphere{Location .1 pigment{rgb 0}finish{ambient 1 diffuse 0}}
  #end

and on second machine create "remove_frame" file as:

  #declare Location=10000*x;
  #if(even(frame_number))
    camera{location Location}
    sphere{Location .1 pigment{rgb 0}finish{ambient 1 diffuse 0}}
  #end

To automate it perhaps it could be good to add some feature to your
application like "use different file for this slot". Of course some
recognition of output should be necessary (easy by hand). Of course it is not
trivial issue since additional sphere (if large) can affect radiosity and some
more complicated frame_number checking can be applied for larger number of
slots/processes controlled by server.

BTW: Since your post does not have binary file and is about unofficial patch
related issue I suggest povray.unofficial.patches group for similiar problems
in the future.

ABX

Post a reply to this message

Theo,

Thanks for your support, but that will not help you in the 
short run !!

The mechsim patch calculates all data on a per-scene basis,
because it needs the input from the previous frames. 

All you need to do is saving all the data sets from each step
and you have made you own animation compiler !!

(Distibuted) rendering is then step number two, but that is easy
acccmplished on linux/unix boxes with a set of scripts.

B.t.w. I go one step deeper, I have found that my decicated rendering
machine, a old BP6 with dual celeron cpu, is actually faster if I
trace multiple scenes at the same time, so I do lots of partial
renderings, which are glued into complete frames later.

Success !!

Willem

Post a reply to this message