...
One of the interesting things of these geometries is that they can be split into several subregions or subvolumes. This can increase the efficiency of the intersection tremendously. Instead of having an object with a huge bounding box, this can be divided into several regions, with much more smaller bounding boxes. These regions can be spatially connected or not, and each region could evaluate a different mathematical problem to calculate a point on its surface. Each region or subvolume has its own bounding box, which is calculated in getSubVolumeBoundingBox, and the number of subvolumes is returned in getNumSubVolumes. There is also a function that returns the bounding box of the whole object, getBoundingBox. One of the optional functions, isOverlappingBoundingBox, checks the intersection of two boxes, one sent by the render engine, and the other that of the given subvolume, to optimize the rendering speed. Note that in getSubVolumeBoundingBox, getBoundingBox the returned bounding box in general is not axis-oriented, it should be subvolume-oriented, and because of this eight points must be returned. First the four "lower" ones, and then the four "upper" ones. In isOverlappingBoundingBox the input bounding box is not axis-oriented and is in the local coordinate system of the extension object, and defined by eight points. Don't underestimate the influence of this function. It can make wonders.
These extensions can also have their own custom UV generators. These generators are declared using getNumberOfUVGenerators and getUVGeneratorName. Once declared, they can be used normally with Cmaxwell::Cobject::addChannelUVW( dword uvIndex ) and Cmaxwell::Cobject::generateCustomUVW( dword iChannel, dword iGeneratorType ).The generators are implemented in getUVForChannel. This is also a speed critical function, so it must be optimized very carefully (no file I/O, no OS calls, no SDK calls...).
...