POV-Ray : Newsgroups : povray.binaries.programming : An updated povr tarball for Unix/Linux. f6b1c13e : Re: An updated povr tarball for Unix/Linux. f6b1c13e Server Time
20 Oct 2021 19:30:40 EDT (-0400)
  Re: An updated povr tarball for Unix/Linux. f6b1c13e  
From: Bald Eagle
Date: 27 Aug 2020 07:30:01
Message: <web.5f479816f6dfcecf1f9dae300@news.povray.org>
Le_Forgeron <jgr### [at] freefr> wrote:

> An investigation not as pattern but as warp could be interesting.

Aha, yes - that's a better way of thinking about it.

> The early part to answer is: what happen outside the circle.
> One answer can be: nothing, outside the circle, there is no transformation.

That would be my initial, naive impression.  Something like "once".

> Or something different, as suggested in the pdf for poincarré disk.

I'm sure that there exist a number of different options, and of course we will
probably find out what they are once someone picks up this sort of thing to
begin experimenting with and proceeds to discover what other ways there are or
follows a path of reasoning to suggest a new option.

Geometric inversion?

> It is "of course" to be mainly used with the image pattern, so it is
> better from the very start that the reference plane be the same (to
> avoid a systematic rotate), and the third coordinates is to be dropped.

Oh, please, no.   One of my main dislikes of things like prism {} is that the
coordinates are supplied in <x, z> format.  So then rather than simply passing
[multipurpose] vectors to the object definition, where the y-component gets
_ignored_, I have to write a whole new section of code to convert everything
into a special single-purpose format.   :(

> So far the "perfect" illustration could be some pedestal table with such
> topping, and some chess set on it...
> With an outer ring, which implies some layered textures too.

Likely.  But I also envisioned seeing how all of the various tilings can be
manipulated.   :)

> About bezier bicubic patches, I do not so far understand what is the
> final purpose of the request. Does it sound like gluing the mesh camera
> to a bezier bicubic patch ? (mesh camera or user-function defined camera).
> As a raytracing aims at generating pictures, what is a finish map in
> that context ?

The idea would be to define 4 corners of the bezier patch in terms of - not
<x,y,z> - but <r, g, b> and then rather than doing a straight bilinear
interpolation of the color values between the two points across the rectangle,
bicubically interpolate the colors across a Bezier surface.
Does that make sense?

I guess I also had it in my mind that if I had an existing _geometric_ bezier
patch, that somehow it would be possible to simply define the colors of the 4
fixed corners, and those would get mapped to the geometric coordinates.   Then
the geometric control points would control the bicubic color interpolation
between the color values - avoiding the need to write a whole separate block of
code for the coloring.

I hadn't really though it all the way through, so sorry for any confusion.

But it does suggest that there could be a bicubic WARP where patterns could be
distorted (or image maps corrected) through such a mechanism.

Also, the mesh camera is an interesting idea.  I'm not sure what you mean by the
finish map - but I would imagine it has something to do with the
ray-scene/surface angles?   Like for something simple like specular reflection?
That I simply don't know.
Maybe if it were just an experimental feature, use the undistorted mesh camera
to generate the color but the bicubic functions to control the view....
No idea.

Post a reply to this message

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