It's strange what things can inspire you when your brain's been
operpoved.

Being the type of person who thinks sunlight is just an annoying glare
in the window, I recently nailed blankeds on the windows  of my room.
(curtains have a transmit of about 0.4 and that's way too much.) This
morning, while I was reading posts, a perky sunray somehow broke in
and lit up the room with soft, indirect, diffusely interreflected,
hard-to-model light. Moreover, some of it hit the top of the
indescribable plastic thing sitting on my monitor (along with an
wooden model of A'Tuin) and produced some really nice caustics on the
oscilloscope gathering dust at the top shelf, then some of it bounced
off again from the oscilloscope screen and produced some really nice
caustics on the ceiling that flickered gently as I was clicking the
keyboard. The other part of the ray hit the side of the aforementioned
plastic thing (which is actually the case of a small mechanical
counter saying " '95: wasted; repairable") and pierced the aquarium
right through the stream of bubbles, and the beauty of the spectral
caustics resulting in this rendered any attemped description
incomplete. The fun really began when I moved my hand (probably to rub
my eyes :) ) and the ray bounced off it and lit half the room! I never
knew that human skin was so much diffusely reflective. The mere two or
three square inches of my palm that were lit by the sun acted as a
real light source, progucing nice shadows (kinda too sharp to be real
:) ), specular reflections in the heating pipes and even caustics off
my recently polished guitar deck that gleamed on the painting on the
wall. Impressive what a 1  x 30 in light ray can do :)

Now the question is, how the heck do I model all that in just a
lifetime? And how many Cray supercomputers will I need to render it?

Any help appreciated.

--Peter

P.S. Based on the still going "Where are you..." thread, most of you
guys are Americans, so I did some conversions to spare the majority
the trouble to do so. 1 in = 2.5402 cm  1 cm =  0.3937 in :)

Post a reply to this message

Peter Popov schrieb in Nachricht <36cd1c53.13142319@news.povray.org>...

>Moreover, some of it hit the top of the
>indescribable plastic thing sitting on my monitor (along with an
>wooden model of A'Tuin)

You have a wooden model of A'Tuin? Where did you get that? BTW do you know
of anyone who tried to model the Discworld in POV-Ray?

--
Rudy Velthuis

Post a reply to this message

Rudy Velthuis wrote in message <36ce862e.0@news.povray.org>...
>
>You have a wooden model of A'Tuin? Where did you get that? BTW do you know
>of anyone who tried to model the Discworld in POV-Ray?


If you mean an image with a Pratchett theme, there was one in the "magic"
round of the IRTC. I don't know of any images of the entire Discworld,
though. Maybe somebdy will risk copyright infringement again and does it for
this round...

Margus

Post a reply to this message

Margus Ramst schrieb in Nachricht <36ceba21.0@news.povray.org>...

>If you mean an image with a Pratchett theme, there was one in the "magic"
>round of the IRTC. I don't know of any images of the entire Discworld,
>though. Maybe somebdy will risk copyright infringement again and does it
for
>this round...

What exactly do you mean by "copyright infringement _again_"?

--
Rudy Velthuis

Post a reply to this message

Rudy Velthuis wrote in message <36cf10c2.0@news.povray.org>...
>
>What exactly do you mean by "copyright infringement _again_"?
>
I mean _risk_ again. Like putting Mickey Mouse or Coke in your image. If you
haven't done so, check out "usage of commercial logos" thread in
irtc.general.

Margus

Post a reply to this message

Let me just say that you may want to check out my photon mapping patch once
I make a public beta available.

-Nathan Kopp

Post a reply to this message

I don't think there's a POVer alive who wouldn't want to check it out. Now
stop teasing!

Margus

Nathan Kopp wrote in message <36CF1BDD.6F08F75C@Kopp.com>...
>Let me just say that you may want to check out my photon mapping patch once
>I make a public beta available.
>
>-Nathan Kopp

Post a reply to this message

I've always used a cupped palm to focus dim light into a spot I needed
to see, don't know where I got this from but it's like placing your hand
above your eyes in bright light to shade your eyes as a reflex almost.
Similar thing occurs when you block a light from a shadowy place your
trying to see to adjust your eyes to the darkness there.
Sorry, I wouldn't be much help with that much of a "capture reality"
rendering, especially if you think it might take a lifetime and a cray.
And, hey, I'm both American and *semi*-metric, if that counts for
anything.


Peter Popov wrote:
> 
> The fun really began when I moved my hand (probably to rub
> my eyes :) ) and the ray bounced off it and lit half the room! I never
> knew that human skin was so much diffusely reflective. The mere two or
> three square inches of my palm that were lit by the sun acted as a
> real light source, producing nice shadows
> 
> Now the question is, how the heck do I model all that in just a
> lifetime? And how many Cray supercomputers will I need to render it?
> 
> Any help appreciated.
> 
> --Peter
> 
> P.S. Based on the still going "Where are you..." thread, most of you
> guys are Americans, so I did some conversions to spare the majority
> the trouble to do so. 1 in = 2.5402 cm  1 cm =  0.3937 in :)

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

Bob Hughes wrote:

> And, hey, I'm both American and *semi*-metric, if that counts for anything.

I got a set of them "metric" wrenches once. That metric company needs
to improve their product. The darn things were just too sloppy and
rounded the corners on the hex nuts. Your not assiociated with them
by any chance are you ? I want my money back !

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

On Sat, 20 Feb 1999 15:32:29 -0500, Nathan Kopp <Nat### [at] Koppcom>
wrote:

>Let me just say that you may want to check out my photon mapping patch once
>I make a public beta available.
>
>-Nathan Kopp

Of course I will! After all, it was because you beat me to it that I
gave up doing my virtual light sources patch. You mentioned once that
you implemented faked (not using real wavelengths, of coz) dispersion
in your patch. That's nice. Now the question is, what amound of
photons do I have to shoot from the sun so that a reasonable number of
them passes through a 1 inch wide slit, hits my palm and illuminates
the room with radiosity, caustics and dispersion at that? Maybe you
should incorporate some way to explicitly specify higher concentration
of the photons where they are needed.

