Well, a point about this is that many rendering software
render in multiple passes, because it would create way too
much overhead if it would be done all in once.

The problem for POV is, this feature would have to be implemented
on a fundamental level. As I see it, alpha_only would have to
switch all textures, image_maps, normals etc etc off, and just
do object-hits, in order to speed things up as is wanted.

But, in this case, I think it would be way too much work to
implement it in POV 3.5. This might be a nifty little feature
for POV 4, but until then, I see it as Thorsten does: there's
no point. POV 3.5 will probably load all image-maps, need
to parse everything as before, and you won't get a significant
speed up that way.


--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

>
> What you suggest is completely pointless.  In effect you do twice the work
> compared to rendering both ships in one image at once. No matter what you
> do it will be slower.
> You should really think about solving your problem with what exists rather
> than trying to invent things you think you need but that won't help you
> (and in this case only hurt you). Doing so will be much more productive
;-)
>
>     Thorsten
>

Post a reply to this message

How about simply rendering even frames in one computer and odd frames
in the other? Or the first half of the animation in one and the latter
half in the other.
  Simple solution and saves post-processing trouble (and disk space).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

I think that you can do something similar already, although in three
steps (maybe the kings of povray abuse and obfuscation can help to do
it in two).
  1. Render spaceship A only (otherwise full scene).
  2. Render spaceship B only (otherwise full scene).
  3. Render a 3-colour picture. One colour for each spaceship and one
     for the background.
Postprocessing to merge the three should be trivial.

You already know how to do the first two steps. For the third
extinguish all light sources and change the textures of the spaceships
and the background to pigment{color ___}finish{ambient 1}.

There is a catch to this idea: The reflection, shadow and radiosity of
spaceship A will not be visible in spaceship B.


If your ships use only a two-dimensional colour space (e.g: They are
shades of grey with red lights), two steps suffice. You can recode
your colours to use only red and green and put depth information into
blue. For merging take the colour with less blue (the pixel that is
nearer to the camera) and undo the colour recoding.


-- 
merge{#local i=-11;#while(i<11)#local
i=i+.1;sphere{<i*(i*i*(.05-i*i*(4e-7*i*i+3e-4))-3)10*sin(i)30>.5}#end
pigment{rgbt 1}interior{media{emission x}}hollow}//  Mark Weyer

Post a reply to this message

Thank you for your usual nasty reply, Thorsten. At least the others gave
useful replies without the sour attitude.

"Thorsten" <nomail@nomail> wrote in message
news:web.3e7653d81663f353f50c5f410@news.povray.org...

> What you suggest is completely pointless.  In effect you do twice the work
> compared to rendering both ships in one image at once. No matter what you
> do it will be slower.
> You should really think about solving your problem with what exists rather
> than trying to invent things you think you need but that won't help you
> (and in this case only hurt you). Doing so will be much more productive
;-)
>
>     Thorsten
>

Post a reply to this message

"Tim Nikias v2.0" <tim### [at] gmxde> wrote in message
news:3e765b30@news.povray.org...
> Well, a point about this is that many rendering software
> render in multiple passes, because it would create way too
> much overhead if it would be done all in once.
>
> The problem for POV is, this feature would have to be implemented
> on a fundamental level. As I see it, alpha_only would have to
> switch all textures, image_maps, normals etc etc off, and just
> do object-hits, in order to speed things up as is wanted.

If this proposed feature existed, I would turn off textures, image_maps,
etc. myself using conditional parsing of the scene file.

>
> But, in this case, I think it would be way too much work to
> implement it in POV 3.5. This might be a nifty little feature
> for POV 4, but until then, I see it as Thorsten does: there's
> no point. POV 3.5 will probably load all image-maps, need
> to parse everything as before, and you won't get a significant
> speed up that way.

Like I said, I would define my objects so that they would only load all the
computationally-intensive stuff if a conditional parsing variable were set
in my scene script.

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e767821@news.povray.org...
>   How about simply rendering even frames in one computer and odd frames
> in the other? Or the first half of the animation in one and the latter
> half in the other.
>   Simple solution and saves post-processing trouble (and disk space).

I assume you are assuming this is for an animation with interlaced frames
(which it isn't). But even if I were doing interlaced, I still don't
understand how that would help... when one spaceship was in front of the
other, wouldn't the spaceships seem to dissolve together every other frame?

Post a reply to this message

"Mark Weyer" <wey### [at] informatikuni-freiburgde> wrote in message
news:3E7### [at] informatikuni-freiburgde...
>
> I think that you can do something similar already, although in three
> steps (maybe the kings of povray abuse and obfuscation can help to do
> it in two).
>   1. Render spaceship A only (otherwise full scene).
>   2. Render spaceship B only (otherwise full scene).
>   3. Render a 3-colour picture. One colour for each spaceship and one
>      for the background.
> Postprocessing to merge the three should be trivial.

I actually tried that already and the anti-aliasing along the edges looked
terrible. Maybe it's a limitation of the photoshop tool (Jasc Paint Shop
Pro), but combining PNG or TGA images using alpha transparency just seems to
give much better results than using a color key.

Post a reply to this message

Well, then there isn't much point to it, is there? After all,
the raytracing has to be done either way, so no matter
how complicated your object is, it will always effect the
rendering time. You'd only save texturing/reflection/
refraction/normal parsing, but not the object itself.

Or is there something I don't get? The only thing you'd might
want would be something like an invisible depth-information
in the image, so that combining images with the program
capable of "seeing" that depth would be possible... It would then
just choose, pending on depth, from which image it would have
to pick a pixel.

The only thing I can think of would be to ask Christoph Hormann if
he could implement such feature into his HCR-Edit, but POV doesn't
write two output-files at once (that might be a nice patch though), so
you'd be stuck with tracing four images instead of just two (each ship)
or just one all along.

--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

Post a reply to this message

Scott Gammans <nos### [at] scottgammansspamisevilcom> wrote:
>  I still don't
> understand how that would help... when one spaceship was in front of the
> other, wouldn't the spaceships seem to dissolve together every other frame?

  What I meant was that you could render the animation in the regular
way, without any tricks (ie all objects present at each frame).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3e775c35@news.povray.org> , "Scott Gammans" 
<nos### [at] scottgammansspamisevilcom> wrote:

> Thank you for your usual nasty reply, Thorsten. At least the others gave
> useful replies without the sour attitude.

Well, you asked if it makes any sense!  And several of the other replies
where incorrect.  Or assume that the textures are what is slowing you down
(which can neither be confirmed nor denied without the actual scene).  In
fact, if the sum of objects makes the whole slower than the two parts, then
your problem is insufficient memory and not POV-Ray.

Anyway, in fact, a bit of simple logical thinking gives you the answer to
your question right away...

Originally you have the following times:
Object Intersection 1 + Texture 1 + Object Intersection 2 + Texture 2
(actually less for textures assuming one object hides the other)

Your current way of rendering both separately gives the following times:
Object Intersection 1 + Texture 1 + Object Intersection 2 + Texture 2

Your suggested feature however will result in the following work being done:
Object Intersection 1 + Texture 1 + Object Intersection 2
Object Intersection 2 + Texture 2 + Object Intersection 1

As you can see, your suggestion will always take longer.  Consequently it
does not make sense.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message