3d drawing of a roller coaster

Roller Coaster Designer

Jonathan Bridge & Peter Froud
CS 160 fall 2015
View project - hosted past the UCSC Baskin Schoolhouse of Engineering. We got 3rd place!

As well viewable at https://pfroud.github.io/rollercoaster-designer, although in a somewhat wonky state.

How to utilise

Our program lets the user pattern a roller coaster track from modular pieces.

To modify the track that automatically loads, use 1 of the red Ten buttons at the bottom. The button with a blueish background removes one slice, and the button with a red groundwork deletes the entire track. And then, use the vii buttons at the elevation to add flat, sloped, or turn pieces. You can besides apply the shuffle button at the bottom to add a random sequence of curved track.

Printing the play button at the bottom to outset or stop the cart moving.

System requirements: web browser that supports WebGL. Y'all can encounter if your browser supports WebGL by going to https://become.webgl.org/.

Implementation

The roller coaster you lot run into is a Track instance which holds an array of Pieces. Every Piece holds information about its position, rotation, and the mesh to draw. The Runway instance also manages insertion and deletion of Pieces.

We had a hard time finding a practiced style to store the constants for mesh dimensions. We started with a giant JSON file just ran into a problem: but we wanted to reference an object while still creating it, which JSON doesn't permit. For example, we wanted to do something similar this:

{"down": {              "size": {              "x":              54.3057,              "y":              54.3057,              "z":              40.7995              },              "startOffset": {              "y":              down.size.y - 11.88,              } }}

which is invalid JSON. Amazingly, GitHub's syntax formatting tells us this.

Using Javascript "classes", we can do this:

              TrackConst              .              image              .              downwards              =              function              (              )              {              var              down              =              new              TrackType              (              )              ;              down              .              size              =              {              x:              54.3057              ,              y:              54.3057              ,              z:              40.7995              }              ;              down              .              startOffset              .              y              =              downwardly              .              size              .              y              ;              return              down              ;                          

which is what we want. That example is from scripts/constant.js.

We had to blitz towards the terminate. When trying to implement the Cart moving forth the rails, nosotros learned that arctangent from Javascript's Math class doesn't acquit equally expected. After a lot of ugly coding, nosotros did eventually manage to become something that has a semblance of working. Merely the implementation is gross.

Classes

Not really classes considering JS is prototype-based This diagram shows, poorly, how the classes interact:

Rail: the master class of the projection

• Holds an array of Pieces, which you see as a roller coaster rails
• Manages calculation Pieces throughTrack.insertPiece(piece), where piece is either a unmarried Piece object or an assortment of Pieces. Each Slice must exist moved and rotated to lign upwards with the previous i.
• Besides manages deleting Pieces.
• Location: scripts/Track.js

Slice: i rail segment.

• Knows its location, management, dimensions, and how much pre- and post-correction must exist made to brand other Pieces fit.
• Location: scripts/Slice.js

Support: generates the support beams beneath a track slice.

• Basically makes a cylinder and moves it around just right.
• Just chosen by Piece class.
• Location: scripts/Support.js

TrackConst: A single grade that holds all the constant information.

• For each type of rail, holds mesh'southward dimensions and how much pre- and post-correction must exist made to make other Pieces fit.
• Specifies where extra Supports continue curved pieces to make it look nice.
• For plow or not-flat pieces, defines how the Cart animates over it.
• Never accessed directly, only through global constant TRACK_TYPES which is an instance of TrackType().
• Location: scripts/abiding.js. Y'all might be request why some of our filenames are capitalized and some aren't. Considering we're fundamentally bad people, that'south why.

TrackType: Inner class to TrackConst. Should be chosen PieceType. Holds constants for each type of Piece.

• Each type of Piece (due east.thousand. FLAT_TO_UP) gets a TrackType which holds constants for that type. So the constants are admission through TRACK_TYPES.FLAT_TO_UP, for case.
• Prevents code from being horrible, believe information technology or not.
• Merely used to make global abiding TRACK_TYPES, which just happens in the constructor for TrackConst.
• Location: scripts/constant.js

Gui: how the user interface buttons access the other classes.

• Each button has its own object.
• Accessed simply past the global variable GUI.
• Location: gui/gui.js

Other

Notable global variables:

• Rails: instance of Runway() and the track displayed on the screen. Declared in Rails.js.
• SCALE: tin can change the size of pieces. Ultimately not needed, yet nosotros thought it'd be useful in early implementations. Alleged in index.js.
• SPEED: how fast the roller coaster moves across the track. Declared in Cart.js.
• PLAY: boolean that tells the renderer whether or not to run the Cart blitheness.

Libraries used:

• three.js: the big ane. Abstracts WebGL drawing.
• jquery: dependency of three.js.
• dat.gui.js: helper GUI that nosotros used when first implementing considering it was easier than messing around with CSS every time nosotros wanted to practise something. No longer used, just kept in the library.
• OrbitControls.js: three.js plugin to make the camera usable. View demo.

Other files of note:

• index.html: project entry point, where everything is put in.
• index.js: the initializer for three.js. Sets upward things like photographic camera, controls, ground plane, skybox, lighting, and renderer.
• skybox.js: makes the skybox effectually the rails, using a shader from a library that comes with three.js. Source.
• Cart.js: the frankenstein'due south monster that controls the car. Could be cleaned up a bunch. It's ugly because we were rushed.

Novelties

Nosotros began past using 3D models from Rollercoaster Pre-fab by Adam W, but weren't really satisfied. We idea it would exist better to take total command over the models.

We used Autodesk Inventor to model all our ain track pieces. Nosotros had to spring through some hoops to get those models into the json format the three.js uses. From Inventor, we exported the model to a .dwg file, which we imported into a trial version of SketchUp Pro. From Sketchup we exported an .obj file, which could be converted using convert_obj_three.py which is included in three.js.

Modelling progression: tube, single strut, strut pattern, bend.

You tin can access all of the original and intermediate files in [rails 3D models/](track 3D models).

Sample output

Video

Y'all can run into a video at the bottom of this folio.

Screenshots

waldschmidtmrsooduraske.blogspot.com

Source: https://github.com/pfroud/rollercoaster-designer

Share this post