I think it should be a good idea to remove the keyword "hollow" from
the next version of povray (and replace it with a more descriptive keyword).
It only causes lots of confusion among new users and it doesn't really
describe its purpose.
  This suggestion is not as bad is it may sound. This has already happened:
the "refraction" keyword has become obsolete. Also all the old halo stuff
has been removed. Things have been moved from "finish" to "interior".
Radiosity will probably change in the near future.
  Removing "hollow" may cause problems at the beginning, but in the long run
it will do just good.

  I have to admit that I don't have any good idea for an alternative keyword.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:

 
>   I have to admit that I don't have any good idea for an alternative keyword.

inside ?

-- 
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Nieminen Juha wrote:
> 
>   I think it should be a good idea to remove the keyword "hollow" from
> the next version of povray (and replace it with a more descriptive keyword).
[snip]
> 
>   I have to admit that I don't have any good idea for an alternative keyword.
> 


container?

-- 
Marc Schimmler

Post a reply to this message

Actually, I would change the way media currently works. I'd let all objects
(hollow or otherwise) contain media. 'Hollow' (or equivalent) would mean that
other object medias and global media can also enter the object.
The reasoning being that there are solid objects that can contain particulate
media (e.g. air bubbles in an ice cube). Indeed, when the media container is
given a pigment and/or a finish such a solid object is usually the desired
result. Currently POV doesn't provide for such cases.
I would recommend 'container' or 'media_bound' as replacement for 'hollow',
since with the suggested method such objects should mainly be used as invisible
bounding objects for media (smoke, clouds, etc).

Margus

Nieminen Juha wrote:
> 
>   I think it should be a good idea to remove the keyword "hollow" from
> the next version of povray (and replace it with a more descriptive keyword).
> It only causes lots of confusion among new users and it doesn't really
> describe its purpose.
>   This suggestion is not as bad is it may sound. This has already happened:
> the "refraction" keyword has become obsolete. Also all the old halo stuff
> has been removed. Things have been moved from "finish" to "interior".
> Radiosity will probably change in the near future.
>   Removing "hollow" may cause problems at the beginning, but in the long run
> it will do just good.
> 
>   I have to admit that I don't have any good idea for an alternative keyword.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I agree with this vehemently. Hollow does seem to cause all kinds
of misunderstanding, and isn't a logically accurate term. I would 
also add, though, that I never understood why the default was to
NOT accept media unless a keyword was added. 

Granted, there are ocassions when you want the bounding shape to...
shall we call it "forbid" a global media in a given region for 
special effect purposes, but when you attach a media to an object, 
why also require that you specify a separate keyword to make sure 
doing so has an effect? And need we mention the unexpected 
"camera in a non-hollow object" problems? 

With that in mind, I would propose that what is now known as 
"hollow" become the default condition of all objects, and that 
a replacement keyword "no_media" be added, being to media what
"no_shadow" is to shadows. "hollow" could then be phased out the
way refraction is now, generating a warning and having no effect
(which would result in no negative impact on old scenes, since
"hollowness" is then the default state anyway.)


Nieminen Juha wrote:
> 
>   I think it should be a good idea to remove the keyword "hollow" from
> the next version of povray (and replace it with a more descriptive keyword).
> It only causes lots of confusion among new users and it doesn't really
> describe its purpose.
>   This suggestion is not as bad is it may sound. This has already happened:
> the "refraction" keyword has become obsolete. Also all the old halo stuff
> has been removed. Things have been moved from "finish" to "interior".
> Radiosity will probably change in the near future.
>   Removing "hollow" may cause problems at the beginning, but in the long run
> it will do just good.
> 
>   I have to admit that I don't have any good idea for an alternative keyword.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Charles wrote:
> 
> With that in mind, I would propose that what is now known as
> "hollow" become the default condition of all objects, and that
> a replacement keyword "no_media" be added, being to media what
> "no_shadow" is to shadows. "hollow" could then be phased out the
> way refraction is now, generating a warning and having no effect
> (which would result in no negative impact on old scenes, since
> "hollowness" is then the default state anyway.)
> 
	Well actually it would have a negative effect for non hollow objects,
but that could be fixed with the #version directive and I agree that it
would be more logical to have hollow be the standard state (at least as
soon as a media is specified...)

		Jerome

-- 
*******************************
* Always listen to experts,   * Jérôme M. BERGER
* they'll tell you what can't * mailto:ber### [at] inamecom
* be done and why...          * http://www.enst.fr/~jberger
* Then do it.                 *
*******************************

Post a reply to this message

Charles <cfu### [at] enternet> wrote:
: I would 
: also add, though, that I never understood why the default was to
: NOT accept media unless a keyword was added. 

  Usually fog doesn't go inside objects. That's why.

: With that in mind, I would propose that what is now known as 
: "hollow" become the default condition of all objects, and that 
: a replacement keyword "no_media" be added, being to media what
: "no_shadow" is to shadows.

  Note that it also affects fog.

  There might be situations where you want media inside an object but not
