 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <kua### [at] videotron ca> wrote:
> Would be beter if the texture was UV mapped.
It would be, but usually people make sure the foundation and frame on a house
frame are right before priming and painting the trim.
Besides - since it's a network of stitched bicubic patches, I have to specify
the u/v vectors, and I don't know how to do that with procedurally generated
coordinates. Yet.
Maybe someone can suggest a way to do this, or point me to a good reference that
I can read and get right on to implementing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 31/08/2018 14:14, clipka wrote:
> Am 30.08.2018 um 03:21 schrieb Mike Horvath:
>> Looks like a circular turd if such things were possible.
>
> You should see your doctor about the pigment and texture of your turds ;)
>
Got an appointment Wednesday morning for that very thing. I'll mention
that you said I should.
Unless you want the job?
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
> Looks like a circular turd if such things were possible.
>
> Mike
As a nonspeaker english user is always useful to learn new ways of description
for my own code. I didn't knew the word and had to google it. What a mistake.
Still fighting with De Casteljau.
Bruno Gimeno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Probably a dumb question, but can only meshes be UV mapped?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] 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 ...."
> > * 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
|
|
| |
| |
|
|
|
|
| |
|
|
