AiW: the what & the why()

Ok, let's take one step back, or better, back to AiW:
What is it and what it does best? And most important Why would you need it.

Alice is a cross platform real-time 3D rendering framework.
A cross-platform software—something that's well known among IT specialist—is a software which is able to work in the same way on several (different) platforms.

Such software is usually obtained by using different interpreters, one for each platform you plan to release onto. However, this means that the cross-platform code is first interpreted and then executed, with a considerable performance handicap.

In the real time software class this is a really bad practice: an optimal performance is crucial to obtain a satisfactory user experience.


Achieving peak performance from underlying HD()

In order to achieve both of these goals (cross-platform and real time performance) we're following a different pattern: we'll write an engine version for each platform and always follow a strict rule:

// "The same input must lead to the same output on all platforms"

This way we can still create a consistent user experience on all platforms—it isn't the code that is cross-platform, is the UX—without being forced to have our code interpreted, thus achieving peak performance from underlying hardware.


AiW Framework()

We like to highlight this part of the product definition, because it substantially differentiate AiW from other off-the-shelf rendering engines: as a framework, AiW can be integrated in brand new or pre-existing native application, bring UX consistency and interactive rendering capabilities where there was none before.


Real time 3D rendering()

This is the backbone of the module, but it consists of a set of small sub-features that deserve to be listed separately


Engine features()

Until now, we've only talked about how to render a given scene… But how can we manage an actual scene, in order to be able to draw it later?

Actually, a big chunk of AiW has just this task: managing the scene.



>_ 21.04.2016 - 14:24:04

[Deferred rendering]
print("A modern rendering technique that pre-computes different aspects of the scene (object depth, surface normals, and albedo color contributions) and then blends them together to obtain the final image.
While requiring more GPU bandwidth this technique ensure that more optimization can be performed, and the data that are calculated are used for other post-processing effects (see further)."

[Bump mapping]
print("The bump mapping technique allows the developer to enrich the details of the scene without increasing the weight of the scene geometry, by just altering the way a given surface interact with the light that brighten the scene.
The scene geometry isn't changed (we still have a square wall) and the texture hasn't changed either (it's still a tileable brick texture), but the right wall is clearly more realistic than the left one. This represent simultaneously one of the tricks that can (and should) be used to obtain a satisfactory real time rendering engine and one of the compromises that must be adopted to maintain a decent frame rate: complete realism is not achievable, but is neither needed, because it can be approximated without compromising user satisfaction."

[Screen Space Ambient Occlusion]
print("The Ambient Occlusion effect consists in drawing some dark areas on the scene, simulating the shadows that some complex objects casts on themselves. A real life example of these shadows is the one casted by the cheekbone of a human face.
By taking advantage of what has already been calculated on the deferred rendering step we can compute the ambient occlusion data directly in screen space, instead of scene space. This reduces greatly the computation cost, especially on crowded scenes, because the number of pixels of the scene is constant between frames."

[Real Time Shadows]
print("As you can guess from the previous images, lighting itself is not enough to give the scene a realistic look: with a good lighting algorithm objects are well colored, but they seem “flat” (because they actually are).
The key to the realism illusion stays in shadows. The first two features have only treated static shadows: these shadows are cast on the object by the object itself, without considering anything of the rest of the scene. In order to provide “real” shadowing to the scene all object have to be considered, each lit object should generate a shadow volume and this should be tested against any shape currently visible"

[Level of Detail]
print("Level of details allow the developer to specify different 3D models for the same object, to be switched depending on how far the model is from the camera. This is useful because the farther an object is from the camera, the less its polygons can be seen clearly, so it's pretty useless to draw a hi-poly model far in the distance.
In fact, this can quickly kill the rendering frame rate if many of these objects are on screen, because everyone of them add its full weight to the video card computation capability, but with so much space free on screen the rest of the scene must be fully drawn as well"

print("The geometry tessellation is a way to obtain more detailed models when other techniques can't be used. Basically, it's an algorithm that enhances the object geometry with more and more polygons, based on how far the object is from the camera. Instead of being premade, like what happens with level of details, these polygons are computed runtime, with fractal mathematics.")

[Key Frame Animations]
print("Apart of the various rendering algorithm that can enhance image quality there's also the possibility to animate the various object that exists into the scene, by the use of keyframe-based animations. Further releases might support other kind of animations (e.g. skeletal animations).")

[Custom Shader Support]
print("Of course some users might have particular needing that a standard shader can't satisfy, thus support for custom shaders is granted from the first release.")

[ECS-Based Scene Management]
print("To correctly organize the scene, we used an Entity-Component-System approach. Every object that exists in the scene is an Entity. An entity can have one or more Components, different from each other, that represent the different capabilities of the entity (for example: a TransformComponent allow the entity to have a position in space, an AnimationComponent allow the component to perform animations, etc.). The actual implementation is enclosed into the various Systems, but the user cannot use them directly and must invoke their logic through the components. This allows the user to abstract the logic by simply assigning the right component to the entities and still obtain the full performance of a centralized logic handling.")

[COLLADA file parsing]
print("In order to manage a scene, the scene must be created first. Seeing that a number of commercial software exist for 3D modeling we decided not to include a proprietary editor, and instead we support the parsing of Collada files, that almost every software is able to produce, in order to import scene geometry, materials and animations before the rendering. This will be expanded in further release, by supporting more file formats.")

[Assisted Memory Management]
print("A performance bottleneck in all software application is the memory management: every time a program request additional memory to the Operating System it has to wait for the new memory to be assigned before it can go on.
This problem can be easily addressed by requesting excess memory in advance, and manage it internally. AiW offers a suite of allocators and other tools (memory tracking, memory tagging, etc) to the user that, once combined into a MemoryArena construct, allow to a seamless memory management. Please note that to grant real-time performance, automatic Garbage Collection is not enabled: you can still be prone to memory leaking or fragmentation."

print("Today all of AiW target platforms run on hardware that includes a CPU with more than one core. The extra cores are useful to perform parallel calculations, but in order to use this parallel calculations power the algorithm itself must be written with certain criteria. AiW allows the user to write part of his logic as a job that will be scheduled into a job queue and, later, executed by a dedicated worker (i.e. a thread). By automating this mechanism we can tune the number of available worker, in order to fully exploit every CPU core with a minimum performance overhead.")

[Physic Simulation]
print("Physic simulation is an important part of a rendering engine: some animations or interactions (like a falling object, or a collision) are better when calculated real time, instead of being prepared by a specialist and then simply displayed.
However, we are aware that writing a physic library from scratch is not an easy task, and take out resources that can be used instead for our core features. The physic laws, then, will be simulated by integrating a third party library into AiW, granting a good simulation level while minimizing the impact on the project planning."