Peter
---------
Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov wrote:
> >
> >-Nathan Kopp
> 
 Maybe you
> should incorporate some way to explicitly specify higher concentration
> of the photons where they are needed.
> 
> Peter

light_source{ location  [type modifiers]}

Light Modifiers Available:

Sun, Moon, Star, Candle, Gas_Lamp, Halogen, Halogen_Quartz, Arc_Lamp,
Laser, Sodium_Vapor, Mercury_Vapor, Argon_Gas, Metal_Halide, Zenon,
Neon, Incandescent, Flourecent, Bio_Luminescent, Ultra_Violet,
Infra_Red, Light_Emitting_Semi_Conductor_Junction, Thermo_Nuclear,
and Super_Nova.

Note: The last two entries are difficult to control and are for the more
      advanced users only.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Peter Popov wrote:
> 
> Of course I will! After all, it was because you beat me to it that I
> gave up doing my virtual light sources patch. You mentioned once that
> you implemented faked (not using real wavelengths, of coz) dispersion
> in your patch. That's nice. Now the question is, what amound of
> photons do I have to shoot from the sun so that a reasonable number of
> them passes through a 1 inch wide slit, hits my palm and illuminates
> the room with radiosity, caustics and dispersion at that? Maybe you
> should incorporate some way to explicitly specify higher concentration
> of the photons where they are needed.
> 

Yes.  In fact, all photons are shot at specific objects (at a specified
density for each object) instead of everywhere.

Unfortunately, (at least the first version of) this photon mapping
implementation will not directly impact radiosity.  In other words, if
radiosity wouldn't light up the room from a small highly-ambient spot,
then it won't light up the room from a small photon-lit spot.  Photons
will get the light through the slit, off all the specular-reflective
surfaces, and to your hand, but no further (for now).

Photon mapping will NOT replace radiosity (I thought it would, but I
tried it and it didn't work very well).

-Nathan Kopp

Post a reply to this message

Margus Ramst schrieb in Nachricht <36cf1a2e.0@news.povray.org>...
>
>Rudy Velthuis wrote in message <36cf10c2.0@news.povray.org>...
>>
>>What exactly do you mean by "copyright infringement _again_"?
>>
>I mean _risk_ again. Like putting Mickey Mouse or Coke in your image. If
you
>haven't done so, check out "usage of commercial logos" thread in
>irtc.general.

OIC, I didn't subscribe to irtc.general yet (I'm not good enough to do
anything for the IRTC <sigh>), so I hadn't heard about copyright problems.
Thanks for the pointer and the explanation.

--
Rudy Velthuis

Post a reply to this message

Nathan Kopp schrieb in Nachricht <36CF1BDD.6F08F75C@Kopp.com>...
>Let me just say that you may want to check out my photon mapping patch once
>I make a public beta available.

WHEN??? It would make raytracing sooo much more realistic. Keep up the good
work!

--
Rudy Velthuis

Post a reply to this message

Metric wrenches on ASA hex nuts, tsk! tsk!
I am in no way affiliated with or endorse any and all products which are
not of my own property, and even then...


Ken wrote:
> 
> Bob Hughes wrote:
> 
> > And, hey, I'm both American and *semi*-metric, if that counts for anything.
> 
> I got a set of them "metric" wrenches once. That metric company needs
> to improve their product. The darn things were just too sloppy and
> rounded the corners on the hex nuts. Your not assiociated with them
> by any chance are you ? I want my money back !
> 
> --
> Ken Tyler
> 
> mailto://tylereng@pacbell.net

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

On Sat, 20 Feb 1999 19:45:52 -0800, Ken <tyl### [at] pacbellnet> wrote:

>Peter Popov wrote:
>> >
>> >-Nathan Kopp
>> 
> Maybe you
>> should incorporate some way to explicitly specify higher concentration
>> of the photons where they are needed.
>> 
>> Peter
>
>light_source{ location  [type modifiers]}
>
>Light Modifiers Available:
>
>Sun, Moon, Star, Candle, Gas_Lamp, Halogen, Halogen_Quartz, Arc_Lamp,
>Laser, Sodium_Vapor, Mercury_Vapor, Argon_Gas, Metal_Halide, Zenon,
>Neon, Incandescent, Flourecent, Bio_Luminescent, Ultra_Violet,
>Infra_Red, Light_Emitting_Semi_Conductor_Junction, Thermo_Nuclear,
>and Super_Nova.
>
>Note: The last two entries are difficult to control and are for the more
>      advanced users only.

RTM, Ken! You've missed Copped_Bromide, Yttrium-Aluminum Granate
(YAG), Carbon Dioxide Plasma (it's got a built-in filter 1.0), and
that one failing any description rather that "Pete's eyes while ogling
a Katmai running POV"

:)

Peter
---------
Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov wrote in message <36cd1c53.13142319@news.povray.org>...
>Now the question is, how the heck do I model all that in just a
>lifetime? And how many Cray supercomputers will I need to render it?
>
>Any help appreciated.



I think you'll need a Quantum Computer.  I can't wait 'till they are a
reality -- besides being able to blow away all current encryption
algorithms, they are great for simulation.  In effect, you are harnessing
Nature's CPU directly, the same one that =is= used to compute such a beam of
light interacting with everything else in the room.

--John

Post a reply to this message

I want to make an alpha version (syntax not locked down yet) available in
the first few weeks of March.  The second week of March is spring break
for me, so I should have some time. :-)

-Nathan

Rudy Velthuis wrote:
> 
> Nathan Kopp schrieb in Nachricht <36CF1BDD.6F08F75C@Kopp.com>...
> >Let me just say that you may want to check out my photon mapping patch once
> >I make a public beta available.
> 
> WHEN??? It would make raytracing sooo much more realistic. Keep up the good
> work!
> 
> --
> Rudy Velthuis

Post a reply to this message

Nathan Kopp schrieb in Nachricht <36D### [at] Koppcom>...
>I want to make an alpha version (syntax not locked down yet) available in
>the first few weeks of March.  The second week of March is spring break
>for me, so I should have some time. :-)
>
>-Nathan

