 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> 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.
I do believe that I sometimes ask one question, and you answer another.
(And I've just noticed on an old thread that sometimes I can read the same
question in one of two ways, and the ambiguity of the meaning even makes ME
interpret it differently the second time I read it and respond to a reply.)
For bicubic patches the UV coordinates can be specified for each of the four
corners of the patch. This goes right before the control points.
The syntax is:
uv_vectors <corner1>,<corner2>,<corner3>, <corner4>
with default
uv_vectors <0,0>,<1,0>,<1,1>,<0,1>
"The default range is (0..1) and can be changed...."
There is no "explanation" that you refer to.
For me, an explanation would be along the lines of changing those uv vectors and
showing the effect it has on how a unit-square texture gets mapped on it.
Then you add "scale" into the mix, and it can be pretty unclear - unless you
ALREADY know what's going on and you're reading the documentation
"retroactively", in hindsight, which I think is what often happens when some of
the docs get written or referred to.
"Look, newbie - the docs say exactly that, and we're all telling you that the
text isn't inconsistent with what happens..."
Very technically correct in highly qualified courtroom attorney-shyster
legalese, but of no use to the first-time, or even sometimes the tenth-time or
hundredth-time reader.
The documentation wasn't written by you (AFAIK), but your reply was -
unenlightening. As a [semi]alert reader, I can see where you're going with it,
having played with the uv mapping of bicubic patches before, but I think my
original point still stands - the statement that "The default range is (0..1)
and can be changed...." just sort of HANGS there.....
uv_vectors <corner1>,<corner2>,<corner3>, <corner4>
with default
uv_vectors <0,0>,<1,0>,<1,1>,<0,1>
Simply exemplifies the default, but doesn't do anything to explain the latter
part about how changes are made, what their effect is, or even hint at why you'd
want to change them.
> 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.
I had a go at this last night, and still need to fix/add back part of the code
that might make my understanding of this work. I got it "right", then I redid
it a different way, then realized I needed BOTH...
Let me offer my insight into this, both as an alternative explanation to
interested readers, and as an example of what might be a more illuminating way
of explaining the same situation.
Instead of U and V - the parametric is often defined via functions of Theta and
Phi. There's nothing special about either of these sets of variables
Theta and Phi are just (assuming a non-zero span) ranges of values.
If those values are normalized, we can see how if we arrange them orthogonally,
we can lay them out as "axes" of a unit square.
Then when we "plot" (calculate) the x,y,z values of the parametric, we use those
axes as the number lines that Theta and Phi travel along. U and V of the
unit-square UV texture are the normalized, planar surface defined by those two
vectors.
So yes, when I follow that line of thought, when we raster-scan through the
whole range of V's over all of the U's, then each UV "pixel" of the texture will
be mapped 1:1 with each point of the parametric, and one can "translate" that
little bit of color over to the <x,y,z> point in space where the parametric
equations evaluate to.
"> ... and thus the UV
> coordinates are a trivial side product of that process."
Right-o. And so it is.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.09.2018 um 18:12 schrieb Bald Eagle:
> I do believe that I sometimes ask one question, and you answer another.
> (And I've just noticed on an old thread that sometimes I can read the same
> question in one of two ways, and the ambiguity of the meaning even makes ME
> interpret it differently the second time I read it and respond to a reply.)
That may well happen ;)
> For bicubic patches the UV coordinates can be specified for each of the four
> corners of the patch. This goes right before the control points.
> The syntax is:
>
> uv_vectors <corner1>,<corner2>,<corner3>, <corner4>
> with default
> uv_vectors <0,0>,<1,0>,<1,1>,<0,1>
>
> "The default range is (0..1) and can be changed...."
>
> There is no "explanation" that you refer to.
> For me, an explanation would be along the lines of changing those uv vectors and
> showing the effect it has on how a unit-square texture gets mapped on it.
Technically, that would not be an explanation, but an example.
> Then you add "scale" into the mix, and it can be pretty unclear - unless you
> ALREADY know what's going on and you're reading the documentation
> "retroactively", in hindsight, which I think is what often happens when some of
> the docs get written or referred to.
You're right in that the docs on POV-Ray's UV mapping implementation
apparently presume the user is already familiar with the concept of UV
mapping.
For a person familiar with the concept, I think it is pretty
self-evident what `uv_vectors` does.
Note that you're looking at the reference section, not a tutorial. I
think it is legitimate to expect the reference section's reader to be
already familiar with common 3D graphics concepts; UV mapping is one of
those.
Of yourse you may rightly claim that adding an in-depth explanation of
UV mapping, with examples and all, to the _tutorial_ would do the docs
some good. I wouldn't argue with that; currently all we have is a
section on UV mapping in mesh2.
> "Look, newbie - the docs say exactly that, and we're all telling you that the
> text isn't inconsistent with what happens..."
> Very technically correct in highly qualified courtroom attorney-shyster
> legalese, but of no use to the first-time, or even sometimes the tenth-time or
> hundredth-time reader.
"I failed to understand this documentation, so I turn to complaining
about the documentation" - also a not too uncommon and not too helpful
schtick.
There is certainly a point to it when the person is an average member of
the target audience, because it may be an indication that the
documentation is indeed missing its audience. Hoever,
(a) that point is moot if the person isn't a member of the target
audience in the first place (because the document in question presumes
certain background knowledge) or is the only person who happens to not
get this part of the documentation, and
(b) if what you really want is an explanation (as opposed to a
discussion about whether the docs are good or not), don't complain about
the docs; rather, ASK FOR AN EXPLANATION.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.09.2018 um 08:37 schrieb Thomas de Groot:
> I am not sure I understand what I am looking at. The shadows suggest a
> thoroughly torn up object (the shredding I suppose).
I think it's a Calabi-Yau manifold...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Technically, that would not be an explanation, but an example.
I want my POV-Ray lawyer.
> You're right in that the docs on POV-Ray's UV mapping implementation
> apparently presume the user is already familiar with the concept of UV
> mapping.
> For a person familiar with the concept, I think it is pretty
> self-evident what `uv_vectors` does.
I'm not really sure what the point of that is.
You may as well have a "dataless" document.
The people who don't know what the data means won't understand it, and the ones
who already understand it don't need to see it.
It seems like some strange "documentation for the sake of documentation" rather
than what I'd expect all of that work that went into preparing it to be for -
being a manual for the user. There's a whole cubic mapping diagram to show how
a texture wraps around a cube. An additional sentence or two - as explanation,
or example - either, or, or both - would likely suffice.
> Note that you're looking at the reference section, not a tutorial. I
> think it is legitimate to expect the reference section's reader to be
> already familiar with common 3D graphics concepts; UV mapping is one of
> those.
I think this is setting up a false dichotomy.
Either all you need is a blurb that you're already expected to understand - or
you need a full-color 10-page tutorial.
I think there's quite a lot of POV-Ray users - be they the "target audience" or
not - that often point out that the documentation falls just shy of dispelling
the confusion they have about a topic.
You can call them "complaints" - but I believe they are observations offered as
suggestions and solutions, and improvements.
>
> Of yourse you may rightly claim that adding an in-depth explanation of
> UV mapping, with examples and all, to the _tutorial_ would do the docs
> some good. I wouldn't argue with that; currently all we have is a
> section on UV mapping in mesh2.
Certainly a tutorial would be nice, as would something that touches on
UV-unwrapping, but I think that a few extra lines in the reference section would
be the easiest and most likely to be completed first step.
> "I failed to understand this documentation, so I turn to complaining
> about the documentation" - also a not too uncommon and not too helpful
> schtick.
Characterize it however you'd like.
It's an open-source free software package offered to the public, and one would
hope that this is a forum where open an honest discussion is encouraged.
I've voiced my observations, concerns, and suggestions for making the learning
curve a little easier to climb.
> There is certainly a point to it when the person is an average member of
> the target audience, because it may be an indication that the
> documentation is indeed missing its audience. Hoever,
>
> (a) that point is moot if the person isn't a member of the target
> audience in the first place (because the document in question presumes
> certain background knowledge) or is the only person who happens to not
> get this part of the documentation, and
Take a poll.
> (b) if what you really want is an explanation (as opposed to a
> discussion about whether the docs are good or not), don't complain about
> the docs; rather, ASK FOR AN EXPLANATION.
Yes, I could, but I also see documentation as a way to preemptively address
topics that are likely to need clarification, so that people don;t have to open
the docs, search the docs, read the docs, and then search the forums, and sift
through all of the posts that may or may not eventually answer the question they
have. Which usually leads to the same questions being asked again and again,
rehashed, and then all of this might be repeated if something fundamental is
altered in a version change.
So I point out that the documentation doesn't seem to quite answer my question,
and the alert forum reader would surely, as an average member of my target
audience who is already familiar with common 3D graphics, and the software
package in particular, would be expected to understand that that I AM asking for
an explanation.
:P
I mean, I do try to do as much researching of a topic as I'm able to, before I
ask, and then I give it a go, and give thanks and credit.
But I don't believe I'm off-base.
http://news.povray.org/povray.advanced-users/message/%3Cweb.5b600737497a6101a47873e10%40news.povray.org%3E/#%3Cweb.5b60
0737497a6101a47873e10%40news.povray.org%3E
#GoKennethTheDestroyer
Kenneth. I want Kenneth as my POV-Ray lawyer.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.09.2018 um 01:07 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
>
>
>> Technically, that would not be an explanation, but an example.
>
> I want my POV-Ray lawyer.
>
>
>> You're right in that the docs on POV-Ray's UV mapping implementation
>> apparently presume the user is already familiar with the concept of UV
>> mapping.
>> For a person familiar with the concept, I think it is pretty
>> self-evident what `uv_vectors` does.
>
> I'm not really sure what the point of that is.
> You may as well have a "dataless" document.
> The people who don't know what the data means won't understand it, and the ones
> who already understand it don't need to see it.
The people familiar with the concept still need to know what the syntax
in POV-Ray is, what the defaults are, what caveats are there, and the
like. That's what reference docs are for.
Reference docs are for people who know what features the program has,
and how they work in general, but don't remember the details.
> It seems like some strange "documentation for the sake of documentation" rather
> than what I'd expect all of that work that went into preparing it to be for -
> being a manual for the user. There's a whole cubic mapping diagram to show how
> a texture wraps around a cube. An additional sentence or two - as explanation,
> or example - either, or, or both - would likely suffice.
Feel free to pick up the glove you've thrown at our feet, and
participate in making it better.
> Characterize it however you'd like.
> It's an open-source free software package offered to the public, and one would
> hope that this is a forum where open an honest discussion is encouraged.
> I've voiced my observations, concerns, and suggestions for making the learning
> curve a little easier to climb.
Open and honest discussion is nice, but it's not necessarily specific to
open source software.
The key feature of an open source project is that users can /actively/
participate in improving the software, rather than jsut talk about ways
to improve it.
So if you /really/ want the POV-Ray documentation improved, don't just
tell us in what ways it is wrong - get your hands dirty and write up
revised text for the section (or a completely new section), complete
with examples and images if you like, and contact Jim Holsenback to get
it into the Wiki (which will eventually end up in the inbuilt help).
> So I point out that the documentation doesn't seem to quite answer my question,
> and the alert forum reader would surely, as an average member of my target
> audience who is already familiar with common 3D graphics, and the software
> package in particular, would be expected to understand that that I AM asking for
> an explanation.
The question you ASKED was:
"Probably a dumb question, but can only meshes be UV mapped?"
That has been fully answered by Jerome, (A) by a list of UV-mapped
primitives and (B) by referene to said documentations section as his
source of information.
To which you replied with comments about that doc section, of which
we're currently specifically discussing the information about bezier
patches. Which definitely hinted at the fact that you consider the
documentation wanting in that area, but the wording left a lot of room
for interpretation:
- Did you just want to express your frustration, to vent a bit?
- Did you want to point out a problem that you had already overcome?
- Was this about the /location/ of the information, or its /extent/?
- ...
Don't make the same mistake countless of women make when talking to
their spouse: Don't expect me to successfully read between lines. I'm a
man, man ;)
> But I don't believe I'm off-base.
>
http://news.povray.org/povray.advanced-users/message/%3Cweb.5b600737497a6101a47873e10%40news.povray.org%3E/#%3Cweb.5b60
> 0737497a6101a47873e10%40news.povray.org%3E
>
> #GoKennethTheDestroyer
>
> Kenneth. I want Kenneth as my POV-Ray lawyer.
Who, BTW, explicitly confirmed that /my/ reply to that thread - and I
quote verbatim - "was... reasonable" ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So, you don't understand how UV mapping of Bezier patches works, and
want some clearer explanation?
Here's the deal:
In a sense, you can interpret Bezier patches as parametrics - except
that their functions are not specified explicitly, but rather are
bicubic polynomials (i.e. the sum of a[i,j]*u^i*v^j with i+j<=3, and
i,j>=0) defined implicitly via the control points.
The U coordinate runs along one edge, while the V coordinate runs along
the other edge.
Just like with parametrics, the U and V coordinates each run from 0 to 1
by default.
This default behaviour can be changed though, by specifying:
uv_vectors UV00, UV10, UV11, UV01
where UV00 through UV11 are 2D vectors: Each specify the values U and V
for one of the corner points of the patch. (Note that the corners are
specified in circular order rather than as a matrix.)
Typically, you would use the form
uv_vectors <Umin,Vmin>, <Umax,Vmin>, <Umax,Vmax>, <Umin,Vmax>
where Umin,Umax is the range for the U coordinate and Vmin,Vmax is the
range for the V coordinate.
If this special form is /not/ followed, things get a bit more
complicated; probably the easiest way to envision this is to consider
the function parameters and the UV mapping coordinates as separate
things (which is how it's actually implemented anyway); so for that sake
let's call the function parameters phi and theta; then the UV coordinate
for any given (phi;theta) parameter pair is computed as:
UV = UV00 * (1-phi) * (1-theta)
+ UV10 * phi * (1-theta)
+ UV01 * (1-phi) * theta
+ UV11 * phi * theta
This latter interpolation scheme is not explicitly mentioned in the
docs, so I had to dig in the source code for that.
Another important aspect the docs really /fail/ to mention is which
corners UV00, UV10, UV11 and UV01, respectively, correspond to. I
_think_ the correspondence is as follows:
UV01 aka "corner1" <-> Point_1
UV10 aka "corner2" <-> Point_4
UV11 aka "corner3" <-> Point_16
UV01 aka "corner4" <-> Point_13
but I might be mistaken; for instance, Point_4 and Point_16 could be
swapped. I would have to do more code diving for that, and I deem it
easier for the reader to just try it out than it would be for me to sift
through the source code. (Someone would have to do a reality-check on my
code digging results anyway.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6-9-2018 2:47, clipka wrote:
[snip]
> Don't make the same mistake countless of women make when talking to
> their spouse: Don't expect me to successfully read between lines. I'm a
> man, man ;)
>
ROFL !
[OT]
A typical conversion between me and my wife:
Wife: Give me the and go to the.
Me: Sorry. What do you want and where am I to go?
Wife: Oh! Are you stupid? Do I have to spell it out?!
We always make jokes about it afterwards of course. However, and
typically, that type of short-hand conversation between women is fluid,
albeit incomprehensible to the average man. ;-)
[/OT]
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5-9-2018 22:55, clipka wrote:
> Am 05.09.2018 um 08:37 schrieb Thomas de Groot:
>> I am not sure I understand what I am looking at. The shadows suggest a
>> thoroughly torn up object (the shredding I suppose).
>
> I think it's a Calabi-Yau manifold...
>
Ah... ok...
[scratches lice in pelt and shambles back to cave]
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/09/2018 07:41, Thomas de Groot wrote:
> On 6-9-2018 2:47, clipka wrote:
> [snip]
>> Don't make the same mistake countless of women make when talking to
>> their spouse: Don't expect me to successfully read between lines. I'm a
>> man, man ;)
>>
>
> ROFL !
>
> [OT]
>
> A typical conversion between me and my wife:
>
> Wife: Give me the and go to the.
>
> Me: Sorry. What do you want and where am I to go?
>
>
> We always make jokes about it afterwards of course. However, and
> typically, that type of short-hand conversation between women is fluid,
> albeit incomprehensible to the average man. ;-)
>
> [/OT]
>
I think that I've cracked it. I've learned to argue like a woman.
Go for the kidneys not the throat. ;)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Feel free to pick up the glove you've thrown at our feet, and
> participate in making it better.
> The key feature of an open source project is that users can /actively/
> participate in improving the software, rather than jsut talk about ways
> to improve it.
>
> So if you /really/ want the POV-Ray documentation improved, don't just
> tell us in what ways it is wrong - get your hands dirty and write up
> revised text for the section (or a completely new section), complete
> with examples and images if you like, and contact Jim Holsenback to get
> it into the Wiki (which will eventually end up in the inbuilt help).
http://news.povray.org/povray.advanced-users/message/%3Cweb.577ee122ff0686005e7df57c0%40news.povray.org%3E/#%3Cweb.577e
e122ff0686005e7df57c0%40news.povray.org%3E
> The question you ASKED was:
>
> "Probably a dumb question, but can only meshes be UV mapped?"
NOPE.
http://news.povray.org/povray.binaries.images/message/%3C5b8a7142%241%40news.povray.org%3E/#%3C5b8a7142%241%40news.povr
ay.org%3E
> That has been fully answered by Jerome, (A) by a list of UV-mapped
> primitives and (B) by referene to said documentations section as his
> source of information.
> Which definitely hinted at the fact that you consider the
> documentation wanting in that area, but the wording left a lot of room
> for interpretation:
It wasn't a hint - I came out and said that it was incomplete.
Here are the defaults, ... that can be changed.... ... ... ..." "."
"We're sorry, but the network executives have canceled this program..."
........
> - Was this about the /location/ of the information, or its /extent/?
https://i.imgur.com/Im2Hai0.jpg
> Don't make the same mistake countless of women make when talking to
> their spouse: Don't expect me to successfully read between lines. I'm a
> man, man ;)
I can't believe you just took advantage of this situation to flaunt your White
Male Privilege in the POV-Ray Patriarchy and a) assume my Gender, b) fail to
realize that YOUR gender is simply a fluid social construct, and c) Man-splain
to me. Jeez, you even gave me a hard time because my mod() operations weren't
BINARY.
:P
> > Kenneth. I want Kenneth as my POV-Ray lawyer.
>
> Who, BTW, explicitly confirmed that /my/ reply to that thread - and I
> quote verbatim - "was... reasonable" ;)
[ Way to move the goalposts. ]
Indeed, but that particular post bordered on fisticuffs with someone else, and
exemplified the ideology of, "You don't like it? Tough ----"
Still love what you do here, and that you have the energy and motivation to do
it.
But the documentation is still incomplete, right where I said it was and why.
Why can't you just admit it when you're WRONG?
Hrrrrmpfh. MEN.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
