POV-Ray : Newsgroups : povray.programming : ATT: POV team and everyone - POV4 design proposal : Re: ATT: POV team and everyone - POV4 design proposal Server Time
28 Jul 2024 10:24:27 EDT (-0400)
  Re: ATT: POV team and everyone - POV4 design proposal  
From: Warp
Date: 10 Jan 2002 11:56:39
Message: <3c3dc7c7@news.povray.org>
Eugene Arenhaus <eug### [at] avalon-netcoil> wrote:
: 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.

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

: 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

  Not true. It does.

: Principle IV. Full scripting to replace macros

  I really don't like the word "replace".

: The scene description language should be or include a full-fledged
: scripting language.

  The POV-Ray SDL is Turing-strong. What else do you need?

  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 have made a raytracer with the POV-Ray SDL. Beat that.

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

: This significantly impedes parametric generation of scenes and
: animation, inducing ugly trickery down to abusing the macro language's
: file I/O capabilities in order to circumvent lack of true function
: declarations. Even with all the trickery, it is frequently extremely
: difficult to achieve the desired effect.

  I didn't understand this paragraph at all. How do #macros and functions
"impede parametric generation of scenes and animation"?

  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.

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

: Therefore, we suggest

  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?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.