 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have some questions on which approch to take with the HF macros.
Should they keep the current string input or take functions directly as
input? Taking functions directly is how the macros were originally intended,
but the string method makes it possible to also use macros as input which
makes some things possible that can't be done with functions.
Should they take the input height data from a standard 2d square from <0,0>
to <1,1> (like UV mapping and like the height_field object works) or should
they take the height data from the points in 3D space where the surface is
(just like a solid texture works)? If the latter is decided, I think they
should be named to something else than HF_*, as it is inconsistent with the
basic concept of the height_field object. It's more like displacement
mapping.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> I have some questions on which approch to take with the HF macros.
>
> Should they keep the current string input or take functions directly as
> input? Taking functions directly is how the macros were originally intended,
> but the string method makes it possible to also use macros as input which
> makes some things possible that can't be done with functions.
Although there are some things where macros could be useful, the ugly
ParseString() construction is reason enough to use only functions IMO.
> Should they take the input height data from a standard 2d square from <0,0>
> to <1,1> (like UV mapping and like the height_field object works) or should
> they take the height data from the points in 3D space where the surface is
> (just like a solid texture works)? If the latter is decided, I think they
> should be named to something else than HF_*, as it is inconsistent with the
> basic concept of the height_field object. It's more like displacement
> mapping.
I think at least for the cylinder both versions have their advantage, for
sphere, the 'displacement mapping' style is probably more useful and for
square it's just a matter of scaling. Maybe adding an uv-mapping
parameter would be good.
Another thing that should be changed: The files generated with
'OutputToFile' have no line breaks which makes it difficult to edit them
manually. There should be one after each triangle i think.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c778848@news.povray.org>,
"Rune" <run### [at] mobilixnet dk> wrote:
> Should they take the input height data from a standard 2d square from <0,0>
> to <1,1> (like UV mapping and like the height_field object works) or should
> they take the height data from the points in 3D space where the surface is
> (just like a solid texture works)?
I designed them to operate this way for a reason. They are most often
going to be used with built-in patterns and user defined functions,
taking the points in space allows them to be done without seams, and in
the case of the sphere, without "pinching" at the poles. If the <0, 0>
to < 1, 1> range is used, this will be impossible without using
image_maps with specially generated images. This way, you can easily
adapt images simply by using the existing mappings (an extra keyword and
number), but don't have to go through any extra work to get a clean
fully-procedural object.
They aren't tied to images like the built-in primitive originally was,
there is no reason to force them into the <0, 0> to < 1, 1> range.
> If the latter is decided, I think they should be named to something
> else than HF_*, as it is inconsistent with the basic concept of the
> height_field object. It's more like displacement mapping.
I do not see how it is inconsistent with the idea of a height field.
They are still "height fields", they are objects in which the height
varies...they take their heights from a function, but image data is not
necessary for the definition. They operate slightly differently from the
height field object, because they aren't subject to the same
constraints, but the differences are well documented.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" wrote:
> They are most often going to be used with built-in
> patterns and user defined functions, taking the points
> in space allows them to be done without seams, and in
> the case of the sphere, without "pinching" at the poles.
I'm aware of this, but there are also cases where one does indeed want to
use a specially designed image_map. I think it'd be best to provide the
option to use either method.
> This way, you can easily adapt images simply by using
> the existing mappings (an extra keyword and number)
No, aligning the pattern right can be a big problem. Imagine a cylinder
going from <1,2,3> to <6,5,4> - not so easy to fit the pattern to that
object. So I think that the option to use the <0,0> to <1,1> area should be
internally supported in the macros.
> They are still "height fields", they are objects in
> which the height varies...
Ask anyone about the height of a cylinder, and you'll get an answer that
certainly doesn't fit which the definition of height in the macros in
question. "Height" does not make sense for a cylinder, and for a sphere it
only applies if the context is making planetoids.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c77b483@news.povray.org>,
"Rune" <run### [at] mobilixnetdk> wrote:
> I'm aware of this, but there are also cases where one does indeed want to
> use a specially designed image_map. I think it'd be best to provide the
> option to use either method.
There is an option.
> No, aligning the pattern right can be a big problem. Imagine a cylinder
> going from <1,2,3> to <6,5,4> - not so easy to fit the pattern to that
> object. So I think that the option to use the <0,0> to <1,1> area should be
> internally supported in the macros.
Hmm...I'd say this is a deficiency of the mapping warps, not of the
macros.
> Ask anyone about the height of a cylinder, and you'll get an answer that
> certainly doesn't fit which the definition of height in the macros in
> question. "Height" does not make sense for a cylinder, and for a sphere it
> only applies if the context is making planetoids.
Look for "spherical height field" and "cylinderical height field"...I
didn't make them up. The definition certainly does match what the macros
use...height on a sphere is the distance from the center, on a cylinder
it is distance from the axis (relative to the surface of a perfect
sphere or cylinder...a height of 0 on a 1 unit radius spherical height
field is 1 unit from the center).
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> Although there are some things where macros could be useful, the ugly
> ParseString() construction is reason enough to use only functions IMO.
This gets my vote as well.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" wrote:
> "Rune" wrote:
> > I'm aware of this, but there are also cases where
> > one does indeed want to use a specially designed
> > image_map. I think it'd be best to provide the
> > option to use either method.
>
> There is an option.
What option?
> Hmm...I'd say this is a deficiency of the
> mapping warps, not of the macros.
The mapping warps were never designed to apply to an object with any
alignment in space. Thus the mappings can't be used for the purpose of
mapping the square from <0,0> to <1,1> onto any sphere or cylinder without
considerable work from the user. That's why I want it to be an option
directly implemented in the macros.
> Look for "spherical height field" and "cylinderical height field"...
Look where? Where can I find the definitions?
By the way, "cylinderical" is spelled wrong and the wrong spelling seems to
have made it into the documentation. The correct spelling is "cylindrical".
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c77f65e@news.povray.org>,
"Rune" <run### [at] mobilixnetdk> wrote:
> What option?
The mapping warps/image map mappings.
> The mapping warps were never designed to apply to an object with any
> alignment in space. Thus the mappings can't be used for the purpose of
> mapping the square from <0,0> to <1,1> onto any sphere or cylinder without
> considerable work from the user. That's why I want it to be an option
> directly implemented in the macros.
As I said, a deficiency of the mappings. And it isn't that much
work...at least, no more work than mapping an image texture onto a
cylinder. A set of macros to automate the mapping (MapSphere() and
MapCylinder() for example) might be useful (and would work anywhere you
need the mapping, not just in the height field macros), but it doesn't
belong in the height field macros.
> > Look for "spherical height field" and "cylinderical height field"...
>
> Look where? Where can I find the definitions?
Google popped up a few. Polyray has both as primitives, Virtualight has
a spherical height field. Fractal Terrains uses spherical height fields
for planets, and has a nice, simple description: "every latitude,
longitude position has a radial offset from a perfect sphere". There
have been utilities that output POV-Ray mesh files for these shapes.
(Orb and Cyl for example)
> By the way, "cylinderical" is spelled wrong and the wrong spelling seems to
> have made it into the documentation. The correct spelling is "cylindrical".
The spelling "cylinderical" is very commonly used, and is one I
personally have a hard time avoiding. :-(
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" wrote:
> As I said, a deficiency of the mappings. And it
> isn't that much work...at least, no more work
> than mapping an image texture onto a cylinder.
Which is quite some work that could easily make a user give up.
> A set of macros to automate the mapping (MapSphere()
> and MapCylinder() for example) might be useful
I don't see why it should be made so difficult for the user when the same
could be obtained by adding a new parameter (UV-mapping) to the HF macros
which could simply be set to true or false. If set to false they would work
as currently, if set to true they would take the data from the <0,0> to
<1,1> square. Can't be more simple than that.
What you propose would at the very least require the user to specify the
location/end points and radius twice, one time for the HF macros themselves
and again to make the mapping properly aligned. I think that's a bad
solution.
> it doesn't belong in the height field macros.
I disagree.
For the record I was asking for opinions and I've seen that dropping the
parse_string method is preferred and the HF names can also be kept. But I
have yet to see a good argument why the user should not be given the options
to use either UV mapping of the height data or not, with just a simple
switch.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
