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