Nicolas Alvarez wrote:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> I'd already raised the issue that I felt that a byte-coded (or JIT'd) back-
>> end to any SDL was necessary for speed. If this was exposed and formally
>> documented then, firstly, more or less any language could be used with it
>> (assuming someone wants to write the translator), and secondly, portability
>> is at least vaguely possible by providing a reverse-compiler that outputs
>> some form of 'standard' SDL (whatever we end up calling 'standard' is up to
>> question of course).
> 
> Maybe we need something more POV-Ray specific, but I thought I should bring
> this up anyway... Have you heard of the Parrot bytecode[1]?

Check out llvm.org

	Thorsten

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Attwood wrote:
> 1) An optional "environment {}" command section where
> the command line options for a scene can be placed within
> the scene file (like the COBOL environment section).
> One objection I've read on this is that letting the
> environment (image size, animation options, etc.) be set
> from inside the scene file breaks compatibility with the old
> system, but it would be easy to get around that by just

The real objection seems to be that this would make it harder to
separate the front end and back end of the program, and make it harder
to do things like distributed renders.

> 3) Binary reading from files.

Hmm, could be useful for parsing oddball 3D formats in POV code.

At the very least, it would be nice to have more flexibility in reading
ASCII files. I would like to be able to parse files that are not
comma-delimited. :-) Any thoughts on supporting a scanf-style syntax?

> 4) Post processing of images. This could fall under something
> like a post_process{} section.  One thing that might be nice
> here would be the ability to directly produce animation files in a
> couple of formats.

That would be cool.

> 5) Allow the linking of external libraries, so that POV can
> access custom programming routines from various languages. 

I'm of two minds on this.

This would be *very* useful. If there's something that you can't do in
SDL, you can add it. :-)

On the other hand, it becomes possible to write malicious POV files. How
would you like to download a scene file and have it erase all your files
when you try to render it? Not good.

That's a tough one, because it's not a technological problem so much as
a social one. :-(

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when someone shows you a
photograph of their new rough-slate kitchen floor and you say "nice
normals".
    -- Tom Melly
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG/a1bcCmTzQ++ZncRAlfgAJ46lgwdHuaBtvWR07zC8IaepfFvWgCgjngm
PmiieCkTgNo9vMhHPctVQOA=
=mF0i
-----END PGP SIGNATURE-----

Post a reply to this message

On Mon, 24 Sep 2007 17:47:45 +1000, Chris Cason wrote:

> andrel wrote:
>> Can someone set something up somewhere?
> 
> Can someone recommend specific Wiki software?
> 
> It'd need to support external authentication (to link in to the POV user
> registration system), and captchas or other anti-spam measures.

Hey, Chris - willing to help out here, but I do need to understand a bit 
more about the user registration system.  I'm sure there's a way to make 
it work with Mediawiki.

I can be reached at hendersj at gmail (just realised I post with a fake e-
mail address here, so you may have wanted to contact me but were unable 
to)

Jim

Post a reply to this message

Nicolas Alvarez wrote:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> 
>>C coding with a basic understanding of C++ would probably be sufficient for
>>many of the tasks in re-writing the code that has to be replaced. Recall that
>>all the POV code was originally c, and the fundamental core of the algorithms
>>and objects are still readable by a C programmer.
> 
> 
> Please don't let POV-Ray be written in "C plus classes". C++ is so much more
> than that! :)

Well, since you were the first one to say it...

Yeah, C++ has more features than the classes, but the classes provide a 
great deal of the advantage that C++ has over C, mainly because of the 
way that classes lead to better organization of code.

The polymorphism helps a lot, too, but on a project as large as POV-Ray, 
the ability to organize code in a consistent way will bring benefits 
that will make the benefit from other features easy to overlook.

Regards,
John

Post a reply to this message

> Nicolas Alvarez wrote:
>>
>>
>> Please don't let POV-Ray be written in "C plus classes". C++ is so 
>> much more
>> than that! :)
> 
> Well, since you were the first one to say it...
> 
> Yeah, C++ has more features than the classes, but the classes provide a 
> great deal of the advantage that C++ has over C, mainly because of the 
> way that classes lead to better organization of code.
> 
> The polymorphism helps a lot, too, but on a project as large as POV-Ray, 
> the ability to organize code in a consistent way will bring benefits 
> that will make the benefit from other features easy to overlook.
> 
> Regards,
> John

