Just out of curiousity....

IIRC 4.0 will be OOP - does this just refer to the source, the scripting, or
both?

If the scripting is changing, anyone fancy giving an approximation of a sphere
on check plane using 4.00 scripting?

--
#macro G(D,E,F)#local I=array[3]{D,E,F}#local B=0;triangle{#while(
B<3)#while(I[B])A[mod(I[B],10)]+#local I[B]=div(I[B],10);#end<-5,-
2,9>#local B=B+1;#end}#end #local A=array[7]{x,x*2,x*4,y,y*2,y*4,z
}light_source{-x*6-z*9,1}mesh{G(105,10,146)G(105,246,10)G(105,56,
146)G(105,1256,246)G(1256,126,220)G(22156,2216,201)pigment{rgb 1}}//TM

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
: IIRC 4.0 will be OOP - does this just refer to the source, the scripting, or
: both?

  Most probably just the source.

  It will certainly make the life of patch-makers a LOT easier.

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

>   Most probably just the source.
:,-(

Post a reply to this message

In article <3c57d5a1@news.povray.org>, "Tom Melly" <tom### [at] tomandlucouk> 
wrote:

> IIRC 4.0 will be OOP - does this just refer to the source, the scripting, or
> both?

The POV Team has said they were rewriting it in C++. Actually, the 
current source implements a kind of OOP, it is just hard to manage.
The scripting...it could be argued that it is already OOP: the various 
shapes are objects with a common interface (you apply textures, 
transformations, etc in the same way) and which can be arranged in a 
heirarchy, though they don't actually inherit from each other. The POV 
Team has mentioned they are considering reworking the language, but they 
haven't said anything more about it.


> If the scripting is changing, anyone fancy giving an approximation of a sphere
> on check plane using 4.00 scripting?

I highly doubt any of this has been decided yet...POV 4.0 doesn't even 
exist yet, and it will probably go through many changes. Even the syntax 
of POV 3.5 is still changing.
However, I'm guessing it would look something like it does now, at least 
recognizeable to someone who knows current POV script.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
: The POV Team has said they were rewriting it in C++. Actually, the 
: current source implements a kind of OOP, it is just hard to manage.
: The scripting...it could be argued that it is already OOP

  It maybe modular, but it certainly is not object-oriented.
  Two basic requirements for object-orientedness are inheritance and dynamic
binding. Without those you just have a modular language, not object-oriented.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3c57d5a1@news.povray.org>, "Tom Melly" <tom### [at] tomandlucouk>
> wrote:
>
> > IIRC 4.0 will be OOP - does this just refer to the source, the scripting, or
> > both?
>
> The POV Team has said they were rewriting it in C++. Actually, the
> current source implements a kind of OOP, it is just hard to manage.
> The scripting...it could be argued that it is already OOP: the various
> shapes are objects with a common interface (you apply textures,
> transformations, etc in the same way) and which can be arranged in a
> heirarchy, though they don't actually inherit from each other. The POV
> Team has mentioned they are considering reworking the language, but they
> haven't said anything more about it.
>
>
> > If the scripting is changing, anyone fancy giving an approximation of a sphere
> > on check plane using 4.00 scripting?
>
> I highly doubt any of this has been decided yet...POV 4.0 doesn't even
> exist yet, and it will probably go through many changes. Even the syntax
> of POV 3.5 is still changing.
> However, I'm guessing it would look something like it does now, at least
> recognizeable to someone who knows current POV script.
>
> --
> Christopher James Huff <chr### [at] maccom>


About 5 years ago, I happened across a rayshade script for
some Lego blocks.

I wasn't able to obtain a working copy of rayshade, so I decided
to write a ray-tracer that would read the rayshade file.

I dug out my college notes from my Compilers course and my
CG course, did the geometry calcs, and had a basic ray-tracer
that could do basic primitives, bicubic patches, csg,
transformations, and some limited surfacing (like pigments,
ambient, diffusion, and reflections).  I even added some hooks
for animation.

The more I used it, the more I wanted to re-do it, making the
script object-oriented.  I had two main motivations:

----------------------------------------

First, I wanted to be able to access an object's parts after the
object had been defined to be able to make one instance
different from another.  A simplified example (using POV
pseudo-syntax):

#declare Part1 = cylinder { <0,0,0>, <0,1,0>, 1 pigment{Green}}
#declare Part2 = sphere { <0,0,0>, 1 pigment{White}}
#declare Piece = union {
  object{Part1}
  object{Part2 translate <0,1,0>}
}

#declare Piece1 = instance{Piece}
#declare Piece2 = instance{Piece}

#declare Piece2.Part1.pigment = Red;

So we get two pieces, but one is green and white, and the other
is red and white.

