Hi, I've just done some thinking about patching POV-Ray to do df3
output.
What I'm considering is to render an animation and writing the output to
the df3 file.  The tricky bit I'd like to do is to allow subset renders
to be inserted into the appropriate part of the file, so the following
algo. writes out a complete file even if a subset render is done.

If anyone has already done this or if you see any probs with this
algorithm, please let me know.

if file exists
  if (dimensions different) or (not subset render)
    make new file

if new file
  write header

if current frame > frames in file
  seek to end of file
  write blank frames

seek to offset for current frame
render current frame to file

Cheers, PoD.

Post a reply to this message

PoD heeft geschreven in bericht <37A0B4BF.FA0940A3@merlin.net.au>...
>Hi, I've just done some thinking about patching POV-Ray to do df3
>output.

That would be great. Actually I thougt about asking this as feature request,
altough your tga2df3 conversion utility works excellent (thanks for that).

ingo
--
Met dank aan de muze met het glazen oog.

Post a reply to this message

I was thinking about it but from a different perspective. What if POV
could output a .df3 based on the total (object+global) media density
in the unit cube? Your tga2df3 utility does a very good job at making
df3s out of anims and is 100% portable, but some things are just more
easily modeled with media than with CSG and pigments.

Just my 3.6 st


Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov wrote:
> 
> I was thinking about it but from a different perspective. What if POV
> could output a .df3 based on the total (object+global) media density
> in the unit cube? Your tga2df3 utility does a very good job at making
> df3s out of anims and is 100% portable, but some things are just more
> easily modeled with media than with CSG and pigments.
> 
> Just my 3.6 st
> 
> Peter Popov
> ICQ: 15002700

That would certainly be very usefull but I think it would suit a
separate utility better.
Besides, what I'm thinking of should be a fairly simple hack of existing
POV code.  I don't think I'd be up to the task of implementing your idea
:(

Cheers, PoD.

Post a reply to this message

Peter Popov heeft geschreven in bericht <37a30640.5293149@204.213.191.228>...
>......., but some things are just more
>easily modeled with media than with CSG and pigments.


Peter,
What other ways are there to model media, besides pigments?

ingo
--
Met dank aan de muze met het glazen oog.

Post a reply to this message

On Fri, 30 Jul 1999 21:20:57 +0200, "ingo" <ing### [at] ingodemonnl> wrote:

>Peter,
>What other ways are there to model media, besides pigments?
>
>ingo

Media allows for logical AND and OR operations on the patterns
involved.

Actually the whole idea behind exporting a df3 modeled with media is
that a df3 density will subsequenty render much faster than the
combination of densities and media used to model it. I find this of
great help for all those test renders. It will not offer new
functionality, just ease of use.


Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote in message
news:37a321f4.26014057@204.213.191.228...
> On Fri, 30 Jul 1999 21:20:57 +0200, "ingo" <ing### [at] ingodemonnl> wrote:
>
> >Peter,
> >What other ways are there to model media, besides pigments?
> >
> >ingo
>
> Media allows for logical AND and OR operations on the patterns
> involved.
>
> Actually the whole idea behind exporting a df3 modeled with media is
> that a df3 density will subsequenty render much faster than the
> combination of densities and media used to model it. I find this of
> great help for all those test renders. It will not offer new
> functionality, just ease of use.

    The new functionality would enter if somebody (don't look at me, folks)
were to write a df3 editor, a sort of "3d paint" program.

    Obvious features to add would be:

    sculpt/stain/build (like a brush tool)
    spray               (like an airbrush tool)
    turbulence/blur/sharpen/density_curve_adjust  (filters)
    box/sphere/cylinder/torus (like rectangle/ellipse tools but also
                        somewhat like 3D CAD primitives)
    rotate/flip/stretch...
    resampling to change resolution
    cutting and pasting chunks
    3D-specific tools: sag, hollow, drip...
    tilable_block option


    spinning, slicing, and dicing views
    temporary transparency for viewing one density range at a time
    stereo viewing?

    support for other density_file formats as they come out (one obvious
alternative is an octree; a JPEG-like format might be a possibility too.
That's primarily up to the POV team and secondarily to the POV patchers)

    alternative non-df3 output as a union of objects [eg, spheres partially
filling a axbxc grid] (well, this might give a way to testbed a density_file
format that had not yet been implemented in POV; one could output an octree
easily in this way.)

    Robert Dawson

Post a reply to this message

>    The new functionality would enter if somebody (don't look at me, folks)
>were to write a df3 editor, a sort of "3d paint" program.

<snip scary feature list>

>    Robert Dawson

A df3 manipulating library in C was the last task on my to-do list for
this summer. As it turns out, I must cheer if I finish the first
thing, namely my particle system (I have given up doing it in POV
because the limitations of the language make it really hard a task,
and speed is an issue, too.) I was going to make a windows front-end
or ask a friend to do it (I have a friend who works with VC6) and
would then release the proggie as postcardware or such, but that'll
have to wait at least a month, maybe much more :( Sorry, I am such a
lazy bum!


Peter Popov
ICQ: 15002700

Post a reply to this message

>...my particle system (I have given up doing it in POV
because the limitations of the language make it really hard a task,
and speed is an issue, too.)<

That is why I switched to C++ for my particle system simulator, but I
was hoping you would succeed in doing it in POV. Oh, well, looking
forward to seeing your simulator. Or maybe I will not see it, if it uses
the Windows API and/or source code isn't available.

Post a reply to this message

On Thu, 12 Aug 1999 07:05:04 -0500, Chris Huff
<Chr### [at] compuservecom> wrote:

>That is why I switched to C++ for my particle system simulator, but I
>was hoping you would succeed in doing it in POV. Oh, well, looking
>forward to seeing your simulator. Or maybe I will not see it, if it uses
>the Windows API and/or source code isn't available.

ANSI C using GCC, no binaries distributed, source will be available,
no interface (suck from stdin, spit to stdout... well, it might
support file i/o :) )


Peter Popov
ICQ: 15002700

Post a reply to this message