Of course classes are one big advantage over plain C. But (following 
your example) polymorphism helps a *big* lot to something like POV-Ray. 
You have an abstract Object class (in C++ that would mean it has pure 
virtual methods), and classes that extend it like Sphere, Cylinder, 
Isosurface, and probably CSG objects too (I don't know how CSG code is 
organized currently). You can also have a Camera class with the 
different projections inheriting from it, instead of the *big* switch 
block that is used now. Classes give "the ability to organize code in a 
consistent way". Polymorphism gives the ability to use those classes in 
a consistent (or should I say *identical*?) way.

Objects all have the same basic interface after all. Intersect ray, 
is-point-inside-object, etc. So do camera projections, they basically 
just have to convert a 2D point (pixel in final image) into a starting 
point and a direction.

I can imagine it would be a lot easier to add a new object / camera 
projection / pattern on an unofficial POV if it's all nice OOP. For 
example, the parser could be split that way too (ObjectParser where 
SphereParser etc extend from). Not much more than write two classes and 
add new keywords to the lexer and you're done...

What about exceptions? Probably not very useful for the renderer, but I 
think they could help for the parser, or the frontend-backend separation 
"thing".

Post a reply to this message

William Tracy nous apporta ses lumieres en ce 2007/09/28 21:41:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Tim Attwood wrote:
>> 1) An optional "environment {}" command section where
>> the command line options for a scene can be placed within
>> the scene file (like the COBOL environment section).
>> One objection I've read on this is that letting the
>> environment (image size, animation options, etc.) be set
>> from inside the scene file breaks compatibility with the old
>> system, but it would be easy to get around that by just
> 
> The real objection seems to be that this would make it harder to
> separate the front end and back end of the program, and make it harder
> to do things like distributed renders.
> 
>> 3) Binary reading from files.
> 
> Hmm, could be useful for parsing oddball 3D formats in POV code.
> 
> At the very least, it would be nice to have more flexibility in reading
> ASCII files. I would like to be able to parse files that are not
> comma-delimited. :-) Any thoughts on supporting a scanf-style syntax?
> 
>> 4) Post processing of images. This could fall under something
>> like a post_process{} section.  One thing that might be nice
>> here would be the ability to directly produce animation files in a
>> couple of formats.
> 
> That would be cool.
> 
>> 5) Allow the linking of external libraries, so that POV can
>> access custom programming routines from various languages. 
> 
> I'm of two minds on this.
> 
> This would be *very* useful. If there's something that you can't do in
> SDL, you can add it. :-)
> 
> On the other hand, it becomes possible to write malicious POV files. How
> would you like to download a scene file and have it erase all your files
> when you try to render it? Not good.
> 
> That's a tough one, because it's not a technological problem so much as
> a social one. :-(
> 
> - --
> William Tracy
> afi### [at] gmailcom -- wtr### [at] calpolyedu
> 
> You know you've been raytracing too long when someone shows you a
> photograph of their new rough-slate kitchen floor and you say "nice
> normals".
>     -- Tom Melly
>
That last point can be elliminated by strictly enforcing I/O restrictions for 
ANY external addon. An external module/addon/plugin could be strictly forbiden 
to erase any file, modify any file that don't share the same base name as the 
current scene, create any file outside the default write permition.
Going further, strictly forbide any I/O operation to any external library.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when your personal correspondence to 
friends starts out with #Dear Linda =
Ken Tyler

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alain wrote:
> That last point can be elliminated by strictly enforcing I/O
> restrictions for ANY external addon. An external module/addon/plugin
> could be strictly forbiden to erase any file, modify any file that don't
> share the same base name as the current scene, create any file outside
> the default write permition.
> Going further, strictly forbide any I/O operation to any external library.

That's just it: Once you launch an external process, you have no control
over it. There's no way whatsoever to enforce I/O restrictions.

I suppose that under Unix/Linux you could run it under a chroot, but I'm
not aware that Windows supports anything like that. The ideal solution
would be an OpenBSD jail, but most users don't run OpenBSD...

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you can no longer tell the
difference between the top raytracing book and the "Raytracing for
Dummies" book. To you, they're both hopelessly uninformed.
    -- Taps a.k.a. Tapio Vocadlo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG/oSTcCmTzQ++ZncRAgsOAJ9Ysqry0z2mOExNgFPd6z0rwToJuQCgn4pH
+Oo9saOfPo1DkCZfQFIJOxo=
=Bo7d
-----END PGP SIGNATURE-----

Post a reply to this message

William Tracy nous apporta ses lumieres en ce 2007/09/29 13:00:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alain wrote:
>> That last point can be elliminated by strictly enforcing I/O
>> restrictions for ANY external addon. An external module/addon/plugin
>> could be strictly forbiden to erase any file, modify any file that don't
>> share the same base name as the current scene, create any file outside
>> the default write permition.
>> Going further, strictly forbide any I/O operation to any external library.
> 
> That's just it: Once you launch an external process, you have no control
> over it. There's no way whatsoever to enforce I/O restrictions.
> 
> I suppose that under Unix/Linux you could run it under a chroot, but I'm
> not aware that Windows supports anything like that. The ideal solution
> would be an OpenBSD jail, but most users don't run OpenBSD...
> 
> - --
> William Tracy
> afi### [at] gmailcom -- wtr### [at] calpolyedu
> 
> You know you've been raytracing too long when you can no longer tell the
> difference between the top raytracing book and the "Raytracing for
> Dummies" book. To you, they're both hopelessly uninformed.
>     -- Taps a.k.a. Tapio Vocadlo
There is a way, it's called "sandboxing". The process runs in a limited, closed, 
virtual machine and only have access to what YOU want it to see. That way, the 
process may never even "know" that there is a disk or anything else. It can't 
launch another programm, because it can't locate any programm but those you 
explicitely permit it to see. And those other programms can only be launched in 
that same sandbox. Upon termination, the calling application retreive the 
result, and terminate the virtual machine and anything in it, now and 
unconditionaly.
This can be done indepently of the OS you use and the CPU used.

-- 
Alain
-------------------------------------------------
The strongest reason for the people to retain the right to keep and bear
arms is, as a last resort, to protect themselves against tyranny in
government.
Thomas Jefferson

Post a reply to this message

William Tracy wrote:

>> 5) Allow the linking of external libraries, so that POV can
>> access custom programming routines from various languages. 
> 
> I'm of two minds on this.
> 
> This would be *very* useful. If there's something that you can't do in
> SDL, you can add it. :-)
> 
> On the other hand, it becomes possible to write malicious POV files. How
> would you like to download a scene file and have it erase all your files
> when you try to render it? Not good.
> 
> That's a tough one, because it's not a technological problem so much as
> a social one. :-(

It could also make the POV community diverge in groups with different sets
of libraries. E.g. because some libraries are only available for a 
subset of OSes.

Post a reply to this message

Before adding it to my temporary (until the wiki comes on-line) 
new-POV-page (http://members.chello.nl/a.c.linnenbank/newsdlforpov.html)
I though it would be better to discuss here.

Just an observation:
The syntax for our objects is what makes POV different from most other 
languages its syntax is something like:

object{parameters modifiers)

e.g.

sphere{ <x,y,z>,r
   pigment{rgb <r,g,b>}
   rotate <rx,ry,rz>
   translate <tx,ty,tz>
}

Note that there a re three totally different arguments here.

- the assignment to pigment could be though of as accessing a class 
element, more conventionally denoted as sphere.pigment=...
That might also be the standard (preprocessor ;) ) translation if POV4 
will be based on another language.
There is also the concept that you can have a pigment statement where 
ever you need a texture.

- <x,y,z> and r are unnamed but in a definition of sphere they could be 
defined as (introducing a new object definition syntax [1])

object: sphere(vec3D: location, scalar: radius)

so if you know this definition you could access sphere.location and 
sphere.radius

- the family of modifiers that change the appearance of the object 
(rotate, translate, scale and such). The members of this family interact 
so the natural interpretation is that these are member functions.

[1] do we need a object definition syntax in POV4? I think we do, how 
else could we define new object types? This may also be the point to 
mention that the current set of primitive objects is far from 
consistent. We have sphere{<Center>, Radius} while we also have 
box{<Corner_1>,<Corner_2>}, why don't we have cube{<Center>, size} or
cube{<Center>, <size>}? And why do we have to translate the 
superellipsoid manually with a translate?

PS: what exactly was my point? I am sure I have seen it less than half 
an hour ago.

Post a reply to this message