Warp <war### [at] tagpovrayorg> wrote:
>   Ideally it could be, for example, a macro which takes an array as
> parameter. This array would contain eg. ID (or index) values (perhaps
> identifiers declared by the include file), each one denoting a piece of
> track. The macro would then build the whole track from this array,
> rotating and translating the pieces appropriately.
>
>   Of course the problem becomes with bifurcating tracks: How to specify
> how the track continues with the other bifurcation? Maybe the include
> file could internally keep track of what it has constructed already, and
> the macro above could take an index value which tells it "attach the
> track defined by this array to the existing track, at the bifurcation at
> place n", or something similar.
>
>   Then another macro would be needed to create a train at a certain
> position in the track. Again, bifurcations become difficult because the
> user would have to be able to somehow specify which bifurcation is used.
>
>   This can become programmatically quite difficult quite fast, but I
> believe it's entirely possible to implement. IMO they key is to make it
> as easy as physically possible for the user to create the tracks with
> the least amount of effort. (This is usually my design principle when I
> design libraries, regardless of the language used.)

You sound like a programmer after my own heart, and I completely agree.  Apart
from the complexity/difficulty of any implementation, there's also the question
of the balance of control vs ease of use.  I haven't done more with this yet
other than ponder whilst modeling, but I have had a few possible starting
ideas.

1. User specifies a turtle-like array of distances and turns.  Probably only
marginally better than manual placement, and completely fails to address the
bifurcation issue you bring up.  Might work as a shortcut for very simple track
creation.

2. Generate the track from an image map, perhaps color coded to indicate track
style etc.  Seems that it would be fairly easy to use and give a lot of control
to the user.  It would probably be rather hairy to implement in SDL, though not
impossible.  The code would have to trace the paths and decide what kind of
junctions to create etc.

3. A user specifies an array of vector pairs that denote connected points,
basically creating an incidence list of an undirected graph.  The macro would
have to figure out how to connect them all together reasonably.  Easy to use,
but gives the user a lot less control of the outcome.  Also hairy to implement
(a given at this point?)  Doesn't really address train placement.

4. Convert or import a file created by an external track layout utility, either
in SDL or via an external utility.  I know such programs are out there but I
haven't really examined the field yet.

Looks like I'm probably going to have to do a lot of brushing up on my graph
theory. =)

-The Mildly Infamous Blue Herring

Post a reply to this message