Well, hello again, and thank you for taking interest -

 I feel I need to answer a few reoccurring questions and gripes. :)

 First: Again, I did not mean to bash POV. I merely wanted to provide
food for thought, not for target practice. :) Please try to not feel as
if I am assaulting your favorite program (language, feature, etc.) -
that was never my meaning.

 Second: Yes, you are right, I am most likely not up to date with the
cutting edge development done on POV 3.5, and for that I apologize. I am
much more experienced with software design in general than with this
particular program... My chief experience was with POV 3.1. Thank you
for your comments. Still, my goal was to think of a broad picture, not
to peck on particular features or tricks. 

 Third. No, it is not going to be a "completely different" language. In
fact, it can be made to reuse most scene files with at worst some minor
tweaking, if that goal is set. (With POV team saying themselves they
aren't going to make POV4 100% compatible with version 3 - thou who hast
not sinned... :) )

 And last... the goal of the post was, again, to provide a broader
picture as food for thought. I am not saying that there's no way to do
[X] in POV for any given [X] - the idea was to eliminate the need for
obscure, unintuitive, kludgy ways of doing that [X] for sake of an easy,
flexible way of doing it. There is difference between having to write a
whole program in POV script and merely plugging several objects
together, don't you agree? What I meant that the design similar to what
I outlines would really facilitate both making scenes and writing
patches, and it seems that similar thoughts are not mine alone, if your
corrections to my "gripes" are an indication - POV does move in that
very direction.

Thank you all.

Post a reply to this message

> > 1.    Unified, interchangeable scene object model
> Unified ? Is 3ds format somehow unified? If you want POV reader just write it.

Sorry, this was about scene object model: that is, the way objects that
compose the scene are represented in script and internally. It has
absolutely nothing to do with file formats like 3DS.

> > 3.    Instancing support
> ?
> Are you talking render farms ? It was discussed many times.

No, I am talking about reusing object descriptions internally: like
rendering 10000 copies of a sphere with only one actual sphere object
kept in RAM.
 
>What you suggest is very radicolous change of SDL and imo it is different
> language.

Cute blend of "radical" or "ridiculous" there. ;)

No, it's neither. It can be made, say, 98% compatible with current scene
syntax with no big difficulty. It's not really that different, merely a
small extension of what we have now.

Post a reply to this message

> Since you seem to have put quite a lot of work into this i wonder why you
> did not write any information about you and the reason of your interest in
> POV.  

Thank you; it is really not that much work, just application of past
experience. :) 

As for why I did not tell about myself, - I thought it would be fitting
to remain a fleshless voice rather than seem to be boastful. :)

Well... my reason for interest in POV is essentially my interest for
complex software design, which has shifted in the past three years to
hierarchies of interacting polymorphic objects in particular. There's a
number of tasks for which such hierarchies are very appropriate; in
fact, to put it broadly, all the products where the actual program does
not know about exact structure of its data initially do qualify. (Some
examples are: multimedia players and editors - and all software for work
with compound documents; game engines, customizable user interfaces; I
even once wrote a compiler using the same approach, this is why I think
that such system can parse POV scenes as well.) Since POV is obviously a
program which provides "parts" and lets the end user organize them in a
scene, it does qualify - add my interest ing CG and there you go. (Okay,
I confess - add some frustration from spending hours on figuring out how
to do a particular kludge instead of spending them on meaningful work.
;) )

>A lot of the things you write indicate that you don't have much
> practical experience with POV-Ray and you don't know much about the recent
> feature discussion and development.

True, I confess I did not follow the "cutting edge" though I've lurked
in this group. No doubt some or many of the features discussed were
already implemented. 

What can I say - I provide an outsider's look here. Which you might
still deem useful, I hope...

> - 'instancing' (clone/refer patch) have been discussed and planned before
> but it isn't as simple as it might seem.

I never said it was simple - I only said it was more than worth making.
 
> - your language change suggestions involve a lot of additional keywords
> and much longer scene files which makes learning the language and writing
> scenes not exactly easier.

Sorry, this is not true. The language may be whatever we make it, to
begin with. No need to stick with what I wrote. :)

By the way, more keywords is not necessarily a bad thing, if they are
intuitive. Which is mor readable: 

 sphere { <0,0,0>, 1 }

or 
 
 sphere { center <0,0,0> radius 1 } ?

Readability is a great thing to have, don't underestimate it. And use of
words like "radius" is not so out of line with existing syntax which
after all uses words like "texture" already....

Post a reply to this message

>   You can create an extremely wide variety of geometrical patterns with
> functions, the object pattern or the combination of both (to, for example,
> transform the shape of the latter with the former).
>   It is perfectly possible to make three red circles in a row on the surface
> of a white cylinder with functions.

I was not aware that object pattern was added to POV at the time when
the document was written.
 
> : Principle IV. Full scripting to replace macros
>   I really don't like the word "replace".

My bad. Make it "Full scripting to complement macros". :)
 
>   Of course shortcuts and support for features which make some things easier
> are nice, but the current SDL is not as bad as you are trying to make it
> sound.

