The case for .NET as scene language

[atlaste]

For some time now I've been wondering why pov-ray still uses its own scene language. In most cases, I use loops, if-then-else's, etc. to make a pretty scene. Why not simply use an existing programming language? I can see a couple of advantages and disadvantages for this:

Disadvantages:

• You need more 'code' to create the same scene, because programming languages aren't meant to write 3D code.

Advantages:

• No more need to maintain the parser/lexer;
• A modern, proper JIT compiler has more performance than any interpreter;
• Proper, complex language structures. No more #while loops;
• Modern IDE's like Visual Studio are awesome; everything else is just not the same. As a bonus, you don't really have to maintain the IDE anymore;
• Things like 'clocks' become much easier to manage;
• Import/export from third-party file formats can simply be implemented as a library (if it isn't already available as open source somewhere);
• It's much easier to integrate things like post-processing in the overall process, since image libraries are already available for .NET.

For these reasons, I started creating an interface some time ago to be able to do this. Basically my idea was to create the objects in C++/CLI which then creates the scene. The C++/CLI interface would then be exposed as a DLL, which could be used by all .NET languages (such as C#).

Implementing this is hardly a problem; it just costs a lot of effort. The main 'snag' that I hit was that pov-ray doesn't currently have a proper 'interface', which you can use to create the scene. Also, considering the major changes that are still made to the source code, I'm very much wondering if it's worth the effort to implement this... I'd hate to do everything all over again in a few years.

This also brings me to the issue / question: is it possible to expose a single interface from pov-ray that we can simply use, and which will be supported for a long time to come? Also, if this is implemented, how big would you consider the chance that it will be merged in the main pov-ray repository?

[c-lipka]

Using .NET as the foundation for POV-Ray's scene description language is a no-go (at least at present), due to the lack of full portability across platforms. (Besides, there are other reasons against it.)

The current plan is as follows:

• The internal architecture is to be modularized (work on this has already started, but is still ongoing) to the point that the render engine constitutes a self-contained C++ library. The official POV-Ray application with its dedicated scene description language would potentially be just one of multiple applications making use of that library.
• The parser integrated into the official POV-Ray application is to be replaced with an entirely new implementation based on LLVM, to allow for JIT-compilation. The scene description language would presumably see a major overhaul in the process, but would probably remain custom-tailored for simplicity of scenes with few algorithmic elements.

[atlaste]

Using .NET as the foundation for POV-Ray's scene description language is a no-go (at least at present), due to the lack of full portability across platforms.

I believe you're not really up-to-date here. Actually, .NET Core is fine with portability; it even works on a RaspberryPI with raspbian. Also, mono already compiles to LLVM. I'm sure, because I'm actually running .NET on a debian machine and a rpi right here. :-)

It is true that not all libraries compile on all platforms, yes. Still, a self-contained pov-ray language that doesn't have any libraries might be portable, but not nearly as powerful. Also worth noting is that MS is putting considerable effort in making all base libraries portable (because of their mobile-first strategy).

I'd like to stress that well-established library support shouldn't be underestimated. For example, I'd really like to serialize the model and send it over to cloud instances that can be paid per hour. After all, why ray trace on a single machine if you can use a hundred? With things like WCF and native Amazon / Azure support, these kinds of things can be implemented easily in .NET, that is of course: if the C++ interface supports it.

The internal architecture is to be modularized (work on this has already started, but is still ongoing) to the point that the render engine constitutes a self-contained C++ library.

Right, that sounds like what I need.

Is there already an ETA for this? Should I think days, months or years?

[...] based on LLVM [...] would probably remain custom-tailored for simplicity of scenes with few algorithmic elements.

I would seriously reconsider this strategy for a ton of different reasons. To name a few:

• JIT compilation doesn't really have a lot of value for these simple scenes; the current parser is already fine as-is for that.
• It's the complex scenes with lots of objects that cause pain. It's also these kinds of scenes that benefit the most from using a well-established compiled language interface like C#. To make it more concrete, I'd much rather add a reference to a tree builder, lightsys or a collision detection library, than rebuild it from scratch in a custom pov-ray language. That's not even mentioning things like database support, math libraries, image libraries and so on.
• It's also noteworthy that people using pov-ray are already generating huge POV and INC files from external applications (f.ex. to convert files like 3DS to POV, to generate trees, etc, etc). Programs can easily generate megabytes of INC files, which then have to be compiled again using LLVM? As a professional, daily user of LLVM, I can tell from experience that LLVM won't solve a thing in these scenario's; if anything the current parser/interpreter will probably be much faster.

Obviously it's ultimately your choice to make; as the title of the topic suggests, I'm simply making the case. It's a feature that I've been looking for in the many happy years that I've been using pov-ray.

[c-lipka]

Is there already an ETA for this? Should I think days, months or years?

Since we're all doing this as a hobby, we can't really put an ETA to this. Certainly not days or weeks though.

[...] based on LLVM [...] would probably remain custom-tailored for simplicity of scenes with few algorithmic elements.

JIT compilation doesn't really have a lot of value for these simple scenes; the current parser is already fine as-is for that.

Maybe my wording was ambiguous.

The main reason why we want to integrate a 3rd party VM with JIT capabilities into POV-Ray is actually to significantly improve the expressiveness of render-time user-defined functions; they already do use VM, but it's home-grown, severely limited, difficult to maintain, and we certainly don't have the manpower to ever add JIT capability to it.

While we're at it, as we're growing the user-defined function syntax into something resembling a full-fledged programming language, we intend to unify it with the general scene description language, both for the sake of consistency as well as to improve performance of algorithm-heavy scenes along the way.

But at the same time, we recognize the current SDL's benefit of being concisene and easy to use when it comes to algorithm-lean scenes, or even just algorithm-lean portions of scenes, and want to retain that property. General-purpose programming languages on the other hand are by nature designed to address the algorithm-heavy case, and rarely even make a serious attempt to cater to the algorithm-lean case, let alone succeed to the level we want, so we'll probably need to roll our own if we want to achieve this goal.

Also, a language custom-tailored for simplicity in the algorithm-lean scenario will presumably allow for more compact "bulk" scene files than a traditional general-purpose programming language, improving I/O performance; this will be of importance once we go for distributed rendering, and will presumably also be of benefit for the file-based export-import scenario.

So we want a VM that is easy to integrate into POV-Ray, comes with JIT capability on our major target platforms, and allows for easy bolting-on of a custom language. Besides that, we also want it to be highly portable and legally unburdened, and generally of tried and tested quality. And at present, we believe that our best bet for this purpose is LLVM.

Obviously it's ultimately your choice to make; as the title of the topic suggests, I'm simply making the case. It's a feature that I've been looking for in the many happy years that I've been using pov-ray.

I guess that once POV-Ray's render engine is available as a library, bridges to some popular general-purpose programming languages might become available shortly thereafter.

[atlaste]

Since we're all doing this as a hobby, we can't really put an ETA to this. Certainly not days or weeks though.

Right, I was afraid of that. I understand.

Still, I noticed that most of the code is already using the object model that I presume won't change much, so I think it's workable in its current form. Once I have some time left, I'll just give it a go.

But at the same time, we recognize the current SDL's benefit of being concisene and easy to use when it comes to algorithm-lean scenes, or even just algorithm-lean portions of scenes, and want to retain that property.

Right, there's also a lot to say for backward compatibility, with all the work that people already did. We agree on this.

So we want a VM that is easy to integrate into POV-Ray, comes with JIT capability on our major target platforms, and allows for easy bolting-on of a custom language. Besides that, we also want it to be highly portable and legally unburdened, and generally of tried and tested quality. And at present, we believe that our best bet for this purpose is LLVM.

Sure, LLVM does all that; it's a great piece of work, don't get me wrong. As I said, I'm using it every day... and most days it's with a smile.

Still, it seems to me like you're discarding other possibilities too easily. .NET does all this as well, and the source is available as MIT license. See: https://github.com/dotnet/coreclr . Things like out of the box garbage collection, exception handling and interop help here as well; really, LLVM is not that mature with respect to these, and the moment you interop from LLVM to native C++, this will hit you. Also I'd like to add that the .Net API is much more stable and therefore easier to maintain than LLVM IR.

Moreover, I strongly believe its design better suits the need, for a large variety of reasons (to name one: it's optimized to have a low warmup time - something that's important for pov-ray scenes and LLVM is definitely not doing).

If on the other hand, you're aiming at removing all the (Object) virtual function calls from pov-ray and want to compile the complete scene, I'd probably go for LLVM. Still, that's not what I read here...

this will be of importance once we go for distributed rendering, and will presumably also be of benefit for the file-based export-import scenario.

Hm, so you want to distribute the 'source code' instead of the scene data? I'd say this is yet another reason to go for .NET, since you can simply pick up the IL code (including all library dependencies) and throw that over the line. It's not perfect, but close enough for practically any scenario.
If not and you only want to distribute the scene data, a binary format is very likely to generate less IO than any textual language.

[atlaste]

As mentioned in my previous post, I decided to give it a go.

After a day of figuring out how everything works, I decided to simply go for it. You'll find the feature branch here: https://github.com/atlaste/povray/tree/feature/cppcli . Currently it's very simple and it only renders an empty scene.

If you have any feedback, please let me know; it's very much appreciated... the design of POV-Ray is pretty hard to follow imho. Still, I feel the idea is quite promising, so if I have more time I'm going to follow up on it.

[c-lipka]

the design of POV-Ray is pretty hard to follow imho.

Welcome to my world - see why I'm reluctant to call an ETA for turning this thing into a neat library? ;)

[atlaste]

Welcome to my world - see why I'm reluctant to call an ETA for turning this thing into a neat library? ;)

Yeap ;) To be honest, I'm a bit surprised that it performs at all... the code is riddled with if-then-else constructions and vtable calls. Once everything works, I might feel compelled to start fixing that... I have this thing against code that hurts my eyes... :)

Also... if you looked at my code, you might have noticed I'm currently not using the pov frontend, backend, parser, messenging, etc. I was actually surprised how much 'boilerplate' code there is; to be honest I believe this is a massive waste of effort... After all, there are so many nice things that can be added to the ray tracer; I understand why it's currently there, but there's only so much you can do with a small dev team...

Anyways, I'll give you a heads up here if I have things running properly. It might prove to be a good starting point for an API.

[atlaste]

Just as a heads up: You might want to know that I have a first version up and running. You can find the branch here: https://github.com/atlaste/povray/tree/feature/cppcli .

A lot of stuff of pov-ray already works in this feature branch, including (both sync and async) rendering, finishes, a bunch of basic shapes, transformations, etc. Obviously, there's also still work to do. As I mentioned earlier, the code directly works on the core/base libraries. One thing I'm still planning to do is to replace the dependency on the PovVM as well.

While working on this, I think this work can be of great benefit for a more generic API. Most of the work I currently do is figuring out how the parser, frontend and backend interact, and then gluing the code together in the right place. Currently this place is in the CPP/CLI code, but it should be pretty trivial to one day move it to a CPP library or any proper place (while keeping compatibility with this library in tact).

I'd very much like to hear your thoughts at this point. Also, if you're planning any major changes in the base/core libraries on a short term, please let me know so I can take this into account.