On 11/1/24 09:36, Bald Eagle wrote:
> I would greatly appreciate some advice on how to properly accomplish this, as my
> experiments in the past were fraught with unwanted artefacts:
> https://news.povray.org/ 
> web.6394be0a7dc652cc1f9dae3025979125%40news.povray.org
> 
> I'm sure that one of your long "ramblings on" would be an insightful read, and
> probably spur on other tangential projects - as they always do.
> 
> Hopefully we'll both have a few round-tuits at some point to compare notes.
> 
> Good work, and much appreciated!

Hi Bill.

Thanks.

Unsure how much my particular methods might help! How one might approach 
repeatability depends on the environment, underlying metrics, forms, etc.

In my re-write of the crackle code I took advantage of newer hardware 
and features of C++. For example, I push all the working coordinates 
into a +x, +y +z space. Already the working grid internally (for the 
cubes) was integer based as the origin for each offset point relative to 
the evaluation point.

Much of the trouble I had with repeat (I suspect it's related to what's 
wrong with the v3.8 repeat feature and caching too) was realizing I had 
to do the cube calculations for offsets apart from the cached cube 
coordinates. This something which might not even be doable with the 
cache structure of the V3.8 beta 2 code - not thought about it too much 
though. The yuqk caching is set up differently.

When I finally got my head on straight about that, the repeat code 
became something which creates x,y,z unsigned integer coordinates 
differently for the negative cube coordinates and positive cube 
coordinates about the center evaluation cube - depending upon where in 
the repeat range the evaluation point is on each axis.

In the POV-Ray implementation, a virtual environment of cubes containing 
offset points is created around each cube in space where we find 
ourselves evaluating 3D locations. For the repeat aspect, suppose I 
created what amounts to another virtual working space on top of that one 
in which to repeat.

Backing up, the POV-Ray set up of a virtual box of cubelets containing 
the center cube with the evaluation point is driven by the 'form' 
feature. It requires up to three closest point measures for downstream 
metric calculations.

If for your crackle implementation, you only care about the closest 
points - as is true for solid(*) results - the implementation can be 
simpler.

(*) - In the yuqk re-write I treat the solid feature as something almost 
completely apart from the crackle proper features.

Anyhow. The updated source code will be in the next yuqk release (R16). 
Having it to review might help make sense of what I've written.

Bill P.

Aside: I'm reminded that years ago I experimented some with different 
shape functions set at point locations as a way to to create crackle 
pattern shapes - all in SDL - which was limiting. The traditional 
crackle solid look you can create with cones. Can't find the post... Too 
many ideas and not enough time. :-)

Post a reply to this message