Rapid Prototyping of Computer Simulations
Server Side

Visualization – How we see the Model and Simulation


Visualization – Introduction

                The basic visualization for Falcetto is a Node and Edge graph.  Nodes represent tangible objects, such as people or cities, and are traditionally drawn as circles.  Edges represent the connection between Nodes, and are traditionally drawn as lines connecting the Nodes.  Falcetto maintains these traditions, but does add some extra options for Users that want extra customization.  Falcetto also operates on 3D space, but has display options to appear more 2D when desired.  Multiple rendering engines will be available, depending on the features available in the User’s browser.  The most compatible engine will only provide pseudo 3D capabilities, while other engines can provide hardware accelerated 3D rendering.

                Nodes will appear as spheres by default, with a customizable color.  Spheres are great for pseudo 3D rendering as they will always appear as circles or ovals.  Other shapes are available, as well as several image assets.  Each shape and image asset included with Falcetto will also have 3D model assets available for when a User chooses a full 3D capable rendering engine.  Assets available from the Marketplace are required to have 3D models to accompany them.

                Edges will appear as lines by default, with customizable color and optional direction arrows.  Lines are easily drawn by any rendering engine.  Some rendering engines may support curved lines, which can create a more pleasant appearance.  Edges will also allow other shapes and images, as a repeating pattern.  For example, a power line would be a repeating series of power poles with lines sagging between them.   Edges can have path points and Bezier curves, but will be visually supported to different degrees by the different rendering engines.


Visualization – Classes

                Falcetto provides several ways of editing a Class, and viewing a Class through a Class Instance.  The Class can be edited all by itself, or it can be edited in place from a containing space, such as the Global space.  Typically a Class Instance will display as just an interface cluster (just the Nodes that connect to outside Nodes), but a Class Instance can instead be displayed to show the entire Class as a miniature in the place of the Class Instance.

When a Class is edited independently, the Class is the only thing in the view.  Being the only thing the view reduces distractions, and can improve responsiveness, as the rest of the Model is not in view or being drawn to the screen.  Camera settings for the Class are separate from the Camera settings in the Global space, so when viewing just the Class it will have whatever camera settings the User found optimal.

When a Class is viewed or edited through a Class Instance, the Class will be visible in whatever space the Class Instance is in, referred to as In-Place editing.  The whole Class model will display in the area of the Class Instance, scaled to the size of the Instance.  The camera will not adjust when editing in this way, so complex Classes may display too small to be effectively edited.  During processing and replay, viewing a Class Instance this way will allow the User to see the inner workings of the Class.  Viewing a Class this way is not available for Black Box Models.

The left example shows how a Class Instance shows up normally. The middle example shows how the Class Instance looks when viewing the Class In-Place. The right example shows how the Class looks when edited by itself.

Choosing to edit a Class can be done by either selecting in the Class Navigator GUI panel, or by selecting a Class Instance and using right-click to select the Edit Class option from the menu.  Selecting the Class from the Class Navigator GUI panel will open the Class for independent editing, or allow In-Place editing of a Class Instance that is currently selected.  On browsers that support right-click menus, the User will be able to choose to edit the Class independently, or edit it in the current space.  On browsers that do not support right-clicking, the Class Navigator GUI panel will be the only way to select a Class to edit.

                Using In-Place editing also allows the User to create Specializations that alter the Code or Variables within the Class of the Class Instance.  Providing a clear and intuitive way to tell the User that changes are being applied to the Class versus the Specialization will be difficult, and will likely change often during Beta testing.

                A Node Class may have several externally accessible Nodes within the Class, referred to as Orbit Nodes on the Class Instance.  Externally accessible Nodes will be highlighted within the Class, much like Specializations.  The “center” Node will be highlighted slightly differently.  When the Class Instance is being viewed In-Place, all connections to Orbit Nodes will connect directly to the appropriate Node in the Class.  When the Class Instance is being viewed normally, the Orbit Nodes will orbit around the “center” Node. There will be several options for how to display the orbiting Nodes, such as making them have certain relative positions (imagine tires on a car), or to ensure they are always visible (they move so as to be always visible by the camera).

Orbit Nodes can be useful for visually imparting information from inside a Class, using the color/image of the Node.  For instance, an Orbit Node could alternate between red and green to indicate whether some internal process is operational or not.  As another example, imagine a Class represents a city, and the User wants to know which industry is the dominant export, so they could use an Orbit Node to change its image based on which export is dominant.