I did not try to make it sound bad. I was merely looking at a good
thing, and saying "hmm, if we take this and this and connect them in a
slightly different way, it's going to work even better!"

> : PoV3 only has limited macro support, with parameters strictly
> : precalculated and support of true functions absent.
>   What is a "true function", and how does it differ from #macros or functions?

Well, with a retrospect this might have been stated better, you're
right.

Right now, if I am not mistaken, POV builds the scene once and then
renders it, right? For another animation frame, it parses it again and
renders it. At least it was so when I checked, and I heard that
complaint from many people - parsing takes too long for every frame.

So what I suggest is: parse once; and allow scripting to work on the
parsed scene. Scripts ("true functions") would work on scene tree in
memory, not on scene text file like macros - saves tons of re-parsing
and facilitates a great many things.
 
>   I didn't understand this paragraph at all. How do #macros and functions
> "impede parametric generation of scenes and animation"?

Try to pass a macro to a macro?
 
>   As for your OOP language suggestion, that has been discussed countless time
> before. It's not as a trivial issue as you seem to think.

I do not think it was trivial. It took me years of toil to learn how to
design such things - hardly trivial at all.
 
> : We suggest that the only and sole data type used by PoV4 should be a
> : vector.
>   Why? So no more strings nor floats?
>   How do you print some text with a vector?

Another blooper of mine, thank you! :)

It is meant to mean "only and sole data type used in ray casting".
Additional data types of course will be used, only not in the common
interface.

(As for floats - a float is a 1-dimensional vector.)
 
>   By the way, if this text is "By Eugene Arenhaus", why do you speak in
> plural? Are you a member of a royal family or something?

No, just using formal and impersonal style.

Post a reply to this message

Simon Adameit wrote:
> Do you know Povray 3.5 ?
> With it you can do many of the things that you say are impossible to do in
> POV.

So I see. I was only proposing a way to refine and consolidate all that,
to make development and use easier.

Post a reply to this message

> > Trace's input will be a single ray.
> > Trace's output will be a single ray.
> > In fact, it will be one and the same ray object.

> Umm... I seem to remember a few features that make this pointless. For instance,
unless I am mistaken,
> a partially transparent object splits an existing rays in two, passing one through
the object and bouncing
> the other off it. How the $%# do you do that with a trace routine which only returns
one ray? 

How? Easy. You write a Trace routine for transparency shader that will
create two more ray objects (passing and bouncing), cast them (by
calling Scene's Trace routine), combine the result in its single ray and
return that. 

Or, in short: You can cast a zillion rays if you want simply by
recursively calling Trace.


>I suggest
> you first learn 'why' things work the way they do before making suggestions about
how to 'fix' them. :p

Please do try not rush into replying before thinking. :P

Post a reply to this message

Christopher James Huff wrote:
 
> Well, first, you should be aware that there won't be any official
> discussion about POV 4 from the POV Team until POV 3.5 is finished.

Of that I am well aware. It was merely provided as food for thought. 

I am more than content with waiting. :)
 
> > Example 1.
> > PoV3 has a camera object that is used to render the scene. However, it
> > cannot be used in no other form in the scene, so making a scene that has
> > a television screen viewing the same scene requires trickery with image
> > maps and double-pass rendering, or even recreating copies of the scene.
> Well, the camera isn't really an object, it's more of a setting, like
> global_settings. You can move it around, but you can't texture it and
> you can't see it.

And why not? It does produce raster output, which can be used as texture
UV map if we render it then save the image and use it in another scene,
n'est pas? So why not let it be used as texture UV map without all that
hassle?
 
> Your example, 3 red circles on a cylinder, is quite possible...even with
> POV 3.1, though it is a lot easier with 3.5. And CSG has no side-effects
> on color.

Must have been my personal blunders, then... in my experience with 3.1,
I was not successful with making precisely those three circles that
would either protrude visibly from the cylinder as other cylinders, or
else show rendering artifacts - but not look like they were "painted on
surface".

> > for instance, it would enable the artist to use texture values to
> > control size and positioning of the objects, where currently it has
> > to be done either using random numbers or external programs.
> This can be done already in POV 3.5.

Good. 
 
> > PoV3 only has limited macro support, with parameters strictly
> > precalculated and support of true functions absent.
> What do you mean "precalculated"? And in what ways have you been limited
> by POV macros?

Can I make a macro that would calculate a macro that I would pass it in
a parameter?

> BTW, POV 3.5 supports "true functions" that can be evaluated at render
> time when necessary.

My goal was to propose a "streamlined" version of what already is there. 

I am very sorry if I seemed as if I only wanted to peck on features.
 
> > We suggest that the only and sole data type used by PoV4 should be a
> > vector.
> Well, I'd suggest 4: vector, scalar, character, object. The "object"
> type would be objects in the OOP sense, not shapes. 

I would say that scalar is merely a 1-dimensional vector.

Character/string and object are okay, certainly. Object type would be
needed to link the scene object together anyhow.

> The library would include a standard "string" object to handle characters, "file"
objects,
> etc.

Naturally.

> Anyway, you might want to look at the CSDL draft I will post in
> povray.off-topic...it is a simulation description language I'm working
> on which will have a library for POV-Ray scene description.

