 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbell net> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You sure are talkative today :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Also I am going to talkative....
First of all, the renderer-not-modeller question.
Well, if you stick to a pure renderer vision, as long as you can handle a
tridimensional triangulated surface, with uv mapping info for each vertex,
external texture/bump/relief etc. maps, plus lights and a camera, you can do
anything. By the way, this is 80% of what almost every 3D tool in world does
(yes, they give you EXTREMELY powerful ways of manipulating the mesh and
NURBS etc., but still the basis is this).
Don't you believe this? Well, a box is made up by six faces, each
triangulated by 2 triangles, all together connecting 8 vertices (is the
right plural of vertex? I hope so). Open an OBJ mesh and you will see...
Why don't we develop with POVray in the same way? Because we have more
abstract (yes, Warp, also more compact....) ways of doing the same. An
isosurface is simpler than a 100K vertex mesh, isn't it?
The conclusion of this part is that, as long as the POV team gives us new
(more abstract, more compact to use, higher level) primitives, we are all
happy.
Then, there is another subject, TOTALLY ORTHOGONAL to the above one.
It is the subject of how we compose these primites. By hand, before 3.1,
with macros now. What I am saying is that if the POV team gives us a more
powerful language to build complex scenes, the better. What I am saying is
that ANY feature increasing the power of the macro language makes complex
scenes easier to write. What I propose, provided 4.0 license becomes
compatible with GPL or something of this kind is NOT to reinvent the wheel
(square...) but to adopt an open source language whose objective is to
control the creation of objects (sorry for the tongue twister). You are an
OOP purist (right, I HATE procedural languages) so I make this proposal:
pair old macro language with, e.g. Python. One can say that there are lots
of predefined classes with correspond to POVRay objects, elements
(color_map, finish, etc.) and that "creating" these objects adds them to the
scene. At last, you assign lights and a camera to the scene and tell it to
render itself (with appropriate options). See that there is an object model?
I cannot write UML in ASCII, so understand autonomously if it is containment
or inheritance...
Scene
Camera
Lights
Light
Point
Area
...
Objects
texture
color
normal
finish
Primitives
Box
Plane
...
Complex
isosurface
...
BaseMesh
mesh
mesh2
nurbs
etc.
E.g. I would like to write a subclass of BaseMesh which could directly parse
an .OBJ file without conversion!
By the way, I am sure that the OO reengineering of POV will create these
classes. You have then this situation: "native" classes, implemented in C++
and "user extension" classes, derived from the framework, written in Python
or whatever it is selected. A compatiblity layer allows the usage of 3.5
language.
See? I don't think it is a bad structure.
Bye bye!!!!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alessandro Coppo wrote:
> What I am saying is that if the POV team gives us a more
> powerful language to build complex scenes, the better.
> ... You are an
> OOP purist (right, I HATE procedural languages) so I make this proposal:
> pair old macro language with, e.g. Python.
Here is the caveman's answer to your proposal: keep the language simple. There
are non-programmer enthusiasts out here in the pov community. I'm a
metallurgical engineer who has a lot of programming sense (aced BASIC in high
school and FORTRAN in college) but every time I pick up a Java book, and some C
books, I drop it, gagging. BASIC has a nice intuitive sense for us
non-programmers, and the current povray language is equally cool.
Here I a joke I told a year ago. If the father of Java had invented povray, we
would have to code our scenes like this:
//---------------------------------------------------------------------------------------------------------------------------
import java.colors.*
import java.geometry.shapes.*
import java.light_sources.*
import java.rays.traceable.*
public void status main init destroy sPhere {
java.Geometry.Objects.shapes.roundyOnes.convexOnes.sPhere()
new radius= Radius;
new finish= Finish;
Radius= 1;
public void status main init destroy fInish{
java.texture.finish.prettyOnes.Reflective()
this.Finish=that.fInish;
die;
}
public void status main init destroy lOcation{
java.space.Cartesian.coordinates.linear.Nearby()
this.Location.x=0;
this.Location.y=0;
this.Location.z=0;
die;
}
}
public void status main init destroy pLane{
java.Geometry.Objects.shapes.infiniteOnes.flatOnes.Plane()
this.Direction=up;
public void status main init destroy pIgment{
java.texture.pigment.complexOnes.cHecker()
this.Pigment=try {
this.color=pigment.Green;
catch e exception error void yourself on main street();
that.color=pigment Red;
die;
}
}
public void status main init destroy you all {
java.Devices.nonObjects.pIcturetaking.cAmera()
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The povray language could be kept simple because no-one is going to make
very big programming projects with it. The povray scripting language is
mainly for making scenes, not for making programs.
If the goal is to make a big programming project, then a simple BASIC-style
programming language will not be enough.
No, you can't make BIG programs with procedural BASIC-style programming
languages.
"Making a program" doesn't only mean that you write 100000 lines of code
that seem to work. It also means that you can modify the code easily, add
easily new features to it, make overall bugfixes (like y2k fixes) fastly and
easily, reuse many parts of the code in several places of the program and
also in other programs and so on.
Knowing how to write something with a programming language doesn't
mean that you know how to program. It's very similar to the fact that
knowing how to write english doesn't mean that you know how to write a good
book.
Fortunately povray doesn't need this kind of programming (yet).
--
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:
> Knowing how to write something with a programming language doesn't
> mean that you know how to program.
I think I know how to program, in that I can solve complex issues (a rising heel
in a walk cycle of a blob character, and do so in a way that easily translates
itself to walking up stairs with only changing two variables) but have
difficulty learning the newer programming languages.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
: I think I know how to program, in that I can solve complex issues (a rising heel
: in a walk cycle of a blob character, and do so in a way that easily translates
: itself to walking up stairs with only changing two variables) but have
: difficulty learning the newer programming languages.
Programming is not only knowing how to solve a problem.
Programming is also knowing how to make the program efficient (by using
proper algorithms and data structures), modular, reusable and so on.
Those things cannot be learnt by knowing a 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
|
|
| |
| |
|
|
|
|
| |
|
|