----------------------------------------

Second, I wanted to be able to access an object coordinate
space in order to connect to them.  For example, if I wanted my
model of a person to move its arms about while holding a bar in
both of its hands, I could do something like this:

#declare end1 = John.LeftArm.ForeArm.Hand.coord(<0,1,0>);
#declare end2 = John.RightArm.ForeArm.Hand.coord(<0,1,0>);

cyclinder { end1, end2, 1 }.

----------------------------------------

I since found POVRay, and have used it instead of my own
simply because it is SO much better.

I still, however, have hoped to find a ray-tracer or graphics tool
that has the OO features that I planned for my own rewrite.  I've
even considered writing a parser that would take an OO syntax
and generate standard POV code from it (once I have time for
something like that).

I know these things can be done in other ways using current POV
syntax, and I've done them.  I just think it would be easier to do in
an OO syntax.

--
Tom Bates

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote:
> Christopher James Huff <chr### [at] maccom> wrote:
> : The POV Team has said they were rewriting it in C++. Actually, the
> : current source implements a kind of OOP, it is just hard to manage.
> : The scripting...it could be argued that it is already OOP
>
>   It maybe modular, but it certainly is not object-oriented.
>   Two basic requirements for object-orientedness are inheritance and
dynamic
> binding. Without those you just have a modular language, not
object-oriented.

you mean, if it would something like the following, it wouldn't be OO ?

----- Example, how _I_ would wish the SDL to be
... ----------------------------

#declare MySphere=sphere{<0,0,0>,5}
#declare MyMaterial=material{texture{pigment{color rgb 1}}}

MySphere.setCenter(<5,2,5>)
MySphere.setMaterial(MyMaterial)

MyMaterial.getTexture.setFinish(finish{ambient 0})

#declare MyBox=box{}
MyBox.setCorners(<-1,-2,-3>,<1,2,3>)
MyBox.setMaterial(MyMaterial.clone())
MyBox.getMaterial.getTexture.setFinish(finish{reflection 0.7 ambient 0.0
diffuse 0.2})
MyBox.translate(<-5,0,8>)

Scene.add(MyBox)
Scene.add(MySphere)
Scene.add(camera{lookAt 0, location y*5+z*-10})
Scene.add(lightSource{y*20, color rgb 1})

Scene.render()


-----------------------------------------------------------------------------
----

Maybe I've done too much Java ...

this would IMHO provide a certain degree of compatibility, and allow a
perfect
manipulation of objects, after they've been declared ...

The mainThing I prefer in this solution, is:
- you can declare Objs (maybe even only the frame of the obj)
- specify afterwards, how to manipulate it
- add it to the Scene-Object if it should be taken into account while
rendering
- you can specify the moment, when the scene should be rendered ...
- do some cleanup, or prepair the next frame to be rendered ...


--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/

Post a reply to this message

On 30 Jan 2002 15:19:27 -0500, Warp wrote:
> Christopher James Huff <chr### [at] maccom> wrote:
>: The POV Team has said they were rewriting it in C++. Actually, the 
>: current source implements a kind of OOP, it is just hard to manage.
>: The scripting...it could be argued that it is already OOP
> 
>   It maybe modular, but it certainly is not object-oriented.
>   Two basic requirements for object-orientedness are inheritance and dynamic
> binding. Without those you just have a modular language, not object-oriented.

I assume you're referring to the claim that POV SDL is OO here.  The POV
source, though written mostly in C, could be said to have both inheritance
and dynamic binding.

-- 
#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{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

hehe ... maybe YOU will understand the other post, I made ...

--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/

Post a reply to this message

In article <3c58554e@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   It maybe modular, but it certainly is not object-oriented.
>   Two basic requirements for object-orientedness are inheritance and dynamic
> binding. Without those you just have a modular language, not object-oriented.

If you're talking about the scripting language:
The shapes could be arranged in a heirarchy where they seem to "inherit" 
attributes:
The base "object" has transformations and textures, and all objects have 
double_illuminate, etc.
The solid objects have insides and can be hollow, but are objects. The 
patch objects do not have insides.
The sturm objects can use the sturm keyword for more accurate rendering, 
but are solid objects.
The blob and lathe objects are sturm objects.

The system is just so limited and static that dynamic binding is almost 
meaningless (almost...the individual shapes do "override" transformation 
as an optimization, for example, I'm pretty sure translating a sphere 
moves it's center).

What I was saying is that you could look at it like an object-oriented 
system, and the language could become a real prototype-based object 
oriented language with just a little modification.

If you're talking about the source code, it does a sort of dynamic 
binding using function pointers, and a sort of inheritance using macros 
to generate code common to all shapes.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message