Hi,
I have a little suggeston / future-request.
Myself I like usign Pov without any editor (to type code "by hands" :)
but there are one thing that IMHO makes it unnesesarly uncomfortalbe -  
[too] long names.

Compare i.e.:

difference {
  sphere { ... }
  torus { ... }
  finish { roughness 1 brillaince 2 relfection { .2 .5 } metallic 9 diffuse  
  0.7 }
} superellipsoid { ... }

with :

@@diff {
  s { } tr { }
  fi { rou 1 bril 2 ref { .2 .5 } met 9 diff 0.7 }
} @sup { ... }


So the idea is to use aliases for important names, and to mark them with 
'@'.

Implementation imho would be quite easy - ther is probalby one function 
that reads next element, and tells is it an object, float, string, 
undeclared identyfier, etc...

So only we have to do something like
void interprate(char *s) {
  if (s[0]=='@') {
    char *x = // match alias name, "s","tr","fi" etc
    interprate(x);
  } 
}




The more advanced idea is :

if alias is marked by "@@" like @@diff { ... } then assume that every name 
in it can be an alias, even it it is not marked with "@" (or "@@")

example :
 @sp { @fi { @ref } }   // ok. sp=sphere fi=finish ref=reflection
 @sp {  fi {  ref { } } // errors, fi and ref must be marked by "@"
@@sp {  fi {  ref { } } // ok fi and ref are inside "@@" block
 @sp {@@fi {  ref { } } // ok ref is inside "@@" block

maybe alsow it will be a good idea to implement @! operator, that removes 
aliases from following block (i.e when we need names like "fi" in it)

#declare fi = 5.0;
@@sp {
  fi { }
  @!pig {
     fi // fi is here an 5.0 float
  }
}

this new syntax might look strange now, but it will shorten code about x3 
times ! x3 shorter code = x3 more writing, x3 more comfortable
x3 more code on ona page (or screen)




My suggestions :

@tex  texture
@mat  material
@fin  finish
@nor  normal
@int  interior

@cmap color_map
@nmap normal_map
@mmap material_map

@sp   sphere
@bo   box
@pl   plane
@to   torus

@sup  superellipsoid (that's a good example ;)
@blo  blob

@br   brilliance (only in finish block)
@di   diffuse    (only in finish block)


I want to *help* to implement aliases, but I can not do it my self (I do 
not understand Pov's souces enought)


what do You thing about it ? If You agree that this is usefull, and 
somebody also want's to implement it - I will help :)

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

With all due respect, as nice as it is to save some typing, I think this is
a bad idea that would confuse people. I don't like it.

--
Anthony

Post a reply to this message

To be blunt, that looks horrible and I hope POV never supports it. 
Sorry. ;-)
The only benefit is less typing. It makes things much more difficult to 
read, scatters relatively hard to type and visually noisy @ characters 
throughout the code (I dislike the use of the # character in the current 
syntax for the same reason), and needlessly complicates the language. 
Worse, the same word means totally different things in different 
contexts.
The only benefit would be for obfuscated and shortest code contests. If 
you really just want to save typing, I would recommend you find a good 
editor...you could also use the existing #macro feature:

#macro supell(E, N) superellipsoid {E, N #end

supell(0.1, 0.5)
    texture {...}
}

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
1C8### [at] netplexaussieorg

> The only benefit is less typing. 

that saves time and is more comfortable

> It makes things much more difficult to 
> read, scatters relatively hard to type and visually noisy @ characters 
> throughout the code (I dislike the use of the # character in the current 
> syntax for the same reason), and needlessly complicates the language. 
> Worse, the same word means totally different things in different 
> contexts.

so, how about at least shorten some names, i.e. add keywoed "brill" that 
works same as "brilliance". 

Don't You agree that brilliance, reflection, diffuse, ambient are keywords 
that are used very common (if scene have meany diffrent textures), and ther 
is probably no reason to not have shorten versions. 

Something like "color" and "colour" keywords - the second is in fact aliast 
of 1st, and it is added to make SDL comfortalbe.

This ~10 keywords, maybe with diff and itner will make typing quicker, and 
will not make code less clear IMHO


> The only benefit would be for obfuscated and shortest code contests. If 
> you really just want to save typing, I would recommend you find a good 
> editor...you could also use the existing #macro feature:
> #macro supell(E, N) superellipsoid {E, N #end
> supell(0.1, 0.5)
>     texture {...}
> }

but it's usless in i.e. finish, normal, pigment, blob, mesh etc


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> so, how about at least shorten some names, i.e. add keywoed "brill" that 
> works same as "brilliance". 

No thanks.


> Don't You agree that brilliance, reflection, diffuse, ambient are keywords 
> that are used very common (if scene have meany diffrent textures), and ther 
> is probably no reason to not have shorten versions. 

No thanks. The disadvantages far outweigh the advantages in my opinion. 
"ambient" has 7 characters, it takes a fraction of a second to type.


> Something like "color" and "colour" keywords - the second is in fact aliast 
> of 1st, and it is added to make SDL comfortalbe.

That is an entirely different situation...both are valid spellings for 
the word.


> This ~10 keywords, maybe with diff and itner will make typing quicker, and 
> will not make code less clear IMHO

They are also polluting an already crowded namespace, and will make code 
less clear, adding more stuff to memorize, sprinkling odd characters and 
keywords through the files whose meanings are not obvious.


> > The only benefit would be for obfuscated and shortest code contests. If 
> > you really just want to save typing, I would recommend you find a good 
> > editor...you could also use the existing #macro feature:
> > #macro supell(E, N) superellipsoid {E, N #end
> > supell(0.1, 0.5)
> >     texture {...}
> > }
> 
> but it's usless in i.e. finish, normal, pigment, blob, mesh etc

I don't see how blobs or meshes are any different. And for the texture 
stuff, it isn't useless, just put the stuff you use most often as a 
parameter. You could also leave off the ending bracket to be closed 
outside the macro call.

#macro Fin(Dif, Amb, Spec, Rough, Refl)
    finish {
        diffuse Dif
        ambient Amb
        specular Spec
        roughness Rough
        reflection Refl
    }
#end

You could put these in an include and make things as short and hard to 
read as you want. ;-)
My point is that there is already a feature that can be used to do what 
you want, and the proposed feature has so many drawbacks that it is very 
unlikely you will find anyone willing to waste the time to implement it.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Go ahead type that way, then search and replace before you render.
No need to change POV at all!

