Defining Custom Simulation Geometry

Introduction

For some solvers in DOPs, for example the wire solver, the state of the simulation can be conveniently represented as a GU_Detail. In that case, the solver will create and manipulate instances of SIM_GeometryCopy that are attached to each SIM_Object in the simulation. Sometimes the simulation state is not conveniently represented as a GU_Detail. For example, you may want to plug in a different, existing solver that uses a different geometry representation.

Usage

You can write your own type of simulation geometry by deriving from of SIM_Geometry. The declaration of your class would look roughly as follows:

class SIM_MyOwnGeometry : public SIM_Geometry
{
public:
    // This member not part of the SIM_Geometry interface;
    // it's only accessed by your own solver
    MyOwnRepresentation* getMyOwnRepresentation();

protected:
    // Members that need to be implemented for your own geometry
    virtual void initializeSubclass();
    virtual void makeEqualSubclass(const SIM_Data *source);
    virtual void saveSubclass(ostream &os) const;
    virtual bool loadSubclass(UT_IStream &is);
    virtual void handleModificationSubclass(int code);

    // Allows access to the GU_Detail
    virtual GU_ConstDetailHandle getGeometrySubclass() const;

private:
    MyOwnRepresentation* myOwnRepresentation;
    mutable GU_DetailHandle myDetailHandle; // Cached GU_Detail

    DECLARE_STANDARD_GETCASTTOTYPE();
    DECLARE_DATAFACTORY(SIM_MyOwnGeometry,
                        SIM_Geometry,
                        "Your Own Geometry",
                        getEmptyDopDescription());
};

The most important method that you need to implement is getGeometrySubclass. This will perform the conversion from your own representation to a GU_Detail:

GU_ConstDetailHandle
SIM_MyOwnGeometry::getGeometrySubclass() const
{
    if( myDetailHandle.isNull() )
    {
        GU_Detail* gdp = new GU_Detail();

        myDetailHandle.allocateAndSet(gdp);

        .. // Generate geometry for myOwnRepresentation
        .. // and store this geometry in gdp
    }
    return myDetailHandle;
}

The cached detail handle that corresponds to the internal representation is cached in myDetailHandle. It is computed lazily when getGeometrySubclass is called. How to override the remaining members will be obvious when you look at the examples.

Examples

The HDK example SIM/SIM_SolverSNOW::h shows in more detail how you can create your own subclass of SIM_Geometry. In this example, the internal representation is a voxel array. The snow solver works directly on the voxel array, instead of the GU_Detail. Here the SIM_Geometry interface acts as an adaptor, exposing only the GU_Detail representation that is required by the outside world. The SIM_Geometry interface hides the fact that a voxel array is used internally by the solver.