![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Just some "small" things that I'd like to see one day. I have no idea how
difficult they might be to implement.
* add a float factor for :
"shadowless", "no_shadow", "double_illuminate", "no_reflection" and
"no_image" (any other?)
used like this :
shadowless <amount>
shadowless // use as always
shadowless 0 // does nothing
shadowless 1 // as shadowless
shadowless .33 // like an intensity*.66 normal light_source plus an
intensity*.33 shadowless light_source
* "blinn_ior" distinct from interior{ior} - maybe use the interior ior value
if no blinn_ior specified
* should "no_shadow" and "shadowless" be interchangeable ? (as there can be
no mistake as to whether the keyword is in an object or in a light and they
serve a _very_ similar purpose).
* could a "no_highlight" (or rather a "highlightless") keyword added and the
highlightlessness be dissociated from shadowlessness?
* support of this syntax :
WARP:
warp{WARP_ITEM TRANSFORMATIONS}
instead of always doing "inverse transform, warp{}, transform" (even if it
is done so internally).
* would a no_radiosity (for objects) and a radiosityless (for lights) be
possible? (I have a hunch that this one would be quite difficult.)
Could my dreams ever come true? (but one as somebody said here some time
ago...)
Any wish granting will be greatly appreciated.
Povingly,
Philippe
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39e17f7c@news.povray.org>, "Philippe Debar"
<phi### [at] hotmail com> wrote:
> * add a float factor for :
> "shadowless", "no_shadow", "double_illuminate", "no_reflection" and
> "no_image" (any other?)
Possible, though I don't know how useful most would be. A better idea
for some, like double_illuminate, would be a pigment to specify the
color of the illumination. For shadowless/no_shadow, you can simply use
a semitransparent object. For no_reflection and no_image, you could
probably easily do whatever you want with combinations of opaque and
semitransparent versions of the object.
> * "blinn_ior" distinct from interior{ior} - maybe use the interior ior
> value if no blinn_ior specified
This could be an optional parameter for the blinn highlight, you
wouldn't even need to add an extra keyword...but it might calculate the
ior from the differences in ior between objects, like it does for
refraction, which might make this more difficult.
> * should "no_shadow" and "shadowless" be interchangeable ? (as there
> can be no mistake as to whether the keyword is in an object or in a
> light and they serve a _very_ similar purpose).
I think both should use the "shadowless" keyword(or even better,
"shadows on|off"). "no_shadow" implies one shadow, and there can easily
be more...and besides, it has one of those pesky underscore marks which
I find slow typing down.
> * could a "no_highlight" (or rather a "highlightless") keyword added and
> the highlightlessness be dissociated from shadowlessness?
How about a "highlights on|off" keyword? Or even better, control of
specific types of highlights..."specular on|off", "phong on|off", "blinn
on|off".
> * support of this syntax :
> WARP:
> warp{WARP_ITEM TRANSFORMATIONS}
> instead of always doing "inverse transform, warp{}, transform" (even
> if it is done so internally).
Would allowing transformations to be done within the warp{} block be
what you want? Or are you talking about transforming the warps
themselves?
I think it could be useful if you could use scale, translate, etc. as
warps in the warp{} block, this would be a better solution to the
problem my "scaled turbulence" patch tries to solve.
> * would a no_radiosity (for objects) and a radiosityless (for lights) be
> possible? (I have a hunch that this one would be quite difficult.)
Again, I would like "radiosity on|off" better...I just prefer the
"feature on|off" syntax to a keyword that turns things on or off.
And I don't think it would be possible to exclude lights. Objects would
be different though...I think "no_image" makes them invisible to
radiosity(though it also makes them invisible to you...).
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] mac com> wrote:
: For shadowless/no_shadow, you can simply use a semitransparent object.
It's not the same thing.
Well, it is for convex objects but not every object.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39e1a990@news.povray.org>, Warp <war### [at] tag povray org>
wrote:
> It's not the same thing.
> Well, it is for convex objects but not every object.
Maybe true...on the other hand, the user might *expect* the results to
be the same as using partial transparency, with darker areas where the
object overlaps itself more times. In other words, a pair of cubes with
"shadows 0.5" should probably look the same as a union of the same cubes
with "shadows 0.5"...which would probably be impossible or difficult to
implement and very confusing to use otherwise...should light passing
through two objects with "shadows 0.5" be attenuated to 0.25 or 0.5 of
it's original? What if the objects have "shadows 0.2" and "shadows 0.6"?
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Chris Huff" <chr### [at] mac com> wrote in message
news:chrishuff-0FE0ED.06112709102000@news.povray.org...
> > * add a float factor for :
> > "shadowless", "no_shadow", "double_illuminate", "no_reflection" and
> > "no_image" (any other?)
>
> Possible, though I don't know how useful most would be. A better idea
> for some, like double_illuminate, would be a pigment to specify the
> color of the illumination. For shadowless/no_shadow, you can simply use
> a semitransparent object. For no_reflection and no_image, you could
> probably easily do whatever you want with combinations of opaque and
> semitransparent versions of the object.
I certainly have immediate uses for shadowless, double_illuminate and
no_image. I included the others to keep some syntax coherence.
For no_shadow, no_reflection, no_image I do not see how to easily get the
effects I am thinking off (rather like a fade in/out then a filter or a
transparency).
> > * "blinn_ior" distinct from interior{ior} - maybe use the interior ior
> > value if no blinn_ior specified
>
> This could be an optional parameter for the blinn highlight, you
> wouldn't even need to add an extra keyword...
I choosed "blinn <amount> blinn_ior <ior>" for syntax similarity with
"phong <amount> phong_size <size>" and "specular <amount> roughness
<roughness>".
> but it might calculate the
> ior from the differences in ior between objects, like it does for
> refraction, which might make this more difficult.
Sorry, but I really do not understand what you are talking about... :-( I
thought the blinn highlight finish was constant on an object (if you set
texture maps aside) and independant from any other objects... I guess I do
not know what I am talking about. I'll go and check MegaPov documentation
(RTFM).
Are you implicitly saying that the other changes are trivial ? (hope)
> > * should "no_shadow" and "shadowless" be interchangeable ? (as there
> > can be no mistake as to whether the keyword is in an object or in a
> > light and they serve a _very_ similar purpose).
>
> I think both should use the "shadowless" keyword(or even better,
> "shadows on|off"). "no_shadow" implies one shadow, and there can easily
> be more...and besides, it has one of those pesky underscore marks which
> I find slow typing down.
Yes, I like "shadow on|off |float", for both usages. It is more intuitive.
And "reflection", "image", "highlight" and "double_illuminate" (and
"radiosity"). I do prefer all singular keywords, but I do not really care as
long as it is consistent (may be difficult with plurals). (Side note : but
_I_like_ underscore marks.)
> > * could a "no_highlight" (or rather a "highlightless") keyword added and
> > the highlightlessness be dissociated from shadowlessness?
>
> How about a "highlights on|off" keyword? Or even better, control of
> specific types of highlights..."specular on|off", "phong on|off", "blinn
> on|off".
Yes, "highlight on|off|float" _plus_ specific control.
> Would allowing transformations to be done within the warp{} block be
> what you want? Or are you talking about transforming the warps
> themselves?
> I think it could be useful if you could use scale, translate, etc. as
> warps in the warp{} block, this would be a better solution to the
> problem my "scaled turbulence" patch tries to solve.
Instead of writing :
[...] scale .5 warp{turbulence 1/3} scale 2 [...]
Use :
[...] warp{turbulence 1/3 scale .5} [...]
>
> > * would a no_radiosity (for objects) and a radiosityless (for lights) be
> > possible? (I have a hunch that this one would be quite difficult.)
>
> Again, I would like "radiosity on|off" better...I just prefer the
> "feature on|off" syntax to a keyword that turns things on or off.
> And I don't think it would be possible to exclude lights. Objects would
> be different though...I think "no_image" makes them invisible to
> radiosity(though it also makes them invisible to you...).
Yes, yes, whatever the keyword : the functionnality!
Thanks for your answers,
Povingly,
Philippe
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Chris Huff" <chr### [at] mac com> wrote in message
news:chrishuff-C72E92.06404009102000@news.povray.org...
> In article <39e1a990@news.povray.org>, Warp <war### [at] tag povray org>
> wrote:
>
> > It's not the same thing.
> > Well, it is for convex objects but not every object.
>
> Maybe true...on the other hand, the user might *expect* the results to
> be the same as using partial transparency, with darker areas where the
> object overlaps itself more times. In other words, a pair of cubes with
> "shadows 0.5" should probably look the same as a union of the same cubes
> with "shadows 0.5"...which would probably be impossible or difficult to
> implement and very confusing to use otherwise...should light passing
> through two objects with "shadows 0.5" be attenuated to 0.25 or 0.5 of
> it's original? What if the objects have "shadows 0.2" and "shadows 0.6"?
mmh, yes. Confusing and difficult to implement, I can see that. I'll
think over it for a while to see if I can come with a good explanation of
what I have in mind (and check if what I think of does show a consistent
behavior).
Povingly,
Philippe
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39e3239f@news.povray.org>, "Philippe Debar"
<phi### [at] hotmail com> wrote:
> I certainly have immediate uses for shadowless, double_illuminate and
> no_image. I included the others to keep some syntax coherence.
I assume you mean uses for versions of these which have "amount"
parameters...
I don't mean the effect wouldn't be useful, I meant that it was probably
possible to do with other means.
> For no_shadow, no_reflection, no_image I do not see how to easily get the
> effects I am thinking off (rather like a fade in/out then a filter or a
> transparency).
What is the difference? To me, it sounds like you want "transmit".
> I choosed "blinn <amount> blinn_ior <ior>" for syntax similarity with
> "phong <amount> phong_size <size>" and "specular <amount> roughness
> <roughness>".
Good point...I would personally like a shortcut syntax:
phong AMOUNT, SIZE
specular AMOUNT, ROUGHNESS
blinn AMOUNT, FACETS, IOR
This could probably be done while preserving the current syntax, it
would just make finish statements shorter. :-)
> Sorry, but I really do not understand what you are talking about...
> :-( I thought the blinn highlight finish was constant on an object
> (if you set texture maps aside) and independant from any other
> objects...
When calculating refraction, POV uses the ior of the medium the ray is
coming from as well as the ior of the object it is entering to perform
the calculations...a glass sphere in water will appear differently than
a glass sphere embedded in a diamond or floating in the air. If blinn
uses this model(which I think it probably should), you won't be able to
get the right results by simply adding another value for it to use...you
will have to duplicate the ior calculation(not impossible, but a
significant increase in difficulty).
> Are you implicitly saying that the other changes are trivial ? (hope)
Adding a keyword is easy, and if it uses the ior value directly, adding
a separate one for the highlight would also be easy.
> Yes, I like "shadow on|off |float", for both usages. It is more
> intuitive. And "reflection", "image", "highlight" and
> "double_illuminate" (and "radiosity"). I do prefer all singular
> keywords, but I do not really care as long as it is consistent (may
> be difficult with plurals).
Singular doesn't make sense with shadow control...an object can have
multiple shadows, one from each light, and a light_source has a shadow
for every object. Also, there can be several highlights. However, there
is only one image, and phong, blinn, specular, radiosity, and
double_illuminate don't describe "things"(you can't have multiple
radiosities or triple-illumination).
> (Side note : but _I_like_ underscore marks.)
Hmm, they require a "shift- -" combination, which makes them harder to
type. I tend to press the shift key and search around till I hit the -
key or go back to looking for the right key(I am a touch typist, but
that particular combination is difficult for me)...I avoid using them in
variable names, though I understand their use in keywords, where you are
restricted to lower-case letters.
> Yes, "highlight on|off|float" _plus_ specific control.
So the "highlight(s)" keyword would control all of the highlight types
that the light_source affects? Sounds like a possibly nice feature,
though not absolutely necessary, and requiring a new keyword...
> Instead of writing :
> [...] scale .5 warp{turbulence 1/3} scale 2 [...]
> Use :
> [...] warp{turbulence 1/3 scale .5} [...]
Ah, ok...what I was thinking of would be more like this:
warp {
scale 2
turbulence 1/3
scale 0.5
}
I think it makes more sense to have the transforms *be* warps than to be
applied to the warps...especially when you have multiple cycles of
scaling, translating, and turbulence, for example.
This:
warp {
scale 4
turbulence 1/3
scale 0.5
turbulence 1/5
scale 0.5
}
using your syntax would be this:
warp {
turbulence 1/3
scale 0.25
}
warp {
turbulence 1/5
scale 0.5
}
and using the current syntax would be:
scale 4
warp {
turbulence 1/3
}
scale 0.5
warp {
turbulence 1/5
}
scale 0.5
The main advantage of my syntax is that it is more compact, but yours is
more readable(for simple cases, at least, and if you don't mind having
multiple warp{} blocks). Also, what will your syntax do with something
like this?
warp {
scale 0.5
turbulence 1/5
scale 0.5
}
Would that be the same as this?
warp {
turbulence 1/5
scale 0.25
}
Or will the transforms only affect warps before them?(this would
probably be difficult to implement)
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Chris Huff" <chr### [at] mac com> wrote...
> The main advantage of my syntax is that it is more compact, but yours is
> more readable(for simple cases, at least, and if you don't mind having
> multiple warp{} blocks).
The intent is for one warp block to describe one warp. If we want multiple
warps (as your examples do) then I think it would be good to have multiple
warp blocks. If you want to specify more than one warp in a single block,
then you should name the block with the plural "warps" instead of singular
"warp".
I think Philippe's original intent was to be able to change the size of the
turbulence (warp in the general sense) directly. So, if you wanted
turbulence on twice the scale, you would normally have to scale the texture
by 1/2, apply the turbulence, and then scale the texture back to its
original size. The thought is that it would be nicer if we could just apply
the "scale 2" to the turbulence when we want it to be applied in this way.
-Nathan
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39e3aa1a@news.povray.org>, "Nathan Kopp" <Nat### [at] Kopp com>
wrote:
> The intent is for one warp block to describe one warp. If we want
> multiple warps (as your examples do) then I think it would be good to
> have multiple warp blocks. If you want to specify more than one warp
> in a single block, then you should name the block with the plural
> "warps" instead of singular "warp".
Hmm, I always thought it acted similar to the transform{} block...but if
a warp{} block is considered to be one warp, it certainly would make
sense to have the transformations affect it like they would a pattern or
object, instead of acting like warps themselves.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Nathan Kopp" <Nat### [at] Kopp com> wrote in message
news:39e3aa1a@news.povray.org...
> I think Philippe's original intent was to be able to change the size of
the
> turbulence (warp in the general sense) directly. So, if you wanted
> turbulence on twice the scale, you would normally have to scale the
texture
> by 1/2, apply the turbulence, and then scale the texture back to its
> original size. The thought is that it would be nicer if we could just
apply
> the "scale 2" to the turbulence when we want it to be applied in this way.
Exactly.
What I originally had in mind when I thought about this syntax was something
like :
[in a media block...]
warp
{
turbulence .75+.1*sin(5*clock)
scale .9+.2*sin(7*clock+3)
translate <.1*cos(11*clock+5), clock, .1*sin(13*clock+7)>
}
warp
{
turbulence .75+.1*sin(13*clock+5)
scale .75+.15*sin(17*clock+7)
translate <.1*cos(5*clock+11), -clock, .1*sin(7*clock+13)>
}
[...]
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |