|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|