tabithabragg/groundcontrol

1. This repository is a suite of native DCC plug-ins, not a single application. The code is split primarily by host platform: CarraraExtensions for Carrara, and LightwavePlugins for Lightwave. Each plug-in lives in its own folder and is built as a separate binary/module that the host application loads.

2. The architecture is “plugin-per-feature.” Most folders map to one installable plug-in package with its own entrypoint file (*DLL.cpp, gcMain.c, etc.), public headers, and host-specific resource files (.def, .r, .rsr, .plist, Visual Studio/Xcode projects). The host app is the runtime container; this repo provides modules that extend import, geometry generation, shading, deformation, and rendering behavior.

3. The largest functional area is terrain and geodata. GroundControl is the main terrain/geodata subsystem in Carrara, with supporting types for elevation meshes, shapefiles, DEMs, water, bump/shader filters, and generators. The Lightwave side also has a GroundControl plug-in with file loading and mesh-building code (gcImageLoad.c, gcMeshload.c, gcMain.c). This area is backed by a shared C library under Library/GroundControl, which contains low-level mesh, binary tree, math, and data helpers used by the plug-in layer.

4. Geometry generation is another major subsystem. AnythingGrooves contains primitive generators such as cone, cube, cylinder, plane, and sphere, plus conversion-to-mesh logic. AnythingGrows adds procedural growth/hair-style generation with a primitive, deformer, billboard support, strand generator interface, and hair generator. These modules typically transform parametric inputs into mesh or strand data before handing it back to the host.

5. Shader and material extensions form a separate family. ShaderOps, ShaderOps2, ShadersPlus, Shoestring_Shaders, and ShaderGel are all collections of shader nodes/ops. They include color/math operators, UV transforms, mixing/compositing, gradients, lighting controls, and procedural effects. Architecturally, these modules sit inside the host’s shading pipeline and operate on material inputs/outputs rather than geometry.

6. Renderer-adjacent plug-ins are separated from pure shader nodes. WireframePro, ToonPro, Noir, Parchment, StarBright, and Gemini focus on non-photoreal or stylized rendering, selection/override behavior, wireframe display, toon/cell shading, and related rendering controls. The shared WirerendererCommon folder contains common data and state helpers for wire/toon rendering behavior across those plug-ins.

7. There is a smaller set of scene/utility plug-ins that manipulate existing assets rather than generate new ones. DCGImporter handles sequenced OBJ import. TerrainTools contains operators for terrain editing and conversion tasks such as normal/terrain transforms, intersection, surf, cutout, and beach-related operations. ShaderGel and Cognito appear to be additional host extensions with their own module boundaries, likely using the same overall plug-in pattern.

8. Shared code is intentionally separated from plug-in wrappers. CarraraExtensions/Common holds reusable infrastructure: scene utilities, shader helpers, mesh accumulators, cache helpers, tree structures, debug/util macros, and generic math/random utilities. This is the “library layer” beneath several Carrara plug-ins, keeping mesh traversal, shader plumbing, and collection logic out of feature-specific modules.

9. The main data flow across the repo is: host application loads a plug-in module → plug-in presents UI or hooks into host events → plug-in reads scene/file/terrain/shader inputs → shared helpers build or transform mesh/shader/state data → results are returned to the host as geometry, shading results, or importer output. For ground/terrain features, the flow often starts from external data files and ends as terrain meshes, elevation maps, or water/bump/shader effects in the scene.

10. Build and packaging are host-specific and legacy-toolchain oriented. Many folders contain both Visual Studio and Xcode projects, indicating cross-platform builds for older plugin SDKs. The presence of .def, .r, and .rsr files suggests exported symbols plus host-specific resources/localization/UI assets are bundled per plug-in.

11. The repository structure also shows an active fork/maintenance story. The README explains that the Lightwave GroundControl plug-in is a development/testing build intended to load a groundcontrol.p plugin file into both Layout and Modeler, with compatibility work for Lightwave 2018–2020. So the repo is not only source code but also a distribution tree for multiple historical host integrations.

12. For an architecture diagram, the most important boundaries are: host application boundary, plug-in module boundary, shared-library boundary, and external data boundary. The host loads modules; modules depend on shared helpers; terrain/import plug-ins ingest external geodata; shader/render plug-ins sit inside the rendering pipeline; and geometry plug-ins synthesize meshes or strands that are handed back into the scene.