Rainer Mager wrote:
> 
>     One other thought I've had was going back to the interpreted idea
> mentioned above. I was wondering if a very small, tightly coded, minimum
> feature-set of ray tracing could be written and compiled and from that set
> additions are added. I do not know enough about the details of a ray tracer
> to say too much more but it seems there are things in POV that need not be
> in the core of the program. For example, shouldn't there be a more flexible
> way to define objects such that there need not be so many different types?

Hmmm... no.  More flexible means more features means more types of objects.
What do you want?  To always start with a sphere and have to deform it into
the object you want?  Always define your objects as an isosurface?  Use only
triangle mesh objects?  I don't think many people would be happy.

If you think POV has too many options/objects/textures, take a look at 3DS
MAX... the features there (especially when you add plugins) are practically
endless (MAX gave me a headache the first time I used it, but I think the
multitude of features are quite useful).

My opinion:  more object types = more flexibility and speed = better system.

> Yes, yes, I know, this would cause a speed hit on the rendering but I'm
> wondering if that could be minimized via the scener parser/compiler.
> Similarly, all of the warps, turbulations, media, etc should be able to be
> emilimated via a very basic system. Perhaps something that allows flexible
> object definitions, flexible light definitions, and flexible texture
> definitions, and the camera of course. After all isn't that all we need?
> Every pov scene is simply objects with textures, light (maybe with texture),
> and the camera (maybe with textures). Even media can just be objects with
> textures.

Well, technically it's in the object's interior, not it's texture.

>     If those 4 things could be broken down into a very basic definition then
> everything else could be built on top of that in some scripting language. If
> those basics were optimized enough in the main code then perhaps the later
> scripting slowness would not be too bad.

In raytracing, it think that it's safe to say that EVERYTHING should be
optimized, not just the very basic stuff.  Slowness is never "not too bad",
unless there is no other way to solve the problem.

-Nathan Kopp

Post a reply to this message