Indirect3D

Overview Downloads Screenshots project's home

Concepts

These are concepts without guts. Maybe something is missing

Indirect3D objects: They are implementation of IIND3DObj interface(it's a COM-like interface). They may be either statically linked to program or placed into DLL, that will tell about them and provide construction mechanizm(via exported procedures). Sometimes here they are called 'components', but there is no difference between this two terms.

Hierarchy: Objects are managed hierarchycally - they are attached one to another to form something like a tree. Object's interface methods provide a way to attach object and also a way to get inforamtion about "parents"(objects to which this object is attached) and "children"(objects that are attached to object). Objects may be linked almost arbitrary, so one button may have 2 parents, and it will be rendered in both. Typically object does something with it's children: visible objects render themself and their children, non-visible(movers, recolorers, morhpers) change their children.
Main in hierarchy is root(Renderer). It handles interaction with application - renders object on it's request, informs other objects about moseclicks and keypresses, passes events, provides component creation mechanizm, does memory cleaning and some other things.

State: Indirect3D Renderer keeps STATE, which is a tree in which different values are stored. This tree is dynamic - any component or extension can place it's own values there. And any other component or extension can find specific value in tree if it knows it's id(that id should be given in specification for value).
Values are divided on 'static' and 'dynamic'. Static are rarely changed(and typically they arent changed during rendering). Dynamic values are typically changed during rendering, they use push/pop mechanizm of changing.

Lifetime cycle: There are two kinds of attaches - normal and weak. This kind depends on object kind. 'Weak' objects are helper objects, like movers and recoloreres. Object will be destroyed when detached from all non-weak "parents"(so it doesnt take in account weak objects - if button is no longer rendered, it will unlink from 'blinker' automatically). Standart COM reference counting is used, but object may unlink(detach) from all other objects at any time. However, some references on may stay existing(for example, if material was used, it will not be destroyed until all objects that use it will release it).

Rendering of hierarchy is done recursively - each object renders it's children(if it's 'visible').

Materials: Each object has 4-component color(ambient, diffuse, specular, emission) + shininess value. Each color component may be used or non-used. In addition it has material field(shader). When this field is nonempty, object calls material's methods on start and end of drawing to enable/disable textures or other things. Material can also say component to render itself several times for multipass algorithms.

Event model:
Each object has a list of 'events' and 'triggers'. They have name and associated id. Event is what can happen with object(like OnClick for button). When it happens(button is clicked), 'message' with id that is associated with it is created and posted in 'message list' in STATE. That 'message' can have an 4-byte data, typically pointer on sender. Trigger is what object can do in response on message(like 'Enable', 'Destroy', 'Goto'). When ProcessMessages is called(it's called recursively, like Render), objects scans message list for messages with same ids as it's triggers. If there are such, trigger handler is called. After all objects process their messages external message handler is called. After that list of events is destroyed by renderer.
For example, we have a button which might be in 'pressed' and 'unpressed' state. It has triggers 'press' and 'release' and events 'mousedown' and 'mouseup'. If we set same MsgId to 'press' and 'mousedown' and same to 'release' and 'mouseup', it will work properly - 'mousedown' will cause 'press' and 'mouseup' - 'release'. Using triggers many things may be done without programming.

Properties: Each object can have list of named properties. Property may be of ordinary type(integer, boolean) - with ordinary property editor, or custom type - with custom property editor(which is dialog called by procedure). Properties can have static or dynamic size. Among predefined types there is an object type - a reference on ind3d object.
Any properties can be stored/readed by streamer.
Propertie's 'name binding' allows streamer to work with different versions of object, which can differ by it's properties. Even changing properties in runtime is allowed.

Streaming:Any object can be stored with it's properties/events/triggers. Relations between objects can also be stored. If all objects are implemented correctly, there will be no difference between stored and loaded scene. Only modified properties/events/triggers are stored. Additional info can be also stored in stream. FastFruit implementation writes there Download file information and internal editor's event names.
Stream format can can be also used for scripting(language for this scripting is called Nabla and is now being developped. Nabla compiler can be also used to write scenes or representing them in human-readable format).

Services: Indirect3D services are special interfaces that are registered in renderer's ServiceList and can be retrieved by GUID(unique identifier). They can implement different features and extensions.