Link

1. Nodes

Modular node-based authoring editor

Designed to support also large and complex projects, the authoring editor and run-time are based from the bottom up on a open graph architecture, combined with prefabs and templates.

For example, 3d objects may be hierarchically linked, animations are organized in a hierarchical animation blend tree, commands and events flow from sensors to scripts and animation controllers, entity definitions are re-used and adapted.

The directed graph may have cycles, required for example for defining command and event flows. To make it more simple for the user to organize many nodes and their relationships, the authoring editor organizes nodes in a hierarchy.

Conversion into an optimized run-time graph

	Live conversion		Loading or dynamic instantiation
Authoring editor nodes		Run-time descriptions (optionally persistent)		Optimized run-time object graph

For performance reasons, the run-time of Shark 3D does not directly operate on authoring editor nodes. For example, if the run-time would directly evaluate the nested prefabs, this would degrade the run-time performance significantly.

Instead the authoring editor converts its graph into actor and component descriptions for the run-time engine. These descriptions are optimized for the particular run-time. While editing, these descriptions are created only internally in memory. But the descriptions can also be packaged into a file, for example for shipping a game without the authoring editor.

The run-time engine then uses these descriptions to create, connect and configure actors and engine objects, including run-time dependency graphs. In the simplest case the run-time object graph is just an instantiation of the descriptions. However, as soon as you instantiate elements dynamically, for example a dynamic number of characters in your scene, the run-time object graph may look quite different from the description itself.

While editing, these conversion steps are done live on the fly updating only parts of the descriptions and run-time object graph as needed.

Accessing the run-times belonging to a node

When nesting prefabs or when dynamically instantiating prefabs, then many visible run-time objects may be based on the same editor nodes.

For example, you may have defined one character prefab containing a sensor volume or animation controllers. If you have directly or indirectly instantiated the character multiple times in the scene, then each character instance has its own sensor volume instance at its particular position and its own animation controler state.

In the editor you can choose which run-time instance you want to inspect live, see the current run-time values, and send commands to it. For example, you can inspect the animation controller state and trigger the animation of a selected character instance.

Extensibility

All nodes and their conversion into run-time descriptions instantiating low-level components are defined in modules and can be easily extended.

Link

2. Performance

Optimized for performance

Shark 3D is designed for multi-threading from the bottom up. The whole multi-threading design is optimized for performance. It avoids synchronization overhead as far as possible, and avoids that multiple thread access shared data.

Platform specific code and optimizations

Shark 3D has specific backends for each platform. Each backend provides platform-specific features and platform specific optimizations. In addition, special attention is paid to memory optimization on consoles.

Console specific code is not limited to console specific backends. Instead, every source code file may contain console specific optimizations. For non-console SDKs, console specific code is completely stripped off on per-line basis. By this, console specific optimizations are not limited by cross-platform abstraction layers.

Link

3. Streaming and background loading

Multi-threading from the bottom up

The whole Shark 3D uses a multi-threading architecture from the bottom up. As one benefit, you can easily load scenes, levels and world parts in a separate thread while Shark 3D is running in the foreground.

Easy to use

Loading level and world parts in the backgroud is very easy for the scripter: With one script command, you can load a level or world part. If loading has finished, you get a notification you can again handle via scripting.

Smart resource management

If world parts re-use the same resources, it is not necessary to duplicate these resources. Due to the integrated multi-threading architecture of the Shark 3D core, world parts which share resources like objects, textures, and shaders can be accessed by multiple threads. This can safe memory siginifcantly.

For example, when loading a new world part in the background, the world part may use a texture which is already in usage by the renderer in the foreground thread. The resource manager handles this situation smartly without allocating the texture a second time.

Swapping world parts in the background

You can not only load but also save world parts in the background.

Effectively you can swap in and out level parts of an unlimited large world. When swapping out a level part, the whole state of each level part can be written to disk and can be loaded again.

Huge persistant worlds without loading screen

As result, you can create arbitrary large persistent worlds. The player can explore these worlds without loading screen.

Link

4. Renderer

Complex materials

Accurate per-pixel lighting and shadowing, editable by the shader editor, provides realistic looks of different kinds of surface materials.

Advanced lighting by real-time area lighting

A real-time full scene light source may be not only a point light source, but also an area light source generating extended soft penumbras.

