Patrick Elliott wrote:
> In *any* other language you need to do something like:

That's not true. There are a number of other possibilities, including 
languages that have been around a lot longer than Lua and specifically 
designed for this sort of work (as Lua was).

But since I got seriously harshed for even mentioning possibilities last 
time, I'm not going to continue on with this discussion.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Ger <No.### [at] thankyou> wrote:
> Does POV really need a new language

  Yes. You yourself gave the reason why:

> lets
> not forget that POV needs 3 things most. Speed, more speed and some speed.

  The new language doesn't have to look very different from the current SDL,
but some changes are necessary (for example related to macros).

-- 
                                                          - Warp

Post a reply to this message

> And its method of 
> representing arrays allow you to *literally* drop complex data 
> structures in to the array, for immediate use. For example, in the 
> client I use it in, if you want to get data on something as simple as a 
> line of text, you need to just push the data into a table in Lua, then 
> access it like an array. The method for transferring such data "into" 
> Lua is fairly trivial. Other languages *can't* handle the transfer of 
> such structured data. They are forced to rely on creating multiple 
> arrays, to hold each subtype of data. So while Lua uses a single table 
> that looks like:
> 
> mytable (position)
>   \---Letter
>   \---Font
>   \---Color
>   \---Ect.
> 
> In *any* other language you need to do something like:
> 
> dim letter()
> dim font()
> dim color()
> dim etc()
> 
> Then load **each** of those independently.

Umm... Isn't that how things work on *any* loosely-typed language?

var arr = [123, [12,34], "foo", /\s+public ?(.*)/g, new Sphere(1,2,3)];

A valid Javascript array containing a number, another array, a string, a 
regular expression, and a Sphere (provided that the Sphere object was 
defined).

Post a reply to this message

Ger wrote:
> 
> In all this talk about this or that programming language I
> feel that one question is being side stepped. Does POV really
> need a new language or can all this be accomplished with a
> good spring cleaning of the SDL.

What POV does NOW could be accomplished with a good spring cleaning, and 
I agree with you that much of what others want to do can be accomplished 
more easily with outside tools. I do not care for the idea of renderer 
+second-rate image processor +second-rate text converter +second-rate 
animation studio +second-rate... +++.

However, outside programs cannot be used to build shaders. I believe 
development should be focused in that area. I can't see how objects 
would be necessary to program shaders, but someone else might. There is 
a clear need for object-like stuff like MyObject.rad.

  -Shay

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> can be accomplished 
> more easily with outside tools.

  I disagree in two counts:

  1) "Can be accomplished" is not always true. You can't add new rendering
features to POV-Ray with outside tools. It's just impossible.

  2) Even when using a supported rendering technique, "more easily" is
often just not true. Using things like third-party converters, automatic
mesh manipulation programs and such is usually much more cumbersome than
if you could do the exact same thing in POV-Ray itself by simply writing
one #include line and one function call.
  Possible? Yes. More easily? Often not. Not even equally esily.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

> Shay <Sha### [at] cccc> wrote:
>> can be accomplished
>> more easily with outside tools.
> 
>   I disagree in two counts:
> 
>   1) "Can be accomplished" is not always true. You can't add new rendering
> features to POV-Ray with outside tools. It's just impossible.

I fully agree that rendering features should be integrated into the POV
render engine. But things like JPG conversion and creating animations have
no business there. It's simply not possible to create a program that "does
it all"

> 
>   2) Even when using a supported rendering technique, "more easily" is
> often just not true. Using things like third-party converters, automatic
> mesh manipulation programs and such is usually much more cumbersome than
> if you could do the exact same thing in POV-Ray itself by simply writing
> one #include line and one function call.
>   Possible? Yes. More easily? Often not. Not even equally esily.
> 

I think you need to make the distinction between "Stuff that acts upon the
render" and "Stuff that acts upon the finished image". The former has to be
inside POV. The latter better stay out.

-- 
Ger

Post a reply to this message

Ger <No.### [at] thankyou> wrote:
> I think you need to make the distinction between "Stuff that acts upon the
> render" and "Stuff that acts upon the finished image". The former has to be
> inside POV. The latter better stay out.

  I would prefer 1000 times more to do post-processing of the final image
