Tom Melly <tom### [at] tomandlucouk> wrote:
: Interesting idea - has anyone ever written an alternative scene language for
: POV (e.g. OOP) that, when run, outputs a translation to normal pov scene
: lang.?

  I think that someone has made a C++ library (using full object-orientedness)
for reading and creating povray objects and files.
  IIRC it could even read povray 3.0 files.

  Try searching the povray links section (if no-one gives an URL here before
that).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Alessandro Coppo wrote:

> No discussion about the objects and property side, but the
> build together side could be vastly improved by another language. Think of
> what could you do if instead of just #macro's you have a complete OO
> language capable of creating scenes (i.e. assembling POV primitives).

There are some pov users that are programming idiots.  I got A's in high school
BASIC and college FORTRAN classes (I'm 35) but am utterly  OO-illiterate,
despite having spent a few hundred on Java and C books.

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
> "Warp" <war### [at] tagpovrayorg> wrote in message
> news:39d47a94@news.povray.org...
>>   So what makes a language powerful is not the number of lines but how
>> easy and intuitive is to make something.
>>
>>   If I want a more "powerful" language, what stops me from using whatever
>> language I want to generate the povray output?
>>

> Interesting idea - has anyone ever written an alternative scene language for
> POV (e.g. OOP) that, when run, outputs a translation to normal pov scene
> lang.?


Somewhat.  I have a particle system in c++, that when compiled outputs the
system in POV readable format.  IT's all OO.  But I've found that that's
only useful when it's really time intensive.  If there was an existing code
base (ie, all the primitives and such already spelt out), but as it is, it's
not useful in general.

Geoff

Post a reply to this message

Warp wrote:
> 
> Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
> : Say you're doing a 400 x 300. That's 1200 pixels.
> : First you shoot pixels AS IF it were a 40 x 30, where you choose by some
> : algorithm 1 pixel out of every block of 100.
> : Report the color of these pixels to the viewer as if it were ONLY a 40 x 30.
> : Now assume it's a 160  x 120,  shoot 3 pixels out of every block of ....... and
> : so on......
> 
>   How do you calculate antialiasing here?

Since the 'preview' image is not a final product, skip anti-aliasing and
save lots of computation.

				++Eric
-- 
Eric Fielding

Eri### [at] sierrasjplnasagov  -or- Eri### [at] jplnasagov

MS 300-233                             direct phone: +1 (818) 354-9305
Jet Propulsion Lab                              fax: +1 (818) 354-9476
4800 Oak Grove Drive
Pasadena, CA   91109

Post a reply to this message

Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
: but am utterly  OO-illiterate,
: despite having spent a few hundred on Java and C books.

  Knowing an OO-language doesn't mean you know how to make OO-programs.
It's a very common mistake to think otherwise.

  An object-oriented programming language can't force you to make
object-oriented programs. The reason is that the object-oriented design of
a program starts before you write even the first line of code.

  To learn object-oriented programming you have to read books about
object-oriented programming, not books about some programming language.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:

>   To learn object-oriented programming you have to read books about
> object-oriented programming, not books about some programming language.

So if POV-Ray incorporates OO style syntax I am going to have to go
out and buy books to learn how to use it ? This does not sound very
encouraging !

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: So if POV-Ray incorporates OO style syntax I am going to have to go
: out and buy books to learn how to use it ? This does not sound very
: encouraging !

  No, it means that you'll be using the OO style syntax but you probably will
not be making very good OO-programming.
  Although the OO programming language can't force you to make good OO
programs, it doesn't mean you can't make any programs with it. If you don't
know OO design they will just be poor OO programs.

  So don't worry; if povray ever incorporates OO style syntax I don't think
you or anyone else will have too many problems using it.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:

>   An object-oriented programming language can't force you to make
> object-oriented programs. The reason is that the object-oriented design of
> a program starts before you write even the first line of code.
>

Actually, I think my blobmon character is object-oriented, in the way I've
broken down INC's to handle different tasks. One has just raw data, another
computes how raw data variables crunch each other, another poses the model.  A
POV file would then include the INC and have a walking figure...

 Am I correct in that you could "object-orient" a very complicated scene file
with today's povray?

I've sat through the first-grader's presentation on OO at the beginning of
those C and Java tutorials I've seen at work and on the web........

Post a reply to this message

On Fri, 29 Sep 2000 12:30:34 +0100, Tom Melly wrote:
>"Warp" <war### [at] tagpovrayorg> wrote in message
>news:39d47a94@news.povray.org...
>>   So what makes a language powerful is not the number of lines but
>> how easy and intuitive is to make something.
>>
>>   If I want a more "powerful" language, what stops me from using
>> whatever language I want to generate the povray output?
>
>
>Interesting idea - has anyone ever written an alternative scene
>language for POV (e.g. OOP) that, when run, outputs a translation to
>normal pov scene lang.?

Not a real scene language, but a few of my earliest scenes are actually
a combination of hand-coded povscript and perl-generated pov-script. So
you could say I used perl as a scene-description language :-)

Don't remember why I did it this way. PovRay 3.0 already had #while and
#if. Maybe it wasn't in the docs. 

	hp

-- 

|_|_) | Sysadmin WSR       | vor dem rechner.

__/   | http://www.hjp.at/ |       at.linux, 2000-09-24

Post a reply to this message

Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
: Actually, I think my blobmon character is object-oriented, in the way I've
: broken down INC's to handle different tasks. One has just raw data, another
: computes how raw data variables crunch each other, another poses the model.  A
: POV file would then include the INC and have a walking figure...

  That's modular programming. You split the bigger task into smaller more or
