AtomExAssets

The future assets pipeline for JME3 games!

Features

  • Real pipeline

  • Multi sources & Multi targets

The "real" pipeline

Pipeline is a common term in computing and also asset making. From sattelite view, pipeline is progresses between input and output.

400px

Here in game we talking about Assets aspect, mostly!

In real world, converting-processing data and assets also require amount of times, efforts and cause headaches, almost comparable to making data and assets.

Converting

Converting between things is a hard problem:

  • Semantic: “things are different “in contexts.

  • Incompatible: Converting almost one-direction only. Converter programs sometime not reliable and not support your data

  • Hidden: Some format is unknown. Some require commercial and $$$

  • Fault-tolerant: Currently almost asset pipeline is easy to fail and do not support recovery.

Processing

Processing again is require a lot power:

  • Time: Did you ever generate lightmap or PVS? - It may take a long long wait and easy to fail.

  • Power and units: Did you ever render a movie? - It may require a render farm.

  • Connections: Is there anything has to transfer between units? - It may delay the whole progress.

Innovations

AtomExAsset try to leverage pipelines from ideas inspired:

From Preon

Bit stream language

From DataTurbine

Real-time data over network

From Distributed computing

http://storm.incubator.apache.org/ -

From Other CCDs and Engines

3DSMax and Autodesk programs: Render farm integrated.

Blender: DNA structure

Unity: Metadata and SVN integrated

Multi sources & Multi targets

First look

Slides

Architecture

Supported sources & targets

Quickstart

Unified Format? How about NO

“Unified Format (use one format to encoded, decoded all kind of assets) is actually a nice idea but it’s not real useful in real life situtations (or not even possible?)

AtomExAsset in other hand has unified pipeline via: Codecs, Flows, EntryPoints. Its “unified data are actually a temporial data which has meta-data embeded.

Temporial scene data

Codecs

Models

Textures

Animations

Basic usages

EntryPoints

EntryPoint is a higher abstract level of AssetKey where we accept the fact that Assets is not actually separated but reference in nested way, via each other and form a topology. We are talking about batch solutions which are very popular in real-life gamedev, and a way to integrate the flow of assets to the normal pipeline…

A lot of AAA games of big company relied on packed and streaming assets (online, from disks..). This assets usually get loaded by chunks instead of a whole at a time, make it possible to process as fast and smooth as possible.

You can see one simple example of the situation when:

  • We reference to a Texture assetkey of a single Tile: assetManager.load(“tile1.png);

  • We later make a texture atlas of Tiles: tiles.png

  • How can we reference to the original tile the old way, ignore the fact that it got batched!?

Texture atlas for ex and all kind of batching assets (pack, atlas, uber …) are techniques to optimize/boost load time and real-time performance. Obfucasion, encoding add an extra layer technique that hide the real data from the back-end user; who shouldn’t touch that data and modify them.

Also the always processing nature of the the asset in Atom pipeline require “dynamic entry point which AssetKey’s abstraction is not enough. EntryPoint and Flow are two new concept in the playground that you should take time to get familiar with.

Flows

J3A

j3a (see, it looks like j3o) stand for “Alternate Automatic Assets is not actually format, but a meta-data or entry point in the asset system. One can use .j3a as entry point to load what ever he want with just the name, for ex:
 assetManager.load("monkey.j3o")

is equal with:

 assetManager.load("monkey.j3a")

but the later has extra effects:

  • It put a update watcher over the entry point

    • the file in filesystem

    • if you has config for that entry to “link to another remote point (git, remote asset central), it actually manage the linkage for you

  • It manage the flows of the loading progress of that entry

  • It manage the avaiablility, validation, necessarility of that entry if you are in a streaming scenario

  • It let the assets pipeline fault tolerant.

    • So if the entry point is not available yet, you has a place holder util the file is available. The “holding back effect also can be set if need

    • If the request to the entry point actually timeouted, cached assets are used

Usage along with the "official" asset pipeline

You can see the Atom’s asset pipeline as a replacement of the official one. In fact, you can also let them work together seamlessly because Atom pipeline just bypass JME3’s assetManager in a few special case.

“

Way1 - Atom over JME3: Put assetManager under an entry point, let call it “SEP - StaticEntryPoint.

 assetManager.load("SEP\")

Way2 - Atom with JME#:

 assetManager.load(".j3a")

Documentation

Write encoder & decoder

Models

Textures

Animations

Basic usage

Preon reference:

http://preon.codehaus.org/preon-binding/apidocs/1.1-SNAPSHOT/nl/flotsam/preon/codec/package-summary.html

Manage dataflow & turbine

Server & Nodes

AtomExAssets ultimately use Building tools and Framework to help Java developer doing Game assets!

Beside of Defacto of the building tools: Ant & Maven, the new rising star Gradle. AtomExAssets also use the powerful framework:

http://www.go.cd/

home-image1.png