On 2/29/24 13:36, Bald Eagle wrote:
>> after two days of absence, I find your example... and what example !
>> on first reading, I understood nothing, but I'm going to peel it back a
>> bit more.
> He's just got the uv-mapping data hardwired into the object definition.

:-)

I'm always overwhelmed on initially seeing more than the simplest code 
from others! My own old code too, truth be told.

I'm aiming for the scene I posted to be a shipped example in the next 
release. As I've added more comments, I picked up a couple more typos 
(*)... None affected the result, but they certainly hurt the clarity of 
the example. The next release of yuqk will have this code with 
additional comments - and I hope no remaining mistakes - should you want 
to wait to 'peel'.

(*) - f_elliptical_sphrswp(...,-90,-90...) should have read '+90,-90'. 
The first value is an initial starting position for the sphere sweep and 
the only values allowed are left handed rotations of [0.0...360.0) so 
the implementation took the -90 as abs(-90) or +90, despite what I typed...

---

What Bill W says is true. Conceptually, it's just user directed, 
piecemeal, uv mapping in play here - another form of what you were 
trying in fact.

In yuqk, generally, I've been pushing the code toward more ways to paint 
shapes - often using other shapes. The inbuilt f_path() function in yuqk 
is as much about painting CSG shapes, as it is about having a new way to 
set up isosurface shapes (which can also paint themselves).

The 'list_object' pattern new to yuqk is conceptually an internal 
implementation of Matthew Goulet's / Blue Herring's 'multiobj.inc' from 
the currently offline, but being worked upon, object-collection 
(lib.povray.org).

Yuqk's inbuilt f_elliptical_sphrswp() is conceptually similar to Bruno 
Cabasson's elliptic_torus.pov.

Some of yuqk's density_file interpolation extensions are for playing 
with 3D painting of objects. Ideas related to SDL proximity pattern 
implementations of years past (Edouard Poor?).

Yuqk's new 'pattern_modifiers' keyword is about capturing complex 
spatial manipulations which can then be accessed to keep textures, 
function defined shapes, and CSG-shapes aligned / matched. The aim is 
texturing in simpler 3D space and shapes ahead of spacial changes / 
deformations - and having it all track correctly for a final result. 
This an extension of capturing transforms in the same manner.

Anyhow. It's true a lot of what looks new / complicated in yuqk is just 
what others have taken runs at long ago in a different, perhaps 
extended, form.

(The user_defined{} bit is, of course, clipka's work already in v3.8 
beta 2 / v4.0)

Bill P.

Post a reply to this message