On Tue, 13 Apr 1999 22:22:40 +0300, Margus Ramst <mar### [at] peakeduee> wrote:
>OO wasn't exactly what I was talking about here. More along the lines of the
>modular design concept. While I am by no means familiar with the
>technicalities, I am under the impression that integrating new features
>(processes, objects etc.) is more difficult than it need be. You tell me,
>you know better.

Adding new objects, assuming you can provide the necessary functionality
for them, is simplicity itself.  Likewise with new textures and warps.  The 
only thing most people might have trouble with is adding keywords to the 
parser, but even that isn't really all that hard if you follow the existing
examples.  Unless you're doing something like the isosurface patch that
makes massive parser changes, but even those hook into the existing code
in relatively few places.

Adding new functions, like trace() or min_extent(), is fairly easy.  Again,
these are small parser changes that are easy once you know where to make
them.

Adding new global functionality like U-V mapping or displacement mapping or 
nonlinear transforms, however, requires a change to every object type.  Even
in a more modular world, this would still be the case.  If I need to add a 
"give me a triangle mesh" function to the base class, I will either need
a default implementation of it, or someone will have to add it to each and 
every derived class.  From a non-OO, modular standpoint: if I add that function 
to what's expected from an object, every plugin will have to change.  The 
issue here, for those who have worked with COM or CORBA or Java, is that the
*interface* to an object is changing and requires all implementations of that 
interface to change.  Nathan has gone the default-implementation route with
the UV patch, and I suspect the displacement stuff, if it is ever added, will
be done similarly.  That part could be made easier with a modular or OO 
approach, in that you'd only have to change the nondefault implementations.
I don't see any way of making the rest easier, though.

Other patches like dispersion and photon mapping and blurred reflection and 
so forth are fairly localized already to whatever piece of functionality 
they affect (all lighting code, in these cases.)  Modularity wouldn't help
much there, because the code in question is already in only one place.

Another (potential) kind of patch adds functionality to the language itself,
like the old #macro patch.  These are purely parser changes, and some are
easier than others.  I don't know of any current examples of such patches.

Finally, there are patches like my motion-blur patch that change lots of
fundamental data structures.  Modularity won't help much there.

Perhaps what we need more than modularity is documentation of how patches are
done.  I think DSW is working on that, but I'm sure he could use our help.

Post a reply to this message