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

In article <39e17f7c@news.povray.org>, "Philippe Debar" 
<phi### [at] hotmailcom> 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] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> 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

In article <39e1a990@news.povray.org>, Warp <war### [at] tagpovrayorg> 
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] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" <chr### [at] maccom> 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

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-C72E92.06404009102000@news.povray.org...
> In article <39e1a990@news.povray.org>, Warp <war### [at] tagpovrayorg>
> 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

In article <39e3239f@news.povray.org>, "Philippe Debar" 
<phi### [at] hotmailcom> 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] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" <chr### [at] maccom> 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

In article <39e3aa1a@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
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] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Nathan Kopp" <Nat### [at] Koppcom> 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