On Thu, 10 Jan 2002 15:09:43 +0200, Eugene Arenhaus wrote:
> Hello.
> 
> Here's my two cents. 
> 
> Comments, discussion, corrections, additions are welcome.
> 
> "Waa, who needs [X]" and "Blasphemy!!!" are not welcome. :)

What about "where's your working, tested, and debugged source code for
these patches again?"

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message

On Thu, 10 Jan 2002 15:09:43 +0200, Eugene Arenhaus <eug### [at] avalon-netcoil>
wrote:

> Here's my two cents. 

It's rather two thousands.

> Comments, discussion, corrections, additions are welcome.

Not to much

> We believe that basing PoV4 internal design on the following four
> principles should be sufficient to achieve this goal:

Who is we ?

> 1.	Unified, interchangeable scene object model

Unified ? Is 3ds format somehow unified? If you want POV reader just write it.
Specification is available.

> 2.	Complete accessibility of object properties from scene description language

Smart scripting gives it to you

> 3.	Instancing support

?
Are you talking render farms ? It was discussed many times.

> 4.	Full scripting to replace macros

I partially understand what it means but probably yes.

> Example 1. 
> Example 2.
> Example 3.

Do you know POV 3.5 features ? Please study it.

> I (let's drop the formal "we" now)

Finally, I don't like choirs ;-)

> Therefore, we suggest

Again ?

> May the possibilities never end!

Seems you have big knowledge about languages. Try to write parser for your
syntax and converter to old syntax. If everything is possible then it should be
too. What you suggest is very radicolous change of SDL and imo it is different
language. If it is good enough and gives the same possibilities why force so
many povers to learn all things/tricks again ? Why break all exporters to
disallow POV 4 rendering ? Why break all old include files ? Some people still
work with POV 2 scripts.

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)&_((x+y)*.7,z,.1)&_((x+y+2)*.7,z,.1)&_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

> If it is good enough and gives the same possibilities why force so
> many povers to learn all things/tricks again ? Why break all exporters to
> disallow POV 4 rendering ? Why break all old include files ? Some people
still
> work with POV 2 scripts.

seeing as every incarnation of pov slectivly breaks previous versions of the
SDL, why should it be a concern?


--

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

On Thu, 10 Jan 2002 14:00:04 -0000, "Rick [Kitty5]" <ric### [at] kitty5com> wrote:
> 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

ABX

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. :)
> 
> [...]

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

Some points:

- there are features for using object geometry in patterns (object
pattern) and using patterns directly for objects (function image type and
isosurfaces)

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

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

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

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. :)
> 
should this become a discussion about art or technique?

Post a reply to this message

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

> Hello.
>
> Here's my two cents.
>

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

Post a reply to this message

On Thu, 10 Jan 2002 15:09:43 +0200, Eugene Arenhaus <eug### [at] avalon-netcoil> wrote:
> 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? I suggest
you first learn 'why' things work the way they do before making suggestions about how
to 'fix' them. :p

Post a reply to this message

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