![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Greg M. Johnson <gre### [at] my-dejanews com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I think I know how to make the program efficient (by using proper algorithms and data
structures), modular, reusable and so on.
I just chafe at the inelegance of some languages like Java.
Warp wrote:
> Those things cannot be learnt by knowing a programming language.
They aren't learned in computer science; it's just plain logic and common sense.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Greg M. Johnson <gre### [at] my-dejanews com> wrote:
: They aren't learned in computer science; it's just plain logic and common sense.
I wouldn't say that. Computer science gives you the basic theory. Of course
experience is needed, but experience without knowledge is of little use.
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39d47d5b$1@news.povray.org>, "Tom Melly"
<tom### [at] tomandlu co uk> 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 have been playing around with this idea..."CSDL", or C-like Scene
Description Language. It would be an object-oriented language with a
vaguely C-like syntax(variable declaration style, {} blocks, flow
control statements, etc).
I would have a translator program that reads the CSDL files and outputs
.pov files(the first version would execute the CSDL and output objects,
but later versions might be able to translate some things like loops to
POV code). Other features could be things like OpenGL previews.
Unfortunately, I haven't found any good quick-start tutorials for Bison
or Flex and nothing on using the versions of these tools available on
the Mac(which seem to be very few, undocumented, and not up-to-date.).
This shouldn't be a problem with OS X though...yet another advantage of
a UNIX-based system. :-)
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
You guys look at this the wrong way... What about the people not wanting to
spend hours learning a new language, instead of just adding to whatever they
know about POV-Ray language already?
Besides, C++ based languages have a tendency to have a _very_ steep
learning curve...
This was just a thought, felt like sharing it... :P
Zilvah
------------------------------------------------------------------------
"Chris Huff" <chr### [at] mac com> wrote in message
news:chrishuff-B19E31.11023906102000@news.povray.org...
> In article <39d47d5b$1@news.povray.org>, "Tom Melly"
> <tom### [at] tomandlu co uk> 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 have been playing around with this idea..."CSDL", or C-like Scene
> Description Language. It would be an object-oriented language with a
> vaguely C-like syntax(variable declaration style, {} blocks, flow
> control statements, etc).
> I would have a translator program that reads the CSDL files and outputs
> .pov files(the first version would execute the CSDL and output objects,
> but later versions might be able to translate some things like loops to
> POV code). Other features could be things like OpenGL previews.
>
> Unfortunately, I haven't found any good quick-start tutorials for Bison
> or Flex and nothing on using the versions of these tools available on
> the Mac(which seem to be very few, undocumented, and not up-to-date.).
> This shouldn't be a problem with OS X though...yet another advantage of
> a UNIX-based system. :-)
>
> --
> Christopher James Huff
> Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
> TAG: chr### [at] tag povray org, http://tag.povray.org/
>
> <><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |