 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
I've been having some fun lately working on a set of macros to create toy
wooden train sets like those made by Brio, Maxim, and Learning Curve. Any
feedback is welcome and appreciated. This one is a selection of the various
kinds of track pieces.
-The Mildly Infamous Blue Herring
Post a reply to this message
Attachments:
Download 'wt_track_demo_1.png' (279 KB)
Preview of image 'wt_track_demo_1.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This one is a sample of some simple maxim style cars and engine.
Post a reply to this message
Attachments:
Download 'wt_ble_demo_1.png' (179 KB)
Preview of image 'wt_ble_demo_1.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Blue Herring wrote:
> I've been having some fun lately working on a set of macros to create toy
> wooden train sets like those made by Brio, Maxim, and Learning Curve. Any
> feedback is welcome and appreciated. This one is a selection of the various
> kinds of track pieces.
Haha, very nice! Did you also devise some system to manage
assembled tracks so you can place and move trains along them?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin wrote:
> Haha, very nice! Did you also devise some system to manage
> assembled tracks so you can place and move trains along them?
Oh should have waited a few for minutes for you second post ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is a Thomas Wooden Railway type engine I invented called "Lemuel".
Post a reply to this message
Attachments:
Download 'wt_lemuel_demo_1.png' (275 KB)
Preview of image 'wt_lemuel_demo_1.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfr de> wrote:
> Haha, very nice! Did you also devise some system to manage
> assembled tracks so you can place and move trains along them?
Thanks. No, not yet, that's probably the biggest todo I have for this. Haven't
really come up with a good way to do this yet, so I've largely concentrated on
the modeling so far. The track pieces aren't hard to place manually, the
trains are a little trickier, but doing too many of either quickly gets
tedious. It would be much better to have some easier more scalable way of
doing it.
-The Mildly Infamous Blue Herring
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Blue Herring wrote:
> Thanks. No, not yet, that's probably the biggest todo I have for this. Haven't
> really come up with a good way to do this yet, so I've largely concentrated on
> the modeling so far. The track pieces aren't hard to place manually, the
> trains are a little trickier, but doing too many of either quickly gets
> tedious. It would be much better to have some easier more scalable way of
> doing it.
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.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Blue Herring nous illumina en ce 2008-05-20 10:56 -->
> Hello,
> I've been having some fun lately working on a set of macros to create toy
> wooden train sets like those made by Brio, Maxim, and Learning Curve. Any
> feedback is welcome and appreciated. This one is a selection of the various
> kinds of track pieces.
>
> -The Mildly Infamous Blue Herring
>
>
> ------------------------------------------------------------------------
>
Bring back some OLD memories. The difference was that back then, the tracks
where gray plastic.
--
Alain
-------------------------------------------------
I knew a girl so ugly, they use her in prisons to cure sex Offenders.
Rodney Dangerfield
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
