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