Using Geometry Generation

Fundamentals

Class Structure

Data Handling

There are a number of problems with this method - what if we have a number of different items of the same geometry in the scene, each with a different lot of settings (say different sphere radiuses). If you have these constantly changing then the cached data is thrown away possibly each time and there is no benefit to be gained - particularly in multithreaded applications.

This code takes a different approach to the normally accepted process. Instead of caching data inside the generation routines, it asks the client to cache the memory instead. What it ends up doing is allowing the user to control when items should be cached and when they should not be. The benefit of this approach is seen when dealing with multiple different instances of the one shape type. Instead of needing to reallocate memory for each call, the user provides the data for the coordinates, normals and any other data locally and can use it to cache other areas. This approach is particularly important for building geometry by reference shapes in Java3D where you want to reuse your own data arrays rather than copy the internal ones of the generator, that may be trashed when you least expect it.

Why no individual get/set methods?

In the case of the geometry generators I rarely expect people to be using getter methods for detailed information of the internal state. When people get information it is usally to check all of the state information, not just one at a time. If any one of a collection of variables changes then it effects the entire internal state and therefore it is better to request the user to provide everything that changes the internal state to be passed at once. I cover this more in a second. So, for fetching value, while it may seem convenient to ask for just the radius or just the height, typically it leads to the following situation:

  if(gen.getHeight() != newHeight)
    gen.setHeight(newHeight);

  if(gen.getRadius() != newRadius)
    gen.setRadius(newRadius);

Now, onto why it is more efficient to pass everything at once. Internally we know that if someone changes a parameter - face count, radius, height or whatever, we are going to need to recalculate the values. Now we have two options:

1. to recalculate values only at the time that the user asks for a new generation
2. to recalculate at the time the values are set so that a later request for new coordinates is much faster.

Primitives

For example, a sphere starts by generating a unit sphere sized shape in the cached coordinate array. If the user changes the radius, coordinates do not need to be recalculated. Instead, the sphere just takes the values and scales the values by the appropriate amount. The only time the sphere data needs to be regenerated is if the user asks for a different number of facets.

Subdivision Surfaces

Parametric Surfaces

Generation of the surfaces relies on calling an external class that provides 2D functions. The idea here is that the user can take the 2D math functions to build other structures such as a 2D window or path interpolators.