with POV-Ray itself than having to code a separate program for that purpose.
It would simply be way too cumbersome, waste disk space, waste time, and
waste everything.

-- 
                                                          - Warp

Post a reply to this message

Today, nothing prevents all the stuff we produce to be orginized more or
less like a mess. I guess it actually is for some of us, and I guarantee
you it is the case for me. The #include approach is too limited and
prevents from modularity, visibility, naming range, etc ..., and the
reusability is somewhat limited and puzzling. A well known and mature
solution for these features is Object Orientedness. Let's make POV4 be
object-oriented. Not too much, but enough to benefit of what can be good
for our purpose.

If we want (still more or less):
    - OO
    - inheritance (prevents useless re-writing of common properties)
    - modularity
    - reusability
    - visibility rules
    - locatability
    - avoid code duplication

And considering that Java was mentionned in the discussion thread as
providing such features, and considering that Java is also a very popular
language, let's try to make POV4 be inspired by Java for these aspects.
Thus, we can talk about 'packages', 'classes', and 'inheritance'. The
following lines can express that we are definig a new 'module' in our
'organisation'.


// Let's make the relationship stuff-we-write/location be bijective,
// and therefore force a minimal organisation: we express how we are
// organised, and where we locate this module in the organisation.
// Like Java, we can say that this code is in the file
// <some root directory>/household/furniture/Stool.pov4
package household.furniture;

// Reuse already defined stuff (can be/is already compiled)
import hormann.IsoWood3;
import pov.math.vector.*;
import pov.Metals;
import decoration.Velvet;
import tools.NiceStuff;

// We define a type of object 'Stool' that inherits main behaviour from
// 'FourLegged' (defined in the same package).
class Stool extends FourLegged
{
    [CLASS_BODY]
}

It is quite direct from Java, but it is not much of a problem at this level:
Java's OK for that according to me. Only this can satisfy the main
structural concerns, whatever we put in the [CLASS_BODY]. And the code is
as compact as POV.

The use of a Stool in a scene could be like:

package scenes.rooms;

// Only a scene is renderable. The name 'RoomByNight' can be used as the
// default name for the output image.
scene RoomByNight
{
    global_settings {...}
    light_source {...}

    // The stool. POV-like syntax, as if it were a primitive object. Can be
    // considered as a POV-like notational shortcut for a constructor.
    Stool
    {
        [stool properties]
    }
}

Until now, POV is C-like syntax and is limited. Why not Java-like
features/syntax for some aspects? For the rest of the language and
features, we can see later what syntax is most appropriate.

My idea here is to find an agreement on this main structural aspect. These
lines are just an example, an effective start point to help thinking. There
are surely pros and contras.

Comments welcome.

Post a reply to this message

Warp wrote:

> 
>   I would prefer 1000 times more to do post-processing of the final image
> with POV-Ray itself than having to code a separate program for that
> purpose. It would simply be way too cumbersome, waste disk space, waste
> time, and waste everything.
> 
I just wonder how you would want to integrate things like
Photoshop/Gimp/Krita etc and MainActor/VisualStudio into POV. I'm not
saying it can't be done but, to me, it would be a tremendous waste of
programmer time. And if you extend this towards the SDL/parser you would
also need to add Wings/Blender/Poseray etc to the frontend.
-- 
Ger

Post a reply to this message

Ger <No.### [at] thankyou> wrote:
> >   I would prefer 1000 times more to do post-processing of the final image
> > with POV-Ray itself than having to code a separate program for that
> > purpose. It would simply be way too cumbersome, waste disk space, waste
> > time, and waste everything.
> > 
> I just wonder how you would want to integrate things like
> Photoshop/Gimp/Krita etc and MainActor/VisualStudio into POV.

  You didn't understand me.

  When POV-Ray renders the image it has tons of additional information
about it besides simply the pixels. It has depth information, normal
information, all kinds of other things. In order to post-process the
image using this information you need to either save it all in files
and then write a program which reads them and does the post-processing,
or you can write a simple script in the future SDL to do the same thing.

  Something like cell-shading or edge finding will probably take a few
lines of SDL code, while with the gimp or photoshop it's *impossible*
to do (at least with the same accuracy).

-- 
                                                          - Warp

Post a reply to this message