less independent tasks.
  Yes, modularity is an essential part of OO programming, but whether simple
modularity can be considered OO in itself or not is not clear.

  As far as I have understood it, the splitting of a bigger task into smaller
ones (by dividing it into functions, macros, include files or whatever) is
not yet object-oriented programming.

  In OO-programming objects have a declaration (usually called 'class'). This
declaration (class) describes how the object looks like and how it can be
used (ie. it declares an interface). An essential part of this interface
is the so-called information hiding, that is, the implementation of the
class (ie. its data structures and implementation code) is not seen from
the outside and can't be accessed.
  These classes are also called "abstract data types" because they usually
behave exactly like any other data type. For example it could be possible
to make an integer class which behaves exactly like any regular integer
type but may have internally more functionality.

  An instance of this class is called object. An instance is when you create
a physical object which you can handle (part of this creation is allocating
memory for it (often made automatically by the compiler), initializing it
(usually made by the class itself) and so on). There can be many instances
(ie objects) of the same class and they are (usually) independent and
unaware of each other. Each object can have a different state (ie. its internal
values can be anything independently of the other objects of the same class).

  An essential part of OO-design is that often objects have common features
and behaviours.
  For example suppose that you have a class named 'dog' and another named
'cat' and a third called 'tree'.
  The 'dog' and the 'cat' classes will probably have many common functionality
(a functionality which is common to all animals) but different from the
'tree' class. All of them may also have some features common to all living
things (like being alive or dead, etc).
  If a 'dog' can walk and eat, and a 'cat' can also walk and eat, it would
be a bit silly to code the exact same functionality to both (and doing so
would break many modularity principles).
  Sometimes you may also want to handle dogs and cats (and other
animals) in a common way. For example you may have a 'house'-container
with several instances of 'dog' and 'cat' (and perhaps many other
animals) and want to handle all of them in the same way. It would also be
a bit silly to code something like:

if(object is a dog) then make the dog walk, else
if(object is a cat) then make the cat walk, else
...

  It would just be a lot easier (and modular) to say just:

make the animal walk

  This is where inheritance kicks in. Since dogs and cats have common features
(which are common to all animals) and both of them have common features with
the 'tree' (features common to all living things), more abstract classes
could be created.
  We can create an 'animal' class which contains everything that is common
to all animals. Then the 'dog' and 'cat' classes can inherit those features
to itself and then specify some features exclusive to dogs or cats.
  Also we can create a 'plant' class and inherit 'tree' from it.
  Since animals and plants have some common behaviours we can create even a
more abstract class (like 'living_thing' or whatever) and inherit both from
it.
  The inheritance relation between two classes is usually called
"is-a relation", that is, "dog is an animal" and "animal is a living_thing".
Everything that holds for an 'animal' also holds for a 'dog', ie an object
of type 'dog' can be used everywhere an object of type 'animal' is expected.
  It is also possible that some behaviour is common to all animals (eg.
"make noise") but the implementation is specific to each type of animal
(ie. the type of the noise). It is possible to say in the 'animal' class
that all animals make noise but the implementation (which is specific to
each animal) is made in the inherited classes.

  This has several advantages:
  - It structures your data types in a logical way.
  - It's extremely modular. Behaviours that are common to a series of classes
can be written only once instead of having to write it to several places.
  - The abstraction level scheme (thanks to inheritance) gives a lot of
flexibility. It is possible to make, for example, a function that takes
an object of type 'animal' and makes something to it. It doesn't care what
type of animal it is. Then you can give cats and dogs to it and it will work
equally for both. You can also later create new classes inherited from 'animal'
and give them to the function and it will still work without the need of any
modification.
  For example this function could make two things to the 'animal' object:
"walk here" and "make noise". The "walk here" could be independent from
animal to animal and the implementation in the 'animal' class is automatically
called (unless specifically overridden in the inherited class). The "make
noise", however, depends on the type of animal. Still the function doesn't
need to know the type of animal; it just calls the "make noise" functionality
in the 'animal' class and that's it. It doesn't care which implementation is
actually called.
  This feature allows extreme modularity: You can create new types of animals
with their specific way of "making noise" and this function will still work.
You don't have to modify the function to take into account this new animal
type.

  It's important to note the type of the inheritance relation. The relation
is always an is-a relation, ie. from a more abstract concept to a more
concrete concept. It's too usual to misuse this relation.
  The most usual mistake is to use it as if it was a "has-a" relation.
For example, since a 'car' "has a" 'wheel', then we inherit a car from a
wheel.
  This is wrong, of course. A 'car' is NOT a 'wheel'. You can't use a 'car'
where a 'wheel' is expected. A 'wheel' is a part of the 'car', ie. the
car consists of 'wheel' objects (among others).
  The inheritance relation should always be from a more abstract concept
to a more concrete concet. For example it's perfectly normal to think that
a 'car' is a 'vehicle'. An object of type 'car' can be used anywhere an
object of type 'vehicle' is expected.

  This is why in povray splitting a bigger object into smaller objects (which
can possibly be copied more than once to create the bigger object) can't be
called OO-programming. It's modular, but it's not purely object-oriented.
  You can't create abstract concepts in povray and then inherit concrete
concepts from them. You can't for example, create a 'furniture' class
(which is probably so abstract that you can't create an instance, ie an
object from it) and then inherit things like 'table' and 'chair' from it.
You can't create, for example, an array containing 'furniture'-type objects
and add 'tables' and 'chairs' to it (as it is possible in OO-languages).
  Objects in povray don't have clear interfaces either.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message