On 4/1/2009 10:31 PM, Warp wrote:
>    +C already does something like that. It will parse the scene for each
> frame, but it won't render the frame if the image has already been fully
> rendered.

I thought of that response too, but then realized that if you're passing 
frames to different instances of POV then you might have a case of 
instance #1 opening a file for output, instance #2 seeing the file isn't 
finished, and both instances trying to write to it.

Checking, instead, if the file exists before rendering seems a much 
better solution (especially combined with +C, which makes it darn near 
elegant).

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> On 4/1/2009 10:31 PM, Warp wrote:
> >    +C already does something like that. It will parse the scene for each
> > frame, but it won't render the frame if the image has already been fully
> > rendered.

> I thought of that response too, but then realized that if you're passing 
> frames to different instances of POV then you might have a case of 
> instance #1 opening a file for output, instance #2 seeing the file isn't 
> finished, and both instances trying to write to it.

  You are talking about a mutual exclusion problem here.

> Checking, instead, if the file exists before rendering seems a much 
> better solution

  Checking if a file exists and then making a decision about that does not
in itself solve the mutual exclusion problem. What happens if the other
instance gets the turn in between the check and the creation of the file
of the first instance?

-- 
                                                          - Warp

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> I thought of that response too, but then realized that if you're passing
> frames to different instances of POV then you might have a case of
> instance #1 opening a file for output, instance #2 seeing the file isn't
> finished, and both instances trying to write to it.
>
> Checking, instead, if the file exists before rendering seems a much
> better solution (especially combined with +C, which makes it darn near
> elegant).

Actually, I had it happening that two instances were rendering the same frame.
But that doesn't cause errors (on my system). Both instances just render the
same frame, and the instance which finishes last overwrites the file.

The DOS-batch file that I use for rendering first checks if the frame is
present. If not, it creates it (as an empty file), and then it starts Povray.
By instantly creating the frame in the batch file instead of letting Povray
create it, chances are lowered that another DOS-batch file finds that frame
non-existant and starts another Povray instance to render the frame.

This works fine when using just a few instances (eg. 4 instances on a quadcore
system). If each frame takes 1 minute or more to render, it's rare that two
instances are looking for non-existant frame at the same time.

Of course, when using a render farm with hundreds and thousands of instances,
this approach wouldn't be sufficient. Then a platform independant solution
would be to have one process, the master, tell the other povray instances to
render certain frames. A free instance would just tell the master that it's
ready to render, and the master, who keeps track of the frames rendered so far,
would tell the instance which frame to render. Communication could be done by
writing/reading information to/from specific files.

But at the moment, for me it would be really enough just to have an option such
that Povray doesn't rerender existing frames.

Cheers,
Burkhard

Post a reply to this message

Programmable animation.

Currently each frame needs to be completely parsed.  I read somewhere that
support for multiple cameras is available in 3.7, making each camera a frame
with no need to parse the scene again.  But, still this allows no changes, so
perhaps if some OO model could exist for POV-Ray objects, and an event could be
called for each frame, allowing modifications to objects without the need to
reparse the entire scene.  This could especially speed up rendering of
animations that have hi-resolution meshes.

Some way of identifying items would be needed, and the event function.  I don't
know much about the internals to know if #declare could work for this.

circle
{
  <0, 0, 0>, 1

  #declare the_color_map = color_map
  {
    [0 color rgb 0]
    [1 color rgb 1]
  }

  ... // texture, pigment, etc
  color_map { the_color_map }
}


preframe_script
{
// execute after INI preframe command, and after the scene is parsed

// An object model with methods over function calls
#declare c = the_color_map.getitem(0)
the_color_map._setitem(0, c + <0.1, 0.1, 0.1, 0.0, 0.0>)

// or better yet
#declare the_color_map.entries[0].value += <0.1, 0.1, 0.1, 0, 0>


// full control over all aspects of all objects
the_circle.pos
the_circle.radius
the_circle.transforms
the_circle.textures
the_circle.interior



// full control even over the document
#declare new_item = document.create_circle()
#declare new_item.pos = ..
#declare new_item.radius = ...

}

Any object that uses 'the_color_map' would get updated.  If an object wants to
use a map without recreating it, it could get a unique copy, maybe something
like:

cirlce
{
  <0, 2, 0>, 1

  ...
  #declare another_map = color_map { clone(the_color_map) }
  color_map { another_map }

  // During preframe/postframe scripts, changing the_color_map will
  // change all objects that use it, but another_map is a clone of
  // the map and this circles color will not get changed unless
  // another_map is changed
}

One problem is this requires you to first #declare the item to give it a name,
the to use it.  There could exist a way to #declare it with a given name and
use it at the same time.

Post a reply to this message

re. DOM, features, parsing.

There are a number of scenarios where I've wished for scenario testing, e.g. to
see if an object fits in a space, one could do ray-tracing in the SDL on the
scene as it is being built, but what we can't do NOW is put an object in, do
some processing, then remove the object from the scene if we don't want it.

I think this type of 'spatial awareness', along with some functions to compute
overlapping (whether directly, or via bounds of computed intersections), would
go a long way for people who generate scenes procedurally.

Post a reply to this message