fog (or other medias). Perhaps there should be more keywords to specify
these kind of things, as someone already suggested.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On a similar subject, I think the 'no_shadow' keyword should be removed, and
the keyword 'shadowless' should work in place of it.  As is, there are two
keywords that are doing essentially the same thing, and it is difficult to
remember which one is for objects, and which one is for lights.

Mark

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:
: On a similar subject, I think the 'no_shadow' keyword should be removed, and
: the keyword 'shadowless' should work in place of it.  As is, there are two
: keywords that are doing essentially the same thing, and it is difficult to
: remember which one is for objects, and which one is for lights.

  Or perhaps there should be more keywords to control how shadows are
calculated for an object:

  cast_shadow [on|off]  // if off, will be the same as current no_shadow
  self_shadow [on|off]  // specifies whether it should cast shadows on itself
                        // or not (ie. if off, it will be shadowless for
                        // itself but not for other objects)
  receive_shadow [on|off] // specifies whether other objects will cast shadows
                          // on this object or not

  Any combination of these could be possible. For example:

cast_shadow off
self_shadow on

would mean that it casts shadows on itself but not on other objects.
  The default values for all those would be 'on'.

  It would also be nice if we could specify which light sources illuminate
the object and which don't. Or object-specific light sources, which only
illuminate that specific object (I think that this feature is very common
in other renderers). Something like:

object
{ MyObject
  light_source { MyLight }
}

or perhaps:

object
{ MyObject
  illuminated_by { MyLight }
}

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

>  It would also be nice if we could specify which light sources illuminate
>the object and which don't. Or object-specific light sources, which only
>illuminate that specific object (I think that this feature is very common
>in other renderers).

Isn't this available as the light_groups patch? From the SuperPatch docs:

Light Groups

syntax:

light_source {... groups "name1,name2,name3,..."}
object {... light_group "name1" no_shadow "name2"}
media {... light_group "!name3"}

defaults: light_group "all" no_shadow "none"

This is to control light interaction of media and objects. There can be a
max of 30 user defined Light groups, none and all are pre defined. groups
can be called anything but no spaces and they are delimited by commas with
the groups key word. All lights are automatically in the "all" group. if
light_group or no_shadow group contains a ! it is interpreted to mean all
lights not in the group that follows the !.

If a light doesn't interact with a media or object then no shadows are cast
from that object for that light.

Post a reply to this message

TonyB <ben### [at] panamaphoenixnet> wrote:
: There can be a max of 30 user defined Light groups

  Why?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 16 Nov 1999 07:27:57 -0500, Nieminen Juha wrote:
>TonyB <ben### [at] panamaphoenixnet> wrote:
>: There can be a max of 30 user defined Light groups
>
>  Why?

Because MCB used a 32-bit integer to store which light groups are 
in effect for a given object or light source.  It's a design decision,
basically.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On Tue, 16 Nov 1999 01:07:04 -0500, "Mark Wagner"
<mar### [at] gtenet> wrote:

>On a similar subject, I think the 'no_shadow' keyword should be removed, and
>the keyword 'shadowless' should work in place of it.  As is, there are two
>keywords that are doing essentially the same thing, and it is difficult to
>remember which one is for objects, and which one is for lights.
>
>Mark

Not quite. Shadowless in a light source turns off not only shadow ray
calculations for this particular light but also any specular
highlighting. It was initially intended for use as a fill light, and
there are references in the source code inticating this.


Peter Popov
ICQ: 15002700

Post a reply to this message

Nieminen Juha wrote:
> Charles <cfu### [at] enternet> wrote:
> : I would
> : also add, though, that I never understood why the default was to
> : NOT accept media unless a keyword was added.
> 
>   Usually fog doesn't go inside objects. That's why.

Ahhhh, yes. Fog. In six years, I've only had two uses for it, and
neither involved transparent objects, so the first time the hollow
keyword became an issue for me was when halo hit the scene. I had
forgotten (or never read) any previous applications of the word.

>   There might be situations where you want media inside an object but not
> fog (or other medias). Perhaps there should be more keywords to specify
> these kind of things, as someone already suggested.

Yes, that's  true. For flexibility's sake, you probably shouldn't
have fog and media accepted or forbidden with the same keyword. 

Technically for maximum flexibility, it wouldn't hurt if objects 
could accept or forbid any number of named media in whatever 
combinations the artist sees fit, although I don't know how much more
complexity that might add to the code internally, so I'm not sure
whether people would consider it worth the trouble. 

It might, at the least, involve adding some kind of "name" keyword 
inside media that would enable them to become recognizable to the 
renderer as distinct independent named entities. Then you could
add lines to your object such as...

forbid FireMedia //forbid the specific named entity "FireMedia"
//or...
forbid fog //forbid fog within the object boundary

Post a reply to this message

