POV-Ray : Newsgroups : povray.pov4.discussion.general : Reviving some pov4 discussion Server Time
4 Oct 2024 14:46:39 EDT (-0400)
  Reviving some pov4 discussion (Message 21 to 30 of 35)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 5 Messages >>>
From: clipka
Subject: Re: Reviving some pov4 discussion
Date: 11 Dec 2015 18:32:53
Message: <566b5d25@news.povray.org>
Am 11.12.2015 um 22:37 schrieb Le_Forgeron:

> If I was crazy, I would use C++ and a compiler as the parser, filling
> a scene object with other objects...

> Povray::Torus obj1(1,0.1);
> // texturing can be a post constructor operation
> Povray::Cone obj2( Povray::3DVector(0,0,0), 1, Povray::3DVector(), 2);

Still unnecessarily complex, as compared to (e.g.)

cone { <0,0,0>, <0,1,0>, 2 }


One of the key properties of a POV-Ray scene, which make the
requirements for the future SDL so unique, is that it may contain (A)
descriptions of complex algorithms as well as (B) descriptions of
hierarchical data, mixed arbitrarily.

XML, JSON & co. are useful for (B) but cumbersome for (A), while classic
programming languages excel at (A) but suck at (B).

(Add to this the fact that POV-Ray makes heavy use of vectors and
colours, which in most programming languages would have to be "bolted
on" artificially, which usually makes for less than ideal syntax.)


I re-iterate: The ideal SDL for POV-Ray has yet to be designed.

(POV-Ray 3.x SDL manages to cater to both requirements comparatively
well, but - as Dick correctly points out - sucks big time in terms of
consistency; also, it's somewhat outdated when it comes to describing
algorithms efficiently.)

I'm not writing this to crush people's hope for a new SDL; rather to the
contrary, I'd say. But I'd love to crush the hope of any language's
fanboys that their favorite language may become that new SDL, or even
form the basis of it, and -- maybe more importantly -- direct people
away from the (almost inevitably) fruitless search for an ideal existing
language, towards actually contributing to the task of defining a new
language from scratch (drawing some inspiration from other languages
where it seems fitting, but leaving well-trodden paths where they would
be inefficient).


One possible way of contributing to this process would be to simply
write down some hypothetical scene in whatever format you think a
next-generation POV-Ray SDL could look like. Some added text explaining
how that file format is structured would be nice to have, but could also
be deferred as a next step.


Remember, the format _must_:

- be efficient at describing static portions of a scene;

- be efficient at describing algorithms to construct portions of a scene
dynamically.

- be describing a scene in terms of essentially the same elements and
hierarchical structures as the current POV-Ray SDL (some individual
cleanup allowed, my favorite candidates there being the finish and
camera blocks);


As additional requirements, the format _must_:

- allow for two-step parsing, with the first step transforming the
verbose human-readable format into some kind of bytecode "program" that
is to be "executed" later by a virtual machine embedded into POV-Ray;
most notably this will prohibit "macros" from constructing only partial
statements, and dynamical generation of additional algorithmic portions
at execution time will probably be unavailable as well. (The idea behind
this requirement is to maximize parsing performance for scenes with
complex algorithms; the current plan calls for LLVM as the bytecode
format, allowing to even use just-in-time compilation of the scene file.)

- in its essential syntax be agnostic of the details of a scene's
elements and their hierarchy; e.g. the basic syntax must be unaware of
the fact that the element "texture" has a child element named "finish",
and instead only deal with the general fact that some elements have
child elements with specific names. (The idea behind this requirement is
manifold, from simplifying the parser to automatically enforcing more
consistency in the syntax, and even extending the exact same syntax to
user-defined elements.)


Also, the format _should_:

- support vectors and colours as native data types.

- provide some syntax to define custom geometric primitives, shading
models, and similar stuff.


Post a reply to this message

From: Mike Horvath
Subject: Re: Reviving some pov4 discussion
Date: 11 Dec 2015 23:54:29
Message: <566ba885@news.povray.org>
On 12/11/2015 6:32 PM, clipka wrote:
> One of the key properties of a POV-Ray scene, which make the
> requirements for the future SDL so unique, is that it may contain (A)
> descriptions of complex algorithms as well as (B) descriptions of
> hierarchical data, mixed arbitrarily.

One of the key properties that makes POV SDL great, but also one of the 
key properties that makes it unsupported by anyone else in the universe.

I don't like typing XML either but it might mean more third party tools 
in the future.


Mike


Post a reply to this message

From: Le Forgeron
Subject: Re: Reviving some pov4 discussion
Date: 12 Dec 2015 03:32:02
Message: <566bdb82$1@news.povray.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 12/12/2015 00:32, clipka a écrit :
> Am 11.12.2015 um 22:37 schrieb Le_Forgeron:
> 
>> If I was crazy, I would use C++ and a compiler as the parser,
>> filling a scene object with other objects...
> 
>> Povray::Torus obj1(1,0.1); // texturing can be a post constructor
>> operation Povray::Cone obj2( Povray::3DVector(0,0,0), 1,
>> Povray::3DVector(), 2);
> 
> Still unnecessarily complex, as compared to (e.g.)
> 
> cone { <0,0,0>, <0,1,0>, 2 }
> 

Please notice, I wrote "If I was crazy".

of course C++11/14/17 could be abused with initialiser list in
constructor for:

scene += Cone( {0,0,0},{0,1,0}, 2);

that is just a matter of supported syntax for any language, I took
C++, but it would be the same with any other.
> 
> One of the key properties of a POV-Ray scene, which make the 
> requirements for the future SDL so unique, is that it may contain
> (A) descriptions of complex algorithms as well as (B) descriptions
> of hierarchical data, mixed arbitrarily.

[cutting the very good list of expectations]

Just beware of the NIH syndrome.
As well as over-generalisation (e.g. let make a super-generic system
to handle unthinkable evolutions), that's how you finish with heavy
XML inside SQL database, with mandatory manual joint using regular
expression applied on the single table of 2 or 3 columns, instead of
unfolding the whole data scheme across multiple dedicated tables (but
yes, a data scheme does not evolves to handle any extension, and due
to lack of initial strict requirements, you have a meta-engine instead
of a dedicated engine... so customers can customize it as they want...
well, there is no customer which are ready to pay for a meta-engine
and then pay again the customisation... excepted in the ERP/SAP
business model (or is it a mafia ?)).

Despite the C-like origin of SDL (or pascal... or whatever was fancy
in the 80's ), Povray is very object oriented.

Do we want to look at it like an interpreted or a compiled language,
it might be irrelevant for the speed, but in the approach provided to
the new users.
Do we want to write our own parser, or can it be left to an existing one
 ?

If it was one of boost library, would it still be povray ?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlZr24EACgkQhKAm8mTpkW3eHgQAntLCC+Elu2b0LKan1I1Azonk
pPBuGjJLnWqJYwWBdtuPRzid7jA/sATpfVWrQ5MOZCFszDWU3t4Ao1HjhT73i2kP
bKFPs/P+bYWOd3mhnpgYDScOSs0aTL9UFZjY1jsr0La8aQf54ltl5iuyPbpbMm57
b+z5S/wR6ogjdEgu7mM=
=0HOR
-----END PGP SIGNATURE-----


Post a reply to this message

From: clipka
Subject: Re: Reviving some pov4 discussion
Date: 12 Dec 2015 06:22:40
Message: <566c0380$1@news.povray.org>
Am 12.12.2015 um 05:54 schrieb Mike Horvath:
> On 12/11/2015 6:32 PM, clipka wrote:
>> One of the key properties of a POV-Ray scene, which make the
>> requirements for the future SDL so unique, is that it may contain (A)
>> descriptions of complex algorithms as well as (B) descriptions of
>> hierarchical data, mixed arbitrarily.
> 
> One of the key properties that makes POV SDL great, but also one of the
> key properties that makes it unsupported by anyone else in the universe.

Actually that is only true when it comes to /import/ of POV-Ray scenes
into other software. As far as /export/ is concerned, I think the key
properties that make it unsupported by popular 3D software are that (a)
they're all entirely mesh-based, while POV-Ray isn't, and (b) work on
POV-Ray appeared to have stalled for a decade or so after the last 3.6
release.

As a matter of fact, outside the mesh-based world, POV-Ray is still
comparatively popular as an export format.

> I don't like typing XML either but it might mean more third party tools
> in the future.

Choosing XML as the basis for an SDL would (or should) not change the
aforementioned key property of a POV-Ray scene, the mixing of static
data and algorithms, which you claim to be in the way of broader support.

One road I would be willing to go along would be to define a static XML-
(or better yet JSON-) based format, devoid of any scripting elements,
intended solely for efficient data exchange with other programs, to be
supported for input as an /alternative/ to the official SDL intended for
manual editing; also, one mode of operation for POV-Ray could be to not
actually render a scene, but rather to just convert it to that data
exchange format, effectively constituting data export.

Also, for improved integration into the mesh-based world, I think
winning features would be (A) inbuilt support for .obj as a mesh input
format, and (B) inbuilt support for tesselation and .obj export.

Another way to improve support from 3rd party tools could be to provide
the parser and tesselation code as library modules, to serve as a basis
for 3rd party tool import modules.


Post a reply to this message

From: clipka
Subject: Re: Reviving some pov4 discussion
Date: 12 Dec 2015 07:27:29
Message: <566c12b1$1@news.povray.org>
Am 12.12.2015 um 09:32 schrieb Le_Forgeron:

> [cutting the very good list of expectations]
> 
> Just beware of the NIH syndrome.

There's really nothing to beware there; if I could find a language out
there that does suit POV-Ray's needs, I'd probably be the first to go
for it; if nothing else, it would save us all the work of defining the
new SDL in the first place; a pre-existing parser to just plug into
POV-Ray would save a lot of work, too.

Also, if a few modifications to an existing language would get us there
(e.g. bolting some additional syntax for vector and colour data types to
the language), that's what I'd do.

But I won't sacrifice what I consider essential requirements, just to be
able to re-use existing components.


> Do we want to look at it like an interpreted or a compiled language,
> it might be irrelevant for the speed, but in the approach provided to
> the new users.

"We" as the developers definitely want to look /at it/ like a compiled
language, because that's what will give us the best performance in the
parsing of complex scenes.

As for whether the language is to /look like/ an interpreted or compiled
language to the user, you tell me what the difference is and I tell you
what we want. Except for dynamic creation of executable code at
execution time, I can think of nothing that would clearly delineate
interpreted languages from compiled ones.

If you ask whether we want a strongly or weakly typed language, then I'd
say that we want the language to generally be weakly typed, because
that's easier to use; but we probably also want strongly typed elements,
so that we get an early failure if someone mistypes a property name of
e.g. a geometric primitive, or tries to use e.g. a geometric primitive
where a texture is expected.

> Do we want to write our own parser, or can it be left to an existing one
>  ?

We certainly don't /want/ to write our own parser, because we have
enough other work to do, but if we have to (because the language does
not exist yet, or there's no open source parser for it yet, or no
embedded parser targeting an existing portable VM, or none that is
modular enough to be used as such), that's what we /will/ do out of
necessity.


> If it was one of boost library, would it still be povray ?

If boost contained a library providing a suitable embedded language, I'm
sure we'd already be halfway through integrating it into POV-Ray.


Post a reply to this message

From: tth
Subject: Re: Reviving some pov4 discussion
Date: 13 Dec 2015 09:30:22
Message: <566d80fe$1@news.povray.org>
On 12/11/2015 01:20 AM, Mike Horvath a dit:

> I think basing things of SVG would be a good idea. I.e. XML + SMIL +
> JavaScript.

    XML is just a giant garbage.

-- 
http://foo.bar.quux.over-blog.com/article-thsf-2013-114632120.html


Post a reply to this message

From: Alain
Subject: Re: Reviving some pov4 discussion
Date: 13 Dec 2015 16:46:18
Message: <566de72a@news.povray.org>

> On 12/11/2015 01:20 AM, Mike Horvath a dit:
>
>> I think basing things of SVG would be a good idea. I.e. XML + SMIL +
>> JavaScript.
>
>     XML is just a giant garbage.
>

I think that you may over-react to some degree here.
XML does have some very legitimate uses, the real problem, is that's it 
have been abused in ways that where unintended to do things that are not 
supposed to be supported.
The base is mostly OK.
The abuse IS garbage.


Post a reply to this message

From: scott
Subject: Re: Reviving some pov4 discussion
Date: 14 Dec 2015 03:41:07
Message: <566e80a3@news.povray.org>
> Please notice, I wrote "If I was crazy".
>
> of course C++11/14/17 could be abused with initialiser list in
> constructor for:
>
> scene += Cone( {0,0,0},{0,1,0}, 2);
>
> that is just a matter of supported syntax for any language, I took
> C++, but it would be the same with any other.

I've got a good scene:

scene += Cone( {0,0,0},{0,1,0}, 2);
std::remove("some important file");

Is there any way to limit what damage a compiled C++ program can do?


Post a reply to this message

From: clipka
Subject: Re: Reviving some pov4 discussion
Date: 14 Dec 2015 13:59:27
Message: <566f118f$1@news.povray.org>
Am 14.12.2015 um 09:41 schrieb scott:
>> Please notice, I wrote "If I was crazy".
>>
>> of course C++11/14/17 could be abused with initialiser list in
>> constructor for:
>>
>> scene += Cone( {0,0,0},{0,1,0}, 2);
>>
>> that is just a matter of supported syntax for any language, I took
>> C++, but it would be the same with any other.
> 
> I've got a good scene:
> 
> scene += Cone( {0,0,0},{0,1,0}, 2);
> std::remove("some important file");
> 
> Is there any way to limit what damage a compiled C++ program can do?

Absolutely.

If by "compiled" you really do mean "compiled", it's as easy as
permitting only linkage to a tightly controlled set of libraries, of
which you know that they can't possibly do any harm (which may require
providing a custom runtime library).

If by "compiled" you actually mean "built", i.e. compiled /and/ linked,
it's as "easy" as running the program in a virtual machine.


Post a reply to this message

From: scott
Subject: Re: Reviving some pov4 discussion
Date: 15 Dec 2015 04:02:36
Message: <566fd72c$1@news.povray.org>
>> I've got a good scene:
>>
>> scene += Cone( {0,0,0},{0,1,0}, 2);
>> std::remove("some important file");
>>
>> Is there any way to limit what damage a compiled C++ program can do?
>
> Absolutely.
>
> If by "compiled" you really do mean "compiled", it's as easy as
> permitting only linkage to a tightly controlled set of libraries, of
> which you know that they can't possibly do any harm (which may require
> providing a custom runtime library).

That sounds a lot of work, with still a small risk of someone finding a 
loophole to do something bad in their scene.

> If by "compiled" you actually mean "built", i.e. compiled /and/ linked,
> it's as "easy" as running the program in a virtual machine.

Sounds a lot of work too, so that it's transparent to the casual user 
that the scene is being rendered in a virtual machine.


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 5 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.