 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlink net> wrote:
> The only problem with a function image is the really odd 'upside-down mirror
> image' behavior of the resulting pattern 'slice' (at least when it's used to
> make a HF, anyway.) Try making a function image from an image_map to see what I
> mean.
Ah, so *that's* why I found myself in need of a scale <1,1,-1> when I migrated a
particular scene from an auto-generated mesh to an auto-generated-df3-based
height field these days...
I actually have an Idea how this came to be so:
Where's <0,0> in an image?
In a POV context, for some reason I'd be quite quick to claim that it must be
the bottom left corner.
In an image editing context, however, (0;0) classically designates the top left
corner.
So height field code, normally dealing with images, might have to swap around
the image's y co-ordinate for proper operation. And it might do just the same
for function images - but the function images may fail to do a similar
re-normalization for the input pattern.
So the issue may actually be in function images in general, not patterns in
height fields (after all, if I'm not mistaken, function images are the only way
to create a height field from a pattern in the first place).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote:
> > The only problem with a function image is the really odd 'upside-down mirror
> > image' behavior of the resulting pattern 'slice' (at least when it's used to
> > make a HF, anyway.) Try making a function image from an image_map to see
> > what I mean.
>
> Ah, so *that's* why I found myself in need of a scale <1,1,-1> when I
> migrated a particular scene from an auto-generated mesh to an
> auto-generated-df3-based height field these days...
>
> I actually have an Idea how this came to be so:
>
> Where's <0,0> in an image?
>
> In a POV context, for some reason I'd be quite quick to claim that it must be
> the bottom left corner.
>
> In an image editing context, however, (0,0) classically designates the top
> left corner.
YES, you've hit the nail squarely on the head. The x/z 'origin' of an image_map
function in POV_Ray is, strangely enough, at <0,1>, not <0,0>. That took me a
bit of experimenting to find. And your explanation of how it possibly came to
be is the final piece of info that solves the puzzle. Yet *at the moment* I'm
not so sure now that the same thing applies to POV pigments or patterns (see
below.)
>
> So height field code, normally dealing with images, might have to swap around
> the image's y co-ordinate for proper operation. And it might do just the same
> for function images - but the function images may fail to do a similar
> re-normalization for the input pattern.
> So the issue may actually be in function images in general, not patterns in
> height fields...
Since posting my reply, I've gone back for yet *another* round of experimenting
with function images and HFs (this time using the HF_Square macro in
shapes.inc), and I've seen some odd behavior. Part of that is due to a problem
in that macro itself (which I just found a fix for); but my 'fix'--to reorient
how the macro 'sees' an image_map function--does not seem to operate the same
way on functions made from POV-Ray pigments or patterns. I'm getting
conflicting results, in several different ways, so--whether dealing with this
HF macro or a regular HF-- I'm not so sure now that pigments/patterns and
image_maps are even operating the 'same' way when 'functionalized.' Using the
HEXAGON and RADIAL patterns--which have a definite 'direction' or
orientation--they come out looking *exactly* the way they should when used in
the HF_Square macro--no 'mirror image' stuff to contend with, no altered x/z
origin point. Yet an image_map function there DOES need my fix (as a
similar-but-different 'mirror-image' fix was required in a regular HF.) I need
to go back to a 'regular' HF and see if those two specific patterns show up
correctly there as well.
It's all quite weird, and I continue to experiment. I think I *can* say this: A
regular HF and the HF_Square macro seem to operate differently when presented
with functions. (Not so weird in itself; they probably have different code
paradigms.) But nailing down that difference--and the image_map vs.
pigment/pattern discrepancies--is taking some time and thought.
>
> ...(after all, if I'm not mistaken, function images are the only
> way to create a height field from a pattern in the first place).
Yes, that's the only way I know of too.
KW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> Since posting my reply, I've gone back for yet *another* round of
> experimenting with function images and HFs (this time using the HF_Square
> macro in shapes.inc), and I've seen some odd behavior. Part of that is due
> to a problem in that macro itself (which I just found a fix for); but my
> 'fix'--to reorient how the macro 'sees' an image_map function--does not seem
> to operate the same way on functions made from POV-Ray pigments or patterns.
After more work, I decided against using that macro fix, as it really wasn't
needed (the problem was better solved outside the macro.) Instead, there seems
to be *something* basically weird, having to do with how functions 'see'
image_maps (as opposed to how they deal with pigments/patterns); I even have
questions now about functions supposedly "evaluating the pattern on the X/Y
plane". Trying to sort it all out is rather complex and mind-numbing--but I'm
getting *closer* to an answer!
KW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
>...but my 'fix'--to reorient
> how the macro 'sees' an image_map function--does not seem to operate the same
> way on functions made from POV-Ray pigments or patterns. I'm getting
> conflicting results, in several different ways...
I know I'm getting further and further off-topic with this little discussion,
but I just found out something interesting (and definitely weird):
When a function is used in the HF_Square macro in shapes.inc--supposedly the
'equivalent' of POV's regular HF--the function (whether of a pigment/pattern OR
an image_map) actually evaluates the pattern 'slice' on the X/Z plane(!) rather
than the X/Y plane as it is supposed to. That explains lots of things!
OK, enough. :-) I'll continue with this in its own post.
KW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> "clipka" <nomail@nomail> wrote:
> > ...(after all, if I'm not mistaken, function images are the only
> > way to create a height field from a pattern in the first place).
>
> Yes, that's the only way I know of too.
Just an aside to your discussion, obviously, but...
What about using a regular pigment function in the height field? Or a pigment
function called at <x,0,z> in an isosurface? (Not strictly a heightfield but
you get the same effect.) Or, of course, you could always write your own
heightfield macro...
As always, plenty of ways to skin a cat... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> After more work, I decided against using that macro fix, as it really wasn't
> needed (the problem was better solved outside the macro.) Instead, there seems
> to be *something* basically weird, having to do with how functions 'see'
> image_maps (as opposed to how they deal with pigments/patterns); I even have
> questions now about functions supposedly "evaluating the pattern on the X/Y
> plane". Trying to sort it all out is rather complex and mind-numbing--but I'm
> getting *closer* to an answer!
Make sure you're not messing up these two in your experiments:
function { pattern { MyPattern } }
function 20, 20 { pattern { MyPattern } }
They do totally different things. The former lets you use patterns where POV
would expect a function, by merely providing a wrapper; the latter lets you use
patterns where POV would expect an image, by actually sampling a slice of the
pattern in advance.
The former is officially called a "pattern function"; the latter is called a
"function image" or "internal bitmap"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> When a function is used in the HF_Square macro in shapes.inc--supposedly the
> 'equivalent' of POV's regular HF--the function (whether of a pigment/pattern OR
> an image_map) actually evaluates the pattern 'slice' on the X/Z plane(!) rather
> than the X/Y plane as it is supposed to. That explains lots of things!
No, that's actually documented:
"The function values used for the heights will be taken from the square that
goes from <0,0,0> to <1,1,0> if UV height mapping is on. Otherwise the function
values will be taken from the points where the surface is (before the
deformation)."
As the HF_Square macro will build a height field over the X/Z plane, you'd need
to set the UseUVheight parameter to true to get the samples from the X/Y plane.
The regular height_field is always in "UseUVheight" mode, so to speak.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> > > ...(after all, if I'm not mistaken, function images are the only
> > > way to create a height field from a pattern in the first place).
> >
> Just an aside to your discussion, obviously, but...
>
> What about using a regular pigment function in the height field?
You always need an image (= image file or "internal image" aka "function image")
to generate the height field from... or do you know some other way?
> Or a pigment
> function called at <x,0,z> in an isosurface? (Not strictly a heightfield but
> you get the same effect.) Or, of course, you could always write your own
> heightfield macro...
>
> As always, plenty of ways to skin a cat... :)
At other occasions I'd fully agree with you (after all, POV is mostly
"tri-vial", you know ;)), but we're talking specifically about height_field
objects here.
(Well, the isosurface solution won't work as you described anyway, because it
needs some gradient mixed in to act as a height field substitute :P)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> "Bill Pragnell" <bil### [at] hotmailcom> wrote:
> > > > ...(after all, if I'm not mistaken, function images are the only
> > > > way to create a height field from a pattern in the first place).
> > >
> > Just an aside to your discussion, obviously, but...
> >
> > What about using a regular pigment function in the height field?
>
> You always need an image (= image file or "internal image" aka "function image")
> to generate the height field from... or do you know some other way?
Apologies, I think we're talking about the same thing. You don't need any
"image" related SDL keywords, that's what confused me (without having looked it
up till now)!
> At other occasions I'd fully agree with you (after all, POV is mostly
> "tri-vial", you know ;)), but we're talking specifically about height_field
> objects here.
The 'tri-vial' was indeed my angle :) Yes, fair enough, the underscore seemed to
get lost somewhere, I was thinking of general solutions.
> (Well, the isosurface solution won't work as you described anyway, because it
> needs some gradient mixed in to act as a height field substitute :P)
Yes. Well, I didn't really describe it at all :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
High!
Cousin Ricky wrote:
> I didn't make a Trinidad and Tobago; not enough of a challenge, I
> guess. Instead I submit nearby countries Barbados and St. Vincent and
> the Grenadines. (I have flags languishing of even closer countries,
> Venezuela (which is a good swim from Trinidad) and Grenada, as well as
> T&T itself. However, they are from my pre-POV-Ray days.)
Impressive... how did you the coats-of-arms of the Virgin Islands? Did
you use that famous Python script to convert GIMP bezier paths into POV
splines?
I plan to do two versions for each country, a simple one and a more
intricated one containing also the coat-of-arms (if given), depending on
the use of the texture.
Here is what I put together up to now:
1. Afghanistan (of course ;-))
2. Poland
3. Spain
4. Switzerland
...more to come!
See you in Khyberspace! (yes, there will be also flags of POVghanistan
and Khyberspace!)
Yadgar
Post a reply to this message
Attachments:
Download 'flag_afghanistan.png' (2 KB)
Download 'flag_poland.png' (2 KB)
Download 'flag_spain.png' (2 KB)
Download 'flag_switzerland.png' (2 KB)
Preview of image 'flag_afghanistan.png'
Preview of image 'flag_poland.png'
Preview of image 'flag_spain.png'
Preview of image 'flag_switzerland.png'
|
|
| |
| |
|
|
|
|
| |
|
|
