Some answers to Ron Parker <35d9f8a6.0@news.povray.org>

   >You forgot (3): most people don't understand that what they want is next
to
   >impossible with the current architecture...

Well, I surely fall into that category: what I know of POV is (a part of)
what is
in the doc. But currently inimplementable is already far better then
impossible:
you can hope.


   >...but I'm debating whether I want to take on the work.

It surely is quite a task. I thought maybe the IRTC could, as they already
have web votes implemented. But I guess they have enough work already.


  >I just wonder why image_map can't be used like any other pattern, making
it
  >usable as a base for texture_map.

...and why the restrictions on layered textures and texture_map?


   >You can use .x and .y with 2-d vectors as well ...

I just had a small battle with vector promotion and extraction. In v3.1b5,
operator
.v seems to invoke an error whenever it is used (2d or3d vectors). Promotion
doesn't
work as I thought it should :-) <3,4> + z doesn't output <3,4,1> (I think I
got <3,3,3>,
but I am not sure anymore).


   >bounded and clipped light_source - What do you think the syntax should
look like?

Keep it simple and coherent, so something like:
   light_source { 0, color rgb 1 clipped_by{sphere{0,100}} translate
TheLight}
seems to me to be the most logical.


   >a pov-programing tutorial - I've told Twyst that if I ever find any free
   >time, I'd consider writing one for his page.

Get some free time!  Get some free time!  Get some free time!  :-)



   >special and spatial file format for image mapping -
   >Have you played with using a density pattern in a pigment statement yet?

Do you mean df3 files? If so, I'd like to, but I am lost at sea as how to
generate
them. The file format description in the doc is a bit to technical for me.
If ever
you know the location of a better description, let me know - thanks.

Post a reply to this message