Bruce L wrote:
> 
> > [As mentioned in email as well.]  Polyray as a separate application
> > really isn't being supported any more.  The source is available if
> > people really want to play with it, but I've pretty much rewritten the
> > entire thing as a library (which can be seen as a plugin for Moray).
> 
> Is this plugin/dll available/allowed to be called from other programs
> besides Moray? I realize you built it specifically for Moray, and had
> some input into the related SDK, but was just wondering how specific it
> was. Could you just dump a set of triangles and textures to it? Or
> perhaps even just the name of the main scene description file?

Yes - in fact I built most of it before using it as part of a Moray
plugin.  The animation plugin actually consists of two major pieces, the
Moray scene interface and animation manager, plus the rendering
library.  Essentially what happens when it it used to render from Moray
is that all the textures and objects get created by calling an API to
the renderer DLL (with callbacks as appropriate).

I have a few sample applications that use the rendering DLL: An NFF
renderer (uses Haines' nff scene files from SPD), a simple object viewer
for a couple of mesh based formats (3ds, obj, 3dm), and a simple
particle system program.  Like many programmers, I haven't done a whole
lot of documenting of how to use the interface to the library, it sorta
has to be learned from the examples.

If you want to give it a try, just email me directly.

As far as just dumping triangles into the renderer - yes.  That's really
pretty easy to do.  I have a sample program that builds a mesh to
represent a piece of cloth (and then have it drape on some objects) and
then modify the vertices as the simulation steps forward.  In that
particular program, the objects that the cloth gets draped on are
created as standard prims like boxes and the renderer is used to 
tesselate them.  Once I have all the triangles for the scene, the actual
application does the collision detection between the cloth & scene (the
particle system sample is similar).

> 
> I have been considering adding some raytracing interface options to my
> own DMesh object modeller, (ie: spawning PovRay or BMRT,) but additional
> options would be welcome if I'm not stepping on any toes. It's a simple
> organic mesh modeller, not a full scene modeller like Moray, so the only
> real 3D objects are uv-mapped triangles.

I don't really see why not.  I'm pretty sure that the OpenGL & Direct3D
support are turned off in the Moray plugin, but could be turned back on
for a little better speed.  I don't have a hardware 3D accelerator, so I
don't know just how much improvement you would see.  You could use
OpenGL or D3D directly, but you might find using the higher level API
functions of the DLL a bit easier.

> ... (Although if it could handle
> subdivision surfaces, that would be a pretty big bonus <g>) If I
> remember correctly, PolyRay also supported NURBS. Do these exist in the
> plugin/dll version?

The NURBS support in the renderer is actually much better than in
Polyray v1.8.  I have added adaptive tesselation and support for trim
curves.  I've used Rhino files to do some testing and have had pretty
good success.  The biggest problems are for patches that have
significant pinching (e.g., the poles in a sphere that is represented by
a single NURBS patch).

There is code for Loop style subdivision surfaces (that's the kind with
triangular pieces).  I haven't really done much with it, so all you can
do is hand in the starting mesh and tell it how many steps to subdivide
before rendering.  In the long run I wan't to do adaptive subdivision on
it as well (it's harder than for a u/v type surface like a patch).

Xander

Post a reply to this message