POV-Ray : Newsgroups : povray.advanced-users : image mapping : Re: image mapping Server Time
25 May 2024 16:18:49 EDT (-0400)
  Re: image mapping  
From: William F Pokorny
Date: 1 Mar 2024 11:08:38
Message: <65e1fd86$1@news.povray.org>
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 

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

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