As in reality, the penumbra width and shadow sharpness vary depending on the distance from the occluder and the shape of the light source. At the occluder, the shadow edge starts sharply, getting more and more soft with gaining distance. For example, a rectangular ceiling light casts corresponding full scene soft shadows in real-time. Objects truly stand on a floor without floating effect.

Such techniques are implemented in a highly optimized way, using tricks and aggressive approximations at the right places.

Consistent real-time full scene soft and hard shadowing

All objects in the world can cast shadows on all objects, including self-shadowing and penumbras. Furthermore, all objects in the world including characters and the light sources can be dynamic. The 3d scenes look more realistic and get more depth. Especially real-time full scene soft shadowing increases realism significantly.

In contrast to simple shadowing techniques or techniques relying on precalculated data, Shark 3D lighting and shadowing looks consistent. For example, if a dynamic character is partly shadowed by some static pillar, the shadow of the character vanishes correctly within the shadow of the pillar. Also dynamic objects cast shadows onto other dynamic objects. Thereby, shadowing looks realistic and natural.

Different kinds of light sources

Different kinds of light sources provide various kinds of lighting effects. For example, projected textures can be used for example to add projected spot lights.

Avoiding artifacts

Shark 3D provides techniques that are designed to work as robustly as possible avoiding artifacts.

For example, all various variants of shadow mapping have the well-known in-principle aliasing limitations. Typical problematic situations are long distance views when looking into the direction where the light comes from. With Shark 3D you can get nice full scene soft shadows without artifacts also in such situations.

A different aspect of avoiding artifacts is for example render-to-texture in conjunction with antialiasing, which sometimes causes subtle issues and requires special care to avoid artifacts.

Combining features

Due to the modular structure of the Shark 3D shader system, real-time full scene shadowing can be combined with other rendering features in a flexible way.

Cinematic rendering

Cinematic rendering techniques increase realism significantly. This includes for example:

• HDR (high dynamic range) rendering
• Post rendering effects, for example blooming

Outdoor rendering

Use large worlds and wide open terrains. This can be combined with the generic streaming technology.

Reflections and mirroring

The standard shader components of Shark 3D support a wide variety of reflection and mirroring effects. This includes reflections and refractions of approximately planar surfaces or using dynamic environment mapping. Mirrors can be transparent and opaque, static and mobile. It also includes distortion effects like for example the standard case of water surfaces with animated ripples.

Special effects

Standard modules provide features like the following:

• Particles
• Fog
• Import of precalculated lighting
• TrueType Unicode text rendering
• 3d text: Extruded 3d meshes including bevels and mapping coordinates from TrueType Unicode text
• Video files on textures
• Many other features

Performance optimizations

Shark 3D is highly optimized for rendering as many details as possible. This includes:

• Performance is a core aspect when selecting and developing rendering algorithms. Performance must be good in complex scenes of real-world projects.
• Locally optimize all performance critical code.
• Executing per-pixel and per-vertex work on the GPU using platform specific code.
• Optimizing bandwidth by taking advantage of console specific data paths.
• Optimizing bandwidth by storing vertex and index data in GPU memory or GPU accessible memory optimized for the particular platform.
• Platform specific mesh optimization. Optimize triangle and vertex ordering to take best advantage of vertex caching features of the particular hardware.
• Other platform-specific optimizations.
• Other portable optimizations.

In practice, this means that in most situations Shark 3D is not the bottleneck. The limiting factors is the hardware itself and highly optimized platform specific low-level code doing the hard work. As a supplementary effect, on PCs Shark 3D can take advantage of better hardware and better drivers automatically.

Giving control

State changes are expensive. In addition, ordering render tasks in the right way has a huge impact on performance. Especially for complex non-local render effects unfortunately, there are no simple generic rules for best ordering of render tasks. Therefore Shark 3D gives the shader programmer detailed control of ordering render tasks.

Modular renderer architecture

You can easily create new nodes for the shader editor.

This includes using multiple rendering passes, multi-texturing, parameter calculations, shader animations, and much more.

Another feature of configuration is to define different rendering techniques depending on the available hardware. Depending on the presence of particular 3d-card features, one of several shader variants is selected.

Also new shader components can be included into a Shark 3D based application simply by configuration.

Shader modifier components

Multiple shader components may be combined to a compound shader feature, which can be then exposed to the designer in the shader editor. This can be done without having to change C++ code.

