 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greetings !
Half question half feature change request !
Of all the features in Pov-Ray there is one that has properties
that make little sense when compared to the operations of other
features. This would be of course the image_map & and height_field
location.
Why is it when everything else is centered at origin these have
been implemented to start at origin and go to x1 y1 ? There is no
other feature, outside of the media feature and radiosity, that I
can think of, that causes more confusion for new users and old,
than this aggravating quirk.
Would it have been difficult to have had the image automatically
centered ? I think this behavior should be changed in Pov-Ray release
4.0 if at possible. It sure would ease the suffering of millions.
Another problem for many users has been the fact that image maps
act on a solid object the same as a pigment and or texture. That is
if applied to one side of an object it appears reversed on the opposite
side of the object. Perhaps it is time to implement a new option to the
image map feature to allow something like a hollow statement. This would
allow application of an image map to a single surface and not the entire
object. Handy for that beer bottle label, ship decal, and so on.
Comments and discussion encouraged.
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I agree with you one the centering of image_maps, since that what everyone
tends to do anyway before applying any tranformations. (ie. translate <-.5,
-.5, 0>). Same deal with height_fields.
The other thing you bring up is a little more complicated. I don't think it
would be easy to have an image apply to only one part of an object. That
would be handled better with parametric mapping, but that would mean having
to create a UV space for all primitives. For a sphere that should be simple
enough, since that's pretty much covered by spherical mapping anyway. A box
would have to be split up a bit. Cylinder even harder. Sor...hmm.
Maybe it could happen someday.
-Mike
Ken wrote:
> Greetings !
>
> Half question half feature change request !
>
> Of all the features in Pov-Ray there is one that has properties
> that make little sense when compared to the operations of other
> features. This would be of course the image_map & and height_field
> location.
> Why is it when everything else is centered at origin these have
> been implemented to start at origin and go to x1 y1 ? There is no
> other feature, outside of the media feature and radiosity, that I
> can think of, that causes more confusion for new users and old,
> than this aggravating quirk.
> Would it have been difficult to have had the image automatically
> centered ? I think this behavior should be changed in Pov-Ray release
> 4.0 if at possible. It sure would ease the suffering of millions.
>
> Another problem for many users has been the fact that image maps
> act on a solid object the same as a pigment and or texture. That is
> if applied to one side of an object it appears reversed on the opposite
> side of the object. Perhaps it is time to implement a new option to the
> image map feature to allow something like a hollow statement. This would
>
> allow application of an image map to a single surface and not the entire
>
> object. Handy for that beer bottle label, ship decal, and so on.
>
> Comments and discussion encouraged.
>
> Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> Why is it when everything else is centered at origin these have
> been implemented to start at origin and go to x1 y1 ? There is no
> other feature, outside of the media feature and radiosity, that I
> can think of, that causes more confusion for new users and old,
> than this aggravating quirk.
> Would it have been difficult to have had the image automatically
> centered ? I think this behavior should be changed in Pov-Ray release
> 4.0 if at possible. It sure would ease the suffering of millions.
I respectfully disagree. The documentation is incredibly clear.
A simple "translate <-0.5, -0.5, -0.5>" centers things -- this is
so trivial there is no reason to change the source code.
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan Connelly wrote:
> I respectfully disagree. The documentation is incredibly clear.
> A simple "translate <-0.5, -0.5, -0.5>" centers things -- this is
> so trivial there is no reason to change the source code.
>
> --
> http://www.flash.net/~djconnel/
I respectfully disagree with your respectful disagreement.
Your simple example is 28 characters long. That's a lot
of simple typing. Nor does it redily explain the ambiguity.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
IRDWYDOMD :).
There is no ambiguity -- the docs are incredibly clear.
If you mean consistency, it isn'c clear to me it requires height fields
be centered. Boxes aren't. And it is conventional to assign coordinates to raster
images with the origin at a corner. Either centered or uncentered
would be justified.
And if you want to count characters, just do "translate -0.5" .
You can even assign this to a macro to make your own "keyword".
There's no reason to clutter up the official keyword list.
Dan
Ken wrote:
>
> Dan Connelly wrote:
>
> > I respectfully disagree. The documentation is incredibly clear.
> > A simple "translate <-0.5, -0.5, -0.5>" centers things -- this is
> > so trivial there is no reason to change the source code.
> >
> > --
> > http://www.flash.net/~djconnel/
>
> I respectfully disagree with your respectful disagreement.
> Your simple example is 28 characters long. That's a lot
> of simple typing. Nor does it redily explain the ambiguity.
>
> Ken
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think that a simple translate is best, anyhow, who's poor figners cannot
take the miniscule extra effort to type a translate command, hell the amount
you just wrote they must be worn down to the stumps, i hope your medical
insurance covers this.
and while were on the subject, what is the point of fixing something that
isnt broken, if it works, LIVE WITH IT.
Rick
Dan Connelly wrote in message <364### [at] flash net>...
>IRDWYDOMD :).
>
>There is no ambiguity -- the docs are incredibly clear.
>
>If you mean consistency, it isn'c clear to me it requires height fields
>be centered. Boxes aren't. And it is conventional to assign coordinates
to raster
>images with the origin at a corner. Either centered or uncentered
>would be justified.
>
>And if you want to count characters, just do "translate -0.5" .
>You can even assign this to a macro to make your own "keyword".
>There's no reason to clutter up the official keyword list.
>
>Dan
>
>Ken wrote:
>>
>> Dan Connelly wrote:
>>
>> > I respectfully disagree. The documentation is incredibly clear.
>> > A simple "translate <-0.5, -0.5, -0.5>" centers things -- this is
>> > so trivial there is no reason to change the source code.
>> >
>> > --
>> > http://www.flash.net/~djconnel/
>>
>> I respectfully disagree with your respectful disagreement.
>> Your simple example is 28 characters long. That's a lot
>> of simple typing. Nor does it redily explain the ambiguity.
>>
>> Ken
>
>--
>http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yeah, I also agree that centering image_maps would be logical, but it has never
annoyed me, so I haven't complained. Getting height_hields to look right is a
pain anyway, so the translate -.5 thingy kinda doesn't matter. Still, you have a
point.
The other problem is much more important. I don't think it's very difficult (to
somebody much wiser than me ;)). You shouldn't need any parametric mapping in
many cases (like applying an image to only one side of a polygon or cylinder).
This is how I imagine it: if the outside surface is hit by the sample ray,
calculate the map color; if the inside is hit, don't calculate. This should be a
sufficient solution in most cases (like the bottle label example).
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike wrote:
>
> The other thing you bring up is a little more complicated. I don't think it
> would be easy to have an image apply to only one part of an object. That
> would be handled better with parametric mapping, but that would mean having
> to create a UV space for all primitives. For a sphere that should be simple
> enough, since that's pretty much covered by spherical mapping anyway. A box
> would have to be split up a bit. Cylinder even harder. Sor...hmm.
>
> Maybe it could happen someday.
>
> -Mike
>
Maybe it will happen today. ;-) Go to
http://nathan.kopp.com/patched.htm
to get my unofficial version of POV-Ray that includes limited (but mostly bug
free) surface mapping (or parametric mapping or uv mapping or whatever you want
to call it). It currently works for bicubic_patch, mesh, mesh2 (a new syntax
for the mesh object), lathe, sor, sphere, and box.
You could also get the SuperPatch from Twyst's patchstation, since it includes
most of my surface-mapping code (I think it is currently lacking the code for
lathe & sor). If you don't need the lathe/sor stuff, you should probably get
the superpatch since it has all sorts of other really cool features. :-)
Just remember... these are unofficial versions of POV so don't expect any help
from the POV Team.
-Nathan Kopp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan Connelly wrote:
> this is so trivial there is no reason to change the source code.
>
> --
> http://www.flash.net/~djconnel/
I don't believe it's any less trivial than wanting 4 demensional
vectors added to the source code. I have recently seen requests
for that too. Seems strange in light of the fact you can describe
any point in space with the current 3 demensional coordinate
system currently in use.
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> Dan Connelly wrote:
>
> > this is so trivial there is no reason to change the source code.
> >
> > --
> > http://www.flash.net/~djconnel/
>
> I don't believe it's any less trivial than wanting 4 demensional
> vectors added to the source code. I have recently seen requests
> for that too. Seems strange in light of the fact you can describe
> any point in space with the current 3 demensional coordinate
> system currently in use.
You can't apply built in vector ops to homebrew 4d vectors as it is.
This means that you have to do it explicitly with (slow) macros. With
4d position vectors, you can easily program things that use homogenous
coordinates (i.e. rational splines, making homebrew NURBS reasonably
easy). The image map thing is just a matter of an extra line of pov
code, 4d (and more) vectors make whole new capabilities feasible.
Jerry Anning
cle### [at] dholcom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
