POV-Ray : Newsgroups : povray.binaries.images : Wooden Trains : Re: Wooden Trains Server Time
1 Aug 2024 16:30:10 EDT (-0400)
  Re: Wooden Trains  
From: Charles C
Date: 20 May 2008 21:15:01
Message: <web.483376abb9c4dd0f7e6ec82b0@news.povray.org>
"Blue Herring" <bhe### [at] tinfoilcatcom> wrote:
> 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

Nice tracks!

Years ago I wrote a system in SDL to give a car sequential commands to drive
around.  If I wanted to tweek earlier turns, accelerations (etc), the end point
of the path would change wildly which made it challenging.

If it were me, I'd keep the track placement independent of earlier pieces and
figure out the path of the train after-the-fact.  E.g don't work with relative
distances and turns but absolute positions and orientations - pretty manual.
Make sure each track piece can have exactly several (?)* allowable rotations
and allow them to be placed on a grid making placement relatively quick. I
guess that's still similar to your #1. Once the track is built, the path
(spline) intended for train placement can be created by listing track pieces
and grid positions.  Forks can be ignored for the (spline) path creation by
substituting non-forked equivalent pieces instead.**  Afterall you probably
won't have a bifercated train (unless it was going too fast!).

Anyway this is fun stuff to think about. :)

Charles

*I haven't played with these tracks with my nephews in a while so I don't know
how many angles are possible or how fine of a grid would be necessary.

** Here a "piece" = ~3 points for the purpose of spline creation, not the model.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.