SDL is a tool used by POVers to describe their scenes.  As such, it is 
extremely useful and efficient for anything procedural, but not much use 
for anything else.

However, the main core of POV-Ray itself is the renderer, NOT the SDL 
parser.  That being said, the ability to import binary file formats into 
your scene would ease scene creation greatly.

Something like this:

---
camera {...}

import3d {
  3ds "object.3ds"
  translate <x,y,z>
}

import3d {
  obj "other.obj"
  rotate <x,y,z>
}

Obviously, not everything would be possible.  However, for those file 
formats requiring parameters to set up the objects, those parameters 
should be assignable from the SDL.

Also obviously, not all file formats are used equally, so effort should 
be used first to add support for the most commonly used by POVers (I 
would imagine that Poser files would have a high priority for this).

Perhaps an extensible plugin system could be implemented, like other 
projects use.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> SDL is a tool used by POVers to describe their scenes.  As such, it is
> extremely useful and efficient for anything procedural, but not much use
> for anything else.
>
> However, the main core of POV-Ray itself is the renderer, NOT the SDL
> parser.  That being said, the ability to import binary file formats into
> your scene would ease scene creation greatly.
>
> Something like this:
>
> ---
> camera {...}
>
> import3d {
>   3ds "object.3ds"
>   translate <x,y,z>
> }
>
> import3d {
>   obj "other.obj"
>   rotate <x,y,z>
> }
>
> Obviously, not everything would be possible.  However, for those file
> formats requiring parameters to set up the objects, those parameters
> should be assignable from the SDL.
>
> Also obviously, not all file formats are used equally, so effort should
> be used first to add support for the most commonly used by POVers (I
> would imagine that Poser files would have a high priority for this).
>
> Perhaps an extensible plugin system could be implemented, like other
> projects use.
>
> --
> ...Ben Chambers
> www.pacificwebguy.com

That would be nice. Especially for binary versions of native POV primitives. See
http://news.povray.org/web.477fdfecd9aea8ace91832b60%40news.povray.org

Post a reply to this message

For this it would also be nice to read the existing material names and their
definitions, and support overriding the materials somehow.

import
{
  obj "plane.obj"
  usemtl "plane.mtl"
  material "surface"
  {
    texture
    {
      pigment { ... }
      finish { .. }
    }
  }
  material "glass"
  {
    ...
  }
  material "tires"
  {
  }
}

Not a very good syntax, but something like that would be nice if loading
external model data.

Post a reply to this message

I also think it would be nice to have some basic mesh operations while loading.

1. Automatic merging of duplicate vertices as defined by a threshold

3. Automatic subdivision, with support to specify a crease angle

import3d
{
    obj "object.obj"

    // merging of duplicate vertices (before subdivision)
    merge_vertices on
    merge_threshold 0.01

    // subdivision
    crease_angle 30
    subdivide 1
}

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> SDL is a tool used by POVers to describe their scenes.  As such, it is
> extremely useful and efficient for anything procedural, but not much use
> for anything else.
>
> However, the main core of POV-Ray itself is the renderer, NOT the SDL
> parser.  That being said, the ability to import binary file formats into
> your scene would ease scene creation greatly.
>

Agreed that it would ease scene creation greatly, but I think the parser, the
render, and any other features should be separated further than they are now.


> Something like this:
>
> ---
> camera {...}
>
> import3d {
>   3ds "object.3ds"
>   translate <x,y,z>
> }
>
> import3d {
>   obj "other.obj"
>   rotate <x,y,z>
> }
>
> Obviously, not everything would be possible.  However, for those file
> formats requiring parameters to set up the objects, those parameters
> should be assignable from the SDL.
>
> Also obviously, not all file formats are used equally, so effort should
> be used first to add support for the most commonly used by POVers (I
> would imagine that Poser files would have a high priority for this).
>
> Perhaps an extensible plugin system could be implemented, like other
> projects use.

Yes, I agree very much so on the plugin system.  That is, instead of having the
import3d block in SDL, I recommend introducing an extern{ } block that can use
a dynamic library within the search path(s).

Rather than adding things like 'import3d{}' or '3ds' to the list of reserved
words, one could utilize a macro and actually have it call a separate extern{}
block.

The extern{} block would do the real dirty work and heavy lifting, but the type
it would do needn't be limited to importing other objects.  extern{} could do
whatever the plugin directed, including post-processing commands.

For example:
code inside of the scene: (adapted from Allen)
import
(
  obj, "plane.obj",
  usemtl, "plane.mtl",
  material( "surface",
    texture
    {
      pigment { ... }
      finish { .. }
    }
  ),

  material("glass",
    ...
  )
)

The way the parser could view the above code, after the aliases are applied:

extern
{
#require    "objlib.dll"
    usrObj = loadFile("plane.obj");
    usrMatList = loadFile("plane.mtl");
    ...
    [ more plugin-specific commands issued by the parser in ]
    [ a standardized way based on the users code and parser ]
#else
 [stuff that happens if dynamic library cannot be found]
}

The commands that the plugin can issue the parser must be limited, probably to
things like what scene objects there are, environment variables, and commands
to introduce additional objects into the scene.
The amount of memory that the parser allows the plugin to have as well as how
long the parser should wait for a plugin to finish should be user specified.
Things like file I/O should be handled by calls to methods within the parser and
be limited to the search paths.

Bottom line, though, is that I really think the rendering engine, parser, and
any plugins should be kept as separate as possible and loaded as needed.

-Reactor

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
> The way the parser could view the above code, after the aliases are applied:
>
> extern
> {
> #require    "objlib.dll"
>     usrObj = loadFile("plane.obj");
>     usrMatList = loadFile("plane.mtl");
>     ...
>     [ more plugin-specific commands issued by the parser in ]
>     [ a standardized way based on the users code and parser ]
> #else
>  [stuff that happens if dynamic library cannot be found]
> }
>
> The commands that the plugin can issue the parser must be limited, probably to
> things like what scene objects there are, environment variables, and commands
> to introduce additional objects into the scene.
> The amount of memory that the parser allows the plugin to have as well as how
> long the parser should wait for a plugin to finish should be user specified.
> Things like file I/O should be handled by calls to methods within the parser and
> be limited to the search paths.
>
> Bottom line, though, is that I really think the rendering engine, parser, and
> any plugins should be kept as separate as possible and loaded as needed.
>
> -Reactor

That would be really nice.  I think the #require should omit the extension
though to be more cross platform.

Post a reply to this message