 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
----------------------------------------------------------------
Some features I would like to see... (2)
----------------------------------------------------------------
As I already wrote, I use POV since v2 and I am always very
happy to see it progress. I am particulary pleased to see
unified patterns for everything (the autonomous halo patterns
in 3.0 surprised me as they were incoherent with the general
evolution - "fixed" in 3.1, cool).
The new media feature is great, as is the interior/texture
separation. Macros and #local are fantastic. But there is no
end to evolution, so here is my second wish list. Some items are
nearly cosmetic, others verge on the impossible.
My first wish-posting was of carefully collected items... I had
thinked for some time about them and thought they were valuable.
In this second list, although there are some forgotten items
from my first posting, many suggestions are very fresh and had
no time to mature... they surely reflect my current 'work' and
I may be the only one interested... be warned.
Features are listed in what I believe is an order of general
interest and 'possibleness'.
* First, and as promised, 'why isn't there an official POV wish
list / bug fixes, with votes?' (I know the answer: (1) because
nobody maintain one and (2) because it could be too much stress
on the pov team :) ).
* Interior-Finish secession permits the usage of (inexistent)
finish_map. I wait with impatience for:
finish{ average finish_map{[...
* Passing macro identifiers to macro;
* textures component extraction: e.g. something like
'texture{my_stone_tex}.normal', for use in macros;
* As suggested in the doc, permanent local identifiers;
* Why so much syntax difference between 2 dimensions vectors (.u,
.v), 3-4 dimensions vector (.x, .y, .z, .t), rgbft vectors, and
arrays ? (as you can see, I am very macro oriented);
* In texture_map & co, a way to transform the texture_mapping
pattern whithout affecting the mapped textures... I can do
this myself for translate, scale and and rotate - but I can't
for turbulences directives (example : try making a pattern of
wavy lines - whith marble and turbulence - and use this kind
of texture_map{ [0 text1] [.5 text1] [.5 text2] [1 text2]};
let text1 be checkerboard pattern... it is also afected by the
turbulence of the including pattern... if you find a direct
way to avoid this, let me know);
* bounded and clipped light_source;
* distance driven ADC_bailout for lights (in case of many fading
lights);
* seed-driven crand and jitter;
* emitting surfaces (and media?) for radiosity;
* a pov-programing tutorial (not scenes, but pov itself);
* An object-by-object, light-by-light control of lighting,
highlights and shadowcasting (e.g. mylight1 casts shadows from
myobject1, but does not with myobject2, while mylight2 does the
reverse at the same time). This is not very physical but very
usefull;
* special and spatial file format for image mapping - e.g. images
with more equally spaces points for spherical mapping;
* a render-in-time feature :) ... let me explain : set a maximum
time and (eventually) a maximum quality for a render, let pov
do a mosaic render (not preview) with priority, adaptative
subdivision - like an anti-alias that instead of averaging
pixels stores them in a ever refined image file... yep, this
could call to a new image file format. You could extend this
working to animations;
* a totally free camera : let the user define what objects are
projected on (polygon, cylinder, sphere,...), where rays are
coming from (from a point or perpendiculary to a line, curve,
plane, suface), and how the projected image is mapped on the
plane. A good begining would be images that are'nt centered on
the projected vanishing point (you can do this already by
cropping your image - I know).
None of these are requests. It's just a collection of suggestions
and reflections. Once again, I'd like to thank everybody who makes
this outstanding program possible.
Keep it going!
----------------------------------------------------------------
thank you thank you thank you thank you thank you thank you
----------------------------------------------------------------
THANK YOU FOR MAKING POV-RAY
Sincerely,
Philippe
----------------------------------------------------------------
POV INFO
----------------------------------------------------------------
POV-Ray for Windows
Version 3.1.beta.5.watcom.win32 [Pentium II optimised]
----------------------------------------------------------------
SYSTEM INFO
----------------------------------------------------------------
MS Windows 95 4.00.950 B
IE 4.0 4.711712.6
Pentium Pro 233MHz
64MB RAM
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 18 Aug 1998 23:04:19 +0200, Philippe Debar
<phi### [at] hotmail com> wrote:
>* First, and as promised, 'why isn't there an official POV wish
> list / bug fixes, with votes?' (I know the answer: (1) because
> nobody maintain one and (2) because it could be too much stress
> on the pov team :) ).
You forgot (3): most people don't understand that what they want is next to
impossible with the current architecture, so it doesn't do any good to know
that, say, nonlinear transforms are a popular wish. That said, it would be
nice to have a central repository of POV patches, bug fixes, wishes, and
other POV programming information. Twyst has told me he'll give me some
webspace if I want to put it together, but I'm debating whether I want to
take on the work.
Along the same lines, a list of the bugfixes for each release of POV,
including beta releases, sure would be nice.
>* Interior-Finish secession permits the usage of (inexistent)
> finish_map. I wait with impatience for:
> finish{ average finish_map{[...
I just wonder why image_map can't be used like any other pattern, making it
usable as a base for texture_map.
>* Why so much syntax difference between 2 dimensions vectors (.u,
> .v), 3-4 dimensions vector (.x, .y, .z, .t), rgbft vectors, and
> arrays ? (as you can see, I am very macro oriented);
You can use .x and .y with 2-d vectors as well, and I'm pretty sure you
can even use .u and .v with 3 and 4-d vectors, though it doesn't make sense
to do so. You can also use .red, .green, .blue, .filter, and .transmit with
vectors from 2 to 4 dimensions, whether they are colors or not. You just
use whichever one makes the most sense for what you're doing.
>* bounded and clipped light_source;
I have to admit that this would be nice, if for nothing else than simulating
specular reflection. What do you think the syntax should look like,
especially for clipping?
>* seed-driven crand and jitter;
The problem with this is that crand is also very dependent on how the rays
fall. This means that, for all practical purposes, crand would still be
useless for animations, because moving the camera or the textured object or
any intervening or reflecting objects would change how many times crand gets
called for a particular object.
>* a pov-programing tutorial (not scenes, but pov itself);
This is a very good idea, and I've told Twyst that if I ever find any free
time, I'd consider writing one for his page.
>* special and spatial file format for image mapping - e.g. images
> with more equally spaces points for spherical mapping;
Have you played with using a density pattern in a pigment statement yet?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 20 Aug 1998 22:27:58 +0200, Philippe Debar
<phi### [at] hotmailcom> wrote:
>Some answers to Ron Parker <35d9f8a6.0@news.povray.org>
> >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).
The problem here isn't one of syntax but one of a broken expression parser
that doesn't handle 2d vectors properly. I think it's finally been fixed.
> >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.
Ah. I see now that you and I have different views of what it means to clip
a light source. I was wanting to clip them so that they only illuminate,
say, the pyramidal area projected by a square cutout. Such light sources
could be used to simulate specular reflection from plane surfaces.
> >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.
Yep. I posted one a while back. I think it may have been in
povray.programming.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote in message <35dc8acf.0@news.povray.org>...
>> light_source { 0, color rgb 1 clipped_by{sphere{0,100}} translate
>>TheLight}
>Ah. I see now that you and I have different views of what it means to clip
>a light source. I was wanting to clip them so that they only illuminate,
>say, the pyramidal area projected by a square cutout. Such light sources
>could be used to simulate specular reflection from plane surfaces.
Right - I had some difficulties with understanding the clipping/reflection
relationship, but I got it... while replying last time. The sphere centered
on the
light example was very simple; but if you want:
light_source
{ 0 color rgb <1,1,1>
pped_by{
prism { .... conic_sweep.... matrix/*shearing*/} /* or any object you like */ }
}
The light_source doesn't have to be in the clipping object, even if it was
in my example. The syntax is simple, already learned and seemed logical
to me (and, yes, I am a bit lazy).
By the way, the cylindrical light_source does seem to be a clipped
light_source (from an user perspective - I dont know about the inner
working) so light_clipping should be possible in POV.
>Yep. I posted one a while back. I think it may have been in
>povray.programming.
I got it. That's already much better. Thank you very much.
Sincerely,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I was wanting to clip them so that they only illuminate,
> say, the pyramidal area projected by a square cutout. Such light sources
> could be used to simulate specular reflection from plane surfaces.
That's easy... A light source is a point. So create a spotlight
housing around it and scale it down to the equivalent of 0.01mm across.
-Robert Dawson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
