In article <38b81aa4@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> Peter Popov <pet### [at] usanet> 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] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message