For example, a mirror is not just implemented by a single shader. Instead, at least two shaders work together. These two shaders build a compound shader, which is assigned to the mirror object. The first shader component implements the mirroring functionality. This shader may for example generate a texture containing the mirror image. The second shader component is used to render this texture, and possibly to apply additional effects, for example distortion. Thereby, the mirroring feature can be combined with other features provided by different shaders. The mirroring node in the shader editor takes care of correctly combining the mirror component with other components.

Shader animation

Any number of independent animation slots can be passed to the shaders and shader programs. The shader animation technique is integrated completely into Shark 3D networking.

For example, a sensor volume may start and stop a pixel program shader animation. The animation may be controlled by the server, but is executed completely on the client. Such features can be implemented fully on a configuration level needing only few configuration entries. There is no need for any C++ code or scripting code.

Each animation slot can be configured in different ways. First, it can be a simple animation, which is played locally on the client automatically, for example for decorative shader animations. But it is also possible to control an animation slot by the server, taking advantage of all advanced animation techniques of Shark 3D, including server-client optimizations and interpolations.

As a very simple example, you can write a shader blending two textures into each other controlled by a script on server-side. All this can be done by configuration without any line of C++ or script code.

As another example, you may write a customized shader for an energy-protected door in a game using animated shader programs. This shader may use one automatic animation slot for a decorative energy fluctuation animation, and a second animation slot for fading between an open and closed state of the gate, which is controlled by the server. Also this sample can be implemented without any line of C++ or script code.

Target-platform specific optimizations

Consoles and PC, but also different PC 3d hardware have different hardware capabilities. Shark 3D consistently uses the following philosophy: Shader sections that are the same on multiple platforms are usually defined only once; shader sections that are target platform specific can be optimized individually.

There are special shader components that define different shader sub-sections depending on the current hardware. This can be done completely on configuration level. In the extreme case you can define separate shaders depending on the current 3d hardware and current application configuration.

Shader programs

Using shader programs themselves, for example to implement materials, is easy. However, all advanced rendering effects require a smart combination of shader programs combined with suitable C++ code. For example, real-time full scene shadowing effects cannot be implemented only on shader program level. In general, advanced rendering effects have many interactions with other modules, for example scene management, lighting, shadowing, and animations.

For that purpose, we designed a universal shader program mechanism that is smoothly integrated into the Shark 3D shader and animation system. The developer can combine the advantages of the configurable shader system, lighting and shadowing modules with shader programs of the GPU, opening for you the door to new rendering effects.

Importance of an open renderer architecture

One aspect is that a shader system makes it easily possible to create new shaders by plugging together individual functionalities. However, on this level you are limited to the sandbox of the renderer features provided by the particular shader system.

Advanced projects typically come to the point where the built-in rendering features are not sufficient, even if you can combine and configure them in a very flexible way.

Therefore it is very important that the renderer is not a closed system. Instead, the renderer must be very modular on C++ level, too. This makes it possible to add completely new rendering techniques in a modular way without having to modify or even rewrite the renderer.

Advanced rendering techniques work in very different ways

A real open modular architecture is especially important, because there exists no right rendering technique for every situation. For example, there exists a more or less unlimited number of different soft shadowing techniques. Different rendering techniques often don't differ only locally in some shader programs, but differ in more fundamental, global ways. For example:

• Objects in the scene may have to be enumerated by different culling rules.
• Render targets may have to be used in different ways and at different times.
• The program flow regarding scene traversal and rendering into render targets can vary.
• Different global rendering recursions using different modes and parameters may be needed.
• Shader programs may need very special parameters.
• Others.

And depending on the particular project, and often even depending on the particular level or scene, you need to have the freedom to easily and quickly implement a particular special rendering technique.

The Re-entrant Modular Shader System™

In Shark 3D all local and global rendering functionalities are completely moved into independent, decoupled shader components. The core renderer does not know anything about particular global rendering techniques.

Instead, all advanced local and global rendering effects described above and included in the Shark 3D SDK are implemented in separate, independent shader modules. And new advanced local or global rendering features can be implemented in a modular way without having to change the core rendering code of Shark 3D.

Basically the core renderer loop does nothing more than activating shader components. And shader components communicate using generic interfaces that are not limited to particular global rendering techniques.

Implementing features in a clean and modular way

