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

Thorsten Froehlich wrote:
> 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.

That would be rather neat.

Post a reply to this message

Fa3ien wrote:
> I think that, prior to discussions about which approach should be
> taken, we should create a dozen (or so) of typical simple scenes
> which would include most typical SDL features (one with a loop, one
> with a macro, one with textures, one with 'trace', etc...).
> 
> Each envisioned language and/or paradigm should be tested 'against'
> these scenes, with sample would-be code.  This would allow, IMO,
> better evaluation upon criterias such as features, powerfulness,
> expandability, readability, user-friendliness, ease of implementation, etc...

I concur with the others - excellent idea.

-- Chris

Post a reply to this message

Christoph Hormann wrote:
> In short:  Simple tasks like a reflective sphere over checkered plane 
> need to be straight away to implement and to read - without knowing 
> about language concepts.  Like in the current SDL version of such a 
> simple scene the purpose of every token should be intuitively 
> understandable.  More complex features of the language would need to be 
> optional additions to this.

Putting this another way: POV-Ray's SDL grew from a simple means of
providing an object description to something that had many of the
traditional language constructs, while still retaining the ability to
define a scene in terms of objects with no 'programming' as such. This is a
Good Thing since it allows non-programmers to work with it and may have
been a significant factor in POV's acceptance.

Thus, I suspect it is desirable that any new 'official' SDL have the same
ability.

-- Chris

Post a reply to this message

Fa3ien wrote:
> 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.

I'm not opposed to this.

-- Chris

Post a reply to this message

William Tracy wrote:
> 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...

Even 3.6 has no .c files ... but 3.7 is much much (much) more object-
oriented. This was in part necessary due to the requirement to eliminate
(almost) all globals, as well as the fact that it's just easier to manage a
large codebase with you're dealing with encapsulated functionality.

-- Chris

Post a reply to this message

Chris Cason wrote:

> 
> Putting this another way: POV-Ray's SDL grew from a simple means of
> providing an object description to something that had many of the
> traditional language constructs, while still retaining the ability to
> define a scene in terms of objects with no 'programming' as such. This is
> a Good Thing since it allows non-programmers to work with it and may have
> been a significant factor in POV's acceptance.
> 
> Thus, I suspect it is desirable that any new 'official' SDL have the same
> ability.
> 
> -- Chris

Not even desirable, but, at least in my case, mandatory.
I know very little math and have no clue whatsoever about stuff like
isosurfaces and such, and absolutely no desire to learn a "real"[*]
programming language. What I do have however is a very good "internal eye"
which helps me see how I can create CSG-objects out of the primaries, box,
cylinder and sphere. With these limited resources I still manage to create
scenes with 100.000+ parts in it. I posted a mainboard render in 2005.


As an afterthought, while you guys are in the process of creating a new
language, please get rid of the "#" in front of some of the keywords. 
-- 
Ger

[*] With a real programming language I mean something that would resemble
C(++) or Object Pascal or ......

Post a reply to this message