POV-Ray : Newsgroups : povray.beta-test.binaries : Function / pattern issues. New f_repeat(). : Re: Function / pattern issues. New f_repeat(). Server Time
8 May 2024 03:15:23 EDT (-0400)
  Re: Function / pattern issues. New f_repeat().  
From: William F Pokorny
Date: 4 May 2020 03:35:45
Message: <5eafc5d1$1@news.povray.org>
On 5/3/20 12:14 PM, Alain Martel wrote:
> Le 2020-05-02 à 11:22, William F Pokorny a écrit :
...
> 
> Why not use :
...

Something else your question has me again thinking about; I'd really 
like to get to where we can pass a set/collection of user defined 
function pointers to inbuilt functions.

Would allow delayed evaluations, but as important, very rapid 
re-evaluations of functions to do whatever larger task. Density 
functions (AKA proximtiy), for example, on functions used in isosurfaces 
or functions acting as stand-ins for equivalent shapes.

On some level these are just double values acting as pointers, but 
letting users (me...) twiddle with such pointer values at all directly 
is asking for boom, crash, bang!

Been thinking about some new, SDL exposed, mechanism which lets users 
register functions / objects by name for later in inbuilt function use. 
A very rough idea at this point.

Perhaps such a mechanism could be extended to vector handling too as a 
way to pass (return?) vectors directly. Large sets of origin and 
direction vectors for use in cameras or whatever???

Thinking about 'bank' as a SDL name for it, but...?

Underneath expect a global C++ map of some sort. un-def/re-def mechanism 
would need to be updated to check whether the existing name is in the 
bank - and fail during parsing if so. We'd want what goes in the bank to 
be a defined once thing even if we perhaps allow value updates.

Yeah, how to handle function parameters not just x,y,z... Don't know, 
and guess I'm thinking aloud and should stop.

Bill P.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.