In article <3C3D9297.6641E0E4@avalon-net.co.il>,
 Eugene Arenhaus <eug### [at] avalon-netcoil> wrote:

> Here's my two cents. 

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.


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


> Example 2.
> PoV3 has dedicated texture maps that can be combined to create patterns
> on objects' surfaces. However, geometry cannot be used for that; it's
> not possible to draw three red circles in a row on the surface of white
> cylinder, unless you use an image map (which causes artifacts) - not
> even if you use CSG to merge the three red cylinders and one white and
> then clip it all with another cylinder - because CSG has side effects on
> color. Geometry-controlled pigments are just not generally possible.

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.


> Example 3.
> PoV3 has a flat height field object whose shape is calculated from an
> external image map. It does not, however, allow generation of height
> fields from built-in procedural textures,

POV 3.5 has 3 ways of doing that: the built-in height_field using the 
function "image" feature, isosurfaces, and standard macros.


> Principle II. Complete accessibility of object properties from scene
> description language

True, the only way you can do this is to declare the properties you want 
as variables, often a clumsy way to do things.


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


> 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?
BTW, POV 3.5 supports "true functions" that can be evaluated at render 
time when necessary.


> 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. The library would 
include a standard "string" object to handle characters, "file" objects, 
etc.

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.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

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