For example, in Shark 3D, the core renderer does not know anything about shadowing at all. Instead, all shadowing techniques - whether plain shadow maps, plain shadow volumes, or more sophisticated techniques requiring sophisticated render target juggling - are implemented by independent shader modules.

Another sample is that the core renderer does not know anything about mirroring. Especially, mirrors are not hard-coded in the renderer. Instead, a mirror is implemented by an independent shader module.

Combining different advanced rendering techniques

Another important aspect is that for high-end projects you often have to combine multiple different advanced rendering techniques at one time. For example, you need to combine different lighting and shadowing techniques within one scene.

This means that for example that different scene traversals and different ways how render targets are used are active at one time.

Shark 3D naturally supports this. You can combine different advanced rendering techniques in an orthogonal, modular and clean way.

Analogy to non-real-time rendering

Advanced non-real-time renderers don't only provide a shader system where you can create shaders by assembling individual rendering features. In addition, a flexible extensibility is crucial. Every advanced non-real-time renderer has very generic interfaces to plugin new rendering techniques.

The Re-entrant Modular Shader System™ of Shark 3D brings the same power to real-time rendering. There is no renderer with fixed functionality anymore, which only can be enhanced or customized by modifying the core renderer. Instead, the renderer is completely modular. This opens new unique possibilities for high-end projects.

Shader linking

Complex compound shaders easily consist of a dozen shader components. To keep control over complex rendering effects, Shark 3D provides a smart shader linker: Data like render targets, textures, geometry handles, and animation states are bound using human-readable identifiers. Depending on the available hardware, the shader components are linked together for optimal execution performance at run-time.

Visible representation of abstract objects

Shark 3D uses a clear separation between abstract objects and their graphical representations. An abstract world state can have no, one or multiple graphical representations in different physical graphical contexts. Each physical context can have no, one or multiple viewports that share the same hardware resources.

These relationships are managed automatically. For example, a graphical context may be re-created due to a fundamental configuration change. Or a new graphical context may be connected to an existing abstract world state. Then the corresponding context resources are created and uploaded automatically. If necessary, this automatically includes reloading such data from disk. For example such data may be texture data, vertex buffer data and index buffer data.

Renderable objects

If you want, you can write a render component that fully bypasses the complete shader system. Just register such an object directly with the renderer object database, and the object will get calls for rendering.

Multiple 3d states and viewports

An unlimited number of unrelated or related 3d states and viewports can be displayed at the same time on the client. For example, this may include a main 3d world, main 3d sky, and a display. All features available for the main 3d world can be used also for the sky.

Backends

Supported backends include:

• Direct 3D
• OpenGL
• OpenGL ES
• Proprietary console hardware (see also platforms)
• Other backends

Pluggable visibility components

Depending on the particular situation, you can add a culling component for efficiently culling non-visible world parts and objects. This automatically includes static and dynamic world parts and objects. This includes not only classical objects, but also light objects and effects.

Support of advanced rendering techniques

World management needs to work with advanced, cutting-edge rendering features. A very simple instance is the question of finding out which static and dynamic objects are influenced by a light source. This can be answered by the object database in an efficient and elegant way. Different kinds of rendering effects like advanced shadowing and mirroring effects require to access and enumerate objects in a different way. Especially new non-trivial rendering effect requires a new way of accessing the object database. Therefore, in practice a generic object database that is designed for flexibility from the beginning has turned out to be an essential foundation.

Shark 3D provides a modern basis for these modern requirements. This includes, among others features, that Shark 3D provides a clear separation of the Shark 3D visibility system from a generic object database. The object database provides generic object enumeration that may or may not be related to visibility aspects. Another important aspect is that the object database is separated from the logical scene graph. More importantly, the database approach provided us with the foundation and freedom we needed to push the renderer without hitting limits all the time.

Link

5. Animation system

Overview

Shark 3D offers a universal animation and object dependency system with built-in networking support.

The animation system includes multi-layer skin-deforming skeleton/bone animations and universal hierarchical animations and combination with physics as special case of the universal animation system.

Multiple kinds of animations

Shark 3D provides standard components for different kinds of animations. This includes:

• Imported path animations
• Path animations defined in the authoring editor
• Mesh morphing
• Skeleton-based skin deformation
• Hierarchical animation
• Interaction with physics
• Other features

Multiple sub-objects skinned by one skeleton

A character mesh animated by one single skeleton can be divided into multiple sub-objects. Each sub-object can have different shaders and can be enabled separately.

