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