I recently resumed a look at the ripples and waves patterns - which 
exist for both normal and pattern value map blocks.

If you never use other than the default of 10 waves, you can stop reading.

---

Be aware, the internal initialization of vectors and frequency / 
amplitude values happens when each worker thread is initialized. So, the 
parse thread gets initialized, before, it has a chance to parse any 
'global_settings { number_of_waves <n> }' settings or change-settings 
during parsing.

In other words we always get 10 waves in the parsing thread and we'll 
only get the last number_of_waves setting in the post-parse threads for 
photons / radiosity / render.

So what, you shout!

You might be right. This state of thing might come to nothing - except 
when you do something in the parse phase like place objects on a surface 
perturbed by the ripples and/or waves pattern. Later, when the render of 
that surface happens, it isn't the same surface as what existed during 
parsing.

Bill P.


Aside: The other unfortunate bit I'm taking a swing at fixing is that we 
always get the same vectors and values. It's as if we are working with a 
long fixed list and only get to pick the first <n> sets(a). Changing the 
number could change all <n> values, but it doesn't today. What we really 
want are truly independent patterns where we can specify more of what we 
want for each of the uses. We'll see.

(a) - The reason for a fixed list might be how 'waves' is implemented. 
There isn't a hard clamp on the upper range of values, but rather a 
heuristic function. Admittedly, one which might well be as good as an 
optimal one for any reasonable number of waves(b) given the known fixed 
stream of values!

(b) - There is no check on the upper value today while parsing, which 
itself, might result in crashes, bangs and booms - or cursing while a 
render takes forever and 12 years. :-) (Effective limit is MAX_INT)

Post a reply to this message