I understand your problem. I also wanted to assemble the softtext thingie in
a few days, but it took longer and longer, because this had to be done in my
spare time and I don't live on a deserted island (work, obligations, illness
in the family, etc.). I think your problem is the same.

Anyway, can't wait to test the alpha. Don't care about the syntax, as long
as I can use it. There are many syntax issues in POV-Ray I don't like (too C
oriented <g>), so I don't care about one or two more. I particularly hate
the keywords with an underscore in it (look_at etc.).

--
Rudy Velthuis

Post a reply to this message

Rudy Velthuis wrote:
> 
> Anyway, can't wait to test the alpha. Don't care about the syntax, as long
> as I can use it. There are many syntax issues in POV-Ray I don't like (too C
> oriented <g>), so I don't care about one or two more. I particularly hate
> the keywords with an underscore in it (look_at etc.).
> 

Anyone else out there have any opinions on this... right now I have a lot of
keywords WITH underscores... my reason for this is that the more specific
I make the keyword, the less likely it will be that it conflicts with
somebody's variable name.  You know... now that I think about it, maybe I
should ditch some of those extra-long keywords.  (One of the reasons I
dislike COBOL is the long keywords.)  If somebody wants to use one of my
reserved words for a variable name, too bad.  ;-)

-Nathan

Post a reply to this message

On Mon, 22 Feb 1999 14:46:03 -0500, Nathan Kopp <Nat### [at] Koppcom> wrote:
>Rudy Velthuis wrote:
>> 
>> Anyway, can't wait to test the alpha. Don't care about the syntax, as long
>> as I can use it. There are many syntax issues in POV-Ray I don't like (too C
>> oriented <g>), so I don't care about one or two more. I particularly hate
>> the keywords with an underscore in it (look_at etc.).
>> 
>
>Anyone else out there have any opinions on this... right now I have a lot of
>keywords WITH underscores... my reason for this is that the more specific
>I make the keyword, the less likely it will be that it conflicts with
>somebody's variable name.  You know... now that I think about it, maybe I
>should ditch some of those extra-long keywords.  (One of the reasons I
>dislike COBOL is the long keywords.)  If somebody wants to use one of my
>reserved words for a variable name, too bad.  ;-)

The proper thing to do here is for everyone writing scenes, inc files, etc.
to use at least one capital letter in every variable name.  My personal
patches (as opposed to the ones I've borrowed from various other people)
always have short, common keywords.  

Keeping in mind that all keywords need to be lowercase, then, it seems
that the underscore is the best alternative to BiCaps.

Post a reply to this message

How about giving us the new keywords and a little about what they
control and we could probably come to a consensus?  Either that, or just
think to yourself, if I was just using the program and not writing it,
what would make sense to me.

I think some good examples are the keywords for radiosity.  Like
grey_threshold could just be grey.  100% grey is no color.  Simpler but
makes sense.  I think minimum_reuse could just be reuse.

I agree with Ron that it's customary for reserved keywords to use all
lowercase and user defined terms should start with a Cap.  So be
specific.  People can change variable names that conflict with them;
that's what the message window is for. ;)

-Mike

> Anyone else out there have any opinions on this... right now I have a lot of
> keywords WITH underscores... my reason for this is that the more specific
> I make the keyword, the less likely it will be that it conflicts with
> somebody's variable name.  You know... now that I think about it, maybe I
> should ditch some of those extra-long keywords.  (One of the reasons I
> dislike COBOL is the long keywords.)  If somebody wants to use one of my
> reserved words for a variable name, too bad.  ;-)
> 
> -Nathan

Post a reply to this message

Mike wrote:
> 
> How about giving us the new keywords and a little about what they
> control and we could probably come to a consensus?  Either that, or just
> think to yourself, if I was just using the program and not writing it,
> what would make sense to me.
> 
> I think some good examples are the keywords for radiosity.  Like
> grey_threshold could just be grey.  100% grey is no color.  Simpler but
> makes sense.  I think minimum_reuse could just be reuse.
> 
> I agree with Ron that it's customary for reserved keywords to use all
> lowercase and user defined terms should start with a Cap.  So be
> specific.  People can change variable names that conflict with them;
> that's what the message window is for. ;)
> 
> -Mike

What Mike said !

Ken would like to pipe in quickly with a plea for shorter keywords and no
under_scored identifiers. The sooner they are fazed out of exsistence
the better.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Mike wrote:
> 
> How about giving us the new keywords and a little about what they
> control and we could probably come to a consensus?  Either that, or just
> think to yourself, if I was just using the program and not writing it,
> what would make sense to me.
> 
> I think some good examples are the keywords for radiosity.  Like
> grey_threshold could just be grey.  100% grey is no color.  Simpler but
> makes sense.  I think minimum_reuse could just be reuse.
> 
> I agree with Ron that it's customary for reserved keywords to use all
> lowercase and user defined terms should start with a Cap.  So be
> specific.  People can change variable names that conflict with them;
> that's what the message window is for. ;)
> 
> -Mike

I agree with the abovesaid.
I really don't have a problem with underscores; you could make your keywords
start with sth. unique like photon_* so they would be unlikely to conflict
with variables. However, it's easy for people to change their variables.
Only please, avoid mega-long keywords! I can rarely write max_trace_level in
one go without typos.

Margus

Post a reply to this message

On Tue, 23 Feb 1999 11:36:14 +0200, Margus Ramst <mar### [at] peakeduee> wrote:
>I agree with the abovesaid.
>I really don't have a problem with underscores; you could make your keywords
>start with sth. unique like photon_* so they would be unlikely to conflict
>with variables. However, it's easy for people to change their variables.
>Only please, avoid mega-long keywords! I can rarely write max_trace_level in
>one go without typos.

What about catmull_rom_sphere_sweep?  :)

Post a reply to this message

crss {}
I like abreviation. I'll vote yea on the short keywords too, and the
underscore removal.
Any idea about making spaces available between keywords? Plausible
(doable I don't know) to make a keyword recognisable (oops, my Canadian
sp.) which goes as a pair of words or more? ie. max trace level, or do
they have to be a solid string in the C programming language
definitions? Hey, how would this be for something in POV-Ray script too?
Good idea, but not possible?

