Eugene Arenhaus wrote:
> 
> Hello.
> 
> Here's my two cents.
> 
> Comments, discussion, corrections, additions are welcome.
> 
> "Waa, who needs [X]" and "Blasphemy!!!" are not welcome. :)
> 
> So, without much further noise:
> 
> -----
[SNIP of commercial where you promise all and its opposite:
 high speed for animation & lowest memory
 only one type & all kind
 unified(*) object & specific extensions... and so on]

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.
    The critical part for such a design is not enforcing the rules,
    it is in writing the documentation so that maintenance remains
    in the rules, and everybody has the same referential.
    Moreover, you think too much by yourself before exposing your idea
    to the community. So you will fail to get adhesion to your ideas.

Back with your proposal:

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.
Your SDL will in fact be C++ itself.
To parse will be to compile & link,
to render will be to execute the program.
Doing otherwise transform 'making pov' into 'making a C++ parser'.

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

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.
But IMNSHO your solution stinks.

(*)'Unify' seems to be the current buzz word. With probably more experience, 
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!
-- 
Non Sine Numine
http://grimbert.cjb.net/

Post a reply to this message

> > seeing as every incarnation of pov slectivly breaks previous versions of
the
> > SDL, why should it be a concern?
>
> afaik it not breaks, it extends
>
> you can still use poly, quadric even if it is possible with isosurface
> you can still write "declare" instead of "#declare"
> you have still mesh{} even if mesh2{} gives the same obeject for you
> you can still play with union of triangles instead of mesh
> you can still play with spherical, onion and other patterns instead of new
> function pattern (it allow redo of  almost all old patterns)
> the only big thing removed I remeber is halo{} - and I'm sure there was
reason

my point being you cannot take a pov 2.2 file and expect pov 3.5 to render
it without some tweaks

I for one would love to see a move towards oop.


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

"Rick [Kitty5]" wrote:

> I for one would love to see a move towards oop.

I hate change.

-- 
Ken Tyler

Post a reply to this message

On Fri, 11 Jan 2002 06:21:33 -0800, Ken wrote:
> 
> 
> "Rick [Kitty5]" wrote:
> 
>> I for one would love to see a move towards oop.
> 
> I hate change.

Me too.  Especially pennies.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

On Fri, 11 Jan 2002 14:18:14 -0000, "Rick [Kitty5]" <ric### [at] kitty5com> wrote:
> my point being you cannot take a pov 2.2 file and expect pov 3.5 to render
> it without some tweaks

have you checked this?

take below scene and render it twice with 3.5 but change
#version 3.5; to #version 3.1; at second render

#version 3.5;
//#version 3.1;
#local Shape=sphere{0,1}
#local Scale=1;
#local Normal=normal { granite .3 } 
background{rgb 1}
camera{location<30,30,100>look_at 0 angle 10}
light_source{<50,80,100> 1} 
#local I=0;
#while (I<4)
  object{
    Shape
    pigment { rgb 1 }
    finish { specular .2 }
    normal { Normal }
    scale (I*.5*Scale)+1
    translate (8-I*5)*x
    translate 4*y
  }
  object{
    Shape
    pigment { rgb 1 }
    finish { specular .2 }
    normal { Normal no_bump_scale}
    scale (I*.5*Scale)+1
    translate (8-I*5)*x
    translate -4*y
  }
  #local I=I+1;
#end

// ABX

Post a reply to this message

Ron Parker wrote:

> >> I for one would love to see a move towards oop.
> >
> > I hate change.
> 
> Me too.  Especially pennies.

The darn things just weigh me down.

-- 
Ken Tyler

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.

--
light_source{0,1}#macro c(J,a)sphere{0,1pigment{rgb z}scale a translate J+O}
#end#macro B(R,V,O)c(0,4)intersection{c(V,R)difference{c(-z*4x+10)c(-z*4.1x+
10)c(0<7.5,45,5>)}}#end B(12,0z*25)B(8y*4<0,12,50>)          // Batronyx ^"^

Post a reply to this message

> On Fri, 11 Jan 2002 14:18:14 -0000, "Rick [Kitty5]" <ric### [at] kitty5com>
wrote:
> > my point being you cannot take a pov 2.2 file and expect pov 3.5 to
render
> > it without some tweaks
>
> have you checked this?

I have spent hours doing conversions


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

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.

a little pointless as pov 4 will (hopefully) be C++ instead of C?


--

Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

I admire your attempt to motivate change. It seems like you invested a
lot of time writing this. POV-Ray is indeed in need of a facelift, but now
is not the time, and words alone do not make POV better. As I have learned,
personal action is of the escence to improve POV-Ray.

   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. I, luckily, am still in the nose-in-the-books phase. I have much to
study - and practice, before I open my mouth again on any feature-requests
and the like (some of which I will hopefully back up with at least
pseudo-code).

   If you are unable to code, then at least do what I did to get Blinn
shading into MegaPOV: help the coders by doing some research for them. They
have a limited amount of time - this being their 'hobby' - and they spend
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.

   As for your suggestions, yes, some of them sound valid, but others do
not. First of all, you should have known - if indeed you are so interested
in POV as to write this big long manifesto/proposal/whatever - that POV-Ray
3.5 is close to being completed, and indeed has many of the features you say
you would like POV to have. So be glad at least that some of your wishes
magically came true. Mine took much longer to reach fruition.

   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. That way you wouldn't have simply repeated
things we've read before, and might have found out that such a thing is in
the pipeline for indefinite future versions.

   Third, this suggestion of using C++ is also redundant, as you should have
noticed that the Team announced long ago that 4.0 would be done with it.

   To make a long story short: read before you write, study before you code
(so the Team doesn't spend months fixing it), code before you demand,
research and contribute thusly if you cannot code, and try not to rock the
boat.

   I could say a whole lot more to you, but my fellow POVers have said it
for me, so no need to repeat. Good day to you. Do not feel that we are
shunning you. Just pay more attention from now on, OK? :)

--
Anthony Bennett

Post a reply to this message