POV-Ray : Newsgroups : povray.pov4.discussion.general : Reviving some pov4 discussion Server Time
19 Sep 2021 19:18:33 EDT (-0400)
  Reviving some pov4 discussion (Message 26 to 35 of 35)  
<<< Previous 10 Messages Goto Initial 10 Messages
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

From: clipka
Subject: Re: Reviving some pov4 discussion
Date: 15 Dec 2015 09:30:01
Message: <web.567023a68cd067d5ad6fa18f0@news.povray.org>
scott <sco### [at] scottcom> wrote:
> >> 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.

I didn't say there's any /feasible/ way (nor did I mean to) - just that there
/is/ a way ;)


Post a reply to this message

From: clipka
Subject: Re: Reviving some pov4 discussion
Date: 23 Jan 2016 11:05:11
Message: <56a3a4b7$1@news.povray.org>
Am 12.12.2015 um 13:27 schrieb clipka:
> 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.

I /think/ I've found a language that might be suitable; at any rate, it...

(1) shares the design goal of providing both declarative and procedural
elements;

(2) has native support for /all/ of the domain-specific basic types we
would need (most notably vectors and colours);

(3) already covers a major subset of POV-Ray's language domain; and

(4) is already established, /specifically/ in the domain of 3D rendering.


Have a look at NVIDIA's Material Definition Language (MDL):

http://www.nvidia-arc.com/fileadmin/user_upload/iray_documentation/nvidia_mdl_introduction.140512.A4.pdf

http://www.nvidia-arc.com/fileadmin/user_upload/MDL_spec_1.2.2_28Apr2015.pdf

I think all we'd have to do is provide some intrinsic data types for
geometric shapes and some odds & ends (such as light sources, global
settings, etc.), and we'd have a useful Scene Description Language.

Is it pretty to use? Don't know yet.

Can we get Nvidia's implementation for free? Don't know yet, but I'd
doubt it. The language specs are open though, so we could write our own
parser.


Post a reply to this message

From: Warp
Subject: Re: Reviving some pov4 discussion
Date: 23 May 2016 12:02:27
Message: <57432993@news.povray.org>
Le_Forgeron <jgr### [at] freefr> wrote:
> If I was crazy, I would use C++ and a compiler as the parser

This is actually not such an absolutely crazy idea. Consider that
Apple's Metal shading language (which is an alternative to glsl)
uses C++11 as its syntax (and AFAIK pretty much a C++11 compiler
to generate the shader binary). These shaders are compiled at
runtime rather than compile time (they are not compiled from
*within* the shader code, but from the calling code, but
nevertheless, it's done at runtime.)

Nowadays this would be extremely feasible because LLVM has been
designed from the ground up for precisely this kind of thing.

-- 
                                                          - Warp


Post a reply to this message

From: Warp
Subject: Re: Reviving some pov4 discussion
Date: 23 May 2016 12:07:33
Message: <57432ac5@news.povray.org>
Le_Forgeron <jgr### [at] freefr> wrote:
> > 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);

Actually I don't see a reason why this line of code:

    cone( { 0, 0, 0 }, { 0, 1, 0 }, 2);

couldn't add the cone to the (default) scene.

It could even work something like this:

    Cone( { 0, 0, 0 }, { 0, 1, 0 }, 2)
    .pigment( some pigment def here )
    .finish( some finish def here )
    .rotate(10, 20, 30)
    .scale(0.5, 1.0, 2.0);

-- 
                                                          - Warp


Post a reply to this message

From: clipka
Subject: Re: Reviving some pov4 discussion
Date: 23 May 2016 23:41:41
Message: <5743cd75$1@news.povray.org>
Am 23.05.2016 um 18:02 schrieb Warp:
> Le_Forgeron <jgr### [at] freefr> wrote:
>> If I was crazy, I would use C++ and a compiler as the parser
> 
> This is actually not such an absolutely crazy idea. Consider that
> Apple's Metal shading language (which is an alternative to glsl)
> uses C++11 as its syntax (and AFAIK pretty much a C++11 compiler
> to generate the shader binary). These shaders are compiled at
> runtime rather than compile time (they are not compiled from
> *within* the shader code, but from the calling code, but
> nevertheless, it's done at runtime.)
> 
> Nowadays this would be extremely feasible because LLVM has been
> designed from the ground up for precisely this kind of thing.

Not specifically for C++, but yes.

Use of LLVM in a future POV-Ray SDL parser can be considered a given,
both for the scene in general and, even more importantly, any
user-defined "functions" (which will presumably be much more powerful
than they are now).

(Unless something even better than LLVM happens to pop up before we
actually start working on that new parser.)


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

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