Chambers <ben### [at] pacificwebguycom> wrote:
> #declare my_obj = object { ... }
> #declare v_orig = <...>;
> #declare v_dir = <...>;
> #declare intersection = <0,0,0>;
> #declare norm = <0,0,0>;
> #declare intersection = trace(my_obj, v_orig, v_dir, norm)
>
> #declare hit = false;
> #if (intersection.x != 0) #declare hit = true; #end
> #if (intersection.y != 0) #declare hit = true; #end
> #if (intersection.z != 0) #declare hit = true; #end

Why not instead use

  #declare hit = (vlength(intersection) > 0);

Or, as we're being on it, do the proper thing and test for the normal instead of
the intersection point (which *could* happen to be <0,0,0> after all):

  #declare hit = (vlength(norm) > 0);

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> ??? Actually trace() and inside() *only* work on #declared objects, and do so
> independently on whether you have already "invoked" them into the scene or not.

OK, my mistake :o)  I must have made an incorrect assumption a long time ago,
that trace() worked with the instantiated objects in the scene. I haven't used
it since.

I think the original idea might be off-topic now, unless you want scripting
functions to interact with a partially-built scene.

Post a reply to this message

On 4/9/2009 3:28 AM, clipka wrote:
> Why not instead use
>
>    #declare hit = (vlength(intersection)>  0);

Because, sometimes I'm braindead? :)

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

Chris B wrote:
> When you say "all over the place" you may be able to access a few sites, 
> but
> when newbies do a Google and discover thousands of sites containing
> materials most of which just inexplicably don't work and can't readily be
> made to work then it's likely to have a very negative effect on their
> impression of the software.

Most of these materials are quite old, anyway. So it's not like we're 
making a bunch of recent, 1-6 month old docs obsolete.

-Mike

Post a reply to this message

clipka wrote:
> SYNTAX
> 
> * Basically "C Style"
> 
> Although it's probably far too early to talk about individual aspects of syntax,
> the overall "look & feel" might already make sense to discuss, or at least
> gather ideas about.
> 
> I think that with so many "C Style" languages out there and enjoying a lot of
> popularity (C, C++, C#, Java, JavaScript to name just the "major players" that
> spring to my mind), it doesn't hurt to go for a similar style, both in overall
> "look & feel" as well as various details. Not to mention that the curly braces
> will maintain some feeling of familiarity :) (It seems like POV's current SDL
> was inspired to some degree by C, too.) Another benefit is that POV itself is
> written in C++, so the developers themselves are familiar with the style.
> 
> Personally, I'd consider only Perl- and Basic-inspired languages to be
> widespread enough to use them as a basis for a new POV SDL; however, Perl is
> currently undergoing significant syntax changes itself, and Basic will not gain
> many supporters in the POV community I guess - let alone having no similarity
> whatsoever with the current SDL syntax.
> 
> Well, there would be another option: XML. But I don't think we need to discuss
> this here: XML is not particularly pretty to work with directly.

I agree with all your points so far. I'd just like to add that I like 
the Lua scripting language because it has a small footprint and comes 
without a lot of baggage. However, some might *prefer* all the baggage 
that comes with a language such as Python.

Anything C-like (such as JavaScript) would also be OK.

clipka wrote:
 > * Clear distinction of types
 >
 > The distinction between colors and vectors in the current SDL is to 
some degree
 > still a mystery to me; I think the two concepts should be better 
separated.
 >
 > Similarly, I think a clear distinction between floats and vectors 
would be good.

I *strongly* disagree with this point. I think POV's loosely typed 
nature is an asset, not a curse.

-Mike

Post a reply to this message

clipka wrote:
> This would require some alternative way of indicating whether the variable is to
> have global or inc/macro scope (#declare vs. #local); I guess we wouldn't want
> to ditch the #declare but keep the #local.

Ditching #declare would be OK. We should however keep #local.

-Mike

Post a reply to this message

Warp wrote:
> - The scripting language should also be designed so that it's easy to
>   flexibly read, parse and write data files (as well as handle the data
>   itself). This would allow writing things like 3DS or OBJ file format
>   importers as libraries. (This is an example of something which should
>   definitely be a library rather than a core feature.)


I agree with this as well. I wrote a parser for Lua once, so I know how 
difficult it can be. Are there any examples of existing languages we can 
compare to that were designed with this aspect in mind?

-Mike

Post a reply to this message

Kenneth wrote:
> My main concern is actually with 'semantics' (if that's the right word.) I.e.,
> the term #while seems to be quite logical and understandable in its meaning:
> "while (this is true) do this stuff" etc. Same thing with #if. But--using #for
> as an example again--I'm not so sure I understand what "for" signifies, in an
> English syntax sense. (Actually, I do seem to recall 'for-next' being a part of
> Fortran IV that I learned long ago in college. I think. Which has been my only
> experience with 'real' computer programming, aside from Basic or one of its
> iterations on an old Commodore computer. But #for doesn't immediately create a
> mental picture of what it does.) So my own desire would be to have SDL syntax
> that is as easy (or even easier) to 'quickly grasp' than the current version's.
> 
> KW

I can understand your point. When I started programming I found the 
"for" statement difficult to grasp, though now I prefer it in almost 
every case to "while" since it's more powerful and easier to type. The 
word "each" might be better than "for", since "for" is really just a 
shortening of "for each n in x do...", and is an easier description for 
newbies to understand. The only disadvantage is that "each" is not a 
preposition like "if", "for" and "while", and programmers tend to 
nitpick when it comes to consistency.

My 2 cents.


-Mike

Post a reply to this message

SharkD wrote:
>  > Similarly, I think a clear distinction between floats and vectors 
> would be good.
> 
> I *strongly* disagree with this point. I think POV's loosely typed 
> nature is an asset, not a curse.
> 
> -Mike

However, a vector is just another type of array that uses a different 
syntax ("<" and ">" instead of "{" and "}"), so there's no real need to 
keep both, technically.

And, I think the current method of declaring arrays/objects is bulky. In 
JavaScript you can use the "literal" form to declare normal arrays like 
this:
	var foo = [bar1, bar2, bar3];

and hash arrays like this:
	var foo = {bar1 : "lala", bar2 : "bebe", bar3 : "dada"};



In Lua it's even simpler. You declare normal arrays like this:
	local foo = {bar1, bar2, bar3}

and hash arrays like this:
	local foo = {bar1 = "lala", bar2 = "bebe", bar3 = "dada"}

Mixed normal and hash arrays require a bit of extra work in Lua, though. 
But, I'll not get into that here.

-Mike

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> Anything C-like (such as JavaScript) would also be OK.

I'd agree: JavaScript might be the right balance between popularity,
accessibility, and capability.

You might be able to draw upon the existing experience and projects that already
use JavaScript. For example (and these are wild examples), JIT compilers,
already-solved problems with parsing, scope, and OO (or variants thereof).

We'd then need to decide the object model.

Would we have POV-Ray JavaScript just as a SDL, or would it also containin the
rendering instructions (like PostScript says 'showpage' to print, or OpenGL's
control over rendering)? If so, then we'd enjoy lots of extra functionality,
but we'd need to lock it down against potentially malicious third-party
scripts.

Post a reply to this message