Mental note: too many questions at once may appear to inquisitive ;)


Ron Parker wrote:
> 
> On Tue, 23 Feb 1999 11:36:14 +0200, Margus Ramst <mar### [at] peakeduee> wrote:
> >I agree with the abovesaid.
> >I really don't have a problem with underscores; you could make your keywords
> >start with sth. unique like photon_* so they would be unlikely to conflict
> >with variables. However, it's easy for people to change their variables.
> >Only please, avoid mega-long keywords! I can rarely write max_trace_level in
> >one go without typos.
> 
> What about catmull_rom_sphere_sweep?  :)

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

On Tue, 23 Feb 1999 12:32:51 -0600, Bob Hughes <inv### [at] aolcom> wrote:
>crss {}

I asked about that one because it's one of the longer new keywords 
in the superpatch.  Obviously, it's not one of mine.  I don't change
other people's keywords for compatibility's sake, unless there's a
conflict (the #macro stuff from the iso patch, for example.)

>Any idea about making spaces available between keywords? Plausible
>(doable I don't know) to make a keyword recognisable (oops, my Canadian
>sp.) which goes as a pair of words or more? 

Possible but ugly, since the tokenizer splits things on spaces.  Even if
you did make it work with the current tokenizer (and you could, I think)
you'd get weird error messages if you said something like "max trace 10" 
instead of "max trace level 10"  All in all, probably not a good thing.

Post a reply to this message

Nathan Kopp schrieb in Nachricht <36D1B3FB.1B063D3B@Kopp.com>...

>Anyone else out there have any opinions on this... right now I have a lot
of
>keywords WITH underscores... my reason for this is that the more specific
>I make the keyword, the less likely it will be that it conflicts with
>somebody's variable name.  You know... now that I think about it, maybe I
>should ditch some of those extra-long keywords.  (One of the reasons I
>dislike COBOL is the long keywords.)  If somebody wants to use one of my
>reserved words for a variable name, too bad.  ;-)

Exactly. Ditch the underscores. They look unprofessional somehow. I've never
seen a language using *keywords* with underscores. But I don't know them
all.

--
Rudy

Post a reply to this message

Bob Hughes wrote in message <36D2F453.BFCE1758@aol.com>...
>crss {}


I think you're going to extremes here. If all keywords had only 3-5 chars,
it would be impossible (for me, at least) to memorize them. The name should
have at least some connection with the function.
And_what's_wrong_with_underscores_anyway?

Margus

Post a reply to this message

While we're at it, when will someone do a OOP-POV ???
dot separated keywords and so on.
int photon.mapsize
int photon.level
vector camera.look_at
vector camera.postition

Well, I think it would be useful in some cases, and less so in
others.(as is most things)



Mike wrote:
> 
> How about giving us the new keywords and a little about what they
> control and we could probably come to a consensus?  Either that, or just
> think to yourself, if I was just using the program and not writing it,
> what would make sense to me.
> 
> I think some good examples are the keywords for radiosity.  Like
> grey_threshold could just be grey.  100% grey is no color.  Simpler but
> makes sense.  I think minimum_reuse could just be reuse.
> 
> I agree with Ron that it's customary for reserved keywords to use all
> lowercase and user defined terms should start with a Cap.  So be
> specific.  People can change variable names that conflict with them;
> that's what the message window is for. ;)
> 
> -Mike
> 
> > Anyone else out there have any opinions on this... right now I have a lot of
> > keywords WITH underscores... my reason for this is that the more specific
> > I make the keyword, the less likely it will be that it conflicts with
> > somebody's variable name.  You know... now that I think about it, maybe I
> > should ditch some of those extra-long keywords.  (One of the reasons I
> > dislike COBOL is the long keywords.)  If somebody wants to use one of my
> > reserved words for a variable name, too bad.  ;-)
> >
> > -Nathan

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

"Possibly" sounds encouraging.
I was thinking along the lines that if the two or more words could be
done with spaces then somehow it would be seen *only* when all the group
were present, like when part of a keyword is written into the CodeMax
editor it shows that the keyword is not all there (also if written
wrong) by not switching color. So if all the words were present in
proper placement (and spelling) it would be recognized and only then.


Ron Parker wrote:
> 
> >I had previously writ:
> >Any idea about making spaces available between keywords? Plausible
> >(doable I don't know) to make a keyword recognisable (oops, my Canadian
> >sp.) which goes as a pair of words or more?
> 
> Possible but ugly, since the tokenizer splits things on spaces.  Even if
> you did make it work with the current tokenizer (and you could, I think)
> you'd get weird error messages if you said something like "max trace 10"
> instead of "max trace level 10"  All in all, probably not a good thing.

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

'sor' is surface of revolution though. Of course I understand your
sentiment, writing a word out is more obvious. Especially difficult to
recall all the keywords if each and every were short versions. Except I
still could see getting along with several at least. superellipsoid is
one, especially; maybe 'sel'?. Ones like prism are fine.

Got 98 cents for a dollar?


Margus Ramst wrote:
> 
> I think you're going to extremes here. If all keywords had only 3-5 chars,
> it would be impossible (for me, at least) to memorize them. The name should
> have at least some connection with the function.
> And_what's_wrong_with_underscores_anyway?
> 
> Margus

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

Spider schrieb in Nachricht <36D2CD37.BED49543@bahnhof.se>...
>While we're at it, when will someone do a OOP-POV ???
>dot separated keywords and so on.
>int photon.mapsize
>int photon.level
>vector camera.look_at
>vector camera.postition

I've been thinking along the same lines last night. We can access a vector's
x, y and what-not, but we can't access an object's elements like that. I
would really have been glad to have something like camera1.position.x and
camera1.look_at.y or for an Escher pic I was working on.

(Must be our Delphi background, I suppose <heh>.)

--
Rudy Velthuis

Post a reply to this message