Rafal 'Raf256' Maj wrote:

> Hi,
> I have a little suggeston / future-request.
> Myself I like usign Pov without any editor (to type code "by hands" :)
> but there are one thing that IMHO makes it unnesesarly uncomfortalbe -
> [too] long names.
> 
> Compare i.e.:
> 
> difference {
>   sphere { ... }
>   torus { ... }
>   finish { roughness 1 brillaince 2 relfection { .2 .5 } metallic 9
>   diffuse 0.7 }
> } superellipsoid { ... }
> 
> with :
> 
> @@diff {
>   s { } tr { }
>   fi { rou 1 bril 2 ref { .2 .5 } met 9 diff 0.7 }
> } @sup { ... }
> 
> 
> So the idea is to use aliases for important names, and to mark them with
> '@'.
> 
> Implementation imho would be quite easy - ther is probalby one function
> that reads next element, and tells is it an object, float, string,
> undeclared identyfier, etc...
> 
> So only we have to do something like
> void interprate(char *s) {
>   if (s[0]=='@') {
>     char *x = // match alias name, "s","tr","fi" etc
>     interprate(x);
>   }
> }
> 
> 
> 
> 
> The more advanced idea is :
> 
> if alias is marked by "@@" like @@diff { ... } then assume that every name
> in it can be an alias, even it it is not marked with "@" (or "@@")
> 
> example :
>  @sp { @fi { @ref } }   // ok. sp=sphere fi=finish ref=reflection
>  @sp {  fi {  ref { } } // errors, fi and ref must be marked by "@"
> @@sp {  fi {  ref { } } // ok fi and ref are inside "@@" block
>  @sp {@@fi {  ref { } } // ok ref is inside "@@" block
> 
> maybe alsow it will be a good idea to implement @! operator, that removes
> aliases from following block (i.e when we need names like "fi" in it)
> 
> #declare fi = 5.0;
> @@sp {
>   fi { }
>   @!pig {
>      fi // fi is here an 5.0 float
>   }
> }
> 
> this new syntax might look strange now, but it will shorten code about x3
> times ! x3 shorter code = x3 more writing, x3 more comfortable
> x3 more code on ona page (or screen)
> 
> 
> 
> 
> My suggestions :
> 
> @tex  texture
> @mat  material
> @fin  finish
> @nor  normal
> @int  interior
> 
> @cmap color_map
> @nmap normal_map
> @mmap material_map
> 
> @sp   sphere
> @bo   box
> @pl   plane
> @to   torus
> 
> @sup  superellipsoid (that's a good example ;)
> @blo  blob
> 
> @br   brilliance (only in finish block)
> @di   diffuse    (only in finish block)
> 
> 
> I want to *help* to implement aliases, but I can not do it my self (I do
> not understand Pov's souces enought)
> 
> 
> what do You thing about it ? If You agree that this is usefull, and
> somebody also want's to implement it - I will help :)
> 
> --
> #macro
> #g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
> pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local
> l=mod(c,100 );g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end
> light_source{ y 2}sphere{z*20
> 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

-- 
Your connection failed because: Your Flux Capacitor has gone bad.

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in
news:chr### [at] netplexaussieorg 

> 
> #macro Fin(Dif, Amb, Spec, Rough, Refl)
>     finish {
>         diffuse Dif
>         ambient Amb
>         specular Spec
>         roughness Rough
>         reflection Refl
>     }
> #end

> My point is that there is already a feature that can be used to do
> what you want, and the proposed feature has so many drawbacks that it
> is very unlikely you will find anyone willing to waste the time to
> implement it. 

finish { ambient 0 }
finish { ambient 0 diffuse .3 reflection { .2 .4 } metallic .7 brilliance 
1.2 }

will need 2 macros to make any sens, or one macro to be used like :
Fin(0, -1,-1,-1,-1,-1,-1); 
where -1 means "default value"


ok, It was just a suggestion. Meany peoples says "what, I had to write 10 
pages to get a simpel image ? no - thanks" and it's not easy to convince 
them... well - theirs problem ;)

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Daniel Matthews <dan#@3-e.net> wrote in news:110### [at] 3-enet

> Go ahead type that way, then search and replace before you render.
> No need to change POV at all!

add-on is a good idea imho. I'll see if it will be usefull

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

On 23 Jul 2002 20:45:42 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> Myself I like usign Pov without any editor (to type code "by hands" :)

Use POVWin if you want syntax completion. No need for long keyword typing.
IIRC Python port has it either. Leave short one-or-a-few-letter names for
local variables.

ABX

Post a reply to this message

Wasn't it Rafal 'Raf256' Maj who wrote:
>Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
>1C8### [at] netplexaussieorg
>
>> The only benefit is less typing. 
>
>that saves time and is more comfortable

If your main objective is to save typing, then you might consider using
the existing keyword expansion and/or codelist features.

Keyword         your            Keywod
                suggestion      Expansion

texture         @tex            tex[TAB][TAB]
material        @mat            mat[TAB]         
finish          @fin            fini[TAB]
normal          @nor            nor[TAB]
color_map       @cmap           co[TAB][TAB][TAB]
normal_map      @nmap           nor[TAB][TAB][TAB]
sphere          @sp             sph[TAB]
box             @bo             box
plane           @pl             pl[TAB][TAB]
torus           @to             to[TAB][TAB][TAB]
superellipsiod  @sup            sup[TAB]
blob            @blo            bl[TAB][TAB]
brilliance      @br             bril[TAB]
diffuse         @di             di[TAB][TAB]

The difference in the number of keystrokes is fairly minimal, but
keyword expansion and codelist have the following advantages:-

1. The resulting code is readable.

2. ALL the POV keywords are supported.

3. Easier to remember. E.g. you don't have to remember whether @br is
short for "brilliance" or "brightness".

4. You can use it to generate scenes that are compatible with previous
versions of POV.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message