|
![](/i/fill.gif) |
In article <38b81aa4@news.povray.org>, "Nathan Kopp" <Nat### [at] Kopp com>
wrote:
> Peter Popov <pet### [at] usa net> wrote...
> > : strict variable types
>
> I think that the non-programmers might balk at this. I like the way
> that renderman handles this by linking in to existing languages and
> thus only providing core functionality instead of syntax. However,
> for good or bad, POV is not currently heading in that direction.
Maybe we should make a separate language just for us programmers with a
converter to .pov files. :-)
Bad idea, I know. Unless there was an editor which automatically
"compiled" to POV and rendered the scene, it would just be too clumsy a
system to use. Maybe give POV two different parsers? Or make that
possible in a later version while rewriting the source?
> A minimal amount of stricter variables might be good, but I
> personally lean more towards looser variable types. For efficiency
> reasons (as you pointed out), it might be a good idea to allow the
> user to specify a few smaller/faster variable types. But careful
> attention would have to be paid to making it easy to use. Therefore,
> many paradigms from other programming languages (C/C++ especially)
> should not be used because the are not easy to learn and often
> difficult to use. Sure, they might be easy for most of us in _this_
> group, but there will be far more non-programmers who will not want
> to have to worry about what type of variable they need to use to get
> the precision they want.
This is true...maybe types aren't such a good idea, even though they
would be useful in some of the more complex include files and scenes.
However, I would like to see #declare and #local only be used to
*create* variables, with either another keyword(#let?) or no keyword at
all required to modify a variable, something like:
#declare K=0;// creates a variable K
#let K=K+1;// adds 1 to the variable K
K=K+1;// adds 1 to the variable K
This would make a lot of the includes easier to read and maintain, and
would make debugging easier, since it is clearer where a variable is
first created.
> > : displacement mapping for patterns
>
> Sounds interesting.
I think the pattern-vector_map approach would be best for this...any
other ideas?
> > : zero text object thickness
>
> Sounds good for rendering speed reasons.
> On the other hand, maybe a TTF pattern would be better. This way you
> could apply the TTF object to another infinitely thin object (such as
> a disc) and use filter/transmit to get the clear part.
Something like this? :-)
pigment {
object {
text {ttf "crystal.ttf", "my testing text", 1, 0
translate -z*0.001//to avoid co-incident surface problems
},
color White filter 1, color Blue
}
}
My object pattern was originally a text pattern, it was just more
versatile to let it use any object.
> > : Additional BRDF models
>
> I totally agree. Also, not simply _more_ BRDF models, but _better_ BRDF
> models.
I agree too, now that I have an idea of what one is...but what would a
good syntax be? And how well would they coexist?
--
Chris Huff
e-mail: chr### [at] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |