> 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