Could you please tell when you post it?

Post a reply to this message

"J. Grimbert" wrote:
 
> Ad hominem first:
>  I bet you just learned about C++ at school,
>     get some lessons on parsing and
>     some other on project management with experienced people,
>     but have yet no real first hand experience by yourself.

Now that was rather mean, J. Grimbert. :)

FYI:

 I am years past school;
 I have 12 years of practical programming experience;
 I have written some programs before using similar principles;
 My sphere of interests is designing with objects and design of
hierarchical polymorphic systems;
 I shun C++ because it tempts me to write kludgy code - so I stick with
Object Pascal to ensure clarity of design in my projects;
 I do not think that yacc and lexx are the best things for parsing too.
;)

Not quite the picture you painted.

(Hmm, loooks like I am spilling personal info after all...)

>     Moreover, you think too much by yourself before exposing your idea
>     to the community. 

True. Sometimes an outsider's view can shed a light than someone's whose
eye is too involved, not seeing the forest behind the trees.

>So you will fail to get adhesion to your ideas.

Adhesion to ideas I do not seek, I am not here to start a cult. If
something good grows from the ideas, I'll be happy. If not, there are
many things in the world.
 
> The only way I can see to implememnt your design is to have
>  the rendering engine as a C++ library which is missing one object
> with two method: create() and trace(). The object is of course the
> scene to render. and trace() is in fact inherited from the library,
> so only the create method need to be written by the artist.

That's the way you see, which may be different from mine. In fact, it is
different from mine, so there's obviously more than one way to implement
my design. 

For one, if we get technical, I'd have not only Create() and Trace(),
but also Timer(), and Parse() with its framework.

The artist would not, of course, need to write a line of C/C++ code. The
object creator ("patch writer") would mostly implement Trace() for each
object and configure Parse(). The artist will use script just as it is
done currently.

> Your SDL will in fact be C++ itself.

Wrong. It will be a set of self-parsing, self-organizing, self-tracing
objects.

> To parse will be to compile & link,
> to render will be to execute the program.

Wrong.

> <Irony on>
> You're just asking the artist to learn C++ instead of Pov SDL.
> But as YOU already know C++, it's obviously no-cost for everybody else.
> <Irony off>

Irony missed, sorry. This was neither meaning nor word nor intent.
 
> You have nevertheless some good points in pointing out some problems
> that do exists in pov 3. It is the only interest of your design.

I come to think that pointing out problems was not exactly the main
point of the document.

> But IMNSHO your solution stinks.

Does it? Well, what you have described is "your idea of my solution".
 
> you would know that a really unified object class really does nothing excepted
> prototyping, because each specific object class must rewrite all or part
> of the method and extend the data!

That is PWIM - Precisely What I Meant. :)


Thank you for your time and nerve!

Post a reply to this message

> As already mentioned several times, much of what you desire is already possible.
> As with anything, there is always room for improvement. I suggest you wait for
> the code to 3.5 be released, then follow the convential route of implementing
> your own unofficial version. The well implemented, popular parts could make it
> into a future version.
 
Thank you for advice. 

My proposal was not about implementing features in a different way; it
was about organizing existing features in a better way.

Post a reply to this message

"Tony[B]" wrote:
 
>    I admire your attempt to motivate change. It seems like you invested a
> lot of time writing this. 

Not even on the same order with the time I spent researching those
principles. Which are not exclusively applicable to PoV.

Thank you, nevertheless.

>    If you want things to be more like you plan them, then get your hands
> dirty and code till you wear your fingers down to a nub - prove that it can
> be done. 

Well... What "it"? Implementing these principles in software design? It
can be done, if my current pet project, the Quill, is any indication. It
is built using exactly the same approach: self-parsing, interacting,
uniform but polymorphic objects, even though it is not a raytracer. (It
would not be hard to "stuff" the Quill with raytracing routines, just to
"prove" the point - but it is not written in C++, so adapting PoV to its
framework would be kind of pointless - the result will be not nearly as
portable as PoV is.)

> most of it coding, not researching. Also, a wish-list such as yours sounds
> much sweeter to the ears with some papers/pseudo-code/code to back it up.

It's not about a "wish list". It's about having the same features but
organized in a way that would enhance the whole.

It seems that this is the most frequent misunderstanding so far:
thinking that I was complaining on features. Look closer: all "features"
I mentioned are really not the way something is implemented; they are
about how objects *connect* in the scene. It's about how to make
everything connect more efficiently and smoothly. Wouldn't a lubricated
machine run better than dry gears?
 
>    Second, it would have also been wise on your part to read previous
> discussions on the matter of OO'ing the POV SDL, to find out why the Team is
> not persuing implementing it yet. 

I did. What I read there is "yet". :)

Look, I did similar frameworks myself. They are certainly not a trivial
piece of programming, but they can be done and no one is going to
convince me it can't - as long as I can see my own code doing it in
front of my nose.

> things we've read before, and might have found out that such a thing is in
> the pipeline for indefinite future versions.

(It was proposed exactly for that future version.)

Post a reply to this message