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