On 5/3/20 12:14 PM, Alain Martel wrote:
> Le 2020-05-02 à 11:22, William F Pokorny a écrit :
...
> 
> Why not use :
> 2 Count in X, Y, Z as a vector <X, Y, Z>
> 3 Delta as vector <X, Y, Z>
> 4, 5, 6 Individual directions. Allow for non-orthogonal patterns.
> 7 Cell pattern offset vector <X, Y, Z>
> 
> The later one may also be split in 3 to allow for more variation.

In use folks would define things with a vector, but you cannot pass 
vectors to functions - even with the v.x like syntax. Which is kinda a 
pain.

This latter behavior is I expect related to noticing recently the parser 
does not fix parameter constants on calls even when everything is known 
to the parser when a function call is defined(1).

It might be the parser is allowing for re-definitions before actually 
rendering given the parser generally allows this. But a guess. I don't 
really know why the interface is set up as it is(2).

Bill P.

(1) In other words it saves render time to do

#declare actualParam2 = ABC+XYZ*2.345;

function { FN00(x,y,z,actualParam2) }

if ABC and XYZ are known, rather than to calculated it on call in the 
parameter position. Doing it this later, more concise, way gets 
calculated on every call (at least where I've noticed and looked).

(2) - Might take a look at the parser interface handling at some point, 
but for now just trying to get a bunch of fixes and functionality in 
place with patterns/functions and the interplay between them. Once 
enough is there I can better test the form for how I think the whole of 
it should work by trying to do more complex isosurfaces. (All, perhaps, 
how things were intended to work given the code architecture in place)

Post a reply to this message