Warp <war### [at] tagpovrayorg> wrote:
> George Pantazopoulos <go### [at] tomyaboutpage> wrote:
> > This would have benefits for parallel rendering, since a fast machine could
> > parse the scene, then distribute the pre-parsed scene info to other nodes.
>
>   Parsing the SDL is actually often not the slowest part of the whole
> parsing step. The vast majority of time usually goes into allocating
> and setting up the objects and such.
>
>   The exception is when the SDL has loops which loop a lot, in which
> case a bytecode would speed up this interpretation. (For example, I once
> compared the speed of an SDL code which just prints an ascii mandelbrot
> set to stdout with a completely equivalent Perl code, and the latter was
> approximately 13 times faster. This is because Perl compiles to bytecode
> and then interprets that.)
>
> --
>                                                           - Warp

Would it be possible to imagine such a thing: Develop Java POV-equivalent
classes and an adaptation layer though JNI that would parse Java code and
build the actual POV scene, and then render it by the actual POV engine
(adapted and activated by JNI)? Or am I off-track? It would be possible to
benefit all the power of the java syntax and modularity (and a debugger for
our macros).

Could one imagine something like this

import org.pov.*;
import org.pov.vegetation.*;
import org.pov.hormann.isowood.*;
import org.pov.tran.clouds.*;
import org.pov.someguru.WonderfulFeature4;
import org.pov.cabasson.PoorFeature1;

public class MyScene extends BasicOutDoorScene // Which extends POVScene,
and already has a light_source, a sun, and methods for the seasons and
Earth rotation ....
{
    public static main (int argc, String [] argv)
    {
        SetHandedness(LEFT_HANDEDNESS);

        GlobalSetting gs = new GlobalSettings();
        Radiosity rad = new RadiositySettings(); // Empty constructor with
defaults
        rad.setPretrace(0.04, 0.01);
        rad.setErrorbound(0.6);

        gs.setRadiosity(rad); // Or
gs.setRadiosity(Radiosity.OUT_DOOR_LOW_QUALITY)

        BuildScene();

        Render(640, 480);
    }

    private void BuildScene() // virtual method
    {
        final RADIUS = Double.parseDouble(argv[0]).doubleValue();

        Sphere s = new Sphere (0, RADIUS); // promotion is implemented by
method overloading: could be new Sphere (new Position(0,0,0), RADIUS) or so
....

        s.translate(10, 0, 0);
        s.rotate(-20, 0, 0);
        Pigment p = new Pigment(new Rgbt(1));
        Interior interior = new Interior();
        interior.setIor(Consts.GLASS_IOR);
        interior.setFadeColor(Colors.Blue);
        interior.setFadeDistance(s.getRadius()/2);
        s.setPigment(p);
        s.setInterior(interior);
        set.setPhotons(new ObjectPhotons(...));
        this.add(s);

        Plane ground = new Plane
        (
            y, 0,
            new Pigment
            (
                CHECKER,
                new ColorMap
                (
                    .../...
                ),
                new Turbulence(0.5, 2.0, 0.65, 8)
            )
        )
        ground.getPigment().setWarp(BLACK_HOLE, new Position(...));
        ground.getPigment().scale(2.0);
        this.add(ground);

        /// Etc ....

    }
}

If the java classes are well chosen, I think the java-equivalent syntax of a
scene could be as clear as sdl. Maybe more, when the scene would use lots of
complicated macros. Btw, JNI allows a DLL to call java code, then the sdl
function{} feature would execute at java speed (quite fast with HotSpot).

Then this scene would be rendered with a command line like:

java org.pov.MyScene 1.0

But I would not mind if you called me insane ... cos' I am  already  LOL

    Bruno

Post a reply to this message

>> As an aside, if the SDL ever becomes object-oriented, the whole subject 
>> will become a whole lot more confusing. ;-)
> 
>   Not really. C++ doesn't talk about "objects" anywhere in its syntax,
> and neither has the SDL to do so (when referring to class instances).
> Even the documentation could avoid the word "object" in relation to
> class instances (and talk about "instances" instead).

Yeah, that sounds like it would work. Just need to be careful to *stick* 
to that terminology and it should be fine...


BTW, I was thinking about just inventing my own new SDL language and 
writting a program that can convert it to standard POV-Ray SDL. But, 
unfortunately, this would of course involve writing a parse, so that 
project never really got anywhere...

Post a reply to this message

Orchid XP v3 wrote:
> BTW, I was thinking about just inventing my own new SDL language and 
> writting a program that can convert it to standard POV-Ray SDL.

http://sourceforge.net/projects/lome

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message

>> BTW, I was thinking about just inventing my own new SDL language and 
>> writting a program that can convert it to standard POV-Ray SDL.
> 
> http://sourceforge.net/projects/lome

Mmm, looks *highly* active...

Post a reply to this message

Orchid XP v3 wrote:
>>> BTW, I was thinking about just inventing my own new SDL language and 
>>> writting a program that can convert it to standard POV-Ray SDL.
>>
>>
>> http://sourceforge.net/projects/lome
> 
> 
> Mmm, looks *highly* active...

No. I wrote it. I put it up. Use it if you please. Don't use it if you 
don't want to. But if you're looking for a new SDL language that 
includes converters to standard POV-Ray SDL, there it is. Source and 
everything.

And no, it won't *be* highly active before someone else wants a similar 
thing. So go ahead, and give me your improvements, instead of just 
complaining. ;-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Just because you find out you are
     telepathic, don't let it go to your head.

Post a reply to this message

>>> http://sourceforge.net/projects/lome
>>
>> Mmm, looks *highly* active...
> 
> No. I wrote it. I put it up.

Really?

Interesting; I didn't know it was possible to do that...

> Use it if you please. Don't use it if you 
> don't want to. But if you're looking for a new SDL language that 
> includes converters to standard POV-Ray SDL, there it is. Source and 
> everything.
> 
> And no, it won't *be* highly active before someone else wants a similar 
> thing. So go ahead, and give me your improvements, instead of just 
> complaining. ;-)

OK, how about... some instructions? (Or am I just looking at the wrong 
page?)

Post a reply to this message

> OK, how about... some instructions? (Or am I just looking at the wrong
> page?)

Yes. You want to be looking at the page with the source code on it.

:->

-- 
"After all, one can't complain.  I have my friends. Somebody spoke to me
only  yesterday.  And was it  last week or  the week before  that Rabbit
bumped into  me and said  'Bother!'  The Social Round.  Always something
going on."  -- A. A. Milne, 'Winnie-the-Pooh'  http://surreal.istic.org/

Post a reply to this message

>> OK, how about... some instructions? (Or am I just looking at the wrong
>> page?)
> 
> Yes. You want to be looking at the page with the source code on it.
> 
> :->

o__O

Looks like I need to learn C# really fast... heh.

Post a reply to this message

Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> Could one imagine something like this

  Please don't take this in the wrong way, but your example gives me
cold shivers.
  No Java, please. Something more suitable for POV-Ray and less "javaish".

  Of course nothing stops you from creating a library for Java which can
be used to create POV-Ray scenes, but that's a different matter.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v3 <voi### [at] devnull> wrote:
> BTW, I was thinking about just inventing my own new SDL language and 
> writting a program that can convert it to standard POV-Ray SDL. But, 
> unfortunately, this would of course involve writing a parse, so that 
> project never really got anywhere...

  A project like that would be more or less a waste of time.
  A new SDL language should be such that it can be interpreted even
at render time (in order to create, among other things, shaders).

-- 
                                                          - Warp

Post a reply to this message