The skin deformation of one single mesh can be also driven by different groups of bones which are driven by separate animations.

Any number of animation layers

Any number of animation layers can be played and faded in or out at the same time, at different times, or overlapping time periods, controlled by one or more scripts.

Fading and blending of bone-animations

Animations can be faded and blended. For example, you can smoothly fade in and out the "run" animation. The "run" animation itself may be started at the same time, continued playing, or stopped immediately. You also can blend between two or more animations. This is a special case of fading multiple animations in parallel. Fading animations allows you to eliminate animation state "jumps". Every animation state goes into another animation state smoothly.

Animation groups and group fading

Animations can be grouped together to groups having common fading.

Combination of multiple bone-animations

The Shark 3D animation system allows a non-linear combination of several animations in real-time. Combining animations correctly respects bone hierarchies. For example, suppose you have one animation also rotating the arm, and another animation moving the fingers of a hand. The animation of the fingers has to be rotated according to the current arm rotation. Shark 3D plays the finger animation correctly for every rotation state of the arm.

Any number of attachment points

Skeletons can have any number of attachment points, e.g. for weapons.

Manual joint control

Skeleton joints can be controlled explicitly by custom components.

Re-using animations for different skeletons

The same bone-animation can be shared between different skeletons. The different skeletons must have the same bone hierarchy, but can have different extensions and base angles. This saves memory when having several different characters.

Hierarchies

Hierarchical animations are a very simple special case of the universal Shark 3D animation system. But objects are not restricted to usual hierarchical dependencies, but may basically depend in any way from other position and animation states.

Optimization

The universal object hierarchy system internally is optimized to automatically minimize calculations using several optimization techniques. For example, as long as the position of an attachment point of an animated character is not needed, it is not calculated. Similarly, if an animation layer is not played at the moment, it does not consume calculation time. Such kinds of optimizations are performed basically for every object in the object hierarchy system.

Character walk animation system

Advanced features include for example a character walking animation system. This component can automatically generate suitable walk animations for walking in any directions including diagonal sliding.

Adding custom components

You can add custom components providing new functionality or for replacing standard components.

Combination of custom components with standard components

Your custom components can work together seamlessly with standard components. Especially, standard components can fetch data from custom components. The only requirement is that the custom component implements a corresponding standard interface. These standard interfaces are designed to be generic and as flexible as possible.

Link

6. Audio

Smart world management

Sound sources are managed in an object database. When updating sound, not all sound sources in the level, but only hearable sound sources cost computation time.

3D sound

The sound system completely works in 3d. The 3d sound can be played on various backends, including for example on 5.1 systems.

Physics sound

You can combine the sound system with the physics engine and automatically get for example collision and sliding sounds.

Standard backends include:

• Console hardware.
• DirectSound3D.
• OpenAL.

Link

7. Physics

Flexible collision detection

Support for mesh geometry (convex and non-convex), primitive geometry (e.g. spheres), and a combination of both.

Various types of constraints

Including ball-and-socket, hinge and hinge-two, "keep-vertical", and many more.

Generic motors

For example the motion of a motor can be defined as path in Max™ and controlled in a flexible way by scripts.

Player control

This includes for example a special component for player movement in air or on ground.

Skinning

Rigid body skeletons can drive mesh skinning for rendering. This can be used for example for faked bendable objects like trees including rag doll effects.

Optimized for large worlds

Physics computation time does not depend on the total number of objects in the level, but only on the number of active objects in the level. Inactive objects away from active objects cost no time at all (except some minimal overhead for collision pair detection, where inactive objects cost the same as passive environment).

Compact collision geometry storage

Internally, collision geometry, especially mesh collision geometry, is stored very compactly and optimized for efficient access.

Smart collision database

This allows for a very efficient collision object pair detection also in large scenes and levels.

Collision and friction sound

A standard module automatically generates collision noise and friction noise. This module provides several possibilities for generating different sounds depending on material.

Internally, the physics noise generation uses several optimizations. This includes for example using only one sound source for multiple nearby contact points.

Integrating networking

You can enable physics objects to automatically synchronize via network.

Pluggable custom physics

You can also plug in your custom physics and combine it with existing Shark 3D features, like for example automatic sound generation.

Link

8. Networking

Easily create multi-user applications

Networking can be used with minimal development effort. You do not have to write complex networking code. Shark 3D provides many standard networking features making it easy to add networking support to your application.

