 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204 213191226>,
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj wrote:
> 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
>
add-on what?
There is nothing to add, it is just a question of how you choose to use
what is already there!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23 Jul 2002 22:01:38 -0400, Rafal 'Raf256' Maj wrote:
> Something like "color" and "colour" keywords - the second is in fact aliast
> of 1st, and it is added to make SDL comfortalbe.
Actually, if one can be considered an alias of the other, I'd have to say that
the first is the alias. But of course it doesn't actually work that way.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I would resign my commission as coordinator of the Shortest Code Contest if
this were implemented.
"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> To be blunt, that looks horrible and I hope POV never supports it.
> Sorry. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204213191226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> 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"
Far too many parameters to be practical there...and what's wrong with a
set of macros?
> 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 ;)
And a third as many pages of apparently garbage text is an improvement?
People already balk at the idea of learning the scene language, it helps
if the keywords actually make some sense. Someone new to POV sees
"finish" followed by words that describe real-world surface
characteristics and it is fairly obvious the type of thing it referrs
to, they see "@@fi" followed by a bunch of similar garbage and what do
you expect them to think?
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
