Am 02.09.2018 um 14:30 schrieb Bald Eagle:
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>>> * bicubic_patch
> 
> UV coordinates are based on the patch's parametric coordinates. They stretch
> with the control points. The default range is (0..1) and can be changed.
> 
> Well THERE's a teaser for you.  That should really be "...and can be changed by
> ....."  or followed by a link, or "see section ...."

Or "see below", because there it is: `uv_vectors`.

Granted, the addition of the "Additional UV Exmaples" picture has
increased the distance between that statement and the `uv_vectors`
explanation.


>>> * cone, cylinder
> 
> however, keep in mind that a true cone is not a cylinder.
> 
> Well --- that's one of those ones that makes you read it over and over again,
> trying to divine the import of that statement.
> Did they mean "a true cylinder is not a cone"? Because I'm not sure I would have
> ever thought a cone was a cylinder.

My suspicion is that the statement there is purely superfluous.

> Maybe this hints at there being a technical mathematical difference between how
> cylinder{} is uv-mapped vs using cone{} with 2 equal radii...   ?

That would be difficult, because a cone with 2 eqial radii is precisely
how the `cylinder` primitive is implemented.

> 
>>> * lathe, sor
>>> * lemon
>>> * mesh, mesh2
>>> * ovus
>>> * parametric
> 
> in this case the map is not taken from a fixed set of coordinates but the map is
> taken from the area defined by the boundaries of the uv-space, in which the
> parametric surface has to be calculated.
> 
> I can speculate on this, and try to imagine the true meaning, but if someone
> rendered the affine transformation from <x,y,z> to <u,v> with a pattern like
> cells or something, it would be a bit easier to see exactly how that happens.
> 
> Something stellar would be to see a parametric equation, and the equations used
> to convert those <x,y,z>  values to the <u,v> values

A parametric is /defined/ by the inverse process of UV mapping: Instead
of computing UV coordinates from given 3D coordinates of a point on the
surface, you start with a 1x1 square in UV space and transform it into
3D space via a function f(u,v)->(x,y,z). (In practice, POV-Ray uses a
set of three functions, f1(u,v)->x, f2(u,v)->y, f3(u,v)->z.)

So finding the ray-surface intersection points of a parametric boils
down to finding (u,v) pairs such that f(u,v)=(x,y,z), and thus the UV
coordinates are a trivial side product of that process.


> re:  the example code at the bottom of the page:
> 
> 3.1.5.1 SYS File Type
> 
> The section on Output File Types refers to the 'SYS' file type as being system
> specific. For the Windows implementation of POV-Ray, this system file type
> equates to .BMP files (the standard windows image format). The default output
> type is SYS.

Since v3.7:

----------------
The SYS file type has been deprecated, and the cross-platform output
file type is now PNG, or type n. See the section Output File Type for
more information.
----------------

Post a reply to this message