Visualization – Engines

                Falcetto will provide several rendering engines, in order to best balance between features and compatibility.  The first engine will be a proprietary pseudo 3D engine, running using HTML 4 code for maximum compatibility.  The other engines will be built as stretch goals.  The second engine will use HTML 5 code with canvas objects, drawn using a combination of vector graphics and images for a cleaner pseudo 3D appearance.  The third engine will use the canvas objects to attempt to render full 3D vector graphics (no images), which will provide the best non-plugin graphics, but may have the worst rendering speed.  The fourth engine will utilize Adobe Flash plugin, and will allow switching between pseudo 3D and full 3D from within the engine.  The fifth engine will utilize the Unity web player plugin, and will allow full 3D rendering, which should also be able to tie into hardware acceleration.

                Pseudo 3D will be accomplished using a combination of pre-rendered images and scaling.  If a 3D asset were to be pre-rendered, it would easily result in hundreds of images, each of which will be tagged with the viewing angle.  The pseudo 3D engine will pick the pre-rendered image that is the closest match to the current viewing angle.  The more pre-rendered images, the more accurate the image will be, but the more data will need to be downloaded.   The engine will not make assumptions, nor enforce requirements, as to what viewing angles were during rendering.  This allows the asset creator to choose whatever viewing angle algorithm they want to use.  For example, it would be simplest to permute all at consistent intervals of rotation and elevation, but that will result in lots of similar images at the higher elevations; a soccer ball layout would provide a great balance of angles and low download speed, but would be more difficult for the asset creator to implement a camera algorithm for.

                Multiple views of the Model will be allowed to be on the screen at the same time.  Each view can be running a different engine.  This can allow the User to clearly see the difference between engines, which can help with deciding which engine will be best for day to day use.

                Any Node may be selected as a camera for the views.  Each Node contains a pre-existing Variable that contains its direction and up vector.  This allows an easy and intuitive way to view the simulation from the point of view of one of the objects, which is especially fun for vehicles such as planes or roller coaster cars.  There are pre-existing Variables designed specifically for making a Node act like a camera, such as what Node/group to fit in its view, whether to follow, what distance to follow at, and whether it is a fixed offset or a chase camera.  If the pre-existing Variables are not used on the Node, then the special camera behavior will not be utilized.  Whether a Node is visible during simulation and replay is another pre-existing Variable that is useful for cameras, as it allows them to be visible during editing, but will be hidden while watching the simulation.

                In addition to shapes and images, a Node can be displayed with text, or just as text.  By default, this text will always be visible to the camera when the Node is in view.  An option will be available for making the text obey the pre-existing direction Variable, but will not be obeyed by all rendering engines.  A few font options will be available, generalized for compatibility between engines and browsers.

                The engines will support translucency to different degrees.  This can be useful for visualizing the difference between the display size, and the logical size of Elements.  For instance, chemistry visualizations usually show an atom as smaller than it actually is, in order to be able to use Edges to display the connectivity between atoms, rather than electron cloud overlap.

                Usually Elements will be displayed without borders, but some support for borders exists for certain situations.   If the engine detects that the Element’s color is too similar to the background color, then a border may be automatically displayed.  This border will be a slight darkening or lightening of the color, just to create a visual offset.  Some engines may detect that many Nodes of similar color are closely clustered, and thus decide that borders will be useful for distinguishing between Nodes.  The User may choose to show borders, overriding the default behaviors, which can be especially useful if the engine is not detecting these situations often enough.



Creating charts to show the change in values over time is a classic way to represent and compare simulation data.  Falcetto provides easy ways to select which variables will be available for putting into charts.  Charts can then be created using the available variables.  Sometimes, the User may want to chart to variables that are very different in scale, such as calories burned for a person versus the calories burned for a mouse, so Falcetto provides a way to easily transform (scale and offset) a variable so that it can fit on the same chart as other variables.  The values shown on charts can also be exported to formats such as CSV and Excel (may require Server Side subscription), so that you can use your preferred spreadsheet software to create your own charts for use outside of Falcetto, such as class presentations.


Replaying a Simulation

                Usually, a User will want to watch a simulation as it runs, then replay the simulation for other people to watch.  When replaying the simulation, there is no need for it to re-calculate all of the data, but instead it will just re-use the data it already calculated.  Falcetto will remember and store the User’s simulation data, allowing viewing the simulation as a movie, or charting its data.  The results can also be downloaded, shared, or submitted to a teacher.

Usually, the simulation will not process at the same speed as the simulation’s time keeping, meaning that the simulation either processes faster than real time, or slower.  For instance, it may take 2 seconds to process a cycle that represents .1 second.  When replayed later, the cycle can be played at its intended speed of .1 second.  Replaying in a slow-motion or fast-forward is also available, for instance watching a “3 year” simulation in just 3 minutes.

For instance, simulating a bouncing ball should happen very quickly, so replaying it will allow the User to watch the ball bounce naturally.  The simulation can be replayed at different time scales also.  For instance, a simulation where a thousand sheep and wolves live treats each cycle as a year and will take a long time to process each cycle, but when replayed the User would want each cycle to play in only one second rather than a year.

Content ©2014-2019 Ether Tear LLC. Website powered by Ether Tear LLC, ©2013-2019