On 4/8/2009 9:41 PM, MessyBlob wrote:
> "clipka"<nomail@nomail>  wrote:
>> What good would that do? I mean, stuff that trace() and inside() cannot do for
>> you yet?
>
> The problem is that you can't do trace() or inside() on an object that has not
> yet been placed, but when it has been placed, it is a permanent placement.

That's actually not true.

When you call trace(), it's on an object that has been declared, but not 
necessarily placed.  You can do it like this:

#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

#if (hit)
   object { my_obj }
#end

The above code has the nice property of only parsing the object, and 
thus tracing it, if your intended intersection actually occurs.

However, it highlights one of the needs in the SDL of proper object 
support: mainly, the need to pass norm as an "out" parameter to the 
trace function, rather than returning a vector pair of the intersection 
point / normal.  With proper class support, this could be remedied.

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> The problem is that you can't do trace() or inside() on an object that has not
> yet been placed, but when it has been placed, it is a permanent placement.
> Conversely, if you place an object, and then as a result of trace(), decide you
> don't want that object to be placed, you can't then remove it. OO would solve
> this, in that the object would be referencable after placement, and deleted (or
> modified).

??? 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.

#undefining such an object even clears up the memory again, and right before
rendering all "non-invoked" objects are ditched automatically.

> > POV simply cannot really compute overlapping, for reasons of its very basic
> > design.
>
> I knew it was difficult, if not impossible on complicated objects (without some
> serious mesh work) so I was throwing this hat in the ring to challenge the
> existing design. Fair enough, I don't mind it being squashed if it's a no-goer.

I don't think the very fundamental basics of POV would be open for debate. Even
*if* POV 4 would be a complete re-write (which I currently doubt), it would be
based on the very same principle for geometric representation. To me there is
not the slightest doubt about that.

(The main motivation for this complete-rewrite thing, as it appears to me, were
legal issues with an intended license switch, but I gather these have been
addressed by now for most parts of the code.)

Post a reply to this message

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