Hello,


The problem of the day :
I'm trying to project an image onto the rounded corner.


I've tried a lot of try with image_map and uv_mapping without success.
Here is my "best" (less bad) result for now.

Do you think it's possible to map the image directly onto the object?

The joined image is the result of three parts with two planar and one
cylindrical projection, but the joints don't stick :(


How would you do it ?




The geometry of the rounded corner is simple and I can post the code
with my tests using image_map{}.

The image used is here : <https://shorturl.at/mnqz2> on which I added
red marks.





-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

Attachments:
Download 'coin4.png' (495 KB)

Preview of image 'coin4.png'

kurtz le pirate <kur### [at] gmailcom> wrote:

> How would you do it ?

Use a parametric function, so that you could make the geometry of the curve, and
then use that to uv-map it manually in SDL by applying the function as a 1:1
mapping function from <x, y> to the <u, v> of the shape.

I have to head out, but can elaborate on that if you need me to.

- BW

Post a reply to this message

On 2/26/24 12:05, kurtz le pirate wrote:
> How would you do it ?

Attached is a method using new v3.8 and yuqk features. While working up 
new inbuilt functions for yuqk, I've tried to implement them with the 
ability to return 't' or indexes for maps when that's possible.

The shapes I left as isosurfaces. Better render performance could be had 
by using using more basic CSG for the shapes and still the function set 
up for applying the image_map.

Bill P.

Post a reply to this message

Attachments:
Download 'rndcrnr.jpg' (158 KB) Download 'rndcrnr.pov.txt' (7 KB)

Preview of image 'rndcrnr.jpg'

On 2/28/24 05:13, William F Pokorny wrote:
> Attached is a method using new v3.8 and yuqk features.

Yep. In the scene where I wrote ObjLeftL and ObjLeftR, those should have 
been ObjLegL and ObjLegR, respectively.

(The definition of Pink is also extraneous)

Bill P.

Post a reply to this message

On 28/02/2024 17:57, William F Pokorny wrote:
> On 2/28/24 05:13, William F Pokorny wrote:
>> Attached is a method using new v3.8 and yuqk features.
> 
> Yep. In the scene where I wrote ObjLeftL and ObjLeftR, those should have 
> been ObjLegL and ObjLegR, respectively.
> 
> (The definition of Pink is also extraneous)
> 
> Bill P.
> 

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.


and I need the yuqk fork, which I don't have and which isn't (yet?)
available for my platform.


It's an excellent proofreading exercise.
What a job! Hats off to you!


-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

kurtz le pirate <kur### [at] gmailcom> 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.
So, if you were going to map a sphere, you'd use theta and phi to describe the
surface.
remapping theta and phi from radians to a 0-1 domain, you can grab the pixel
from the image.

So you just write a function to do that "inverse uv mapping", and apply it to an
average texture that combines the r, g, and b values from the image map.

- BW

Post a reply to this message

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

William F Pokorny <ano### [at] anonymousorg> wrote:

>In yuqk, generally, I've been pushing the code toward more ways to paint
shapes - often using other shapes.

Check out:
https://developer.nvidia.com/gpugems/gpugems/part-iii-materials/chapter-20-texture-bombing

Seems simple enough to do, and ought to be fast if implemented in source.

- BW

Post a reply to this message

On 3/1/24 13:47, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> In yuqk, generally, I've been pushing the code toward more ways to paint
> shapes - often using other shapes.
> 
> Check out:
>
https://developer.nvidia.com/gpugems/gpugems/part-iii-materials/chapter-20-texture-bombing
> 
> Seems simple enough to do, and ought to be fast if implemented in source.
> 
> - BW
> 

Thanks for the pointer! Added it to my notes.

I think, maybe, Sam did something like this a long time ago in SDL. I 
vaguely remember an image of tree leaves on the ground...?

Bill P.

Post a reply to this message