Version 0.1
Prepared by Simon Tupý 4.C
SSPŠaG
September 2, 2022
- 1 Introduction
- 2 Scenarios
- 3 Architecture Overview
- 3.1 Work Flow
- 3.1.1 Viewport Window
- 3.1.1.1 Saving and Loading Scenes
- 3.1.1.2 Camera Controls
- 3.1.2 Profiler Window
- 3.1.2.1 Frame Time Graph
- 3.1.2.2 Frame Time Counter
- 3.1.2.3 Renderer Statistics
- 3.1.3 Scene Hierarchy Window
- 3.1.3.1 Entity List
- 3.1.4 README Window
- 3.1.1 Viewport Window
- 3.2 Main Modules
- 3.3 Details
- 3.4 Possible Program Flows
- 3.1 Work Flow
The purpose of this document is to present a description of the functions and interfaces of the final product. Furthermore, it will introduce and discuss commonly used concepts, interfaces and usecases, including a basic overview of the application's structure and inner workings.
| Term | Definition |
|---|---|
| Software Requirements Specification | A document that completely describes all of the functions of a proposed system and the constraints under which it must operate. For example, this document. |
| CFD | Computational fluid dynamics - the use of applied mathematics, physics and computational software to visualize how a gas or liquid flows, as well as how it affects objects as it flows past. |
| Advection | The evolution of mass forwards in time using a velocity field. |
| Convection | The process of transferring heat via circulation of movement of the fluid. |
| Lagrangian (methods) | Methods that move a fluid volume (ie. by using advection), most commonly used with particles. |
| Eulerian (methods) | Methods utilizing a grid-based approach to fluid simulation. |
| SPH | Smoothed particle hydrodynamics - the most common form of CFD. |
| FLIP | Fluid-Implicit-Particle method used in CFD. Utilizes fully Lagrangian particles to eliminate convective transport. |
| Device | A device capable of running CUDA code (ie. an Nvidia GPU) |
| Host | The CPU and CPU related code |
| Key | A keyboard key or mouse button declaration. |
This document is intended mainly for testers, developers, the marketing department, and other parties that may be involved.
- Software Requirement Specification Šimon Tupý https://github.com/Goubermouche/FluidEngine/blob/master/Documents/SoftwareRequirementSpecification.md
The main use case of the product will be the process of viewing and interacting with a simple fluid simulation. In the future we hope to expand this by providing options of exporting generated fluid simulations.
The main audience this product is intended for are computer graphics, simulation and GPU compute programmers.
The original idea was inspired by the realtime toolset provided by JangaFX, whom have incidentally also introduced a real-time fluid simulation tool a couple months after we began working on the product. The individual products however target different audiences.
Due to the limited time frame the scale of this project is limited to just the engine and 2 fluid simulation methods (SPH, FLIP). It is expected that both methods will be accelerated using CUDA.
N/A
Once the user launches the application an empty scene, viewport, profiler and scene hierarchy panels will be opened. The user will be able to edit the scene by deleting or creating new entities and adding various components to them. The currently available components are:
- DFSPHSimulationComponent
- SPHSimulationComponent
- IDComponent
- MaterialComponent
- MeshComponent
- TagComponent
- TransformComponent
- RelationshipComponent
- ColliderComponent
- ParticleSamplerComponent
An example workflow may looks something like this: The user launches the application; an empty scene appears. After the application loads the user creates a new entity by pressing the RMB in the entity hierarchy panel, then he selects it by pressing the LMB. After selecting the entity the user adds a new 'DFSPHSimulationComponent' component to the entity via the 'Add Component' button located in the component panel, the user uses the default simulation parameters without changing anything. After creating the simulation entity the user creates another new entity by following the entity creation process described above, however, this time a 'ColliderComponent' is added instead. The user then selects the component in the component panel and chooses a desired base mesh for it. After creating a collision object the user repeats the steps described above and creates a 'ParticleSamplerComponent' and selects the desired base mesh. After the simulation is set up the user re-selects the simulation entity and presses the 'Simulate' button, after the simulation finishes simulating and gets cached the user will see a live replay of the simulation with the ability to scrub through it (The scene, as described above, will contain 2 objects: a collision object and an object created from sampled particles).
Furthermore the user will have the ability to open and save scenes (the application will be shipped with an assortment of example scenes showcasing its functionality). The application will provide a simple window-based layout that the user can edit and transform to their liking.
The viewport window contains an OpenGL framebuffer texture, that displays the current scene.
To save and load scenes the user can right click the viewport and select either the "Save Scene" or "Load Scene" option. The save scene option also provides a simple shortcut - Ctrl + S - which will save the currently loaded scene, if a default filepath is provided.
The built-in arc ball camera has three movement functions: orbit (MMB), pan (MMB+Shift) and zoom (Scroll)
The profiler window displays useful information about the current scene.
The frame time graph is a basic graph UI component that displays the time each frame took to compute. The graph is comprised of many rectangular shapes, that are scaled by the current delta time value.
Since the frame time graph by itself does not provide exact information we need another UI component - the frame time counter displays 3 values: max, min and current delta time values in milliseconds.
The profiler will additionally provide a simple renderer statistics: the current count of all vertices that are being renderer in this frame, the draw call count and whether VSync is enabled.
The scene hierarchy window displays a list of all entities in the current scene.
The individual entities are displayed using a tree diagram. The individual tree nodes respond to M2 events and produce a simple context menu containing the following options:
- Delete - Deletes the entity.
- Rename - Creates a rename input field and renames the entity.
- Create Empty - Creates an empty child entity parented to the entity.
In the case of the RMB event not being handled by any specific tree node, the list creates a different context menu containing the following options:
- Create Empty - Creates an empty entity.
- Save Scene - Opens a save file dialog window and saves the current scene.
- Load Scene - Opens a load file dialog window and loads the selected scene.
Some scenes may also provide a simple README panel containing relevant information.
The application's core module will provide the essential functionality including but not limited to: math operations, GPU compute, scene and entity management and various utilities. The main loop will also be located here.
The editor will provide users with a simple GUI built on top of the core module that will enable them to manipulate the underlying data (scenes, entities), for more details see the image below:
The image contains a preview of what the main editor page might look like (note that this is currently the default layout of the application and that the application supports dynamically moving and reorganizing it's windows). The current layout displays a simple viewport window, which acts as a parent to a profiler (top) and scene window (bottom). Note that the viewport window contains a transformation gizmo.
Since the user can manipulate the window layout at will they may create their own variations of the default setup; below you can see a simple layout containing the same layout with an additional viewport panel (note that the viewport panel on the right side is currently focused, hence why the gizmo is only visible on this side, also note that the sphere that is currently being rendered is displayed from different angles in both viewports, this showcases the multiple cameras these two viewports work with).
The fluid simulations and GPU compute-related functionalities rely on a working Nvidia GPU - if a valid compute device is not detected on the target system all of these capabilities will be disabled and not available, however, the engine will continue to function.
The application functions similarly to Blender - it enables the user to freely interact with a given scene.