Manta Interactive Ray Tracer Development Mailing List

Text archives Help


Re: [MANTA] Re: Manta Problem


Chronological Thread 
  • From: Abe Stephens <abe@sci.utah.edu>
  • To: Dmitri Rubinstein <rubinste@graphics.cs.uni-sb.de>
  • Cc: manta@sci.utah.edu
  • Subject: Re: [MANTA] Re: Manta Problem
  • Date: Fri, 11 May 2007 00:04:22 -0600
Dmitri Rubinstein wrote:
Abe Stephens schrieb: This would be great. In order to adapt current rendering backend I need only to know how to do a couple of things. I assume that ray tracing backend has following properties:
There are geometry objects which may require time consuming building of an acceleration structure like kd-tree. These objects can be instantiated in the scene multiple times with different transformation matrices. Instances are used for rigid body animation, objects are used to represent static geometry. Also in the case of geometry coordinate interpolation, objects will be rebuilt too. Internal optimizer decide how to split VRML scene into objects and instances optimally.
Manta supports all of those things (geometric primitives, instances, acceleration structures; BVH's are used more than kdtrees), except that the renderer itself doesn't contain any logic of how to split a scene into different acceleration structures.

I've viewed structure optimization as more the responsibility of the scene graph since it contains information about all of the geometry and can make a global decision. I don't think it's necessary for the renderer itself to be aware of the scene graph library at all.

Do you agree? If every rendering backend has some notion of a bvh, kdtree, and a grid, could the scene graph intelligently decide by itself how to chop up the scene?

In order to provide material animation, I also need to know how to assign materials to objects and change material parameters, like diffuse color.
All state changes can be performed using transactions-assuming the underlying classes have enough get/set methods to update all of their properties.

The only limitation that I see currently is an absence of some parametrization interface like in OpenRT. Here is a simple example of a shader specification in the X3D scene (I get portions of it from here: http://www.bitmanagement.com/developer/contact/examples/shader/spec/X3DProgrammableShadersProposal.htm#X3DShaderNode):
The only interface right now is the combination of get/set methods and introspection within python scripts. Similar to the setParameter(...) interface you describe:

getattr(material,"setColor")(Color(RGB(0.1,0.4,0.7)))

This would eliminate the need for any parameter management (other than get/set methods) in the renderer code, instead it would require some fancy python code to parse the X3D or xml specification. It would also require some convention to determine what type of object to pass to setColor since the python methods arguments are typeless (perhaps checking the type returned by getColor).

Abe





Archive powered by MHonArc 2.6.16.

Top of page