Fundamentally, the example trees rendered with the L-systems taken directly from The Algorithmic Beauty of Plants aren't resulting the same visualizations as described in the book. They're close, but there's complication - I think - around a specific symbol and what it's doing: @V in the implementation research paper, and $ in the book itself.

As an example, compare the results for the following sympodial and monopodial trees:

I suspect part of the core of this issue is that what I'm doing to create the rotations for the $ symbol is resulting in a rotation that is far too vertically oriented.

I thought perhaps I had confused basic transforms and headings, but in reviewing the relevant code (https://github.com/heckj/Lindenmayer/blob/main/Sources/Lindenmayer/SceneKitRenderer.swift#L181-L214), I seem to have accounted for the corrected heading.

Since I've been mentally confusing directions, I suspect that I need to add a debugging view (#26), as well as potentially tests, to generate the relevant objects and then interrogate them to verify rotations, translations, etc.

3D view for debugging the output of an L-system rendered into a 3D object using SceneKitRenderer.

• enable control that shows, and allows for, stepping through the entire state sequence to add in the nodes into 3D under user control, rather than all at once.
  • as a baseline, maybe a stepper, but the L-system state size gets pretty darn huge (1000's -> 1,000,000's pretty quick) - so something where you can drag an interactive slider - or use held-down-key controls to indicate rapid movement as well as fine grained control would be useful.
• enable some coloring or highlighting options that can show the generation of a given state element (what iteration revolution is was created upon)
• allow the visualization, and then selection, of the state sequence and which that corresponds to within the tree.
• given a static element that doesn't change with further generations, allow a means of showing the difference of the "new growth" segment that can appear right after with a sort of highly localized "diff state" view between two evolutions.
• consider creating, and embedding, a unique ID with each state element so that the 3D object can be queried and manipulated after generation for highlighting based on the index of the original state array.
• enable a 3D component that shows the current "state" direction and heading
• look into how hard it would be to show rotation operations as animated updates to the current state 3D indicator, so you can see what rotation is actually happening
• enable the evolution to be controlled in this view so that you can selectively move forward (and backward) in iterations.
• enable parameter value application prior to evolution, and resetting or controlling the RND seed element from the master debug view.

I tried to include the library into a Swift Playgrounds iOS (v4) app as a swift package - and it immediately displayed this error on loading:

The target type, "ClangTarget" is not supported.

Unfortunately, this is a limitation of Swift Playgrounds iOS that means that it can't compile one of the dependencies for the Lindenmayer package. It has a dependency on Squirrel3, which is a C-based seedable pseudo-random generator. The C-based project makes it a "ClangTarget" which is what's represented here.

A only-written-in-swift port of that library would allow this all to be used in Swift Playgrounds iOS though, at the cost of some performance for the generation of random numbers.

• converting to using SwiftUI's Angle type instead of Double in renderers and rendering commands for consistency and usability clarity
• adding docs to a variety of methods
• renamed PWrapper to ParameterWrapper
• normalized rendering commands and removed unimplemented ones

resolves #7

In Honda's example model (pg 68 of PARAMETRIC L-SYSTEMS AND THEIR APPLICATION TO THE MODELLING AND VISUALIZATION OF PLANTS), uses the L+C module @V, which is described as maintaining the current axis of "growth", but rolling on that axis so that branching to the left or right results in a horizontal (from the world perspective) divergence.

I haven't sorted out the relevant math to enable that within the 3D visualizations currently, but I'd like to be able to showcase that model as an example.

During the initial implementation, I set up RenderingCommands and Modules are two different things - using enumerations for RenderingCommands (both 2D and 3D). In the current API, a module returns a sequence of 2D commands, or a single 3D command.

After implementing a few L-systems, it's clear that sometimes the modules are simply wrapping a single rendering command, so it might be a lot simpler if Modules and RenderingCommands were effectively the same thing, so that I didn't need to have both modules to represent the rendering commands, as well as modules for whatever the system is supposed to enable.

If the sequence of drawing commands for 2D is really needed (sequence was an experiment), then enabling context-free decomposition into rendering modules (called 'interpretation' in the scientific literature).

Additionally, I think it would make significantly more sense to switch the rendering commands from enums to static structs so that a developer could potentially expand and utilize their own representation engine if they wanted to do so.

• removes CLANG target dependency (C code) in favor of an embedded default pseudo-random number generator using the Xoshiro algorithm in pure swift. It's not as fast, but effective - and allows for using this package within Swift Playgrounds, which doesn't support CLANG target dependencies.

resolves #33

resolves #7

• reset the process flow and extracted the code and equations
• switched the process to forward project into the rotated space for vector evaluation
• explicitly projected the vector instead evaluating the angle between +Y and the rotated UP vector
• added simple tests to verify the rotation is as expected for no translation and tilting 45° in each coordinate direction

resolves #3

• now that all rules are typed, the need for dynamic member lookups for modules is pretty much gone - removing that capability from the Module protocol.

resolves #8 resolves #19

• stub in optional evaluation closure to protocol and types
• converted rule evaluation to use ModuleSet
• simplified ModuleSet's initializers, and updated in testing
• added evalClosure to initializers for all rules, updated tests to pass in nil for full initialization
• switched out all the rules to specific typed rules, using generics - and layering over types in the LSystems
• recreated the combinatorial explosion of rewrite() methods
• fixed up the tests, although test coverage has dropped precipitously with the explosion of types
• no more "casting" of types needed in the produce closures, and they no longer accept throwing closures
• evaluation closures for parametric evaluation of rules now don't require casting either - all typed based on Rules

resolves #5 resolves #18

• establish protocol for a seeded PRNG to use within the systems
• establish default PRNG for both types of L-system
• establish default PRNG for both types of rules
• expanded types for basic, w/RNG, w/Defines, and w/Both
• migrated Chaos wrapper down to just the rules themselves
• added Lindenmayer top-level struct with factory methods on it for different types of LSystems (Basic, +Rng, +Defines&RNG)
• added rewrite rules on specific types of LSystems to provide factory for the various rule types, and exposing the relevant closures for less extra _ need

Rules were previously existential, and writing closures that used the modules required casting. With update #21, that's notable changed - all the modules are shifted into fully typed expressions, and the rules are all generic across a couple different Axis, resulting in a combinatorial explosion of types:

Context matching:

• direct
• left, direct
• direct, right
• left, direct, right

matrixed against:

• basicLSystem (no parameters, no RNG)
• RNGLSystem (no parameters, RNG)
• DefinesLSystem (parameters, no RNG)
• DefinesRNGLSystem (parameters and RNG)

Some of the code is verified, but it should all be basically "worked" to verify that I didn't miss anything while making "the maze of twisty passages, all alike" in order to have typed closures for writing LSystems.

(Coverage of Lindenmayer in general dropped to 36%)

I don't know if it makes sense or not, but it could be quite possible to use Lindenmayer with Server-side swift (or more generally, swift running on Linux or other platforms). Primarily, it would mean conditionally compiling the existing pieces that require Apple platform specific libraries (CoreGraphics, SwiftUI, and SceneKit) and enabling a secondary 2D (if not 3D) renderer.

One option for the 2D renderer is to borrow from what swift-collections-benchmark has done and enable a simple SVG output renderer as a default 2D renderer if the others aren't available. See that project's DefaultRenderer.swift implementation for the gist of the pattern.

If you'd like this capability, please let me know in this issue - or feel free to jump in and help contribute to enable it.

It would be nice to add the ability to easily compute adjustments to final vectors resulting from the 3D modeling commands of yaw, pitch, and roll so that effects such as Tropism (either from wind or sun) could be included in calculating the resulting growth direction of L-systems.

I'm not sure how easily that could be accommodated, and where would be most appropriate - but I'm guessing as an additional component to the production results when there's an explicit growth or bend.

One of the interesting advanced functions of current L-systems is supporting a '%' symbol as a mechanism to prune a branch, and all associated sub-elements, from an existing tree. I suspect that's best done in a follow-on phase after the rule evaluations for each state of the sequence that makes up the tree is complete, at least to allow everything to operate in a parallel mode.

Some previous tooling (L+C modeling tools) use bicubic patches for rendering the interesting shapes of leaves and/or petals rather than explicitly "growing" them with their own L-system. It would be tremendous to allow/enable that same capability when rendering the results of L-systems in 3D.

The initial API for Lindenmayer is blocking and serialized. WIth Swift 5.5 supporting async/await, it would be great to consider exposing some of the API of this library as async and concurrent.

My initial thought is that LSystem.evolve() is the primary target to consider for exposing an async API