Ron Parker wrote in message ...
>On 16 Nov 1999 07:27:57 -0500, Nieminen Juha wrote:
>>TonyB <ben### [at] panamaphoenixnet> wrote:
>>: There can be a max of 30 user defined Light groups
>>
>>  Why?
>
>Because MCB used a 32-bit integer to store which light groups are
>in effect for a given object or light source.  It's a design decision,
>basically.


Just today I finished debugging a modification to the Superpatch which
removes the limits on the number of light groups and the number of entries
in a pure spline.  I can send you the modifications tomorrow if you want me
to.

Mark

Post a reply to this message

Peter Popov wrote in message <0dMxOC8Ugw8=f17WiV4EWjVSy1kk@4ax.com>...
>On Tue, 16 Nov 1999 01:07:04 -0500, "Mark Wagner"
><mar### [at] gtenet> wrote:
>
>>On a similar subject, I think the 'no_shadow' keyword should be removed,
and
>>the keyword 'shadowless' should work in place of it.  As is, there are two
>>keywords that are doing essentially the same thing, and it is difficult to
>>remember which one is for objects, and which one is for lights.
>>
>>Mark
>
>Not quite. Shadowless in a light source turns off not only shadow ray
>calculations for this particular light but also any specular
>highlighting. It was initially intended for use as a fill light, and
>there are references in the source code inticating this.


True, but you will never need to use both the 'shadowless' keyword and the
'no_shadow' keyword on the same object, so there is no need for two keywords
for the general effect of eliminating shadows.

Mark

Post a reply to this message

Nieminen Juha wrote in message <3831214f@news.povray.org>...
>  Or perhaps there should be more keywords to control how shadows are
>calculated for an object:
>
>  self_shadow [on|off]  // specifies whether it should cast shadows on
itself
>                        // or not (ie. if off, it will be shadowless for
>                        // itself but not for other objects)
You can get this effect with either finish{ambient 1 diffuse 0} or in UVPov
specifying 'double_illuminate', depending on the specific effect you want.


Mark

Post a reply to this message

On Wed, 17 Nov 1999 01:01:37 -0500, "Mark Wagner"
<mar### [at] gtenet> wrote:

>>Not quite. Shadowless in a light source turns off not only shadow ray
>>calculations for this particular light but also any specular
>>highlighting. It was initially intended for use as a fill light, and
>>there are references in the source code inticating this.
>
>
>True, but you will never need to use both the 'shadowless' keyword and the
>'no_shadow' keyword on the same object, so there is no need for two keywords
>for the general effect of eliminating shadows.
>
>Mark

The best solution would be to have keywords controlling highlights and
shadows on a per-object and per-light basis. I don't know, does the
light groups patch offer control over highlighting?


Peter Popov
ICQ: 15002700

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:
: You can get this effect with either finish{ambient 1 diffuse 0}

  No, that will not achieve that effect. That would mean that the object
is not shaded. That's not the same as not casting shadows on itself.
  A sphere can't cast shadows on itself but a torus can (due to their
form).

: or in UVPov
: specifying 'double_illuminate', depending on the specific effect you want.

  I think that double_illuminate will not eliminate any shadow calculations.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote:
: Not quite. Shadowless in a light source turns off not only shadow ray
: calculations for this particular light but also any specular
: highlighting.

  In my opinion this should be changed. I have had scenes where I really
wanted the highlights but not the shadows (for one light source; for the
other light sources I wanted both).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On Wed, 17 Nov 1999 00:59:40 -0500, Mark Wagner wrote:
>
>Ron Parker wrote in message ...
>>On 16 Nov 1999 07:27:57 -0500, Nieminen Juha wrote:
>>>TonyB <ben### [at] panamaphoenixnet> wrote:
>>>: There can be a max of 30 user defined Light groups
>>>
>>>  Why?
>>
>>Because MCB used a 32-bit integer to store which light groups are
>>in effect for a given object or light source.  It's a design decision,
>>basically.
>
>
>Just today I finished debugging a modification to the Superpatch which
>removes the limits on the number of light groups and the number of entries
>in a pure spline.  I can send you the modifications tomorrow if you want me
>to.

Yes, please.  That'd be great.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

How about using a sort of mass instead?  That might be too similar to media,
however.

--
This message brought to you by:
-=< Ian (the### [at] hotmailcom >=-

Please visit my site at http://spectere2000.cjb.net! :)

Nieminen Juha <war### [at] punarastascstutfi> wrote in message
news:382c2d31@news.povray.org...
>   I think it should be a good idea to remove the keyword "hollow" from
> the next version of povray (and replace it with a more descriptive
keyword).
> It only causes lots of confusion among new users and it doesn't really
> describe its purpose.
>   This suggestion is not as bad is it may sound. This has already
happened:
> the "refraction" keyword has become obsolete. Also all the old halo stuff
> has been removed. Things have been moved from "finish" to "interior".
> Radiosity will probably change in the near future.
>   Removing "hollow" may cause problems at the beginning, but in the long
run
> it will do just good.
>
>   I have to admit that I don't have any good idea for an alternative
keyword.
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message