On 4/8/2009 7:54 PM, MessyBlob wrote:
> I think this type of 'spatial awareness', along with some functions to compute
> overlapping (whether directly, or via bounds of computed intersections), would
> go a long way for people who generate scenes procedurally.

Like the MechSim patch in MegaPOV, but with the ability to alter or 
remove objects.

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> re. DOM, features, parsing.
>
> There are a number of scenarios where I've wished for scenario testing, e.g. to
> see if an object fits in a space, one could do ray-tracing in the SDL on the
> scene as it is being built, but what we can't do NOW is put an object in, do
> some processing, then remove the object from the scene if we don't want it.

What good would that do? I mean, stuff that trace() and inside() cannot do for
you yet?

An example of what sort of processing you have in mind would be helpful.


> I think this type of 'spatial awareness', along with some functions to compute
> overlapping (whether directly, or via bounds of computed intersections), would
> go a long way for people who generate scenes procedurally.

POV simply cannot really compute overlapping, for reasons of its very basic
design. No way. It cannot even really compute the bounds of "computed
intersections" (whatever that would be in POV internals terms). All it can do
is compute the intersection of computed bounds. Which some nice macros can do
just as well using with min_extent(), max_extent() and the min()/max()
functions.

Really, everything POV can do with geometry is based on trace() and inside() -
plus the bounding boxes. This is really all POV has to offer in terms of
"spatial awareness". No hidden secrets. You have it *all* at your disposal in
SDL.

It's probably more a question of how *fast* it can be done.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> What good would that do? I mean, stuff that trace() and inside() cannot do for
> you yet?

The problem is that you can't do trace() or inside() on an object that has not
yet been placed, but when it has been placed, it is a permanent placement.
Conversely, if you place an object, and then as a result of trace(), decide you
don't want that object to be placed, you can't then remove it. OO would solve
this, in that the object would be referencable after placement, and deleted (or
modified).

Currently, I suppose there's always the option of creating Clear objects, which
trace() would pick up, but they'd slow the final render down. Another
alternative would be to use animation frames, starting with a new frame if an
object needs removing.

Most of my existing 'smart object placement' has used arrays to store existing
object positions, and then subsequent items are placed only where they're
sufficiently distant from all existing objects. Spheres are trivial to place
among other spheres, but once the objects become complicated, or are oriented,
this approach becomes near-impossible.

Some typical examples might be: trees in a forest canopy (or other organic
space-fillers), chains, interlocking toys, sprawling architecture, placement of
objects at rest.

> POV simply cannot really compute overlapping, for reasons of its very basic
> design.

I knew it was difficult, if not impossible on complicated objects (without some
serious mesh work) so I was throwing this hat in the ring to challenge the
existing design. Fair enough, I don't mind it being squashed if it's a no-goer.
I guess that's the nature of brainstorming. :o)

Post a reply to this message

On 4/8/2009 9:41 PM, MessyBlob wrote:
> "clipka"<nomail@nomail>  wrote:
>> What good would that do? I mean, stuff that trace() and inside() cannot do for
>> you yet?
>
> The problem is that you can't do trace() or inside() on an object that has not
> yet been placed, but when it has been placed, it is a permanent placement.

That's actually not true.

When you call trace(), it's on an object that has been declared, but not 
necessarily placed.  You can do it like this:

#declare my_obj = object { ... }
#declare v_orig = <...>;
#declare v_dir = <...>;
#declare intersection = <0,0,0>;
#declare norm = <0,0,0>;
#declare intersection = trace(my_obj, v_orig, v_dir, norm)

#declare hit = false;
#if (intersection.x != 0) #declare hit = true; #end
#if (intersection.y != 0) #declare hit = true; #end
#if (intersection.z != 0) #declare hit = true; #end

#if (hit)
   object { my_obj }
#end

The above code has the nice property of only parsing the object, and 
thus tracing it, if your intended intersection actually occurs.

However, it highlights one of the needs in the SDL of proper object 
support: mainly, the need to pass norm as an "out" parameter to the 
trace function, rather than returning a vector pair of the intersection 
point / normal.  With proper class support, this could be remedied.

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> The problem is that you can't do trace() or inside() on an object that has not
> yet been placed, but when it has been placed, it is a permanent placement.
> Conversely, if you place an object, and then as a result of trace(), decide you
> don't want that object to be placed, you can't then remove it. OO would solve
> this, in that the object would be referencable after placement, and deleted (or
> modified).

??? Actually trace() and inside() *only* work on #declared objects, and do so
independently on whether you have already "invoked" them into the scene or not.

#undefining such an object even clears up the memory again, and right before
rendering all "non-invoked" objects are ditched automatically.

> > POV simply cannot really compute overlapping, for reasons of its very basic
> > design.
>
> I knew it was difficult, if not impossible on complicated objects (without some
> serious mesh work) so I was throwing this hat in the ring to challenge the
> existing design. Fair enough, I don't mind it being squashed if it's a no-goer.

I don't think the very fundamental basics of POV would be open for debate. Even
*if* POV 4 would be a complete re-write (which I currently doubt), it would be
based on the very same principle for geometric representation. To me there is
not the slightest doubt about that.

(The main motivation for this complete-rewrite thing, as it appears to me, were
legal issues with an intended license switch, but I gather these have been
addressed by now for most parts of the code.)

Post a reply to this message