 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/09/2018 12:00, Mike Horvath wrote:
> Probably a dumb question, but can only meshes be UV mapped?
>
>
There are no dumb questions only dumb answers. ;)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 01/09/2018 à 13:00, Mike Horvath a écrit :
> Probably a dumb question, but can only meshes be UV mapped?
>
Not a stupid question, and the answer is no.
There is a page in the wiki about uv-mapping support. (but it is not
easy to find in the search engine)
http://wiki.povray.org/content/Reference:UV_Mapping#Supported_Objects
For the lazy readers, in 3.8:
* bicubic_patch
* box
* cone, cylinder
* lathe, sor
* lemon
* mesh, mesh2
* ovus
* parametric
* sphere
* torus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 01/09/2018 à 14:03, Le_Forgeron a écrit :
> Le 01/09/2018 à 13:00, Mike Horvath a écrit :
>> Probably a dumb question, but can only meshes be UV mapped?
>>
>
> Not a stupid question, and the answer is no.
>
> There is a page in the wiki about uv-mapping support. (but it is not
> easy to find in the search engine)
>
> http://wiki.povray.org/content/Reference:UV_Mapping#Supported_Objects
>
> For the lazy readers, in 3.8:
> * bicubic_patch
> * box
> * cone, cylinder
> * lathe, sor
> * lemon
> * mesh, mesh2
> * ovus
> * parametric
> * sphere
> * torus
>
And in the sleep of the night, come the greatest question ever: why is
the disc not part of that list ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.09.2018 um 10:07 schrieb Le_Forgeron:
>> There is a page in the wiki about uv-mapping support. (but it is not
>> easy to find in the search engine)
>>
>> http://wiki.povray.org/content/Reference:UV_Mapping#Supported_Objects
>>
>> For the lazy readers, in 3.8:
>> * bicubic_patch
>> * box
>> * cone, cylinder
>> * lathe, sor
>> * lemon
>> * mesh, mesh2
>> * ovus
>> * parametric
>> * sphere
>> * torus
>>
>
> And in the sleep of the night, come the greatest question ever: why is
> the disc not part of that list ?
Because it doesn't qualify?
Because nobody ever bothered to implement special UV mapping for it?
Because there is a systematic problem with UV mapping of a disc, which -
now that I come to think of it - _should_ also have precluded cylinder,
cone and lemon from being UV-mapped?
The problem is that the parameterization does not mandate a particular
orientation other than the axis of rotational symmetry.
The rotation of the UV pattern around that axis is arbitrary, and purely
emergent from the current implementation of the primitive (most notably
the code computing a transformation to and from a local coordinate
space); if that implementation ever were to change - be it for
performance, numeric stability, code clarity, or sharing of similar code
- it would affect the UV mapping scheme, and it might be a heck of a lot
of work to emulate the current mapping.
The problem does not arise with lathe, sor or torus because although
they are also rotationally symmetric, their orientation is governed by
definition instead of parameterization, so any transformation to and
from local coordinate space is entirely under user control and unambiguous.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] free fr> 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 ...."
> > * box
> > * 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.
Maybe this hints at there being a technical mathematical difference between how
cylinder{} is uv-mapped vs using cone{} with 2 equal radii... ?
> > * 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
> > * sphere
> > * torus
torus: the map is taken from the area <0,0><1,1> where the u-coordinate is
wrapped around the major radius and the the v-coordinate is wrapped around the
minor radius.
Yes indeed - confirmed. ;)
Note: Recent additions revealed torus mapping to be reversed with respect to the
u-coordinate. For backward compatibility reasons it remains the same in this
release, however this may change in the future.
This is interesting - I'll have to experiment with this and look more closely.
It's gonna be like a damned battery - where they have the negatively charged
electrons flowing out from the side labeled (+) :|
Scientism.
> And in the sleep of the night, come the greatest question ever: why is
> the disc not part of that list ?
It's always the simple things :D ;)
Surface of Revolution also has special disc mapping on the end caps if the
object is not open.
Not a solution, but seems to be a potentially viable workaround.
That's an interesting and clever image map to illustrate the uv-mapping. But
the thing that strikes me as odd there --- is that black and white checkered
stripe supposed to be on the bottom of the box like that? Shouldn't it be all
colored gradient?
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Interpolation vectors are ok, Bezier splines are ok, loops are ok, grid macro
was rewritten from scratch, uv vectors fixed so it tiles perfectly.
Here's a plain torus given just a wee bit of noise to undulate the surface.
uv-mapped, especially for Alain. ;)
Torus radii are 4 and 10, and I needed to re-render the grid at 2000x2000 to get
an acceptable look without too much "stretching" which was painful to look at.
With twice the noise and a good texture, it makes a pretty great looking donut.
I need to find a good tilable cake donut texture to UV-map this with. :)
Post a reply to this message
Attachments:
Download 'bezierstitching_test_3.png' (230 KB)
Preview of image 'bezierstitching_test_3.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I decided to see how tortuously I could twist it, and changed the parametric to
a trianguloid trefoil.
Even after increasing the number of patches to subdivide the surface better,
there's still a bit of "shredding" evident.
72 x 36 = 2596 patches.
Apparently my radiosity block has been judged - and found lacking.
radiosity {
adc_bailout 0.005
always_sample off
count 150
error_bound 0.25
gray_threshold 0.2
low_error_factor 0.25
minimum_reuse 0.01
maximum_reuse 0.2
nearest_count 8
pretrace_start 0.08
pretrace_end 0.04
recursion_limit 5
//brightness 1
} // end radiosity block
There shall surely be more to come - any suggestions on improvements, further
experiments, and crafting a better scene by those skilled in the art are most
welcome as always.
Post a reply to this message
Attachments:
Download 'bezierstitching_test_3.png' (286 KB)
Preview of image 'bezierstitching_test_3.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I am not sure I understand what I am looking at. The shadows suggest a
thoroughly torn up object (the shredding I suppose).
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> I am not sure I understand what I am looking at. The shadows suggest a
> thoroughly torn up object (the shredding I suppose).
I swapped out the parametric equation of the torus for the trianguloid trefoil
(attached animation) as it seemed to have sharp twists and switchbacks.
While the torus is a nice, gentle curve, I wanted to challenge the interpolation
algorithms for the intermediate control points of the Bezier patches, and the
Bernstein polynomials that locate any u,v point on any patch.
I'm not sure if this means I've still got some code to "fix", or that the Bezier
patch simply can't be bent to this extreme without exhibiting artefacts.
The "shredding" seems to be the disconnected edges of the bicubic_patches that
follow the surface of the parametric.
Given that I made the subdivision quite large, and my u,v steps on the patches
is quite large (5) for such small patches, I would imagine that there ought to
be adequate coverage. The patches (should) share the same edge control points -
but that's an unconfirmed assumption, and may be the source of the problem.
"Here's a method for covering something with Bezier patches" ... now how far can
I push it without it breaking?
Post a reply to this message
Attachments:
Download 'parametric2 00_00_00-00_00_12.gif' (555 KB)
Preview of image 'parametric2 00_00_00-00_00_12.gif'
|
|
| |
| |
|
|
|
|
| |
|
|