Bob Hughes wrote:
> 
> "Possibly" sounds encouraging.
> I was thinking along the lines that if the two or more words could be
> done with spaces then somehow it would be seen *only* when all the group
> were present, like when part of a keyword is written into the CodeMax
> editor it shows that the keyword is not all there (also if written
> wrong) by not switching color. So if all the words were present in
> proper placement (and spelling) it would be recognized and only then.

I could live with the loss of underscores and abreviated key words
but have a feeling it would make the language a little too loose
by adding support for spaces. Personaly I see no advantage to it
anyway. If you want to do two things to reduce code size and ease
of entering then turn around and add spaces back in. Where are you
going with this ?

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Bob Hughes schrieb in Nachricht <36D32A3C.A7C6D824@aol.com>...
>'sor' is surface of revolution though. Of course I understand your
>sentiment, writing a word out is more obvious. Especially difficult to
>recall all the keywords if each and every were short versions. Except I
>still could see getting along with several at least. superellipsoid is
>one, especially; maybe 'sel'?. Ones like prism are fine.
>
>Got 98 cents for a dollar?

The size of the keyword can be larger, as long as it is not used very often.
In Delphi we have words like initialization, finalization or implementation
which are really a nuisance to type. But they appear only once in a file. I
think sor is a bit short. I first though it was some kind of boolean
operation (like or, and and not). Superellipsoid is ok for me. (Supertoroid
would be nice too.)

--
Rudy Velthuis

Post a reply to this message

Rudy Velthuis wrote:
> 
> Bob Hughes schrieb in Nachricht <36D32A3C.A7C6D824@aol.com>...
> >'sor' is surface of revolution though. Of course I understand your
> >sentiment, writing a word out is more obvious. Especially difficult to
> >recall all the keywords if each and every were short versions. Except I
> >still could see getting along with several at least. superellipsoid is
> >one, especially; maybe 'sel'?. Ones like prism are fine.
> >
> >Got 98 cents for a dollar?
> 
> The size of the keyword can be larger, as long as it is not used very often.
> In Delphi we have words like initialization, finalization or implementation
> which are really a nuisance to type. But they appear only once in a file. I
> think sor is a bit short. I first though it was some kind of boolean
> operation (like or, and and not). Superellipsoid is ok for me. (Supertoroid
> would be nice too.)
> 
> --
> Rudy Velthuis

I like "superlips". Has a nice ring to it.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

I bet there's some side effects that may not be immediately apparent
too. In Keith Rule's Graphic File Formats, he explains why the use of
commas between vector components were added.  If you have a vector 1.0 2
0.0, the parser might think you meant <1.02, 0.0, 0>.  Something like
that.  I bet a lack of underscores could lead to some keywords getting
mixed up.

-Mike

Ron Parker wrote:
> 
> On Tue, 23 Feb 1999 12:32:51 -0600, Bob Hughes <inv### [at] aolcom> wrote:
> >crss {}
> 
> I asked about that one because it's one of the longer new keywords
> in the superpatch.  Obviously, it's not one of mine.  I don't change
> other people's keywords for compatibility's sake, unless there's a
> conflict (the #macro stuff from the iso patch, for example.)
> 
> >Any idea about making spaces available between keywords? Plausible
> >(doable I don't know) to make a keyword recognisable (oops, my Canadian
> >sp.) which goes as a pair of words or more?
> 
> Possible but ugly, since the tokenizer splits things on spaces.  Even if
> you did make it work with the current tokenizer (and you could, I think)
> you'd get weird error messages if you said something like "max trace 10"
> instead of "max trace level 10"  All in all, probably not a good thing.

Post a reply to this message

On Wed, 24 Feb 1999 02:55:00 -0600, Mike <Ama### [at] aolcom> wrote:
>I bet there's some side effects that may not be immediately apparent
>too. In Keith Rule's Graphic File Formats, he explains why the use of
>commas between vector components were added.  If you have a vector 1.0 2
>0.0, the parser might think you meant <1.02, 0.0, 0>.  Something like
>that.  I bet a lack of underscores could lead to some keywords getting
>mixed up.

Actually, that one was due to the imparsability of <1 -2 3> as a vector.
is that <-1, 3, 0> or <1, -2, 3>?  I remember they documented the change
as such when they did it, anyway.

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote:

  Now, here we have a person who definitively have been raytracing too
long... ;)

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/

Post a reply to this message