You can access these networking features easily at high-level. This includes multiuser support, connection management, easy server-client communication, and managing several scenes or worlds on one server.

Transparent networking

Many standard components support transparent networking. This means that you just manipulate a component on server side, and the component can automatically update its state to all clients.

For example, simply control the animation controller of a door by a script on server-side, and the animation controller automatically will replicate its state on all clients and play the same animation. The only thing you have to do is to register the animation controller for networking.

This also includes initializing a new client correctly. This means, if a new client has connected to the server lately, the animation controller is correctly initialized, for example when currently playing an animation.

Server-side and client-side execution

You have full control where each action is performed. This includes:

• Execute it on the server only
• Execute it on the client only
• Execute it both on the server and the client
• Execute different actions on the server and the client
• Other mechanisms

To reduce network traffic, the server may send only a simple command to all clients, and the clients execute complex actions locally without causing bandwidth.

Of course, standard components have suitable implementations. For example, animation controllers only send animation triggers via network and execute the animation itself locally.

Lag suppression by client controlled components

Components can be controlled easily by the server or by a client.

For example, typically user input from keyboard or mouse moves a player and triggers player animations (e.g. a walk animation). In this situation the player and animation components may be directly controlled by the client where the user input is generated. As consequence, the movements and animations are executed immediately without network delay on this particular client itself.

Using the above transparent networking features, the player actions can be automatically updated to the server and then to the other clients.

Flexible 3d state management

Multiple 3d states can be synchronized via network. For example, typically there is a 3d state for the world itself and for a sky.

Easily sending commands via networking

By adding a particular standard component, you can easily send high-level scripting commands via network at any place.

Loading or creating many objects with minimized network traffic

Shark 3D automatically uses smart techniques to reduce network traffic in case of level loading or creation of complex objects.

For example, the network traffic caused by entering a new level does not depend on the number of objects which are synchronized via networking. Internal object IDs do not have to be allocated and assigned via networking. Instead the networking traffic only depends on the number of objects which do not have the default state and so have to be updated. In practice, this means that typically the network traffic at load time is constantly small, independent from the complexity of the world.

Easy high-level networking management

Networking can be managed easily at high-level, for example by scripts. This includes for example:

• Connection management
• User management (including actions which have to be performed when a new user joins a session)
• Level management
• Many other features

The standard networking framework can be easily modified and extended in any way on a high abstraction level. Components can be modified and new components can be added simply by configuration or scripting.

Heterogeneous networks

For example, Windows™ clients can connect to Linux™ servers.

Easily adding custom networking support to your custom components

You can easily add networking support to your custom components by implementing the corresponding standard interfaces.

Full control on byte-level

When implementing networking support for a particular component, you have full control over the network protocol on byte-level. This includes, you have full control over:

• State synchronization algorithms (including decision between server-client, peer-to-peer or other approaches)
• Interpolation algorithms
• Update rates
• Update point-of-time
• Bandwidth
• Component creation and destruction management
• Many other features

Shark 3D provides a standard component for over-all component networking management. If you want you can modify or replace this component. So, if needed, you have full control over your networking protocol. This includes for example the protocol how components are addressed.

Data compression

A standard component provides network data compression. The compression works not only for individual networking packets, but across networking. This means that if the same data is sent in multiple packets, this data can be compressed very efficiently in the second and further packets.

Working together with other applications

Shark 3D provides standard components for communicating with other applications using a simple text-based protocol. For example, arcade systems may be easily controlled via TCP by a UI written in Visual Basic running on a separate computer. The Shark 3D based application easily can evaluate commands received via network on high-level without complex protocol parsing and without needing C++ code.

Link

9. World management

Generic object data base

The generic object data base of Shark 3D provides a basis for various Shark 3D components. This includes for example the renderer, collision detection (if not using an external physics package), sound management, and sensor objects. The Shark 3D object database allows efficient object enumerations in a flexible way.

For example, a simple object enumeration could be: "Which other objects in the whole world are less than 10 meters away from this object?" A simple query could be for example: "Which object in the whole world is closed to that particular object?"

Instancing

Shark 3D thoroughly supports and takes advantage of instancing. Especially on consoles, instancing is a mechanism to build complex scenes and levels needing a minimal amount of memory. Instances can be defined in multiple ways:

• Define multiple instances of the same object (e.g. trees) already in your 3d modeling tool, for example 3D Studio Max™.

