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