> 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

Fa3ien wrote:

>> 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)

Correct.

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

Exactly, though doing so on all levels is tricks with the current
implementation. I.e. that is why (isosurface) functions cannot access
declared arrays dynamically at render-time.

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

The solution to the parse vs render time limits would be to make all
features of a scene object replaceable by the user from within the language
- i.e. even replace the intersection algorithm or the transformation
computations. That would also put POV on-par with Renderman.

	Thorsten

Post a reply to this message

Le 14.09.2007 17:13, William Tracy nous fit lire :
> 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?
> 
Have a look for yourself when source available.
In 3.6, it's just C in C++ disguise.
No clean object classes, No metaclasses, no hierarchies.


-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

Le Forgeron <jgr### [at] freefr> wrote:
> Have a look for yourself when source available.
> In 3.6, it's just C in C++ disguise.
> No clean object classes, No metaclasses, no hierarchies.

  3.7 might not be perfectly-designed C++ because it still drags so
much code from 3.6, but much better.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Le Forgeron <jgr### [at] freefr> wrote:
>> Have a look for yourself when source available.
>> In 3.6, it's just C in C++ disguise.
>> No clean object classes, No metaclasses, no hierarchies.
> 
>   3.7 might not be perfectly-designed C++ because it still drags so
> much code from 3.6, but much better.

:-)

Yeah, I was curious if there were any actual .c files left. It sounds 
like there isn't, but there's some code in the dark corners that only 
halfway made it through the transition...

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


 > >  - Type 0 are tesselated dynamically during render time and the
 > > tesselation results are discarded immediately once the intersections
 > > are found. In particular, I noticed that POV accessed the u_order
 > > and v_order variables and repetitively called the DeCasteljau
 > > subdivision functions during intersection computations...

I see.

     -- Warp

Post a reply to this message