• Define positions in your modeling tool, and create instances of objects (e.g. characters) at these positions by an actor component in Shark 3D. See also the Editor for details about creating such components.

• Create instances of objects by C++ code.

• Others.

Multiple instances can have different textures, shaders, and animation states. These states can be also switched at run-time by scripting.

Link

10. Persistence and serialization (saving application states)

Universal and flexible serialization mechanism on C++ level

At low-level, Shark 3D provides a universal state serialization mechanism for saving and loading application states to disk.

Serialization can be also implemented for existing external classes which were not prepared for serialization.

Automatic serialization of high-level components

At higher level, all component states are serialized automatically without resulting in any extra work for the designer. This includes for example Perch™ script states and Python™ object states.

A developer who implemented new low-level C++-objects can integrate them seamlessly into the Shark 3D serialization mechanism.

Link

11. Resource management

Resource manager abstraction

All resources are loaded from an abstract resource manager. This resource manager itself can be assembled from multiple components. For example depending on resource name prefixes or directories, resource requests are dispatched to different child resource managers. Different resources may be fetched from different child resource managers.

Resource manager abstraction

Child resource managers include for example the following:

• Fetching resources from individual files
• Updating resources via TCP (see also live editing)
• Fetching resources from a packfile
• User-implemented resource manager components
• Other standard resource managers

Pack files

An useful resource manager component is a standard pack file reader. A corresponding packfile tool packs files into a pack file.

• The packfile layout can be optimized for maximum read performance without seeking.
• Each individual resource of a pack file may be compressed or stored plain.

Link

12. Perch™ scripting

Perch™ scripting language

Perch™ is a simple proprietary scripting language for Shark 3D.

Simplicity

Perch™ is seamlessly integrated into Shark 3D. Perch™ is designed to be easy to use by level designers. Perch™ has a simple syntax and is easy to learn.

Robustness

Perch™ is designed to be as safe and robust as possible. For example, you cannot create memory leaks or dangling object references.

Full Unicode support

Perch™ consistently uses Unicode. Internally, a compact UTF-8 representation is used, avoiding wasting of memory.

Live editing scripts

Perch™ supports Live editing the running console and PC game seamlessly. You can modify scripts while the game is running.

Compiled into efficient bytecode

Perch™ is compiled into a compact bytecode. This bytecode is executed efficiently by the Perch™ run-time bytecode interpreter. In addition, also the Perch™ interpreter itself and its run-time memory usage is very compact. This is especially important for consoles, where memory is a scarce resource.

Link

13. Localization and Unicode

Consistent Unicode support

Shark 3D consistently uses Unicode. This includes supplementary characters.

Text resource files

Configuration text resources and other text resource support the following Unicode codings:

• UTF-8
• UTF-16, big-endian and little endian, including surrogate code points
• ASCII, Unicode characters can be escaped as ASCII character

Localization resource files

Support for Unicode language text resource files makes it easy to port applications to different languages.

Memory representations

In memory mostly UTF-8 is used, because this is the most compact representation wasting least memory, and in practice UTF-8 is not more complicated to work with than UTF-16 due to surrogate code points. When calling operating system calls (for example file system functions), Unicode strings are converted, if necessary, in the format required by the system function.

Efficient binary representation

Shark 3D files can be stored in an efficient binary representation. This format is optimized for fast loading times.

Link

14. Cross-platform development

Multi-platform content

The same Shark 3D features are accessed in the same way on every platform. This means: When keeping platform specific limitations in mind, you can create a multi-platform application and multi-platform content. The same application and the same content runs on multiple platforms.

Taking advantage of platform specific features

The Shark 3D APIs also expose platform specific features. This makes it possible to enrich your applications and your content by platform specific effects and optimizations. For example, you can share your levels between platforms, but create special shaders for specific platforms, taking advantage of proprietary features of each target platform.

Platform specific features can be accessed at multiple levels. For example, you can configure different shaders for different platforms on configuration level. But you can also write completely different rendering effects in C++ for each platform.

Link

15. Component system

More flexibility by an object oriented component object model

To increase flexibility and agility, the Shark 3D is not only object oriented, but also consistently component based.

Components, configuration and scripting

Shark 3D uses an object-oriented micro-component architecture. The functionalities are split into quite small, decoupled pieces.

