I know that the topic of saving povray objects as 3D models has come up before,
but I think the idea is worth exploration.

I also understand that there are macros that do this to some extent or another,
but I'd like to share an idea of mine, and perhaps get input on how it might be
accomplished as a feature in a future version of PoV.

For the purposes of syntax, objects to be saved as 3d files would be required to
be surrounded by an object {} block.

A command line argument +B (for Bake, or +b if flags are case sensitive.)

+BOn -- Bake Objects where n is polygon count
+BT -- Bake Textures (standard image format using +F)
+BN -- Bake Normals
+BL -- Bake Lighting
+BA -- Bake All

(can media be baked?)

also combinations...

+B[{On|T|N|L} | A]

alternatively, baking options could be set in global_settings.

global_settings {
    bake {
        bake_objects <bool>
        bake_textures <bool>
        bake_normals <bool>
        bake_lighting <bool>

        polygon_count <int>
        pixel_depth <int>        // for maps
    }
}

Any thoughts?

A.D.B.

Post a reply to this message

Anthony D. Baye wrote:

> I also understand that there are macros that do this to some extent
> or another

I think there exist some iso_surface approximation macros, not
sure about anything else. Of course, most primitives could also be
expressed using an implicit function, and CSG can be implemented using
min/max functions, so you could in theory generate iso_surface versions
even for rather complex objects and use these as the basis for mesh
generation.

However, as far as I understand it these macros are very slow even for 
normal functions, let alone those representing a complex CSG object.

> For the purposes of syntax, objects to be saved as 3d files would be
> required to be surrounded by an object {} block.

The main problem to be solved is most certainly not the syntax.

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> Anthony D. Baye wrote:
>
> > I also understand that there are macros that do this to some extent
> > or another
>
> I think there exist some iso_surface approximation macros, not
> sure about anything else. Of course, most primitives could also be
> expressed using an implicit function, and CSG can be implemented using
> min/max functions, so you could in theory generate iso_surface versions
> even for rather complex objects and use these as the basis for mesh
> generation.
>
> However, as far as I understand it these macros are very slow even for
> normal functions, let alone those representing a complex CSG object.
>

This is always going to be a problem with interpreted systems:  The macros don't
have any way to observe the calculations that the backend performs, so they have
to duplicate those calculations.  Not only does the program have to interpret
the instructions to perform the calculations, it has to perform the calculations
twice (or more than twice if you're calling several different macros)

If the baking functions had observer access to the results of the relevant
tracing calculations, the process would be much faster.

> > For the purposes of syntax, objects to be saved as 3d files would be
> > required to be surrounded by an object {} block.
>
> The main problem to be solved is most certainly not the syntax.

I understand that the syntax is not the main problem, and without any knowledge
of the code, I can't make any algorithmic suggestions (Although, I'm not sure I
could anyway).

Syntax may, in fact, be irrelevant, considering that there has been discussion
of completely redesigning the SDL for version 4.0

I also realize that the rewrite for version 4.0 takes precedence over addition
of new features, but I have often wished that I could use my povray models in
applications other than static art -- animations notwithstanding -- such as
video game engines.

I fully intend to explore the options myself, but I thought I'd float the idea
and see if it generated any ideas on how it might be done.

Even clues as to the relevant sections of the code would be useful.

Regards,

A.D.B.

Post a reply to this message

On 2/18/2012 11:39 PM, Anthony D. Baye wrote:
> Christian Froeschlin<chr### [at] chrfrde>  wrote:
>> Anthony D. Baye wrote:
>>
>>> I also understand that there are macros that do this to some extent
>>> or another
>>
>> I think there exist some iso_surface approximation macros, not
>> sure about anything else. Of course, most primitives could also be
>> expressed using an implicit function, and CSG can be implemented using
>> min/max functions, so you could in theory generate iso_surface versions
>> even for rather complex objects and use these as the basis for mesh
>> generation.
>>
>> However, as far as I understand it these macros are very slow even for
>> normal functions, let alone those representing a complex CSG object.
>>
>
> This is always going to be a problem with interpreted systems:  The macros don't
> have any way to observe the calculations that the backend performs, so they have
> to duplicate those calculations.  Not only does the program have to interpret
> the instructions to perform the calculations, it has to perform the calculations
> twice (or more than twice if you're calling several different macros)
>
> If the baking functions had observer access to the results of the relevant
> tracing calculations, the process would be much faster.
>
>>> For the purposes of syntax, objects to be saved as 3d files would be
>>> required to be surrounded by an object {} block.
>>
>> The main problem to be solved is most certainly not the syntax.
>
> I understand that the syntax is not the main problem, and without any knowledge
> of the code, I can't make any algorithmic suggestions (Although, I'm not sure I
> could anyway).
>
> Syntax may, in fact, be irrelevant, considering that there has been discussion
> of completely redesigning the SDL for version 4.0
>
> I also realize that the rewrite for version 4.0 takes precedence over addition
> of new features, but I have often wished that I could use my povray models in
> applications other than static art -- animations notwithstanding -- such as
> video game engines.
>
> I fully intend to explore the options myself, but I thought I'd float the idea
> and see if it generated any ideas on how it might be done.
>
> Even clues as to the relevant sections of the code would be useful.
>
> Regards,
>
> A.D.B.
>
Most of what you are looking at is stuff that I wouldn't mind seeing 
too. Being able to bake a texture, for example, and even maybe do so by 
converting some level of detail below a threshold to texture (or a 
better way to color/pattern object textures, would be nice), would be 
very helpful.

As for macros.. Yeah, depending on the macros, you might be dealing with 
some messy stuff. Some of it could be tokenized, or even jit compiled, 
after a fashion, but the way they work, you could practically build a 
whole section of new code out of them, depending on inputs that change 
from section to section, or even frame to frame. And that makes things.. 
way more complex. Still not impossible, but it might require adjusting 
the macro system to be less macro, and more "functions", or something...

Its almost a kind of "self modifying program" problem.

Post a reply to this message

Am 19.02.2012 07:39, schrieb Anthony D. Baye:

> This is always going to be a problem with interpreted systems:  The macros don't
> have any way to observe the calculations that the backend performs, so they have
> to duplicate those calculations.  Not only does the program have to interpret
> the instructions to perform the calculations, it has to perform the calculations
> twice (or more than twice if you're calling several different macros)
>
> If the baking functions had observer access to the results of the relevant
> tracing calculations, the process would be much faster.

Not really. From the tracing calculations, all you would get would be a 
point cloud - and an incomplete one as well, because you wouldn't get 
any information about the back sides. Not to mention that the detail of 
the point cloud would depend on the image resolution. And you'd have to 
figure out yourself how to connect all those points to a mesh.

To convert POV-Ray objects to meshes (which is what you're essentially 
asking for), there are way faster - and more accurate - options for many 
of POV-Ray's primitives. A box, for instance, is a trivial thing to 
convert to a mesh right from its corner coordinates; a sphere could be 
converted by computing a geodome with the fitting radius; and CSG 
objects could be generated by performing operations on the mesh versions 
of their child objects, which will give you exact edges and crevices 
(limited only by the precision of the child meshes).

Post a reply to this message