A engine for fast multi-threaded spatial-management and geometry generation from prodecural and static input on CPU and GPU, to polygonize voxel data sets generate terrains for 3D games, maps and visualizations in WebGL. A entire universe can be generated on the fly, with tools and abstracted procedural brushes, entire planets can be designed in a very short time from contintents to little details in centimeter range.
 

Procedural Design

The engine consists of both procedural and manual content creation. With various tools datasets can be influenced by abstract parameters or controllers and also hand-crafted with brushes in any scale. Using procedural sources as brush enables to design giant areas unique and believable. Materials and layout generation for object-placement can be conducted by procedural decorators, using dataset informations like biomes, while assets can be placed with procedural tools massively and also one by one. The goal is to archive a vast open world while being believable and rich designed, full of unique areas.
 

Flexible generation of datasets

2D and 3D dataplan layers can be defined to store volume data, heightmaps, simulated flowmaps, heatmaps and any required data set to use in the generation process or for the final materals. Localized sources can be manually or procedurally distributed to generate a complex natural looking enivronment and to restrict the required processing power to local data.  Memory is automatically managed by the model and  LOD strategy, limited and optimized to provided options.
 

Multi-threaded generation of models, landscapes, virtual worlds

Different LOD models can be used for polygonization, such as instanced quads processing all on the GPU, or  multi-threaded chunked buffer generation using algorithms such as Marching Cubes or Dualcontouring.
   

Pooling and Data-Management

Reuse of objects is important in JS engines to improve performance, this is optimized by flat indexed octree pools synchronized by transferable buffers with threads. Batches using a predefined chunk size compose geometry with varying required memory, without reallocations.

Datasets are allocated in chunked atlases matching the strategy of the used geometry manager, also optimized for a predfined max. texture size to match for device limits. By including Tesseract glsl functions all required data can be easily accessed by custom shaders.
 

Dualcontouring

Adaptive geometry generation with settings for geometric error tolerance, desired cell size-ranges and more can be adjusted for the given usecase. Optimized memory usage, pooling and flat indexed octrees speeds up generation of large geometries.

Some addtional features can be utilized for specific usecases: Feature-scaling can improve quality at desired areas and early rejection can sparse-out polygons at overlapped areas of separated groups (e.g. water surface of a river). Additional post-processing can be implemented for each group-type to further modify or store additional vertex-attributes. Plugins can extend/customize processing at each stage.
 

Base components

 

Models

A model is a object to place in space such as a sphere for a planet. Multiple layers can be attached, such as a spherical LOD manager, which uses various options to process a quadtree LOD. For example a planet can be modelled by using 2 spherical LOD managers, while one will be used for the atmosphere and another for terrain and general LOD around the nexus (nexus = world center such as the camera).

Different modules will be added the LOD layers, like a generator for geometry, a map for dataset management, and a dataset of the desired data layers. Also, a weather module could be added here, which will append it's dataplan to the dataset and automatically process and provide everything for custom shaders. Depending on the model or usecase a quadtree, 2D spherical quadtree, or a 3D octree content manager can be used to handle and store objects. A content manager also provides automated instancing, impostor generation, hierarchical frustum culling and various options to configure the LOD.

Models and abstracted data is replicated and synchronized with threads. Modules can process their work in threads or partially transfer jobs to their thread instance.
 

Sources

Hierarchical nodes of procedural formula, modifiers, models and static data, synchronized with workers to provide information for the isosurface or any other spatial-based informations. The CPU renderer enables to render in threads without WebGL or any additional requirements, and also allows to process a single sample without a heavy render call and download from the GPU. Once a source is created, it is also available in all threads.
 

Probes

A probe is assigned to a source, parameters like radius, falloff, or values for noise are provided by the source. The probe can be infinite or localized. By using a range defined by a mask function, such as a simple circle or sphere, the LOD for planar, spherical and volumetric terrain can also exclude probes not significantly visible in pixels on the screen from the render stack. Probes can be manually and procedurally placed. Datasets with enabled composition can use different blend modes such as additive or subtractive and will be composed by the renderer. A common usecase is terrain height or volume data.
 

Sampler

A sampler provides information at any position in space, such as the distance field, gradient, and spatial based data. Sources will be localized and their layers prefiltered. Sampler can also be used for collision detection and to derive any dataset information. The code of sources is written in GLSL and will be transpiled to optimized JS code. JS functions can also be imported for manual translation.

 

Groups

Multiple groups or "passes" merging into a single buffer, seperated for drawcalls / materials. As for example, a terrain and water group with different materials and source-layers. Each layer of a sampler can be tied to a group similar to a framebuffer. A sampler writes to all relevant groups and therefore can inherit information, in this example, using the terrain base-height.

 

Generators

Plugins for polygonization / voxelation, such as by default, DMC and DMS for skirts is used.

 

Decorators

A decorator is used for layout generation, object-selection. A indexed content-octree will be generated to be used in the main application accelerating common tasks as collision detection and raycasting. The decorator will automatically generate the octree on insertion and cluster objects (as asset-groups) for automatic batching (instancing). Initial layout generation is defined by sources, using sampler information to further select assets and placement.
 

Partner wanted