The Shark 3D component system consists of a sophisticated system of components, interfaces, and messages. The power of the system stems from a well-designed architecture, including all details like choosing the right component interfaces, components, commands, and event flows.

The Shark 3D components are usually assembled by the authoring editor. You can easily new write editor nodes or GUIs assembling the components in a new way. This both includes high-level logic control over network and multiuser management down to shaders and shader components.

The developers can take full advantage of Shark 3D not only on C++-level, but also on a high abstraction level, enhancing productivity significantly.

The component configuration system includes both object properties and command flow between components.

Component composition and encapsulation

A main feature of the architecture is to allow the combination of several standard components and user-implemented components to a new object with a particular behavior. Combining components usually is called "composition".

For example, a character in a world can be combined out of some standard components like low-level walking collision detection, low-animation components, command dispatchers, and standard character scripts, together with character-specific components like special Perch™ scripts. The construction of the particular character can be done completely live in the editor.

No C++ or script code is needed if all necessary components are already available. And if additional components are needed for the character, only these components need to be implemented, without having to modify other character code.

Component composition improves the re-usability of code enormously, especially since the components are universal and not linked to a particular code environment.

Dynamic object trees

A central property of the Shark 3D architcture are dynamic object trees. This includes that object subsystems can be created at real-time on demand, and can be destroyed again. Such factories can create not only single objects, but complete object trees according object patterns.

All this can be done purely on assembling level, without any scripting or C++ development.

For example, in case of a multiplayer game, each time a new player joins the game, a new player composition object can be created using a factory for this object tree.

So all in all, objects are not only changing their states, but also the object structure, number of objects, and relationships are dynamic.

Commands

A central technique within the component architecture is sending and receiving commands. Components are designed to be universal and not depending on a particular environment. Therefore they have to communicate with other components where no details are known at the time the component is developed.

This is achieved by a universal method invocation technique, which is implemented by using the usual technique of virtual functions. This guarantees easiness and efficiency. The crucial point is a good decoupling of components, a sophisticated design of interfaces, standard commands, and standard methods.

The mechanism how components interact by sending commands can be of course configurated on the component configuration level.

Standard project structure components

Standard components include:

• Standard 3d state management architecture
• Standard level management architecture
• Standard game state management architecture
• Standard player management architecture
• Standard mechanisms for players joining or leaving a networking game
• Many other standard components

SAP: Accessing Shark 3D via network

The SAP (simple actor protocol) is a simple text based TCP protocol that offers interactive access to Shark 3D actor components while Shark 3D is running.

Shark 3D offers Python bindings for this protocol making it possible to access run-time objects via network as if they are local objects.

Since the protocol accesses the components with the standard scripting abstraction you can access all such components without having to prepare the components in any special way. The messages you can send using the SAP are the same messages as used internally by Shark 3D when one component communicates with another component or is accessed via scripting.

You can use the SAP for example for writing an application which controls a Shark 3D based application via network. The client can run on the same or on a different computer as Shark 3D. For example, you also can easily write custom clients providing a special graphical control interface for controlling Shark 3D.

Smart dependency graphs

As one of many features, Shark 3D supports smart object dependency graphs supporting delayed evaluation. Some advantages are for example:

• If an object indirectly depends multiple times on the same prerequisite, then the state of the object is not recalculated multiple times if the prerequisite has changed.

• If a prerequisite changes multiple times without needing the state of the object, then the state of the object is not calculated multiple times.

• If the state of an object is not used at all, and if nobody is interested in getting notified if the state changes, then this object does not cost any performance at all, even if the state of this object depends on the changing state of other objects.

Link

16. Platforms

• Windows™
• Browser: IE, Firefox, Chrome, Opera, etc.
• Linux™
• Mobile devices, see here for more information
• Consoles, see here for more information
• Can be easily integrated into other applications, for example via Python/wxPython, ActiveX, or C++

"PlayStation" is a registered trademark of Sony Computer Entertainment Inc. Microsoft, Xbox, Xbox Logos, Xbox 360 and the Xbox 360 Logos are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries and are used under license from Microsoft.

Link

17. Documentation

Shark 3D comes with introduction articles, overview articles, many samples, video tutorials, and reference books.

A clear hierarchy, extensive cross linking and a search function help you to find the information you need.

The documentation is available both in HTML and pdf format. The HTML format is mainly useful for browsing and searching. You can use the pdf format for printing parts of the documentation well formated.