View this PageEdit this PageUploads to this PageHistory of this PageHomeRecent ChangesSearchHelp Guide

Nebula Device

Check out and compile Nebula
Presence on Mangalore Basis
Code Snippets

To Do:

  • Port to final Mangalore Version
  • Implement Tasks (Physics)
  • Port to newest VideoWrapper and use new features of camera control (like exposure push etc.)
  • Implement Tracker Latency (buffering?)
  • Model Office environment
  • Create necessary shaders
  • Finish SH Lighting support

Hints and Tips

For every Nebula Object, that means an object which is derived from nRoot, the Module Name (Buildfiles) has to match the class name!

To Load a script, use "source blabla.tcl" in the console. To get a list of available Commands, use "object.getcmds"
To travers through hierarchy, use "sel object"

Compiling issues
Error messages for multiple symbol definitions might occur because the vrpn/quat/videowrapper libs are compiled with multithreaded dll instead of static. Make sure that this is consistent with nebula!

Save binary .n2 file as ascii
Load model, e.g. in nViewer.exe. Then invoke command on model: e.g. ..directoty.../eagle/.saveas eagle_tcl.n2

Architecture Overview

Every Gfx object has an RenderContext which holds frame persistant information like Transformation and visibility. This RenderContext is then passed to the nSceneServer. When the nSceneServer is called, the objects which were attached to it, are rendered (after optimizations like sorting)

The nSceneServer manages the rendering of the scene and is basicly the Scenegraph. It supports multiple camera rendering for special effects (render to texture).
The nSceneServer has a RenderPath Object, which is a description, how the the scene is rendered, that means what shaders and passes are used.

Deals with the host filesystem. Is created by the nKernelServer. To read from a file, create a nFile object. By using assigns, it is possible to reference to a directory in a more convinient way.

Object System
In Nebula, every nRoot derived Object is called a Nebula Object. They have a unique name, which can be used for scripting, and can be translated into a C++ pointer. Nebula Objects resides in a hierachy, similar to a filesystem. This is called the Named Object Hierarchy (NOH)

The internal scripting mechanism is language independent. The translation is done by a ScriptServer e.g. nTclServer. Any nRoot derived object is scriptable. It also possible to talk to objects vie Network. Scripts can be invoked from the Nebula Console, or called within C++.

Time Management
Time Management is done by the nTimeServer and must be updatet every frame. The class nProfiler is used to measuring time intervals.

Data Types
Every nRoot derived class can used with smart pointers:
"nRef{nSkinAnimator} refSkinAnimator;"

Scene System

A Scene consists of Scene Nodes, which are packed in Render Context and a processed by a Scene Server. At nSceneServer::RenderScene, the Scene is sorted and the render pass is called:
  1. Shader Pass ( specify shader and parameterd, e.g. nMaterialNode::RenderShader )
  2. Light Pass (calculate light to be passed to the shader)
  3. Geometry Pass (update Geometry)

Scene Node
A Scene Node has several member functions which do the necessary computation before it is sent to the render API. The most common Scene Node is nShapeNode.

Since a Scene Node can be used several times per frame, it has to be stateless (for example, no value for velocity of a car). Therefore a RenderContext has to be created for each visual node.

Nebula provides a nCamera2 Class, which contains the projection matrix, and has to be given to the gfx server. The view matrix maybe controlled by the MayaCamControl class, which contains it as a private member. This matrix has to be given to the SceneServer at BeginScene()

A Nebula Renderpath is a XML file describing how a scene is to be rendered. It specifies, which shaders should be used in which order and describes the used rendertargets. The shaders and Renderstates are described in .fx files, the effect files of DirextX.

Contains a renderpath definition of a shader, which is loaded according to the renderpath.xml and by nrenderpath2. E.g. it contains the name of the shader, validates it (make sure that resource is loaded) and has a nShader2 Object as an attribute.

The nShader2 object, wraps the api specific High-Level functions like techniques, setting of textures and shader parameters. It gives access to shader passes.

Describes a RenderTarget for the Renderpath. Basicly consists of a size and name of a nTexture2 object, to which is rendered to.
A new RenderTarget is then created by the nGfxServer2 that means in the common case, nD3DServer. The three supported usage flags are Color, Depth and Stencil, also they seemed not to be used.

Link to this Page

  • Old Projects last edited on 12 May 2008 at 5:33 pm by