On Wed, 12 Sep 2007 15:51:55 -0700, William Tracy wrote:

> Anyway, that's why I'd really like to get some decent separation between
> the parser and renderer code, within reason.

That would certainly make writing import tools easier - the parser could 
essentially *be* the import tool (ISTR that that's what's often said 
about import/conversion tools - that you'd have to reimplement a 
significant portion of POV to get it working properly).  Something like 
Blender (which is also GPL - since we're talking POV under GPLv3 in 4.0) 
would really benefit from that.

Jim

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Trying to think of a situation where the presence of objects can only be 
> determined during a render...

  Creating objects is not the only use for loops.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Trying to think of a situation where the presence of objects can only be 
>> determined during a render...
> 
>   Creating objects is not the only use for loops.
> 
I might be aware of that, but my question is: under what kind of 
circumstances would you need a user defined loop *after* you have fully 
specified the scene? I can't think of any, but I don't have much 
experience with shaders and complex textures.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> I might be aware of that, but my question is: under what kind of 
> circumstances would you need a user defined loop *after* you have fully 
> specified the scene? I can't think of any, but I don't have much 
> experience with shaders and complex textures.

  Loop over a series of pixels and calculate their average?

-- 
                                                          - Warp

Post a reply to this message

> Interesting concept.
> Trying to think of a situation where the presence of objects can only be 
> determined during a render...
> Failing...

"trace" seems to me the most obvious example of "bi-directionality" between
the rendering engine and the scripting language.

(yeah, it's not during a render, it's during parsing, but it relies on data
  (result of an intersection computation) which should be given by the rendering
  engine)

Of course, that kind of feature could be extended to new possibilities, such
as the one evoked.

That's why, IMO, POV-Ray should been seen as a "rendering system", instead of
a "rendering engine fed by a script".

This doesn't mean the rendering engine and scripting system can't be separated
at code level (being able to develop other complete or partial scripting languages
would be great), but whatever interfacing system (bytecode, etc..) takes place
MUST be able to manage that kind of bi-directonality.

Fabien.

Post a reply to this message

> John VanSickle wrote:
>> By the way, I have been reading the stuff Pixar has at 
>> http://graphics.pixar.com , and some of it suggests improvements in the 
>> way that POV-Ray handles various kinds of anti-aliasing.  How open will 
>> the project be to changes of this nature?
> 
> Once the port is done and we have something stable, I'm entirely open to
> playing with new ideas. We may have a 'stable' and 'testing' tree for
> playing around with new ideas (with binaries released from each; probably
> the testing tree would get a nightly automatic build or something).

Why not start some "laboratory" groups right now ?  I mean, public groups,
where people could freely discuss many thing related to the future of POV-Ray,
in a constructive manner.

For example, there could be groups like :
"implementation of core engine"
"re-implementation of existing features"
"SDL evolution"
"C++ school" (where knowlegeable programmers would supervise motivated, but less
knowledgeable ones
  working as "little hands")
"texturing system"
"sample images re-write"
"documentation revision"
"feature requests" (where people could simply put ideas of new features or changes)
"documented feature request" (where people could say "hey, this could be added to
POV-Ray
  and there's a White Paper / GPL code availiable here / already done in
SuperPOV++0.7b
  and the guy who made it would be OK to help ...")

All this would form some kind of "knowledge base" and a helping community which would
be ready at appropriate time.

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Why not start some "laboratory" groups right now ?

  That would be an interesting thing to try. If for nothing else, then to
see if it would work. (It's not like it would cost anyone anything, and it
can always be cancelled if it results that it's a bad idea.)

-- 
                                                          - Warp

Post a reply to this message

Fa3ien wrote:
> "C++ school" (where knowlegeable programmers would supervise motivated, 
> but less knowledgeable ones

Just curious, as someone who has never really looked at the POV code 
(yeah, I should really find this out myself): Is POV all C++ by now, or 
is there any actual C code left?

-- 
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

You know you've been raytracing too long when you post an idea to a news 
group about starting an Internet movie project using PovRay.
     -- Ken Tyler

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> > Why not start some "laboratory" groups right now ?
>
>   That would be an interesting thing to try. If for nothing else, then to
> see if it would work. (It's not like it would cost anyone anything, and it
> can always be cancelled if it results that it's a bad idea.)
>
> --
>                                                           - Warp

I'm all for getting my hands dirty! :)

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:
> Just curious, as someone who has never really looked at the POV code 
> (yeah, I should really find this out myself): Is POV all C++ by now, or 
> is there any actual C code left?

  How do you define that something is C and not C++?

  If what you mean is "is there still something left which is from the
old C code and which would have a much better C++ equivalent", then
I suppose there is.

-- 
                                                          - Warp

Post a reply to this message