Think you lost me more than I you.
Simply put, if you had 'light source' instead of 'light_source' and
there was a way the pvengine would only see it when written that way,
ie. *not* when typed in as 'source light' or 'light color' (parser would
say "What the...!? then), I would certainly like that way of things.


Ken wrote:
> 
> Bob Hughes wrote:
> >
> > "Possibly" sounds encouraging.
> > I was thinking along the lines that if the two or more words could be
> > done with spaces then somehow it would be seen *only* when all the group
> > were present, like when part of a keyword is written into the CodeMax
> > editor it shows that the keyword is not all there (also if written
> > wrong) by not switching color. So if all the words were present in
> > proper placement (and spelling) it would be recognized and only then.
> 
> I could live with the loss of underscores and abreviated key words
> but have a feeling it would make the language a little too loose
> by adding support for spaces. Personaly I see no advantage to it
> anyway. If you want to do two things to reduce code size and ease
> of entering then turn around and add spaces back in. Where are you
> going with this ?
> 
> --
> Ken Tyler
> 
> mailto://tylereng@pacbell.net

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

That's what I was wondering though, unless it was implausible in the
coding of the program then obviously it wouldn't work anyway, but if it
was possible the why not as I said to one of Kens posts:
Simply put, if you had 'light source' instead of 'light_source' and
there was a way the pvengine would only see it when written that way,
ie. *not* when typed in as 'source light' or 'light color' (parser would
say "What the...!? then), I would certainly like that way of things.
A group of words from 2 to ? using spaces, as long as the program code
could discern in the afore-mentioned way, I would think it might be the
best alternative to underscoring.


Mike wrote:
> 
> I bet a lack of underscores could lead to some keywords getting
> mixed up.
> 
> -Mike
> 
> Ron Parker wrote:
> >
> > On Tue, 23 Feb 1999 12:32:51 -0600, Bob Hughes <inv### [at] aolcom> wrote:
> > >crss {}
> >
> > I asked about that one because it's one of the longer new keywords
> > in the superpatch.  Obviously, it's not one of mine.  I don't change
> > other people's keywords for compatibility's sake, unless there's a
> > conflict (the #macro stuff from the iso patch, for example.)
> >
> > >Any idea about making spaces available between keywords? Plausible
> > >(doable I don't know) to make a keyword recognisable (oops, my Canadian
> > >sp.) which goes as a pair of words or more?
> >
> > Possible but ugly, since the tokenizer splits things on spaces.  Even if
> > you did make it work with the current tokenizer (and you could, I think)
> > you'd get weird error messages if you said something like "max trace 10"
> > instead of "max trace level 10"  All in all, probably not a good thing.

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

Well, I'm OOP in every-way... (I do JAVA as well :-)
But, I think POV animations and several other things would be easier o
acces with .<variable>
Perhaps only read-only (only an only to many?) but it would still be
nice.




Rudy Velthuis wrote:
> 
> Spider schrieb in Nachricht <36D2CD37.BED49543@bahnhof.se>...
> >While we're at it, when will someone do a OOP-POV ???
> >dot separated keywords and so on.
> >int photon.mapsize
> >int photon.level
> >vector camera.look_at
> >vector camera.postition
> 
> I've been thinking along the same lines last night. We can access a vector's
> x, y and what-not, but we can't access an object's elements like that. I
> would really have been glad to have something like camera1.position.x and
> camera1.look_at.y or for an Escher pic I was working on.
> 
> (Must be our Delphi background, I suppose <heh>.)

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

Bob Hughes wrote:
> 
> That's what I was wondering though, unless it was implausible in the
> coding of the program then obviously it wouldn't work anyway, but if it
> was possible the why not as I said to one of Kens posts:
> Simply put, if you had 'light source' instead of 'light_source' and
> there was a way the pvengine would only see it when written that way,
> ie. *not* when typed in as 'source light' or 'light color' (parser would
> say "What the...!? then), I would certainly like that way of things.
> A group of words from 2 to ? using spaces, as long as the program code
> could discern in the afore-mentioned way, I would think it might be the
> best alternative to underscoring.

Why confuse thing by adding spaces ?  lightsource{}   I can read it.
Better yet would be light{}, cam{}, tex{}, pig{}, obj{}, tri{},
smthtri{}, sph{}, cyl{}, tor{}, sprlips{}, and I think you get the idea.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken wrote:
/.../ 
> Better yet would be light{}, cam{}, tex{}, pig{}, obj{}, tri{},
> smthtri{}, sph{}, cyl{}, tor{}, sprlips{}, and I think you get the idea.
> 

I think this could be annoying to the user. When I mis-type
superellipsoid, I can logically deduct what's wrong. When I mis-type
sprlips, what next? I can try superlips <g>, suprlps, sprellips, splips,
sprlps etc...
Granted, I'll learn as time goes by, but why confuse matters? Most good
editors have macro keys to save typing.

Margus

Post a reply to this message

Bob Hughes schrieb in Nachricht <36D4526F.97901B37@aol.com>...
>Think you lost me more than I you.
>Simply put, if you had 'light source' instead of 'light_source' and
>there was a way the pvengine would only see it when written that way,
>ie. *not* when typed in as 'source light' or 'light color' (parser would
>say "What the...!? then), I would certainly like that way of things.
>

It is possible and done before, but I'm afraid the parser would even be
slower than it is now (and it really is, IMHO - please let's not discuss the
speed of the parser again, not here).

But radically changing the keywords is not what we need. I'd rather see a
more object oriented approach, where every object (where light_sources and
cameras would also be objects) would have a predefined set of properties,
which can either be set or read and have a default value. I'm not asking for
data encapsulation or inheritance (yet <g>) or any other *real* object
oriented behaviour, just for a slightly different approach. In fact we
almost have this, but now all properties of objects are keywords too. That
would be too much. All the different types in some objects could just as
well be named constants. Also look_at and position wouldn't be keywords
anymore, but simple properties, where the naming conventions could be
different (e.g. Camera1.LookAt and Camera1.Position - my favourites).

camera {
  Position <1, 1, 1> // or even "Position = <1, 1, 1>"
  Up <0, 1, 0>       //         "Up = <0, 1, 0>
  LookAt <0, 0, 0>   //         "LookAt = <0, 0, 0>
}

light {
  ....

#declare MyBlob = blob {
  Threshhold = 0.7;
  Elements =

    sphere

etc. etc.

But on the other side, this would perhaps turn the script language even more
into a programming language. Good for programmers, bad for non-programmers,
who would have an ever steeper learning curve.

It would propably also make the parser faster (because of the stricter rules
applied), but also much less flexible. Although flexiblity can lead to
sloppiness and mistakes which are hard to find.

There are pros and cons to each approach (the current one and the one I'd
like to see).

So propably the best thing would be to leave it as it is and just add more
and more keywords (either with or without underscores). I could live with
that, as long as the parser speed would be improved constantly.
--
Rudy Velthuis

Post a reply to this message

Spider schrieb in Nachricht <36D46A96.FF2A70EC@bahnhof.se>...
>Well, I'm OOP in every-way... (I do JAVA as well :-)
>But, I think POV animations and several other things would be easier o
>acces with .<variable>
>Perhaps only read-only (only an only to many?) but it would still be
>nice.

See my reply to Bob Hughes too (today, 14:17). It would really be nice to
have them, as properties and not as keywords. There are far too many
keywords wasted for this. Every aspect of every object is considered a
keyword, not a property. If they were properties specific to an object (or a
class of objects), there would be less name clashes, so the keywords could
be shorter and simpler. Also the syntax would be simpler and clearer (to me
at least).

The problem with the POV script language is the fact that it was a very
simple language which has grown so radically, that more and more keywords
had to be introduced. This is because the language had a C-like syntax and
didn't treat objects the OO way then. So there either has to be a radical
change to it, making it more like it should be: an object oriented
description language, or the wild growth is likely to continue.

But I'm afraid we won't find many in the POV-Team to agree with us. And we
might also upset old-time users, who often know the keywords by their first
and last names.

--
Rudy Velthuis

Post a reply to this message

On 24 Feb 1999 08:43:25 -0500, Nieminen Mika <war### [at] cctutfi> wrote:

>Peter Popov <pet### [at] usanet> wrote:
>
>  Now, here we have a person who definitively have been raytracing too
>long... ;)

Thank you, Warp! It was about time someone realised it :)


---------
Peter Popov
ICQ: 15002700

Post a reply to this message

Rudy Velthuis wrote:
> 
> Spider schrieb in Nachricht <36D46A96.FF2A70EC@bahnhof.se>...
> >Well, I'm OOP in every-way... (I do JAVA as well :-)
> >But, I think POV animations and several other things would be easier o
> >acces with .<variable>
> >Perhaps only read-only (only an only to many?) but it would still be
> >nice.
> 
> See my reply to Bob Hughes too (today, 14:17). It would really be nice to
> have them, as properties and not as keywords. There are far too many
> keywords wasted for this. Every aspect of every object is considered a
> keyword, not a property. If they were properties specific to an object (or a
> class of objects), there would be less name clashes, so the keywords could
> be shorter and simpler. Also the syntax would be simpler and clearer (to me
> at least).
> 
> The problem with the POV script language is the fact that it was a very
> simple language which has grown so radically, that more and more keywords
> had to be introduced. This is because the language had a C-like syntax and
> didn't treat objects the OO way then. So there either has to be a radical
> change to it, making it more like it should be: an object oriented
> description language, or the wild growth is likely to continue.
> 
> But I'm afraid we won't find many in the POV-Team to agree with us. And we
> might also upset old-time users, who often know the keywords by their first
> and last names.
> 
> --
> Rudy Velthuis

  Since  I don't have the advantage of a programmers background the idea of
assigning properties to a function as opposed to assigning a keyword is
being lost on me. How can you do one without the other ?

  I have always worked with the assumption that it is the job of the scene
file writer, that would be us, to pass commands to the program. It needs
this kind of input from the operater in order to process the information
in a manner consistent with out needs. If you don't have specific terms
(keywords) for assigning properties to a function you are passing to the
program how will it know what you what it to do ?

  On the topic of changing the current scene file language I see the
possibility of heavy opposition. There are the considerations of ease
of learning a difficult program like this because of it's rich, easy to
understand, object oriented language. You don't have to be a programmer
to use Pov it if you are determined enough and it shows what people are
willing to go through to see all of them pretty pictures that come out it.

 Another important point is the incredibly vast amount of resources available
that have been written as support for the program and all of these rely on
the program language not changing. If you change the language you retire the
work of people from the last 8 years many of which have finally begun to evolve
into something useful.

 Additionaly there is the Pov Teams desire to maintain backward compatibility 
with it's own incarnations. This kind of change not only has a clear and
immediate impact on every user out there, it also makes many thousands of
scene files obsolete and useless. The amount of blood, sweat, and tears, that
went into the making to those scene files would make the person who changed
the program into something considerably less than a saint or friend of the
people.


-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken schrieb in Nachricht <36D62965.52AF9E50@pacbell.net>...
>Rudy Velthuis wrote:
>>
>> The problem with the POV script language is the fact that it was a very
>> simple language which has grown so radically, that more and more keywords
>> had to be introduced. This is because the language had a C-like syntax
and
>> didn't treat objects the OO way then. So there either has to be a radical
>> change to it, making it more like it should be: an object oriented
>> description language, or the wild growth is likely to continue.
>>
>> But I'm afraid we won't find many in the POV-Team to agree with us. And
we
>> might also upset old-time users, who often know the keywords by their
first
>> and last names.
>>

>  Since  I don't have the advantage of a programmers background the idea of
>assigning properties to a function as opposed to assigning a keyword is
>being lost on me. How can you do one without the other ?

I don't see an object as a function. An object is something which has
properties and can do something too (even if it is something silly like
falling sown or breaking).

Now POV is not ready for the doing yet, but IMHO every object has common
properties (texture, size, bounding box) and some specific ones: a sphere
has a radius and a center, a cone two "centers" and two radii, a cylinder
two "centers" but one radius, a box two opposite corners, etc. etc.

I would like to be able to access these properties, like in

#declare MyVect = sphere1.Center

or

#declare MyTexture = box1.Texture



>  I have always worked with the assumption that it is the job of the scene
>file writer, that would be us, to pass commands to the program. It needs
>this kind of input from the operater in order to process the information
>in a manner consistent with out needs. If you don't have specific terms
>(keywords) for assigning properties to a function you are passing to the
>program how will it know what you what it to do ?

I have a different concept of "keyword". In most scripts and programming
languages, keywords are a small set of control words, which define the
language (like "for", "while", "begin", "end", "switch", "object", "struct",
"int", etc.). All other words are just identifiers, which stand for a
string, a character, a numeric, an object/class, a structure etc.

There are many keywords in POV-Ray which are in fact just representations of
a numeric, like
prism's linear_spline, quadratic_spline, cubic_spline, bezier_spline,
linear_sweep and conic_sweep. They are in fact just numerics which were
given a name. In my concept they would be constants or enumeration types,
which (jn this case) represent numbers. It would have done, if the creators
of POV had #declared these words as numerics and had made the PRISM_ITEM
property of a prism a numeric:

#declare linear_spline = 1
#declare quadratic_spline = 2
...


prism { linear_spline, 0, 1, etc...

would be equivalent to

prism { 1, 0, 1 etc...

Rememer, in POV-Ray we often use constants like that: the colors White or
Black, the finishes Shiny or Dull, etc. They are all examples of constants,
representing a POV structure. They are not keywords, although they influence
the output of the program of course. I would liked to have the same kind of
constant definitions for many values which are declared as keywords now. I
would like to get rid of these pseudo-keywords, without upsetting the
language. Of course there could/should be some kind of standard .inc, which
would automatically be defined, even if it were not physically present on
the (hard) disk (some kind of standard "run time" library). To most users it
wouldn't make a big difference, they wouldn't even notice it. Only the
semantics (the true meaning behind it) of the words would differ, not
necessarily their use or their output.

If I decide to #declare a linear_spline now, I'll get an error message. To
avoid these kind of conflicts, the POV creators defined rather extensive
keywords like "linear_spline". If there were only a few keywords, they could
be rather short, and the spline item could just as well be called "linear",
because it would only be valid inside the prism (like any property would
only be valid inside the object it is defined for), and it would be known it
were a spline item:

prism {
  Linear
  // etc.
}

 So you could use the same word in different objects with a slightly
different meaning. But they would not be keywords anymore, they would be
properties of this object (class). And if I would #declare a variable
Linear, it would not be confused with prism.Linear.

>  On the topic of changing the current scene file language I see the
>possibility of heavy opposition. There are the considerations of ease
>of learning a difficult program like this because of it's rich, easy to
>understand, object oriented language. You don't have to be a programmer
>to use Pov it if you are determined enough and it shows what people are
>willing to go through to see all of them pretty pictures that come out it.

I see this too. That's propably why we will have to cope with the old
POV-Ray script language much longer. Although it wouldn't be too hard to
make two different front-ends for the rendering machine. But if I understand
right, the POV-Team objects to this because of the possible danger of people
using (and making money with) their rendering back-end without the proper
front-end (script language parser) and without their consent.

> Another important point is the incredibly vast amount of resources
available
>that have been written as support for the program and all of these rely on
>the program language not changing. If you change the language you retire
the
>work of people from the last 8 years many of which have finally begun to
evolve
>into something useful.

Not really. You wouldn't change POV-Ray 3.1, so it would still be available.
Many programs written for DOS had to be rewritten for Windows. So why
couldn't Moray, sPatch etc. be rewritten for a newer language version? This
is not really very hard. E.g. converting Moray to Windows must have been
much harder.

> Additionaly there is the Pov Teams desire to maintain backward
compatibility
>with it's own incarnations. This kind of change not only has a clear and
>immediate impact on every user out there, it also makes many thousands of
>scene files obsolete and useless. The amount of blood, sweat, and tears,
that
>went into the making to those scene files would make the person who changed
>the program into something considerably less than a saint or friend of the
>people.

These scene files would still render with the current POV-Ray.

And the changes wouldn't be too drastic. POV-Ray has changed in the mean
time too (the treatment of commas, the semicolons in single line #declares,
the demission of halo come into my mind). It would be easy to write a little
conversion utility to translate 3.x source to the new source. Most of the
source wouldn't even have to change. Propably only the syntax would have to
be stricter, perhaps even that would be unnecessary (I know how many would
object to that alone).

BTW, most of my views presented here are not fully though out, but I think
one could get rid of many pseudo-keywords without turning old scenes
invalid. One would perhaps only have to include one or a few new standard
.inc files, doing the #declaration of the pseudos as constants.

But I know, this is propably a very impopular view altogether, so I do not
expect any changes along these or similar lines. It would be nice though, if
we could at least *read* some of the properties of some objects
(camera.position or light_source.color).

 --
Rudy Velthuis

Post a reply to this message

On Fri, 26 Feb 1999 21:17:12 +0100, Rudy Velthuis <rve### [at] gmxnet> wrote:
>There are many keywords in POV-Ray which are in fact just representations of
>a numeric, like
>prism's linear_spline, quadratic_spline, cubic_spline, bezier_spline,
>linear_sweep and conic_sweep. They are in fact just numerics which were
>given a name. In my concept they would be constants or enumeration types,
>which (jn this case) represent numbers. It would have done, if the creators
>of POV had #declared these words as numerics and had made the PRISM_ITEM
>property of a prism a numeric:
>
>#declare linear_spline = 1
>#declare quadratic_spline = 2
>...

In fact, if you look in the appropriate places, you'll find that some of
the radiosity constants are declared just this way, so it will work in a
limited sense.  But the reason for the keywords is that they can be 
specified in any order, or not at all.  Consider, say, the smooth keyword
in a height_field object.  If we instead had
#declare smooth=1; #declare no_smooth=0;
then we would always have to specify either smooth or no_smooth.  And
because they lack any type information, we'd have to be very careful to
specify it in just the right order.  I don't know about you, but I already
get confused about order on some of the more complicated object types such
as bicubic patches. I'd almost rather see a sphere, say, have keywords for 
radius and center as well and make all the parameters optional (but 
defaulted) so I could say:

// a sphere centered on zero with unit radius:
sphere {}
// a sphere centered on zero with radius 2:
sphere {radius 2}
// a sphere centered on MyVect with unit radius:
sphere {center MyVect}

This is actually pretty close to what you're proposing, I think, and could
perhaps even be made backward-compatible, but I think it would have an adverse 
effect on parse time.

I guess what I don't understand is why you ever need camera.lookat.  Consider:

Your way:

  #declare MyCamera=camera {
    location -20*z
    look_at Complex_Slow_Macro_Expression( foo, bar, baz )
  } 

  camera{ MyCamera }
  sphere { MyCamera.look_at, 1 texture {pigment {color red 1}}}

My way:

  #declare camera_look_at=Complex_Slow_Macro_Expression( foo, bar, baz );
  camera {
    location -20*z
    look_at camera_look_at
  } 

  sphere { camera_look_at, 1 texture {pigment {color red 1}}}

I took some liberties with your way to deal with my opinion that there
shouldn't be any serious order dependencies within the scene description.
That is, the declaration of your sphere shouldn't be dependent on the
declaration of your camera having happened first.

I just don't understand why, if you know you're going to need it, you 
wouldn't just #declare the look_at position and use that when you need
it, especially since the alternative is to #declare the camera if you're 
going to look at its members (I can't conceive of any usable syntax for 
looking at the members of anonymous scene elements.)

And if everyone would just adhere to the simple rule that keywords should
be all lowercase and identifiers shouldn't, there would never be any
collisions.  Perhaps there should be a warning (disabled by #version,
of course) if you #declare something with an all-lowercase name.

Post a reply to this message