Difference between revisions of "Nodal geometry"

From Organic Design wiki
m
(current interface tsructure)
Line 1: Line 1:
 
[[Category:Glossary]][[Category:Nodal Concepts]]
 
[[Category:Glossary]][[Category:Nodal Concepts]]
The nodal geometry (aka layer model) underlies the two fundamental hierarchical layout methodlogies which are the ''polar'' and the ''rectangular''. The general idea of containment applied within the geometrical context is implimented in the form of relativity of child co-ordinates to their parents.
+
The conceptual structure of the initial interface is a 2D layer model (see [[geometry]], but its a bit out of date), where layers are stacked in z-order and can exhibit transparency. Layers are arranged as a tree allowing each to contain a list of ''n'' child layers. The position and clipping area of a layer is governed by its parent.
  
The geometry notion is the base-class of polar and rectangular and as such encapsulates all that they share in common. The polar and rectangular notions are then defined as extending this base-geometry notion in their respective specialised directions. The graphical user interface of a peer is [[Desktop]] which defines the collection of ''widgets'' and can also be seen as the ''generic application'' to be extended by more sepcific application based on requirements fed back from the field of use.
+
The interface uses [[SDL]]'s [[Wikipedia:OpenGL|OpenGL]] context for final rendered output, but composes the root-child layers into surfaces and then transfers the surfaces to OpenGL textures. Later we'll allow any layer to be cached as a texture, rather than only the layers at the root level. This way processing load would be reduced by utilising the large unused resource of texture memory on the video card - usually around 256MB. These cached layer-composites are 32bit having alpha and are called ''[[Wikipedia:Sprites|sprites]]''.
  
# The base geometry
+
The root level layers are hooked in to the reduction loop permenantly and they in turn hook in various children based on redraw or collision queries or metrics updates which need to be resolved. These queries are guarunteed to be resolved by the end of the frame. These queries exhibit workflow and so are passed around amongst the nodes to be processed and passed on again until resolved.
At the most general level the geometry is defining the three dimensions of space. In the nodal model, as in the Taoist and the Advaita Vedanta systems, Time is not treated as simply one of the four dimensions composing the space-time continuum, but all four of them do work using the same method of discrete recursive sub-division.
 
  
The geometry is a sub-class of the [[Nodal Space]] which is in turn based on [[List Space]]. The geometry defines the three dimensions which each apply the nodal-recursion allowing the division of the dimension into a potential continuum.
+
Each layer receives a quanta and does the following set of operations which is considered reasonably atomic:
 +
*If absolute metrics are invalid, set from state of relative metrics
 +
*If sprite invalid, render background colour and or bg image
 +
*If collision query, calc and pass on if unresolved
  
At the level of interface, the base-geometry is sructured as a stack of z-ordered layers, which each contain a graphical object. All the layers at this level share the same origin, and the z-coordinate system is an integer sequence.
+
;Sprite
 +
:''Sprites are runtime caches, device specific and represented non-nodally (as a '''spriteInfo struct''' in [[interface.c]])''
 +
*x,y,w,h ''(pixels)''
 +
*scale
 +
*rotation
 +
*dynamic ''(if dynamic, sprite is root of new texture structure at runtime)''
 +
*tile, next ''(maybe move these into container)''
  
#The polar geometry (3DSpace)
 
The polar implimentation of the geometry is being ported from [[space.as]] which already handles hierarchy, recursion and relativity of coordinates. Currently its coordinate system is actually rectangular (x,y,z), but this is actually not too important at this time.
 
  
In this system there is only one set of layers that all objects in the entire space reside in. The objects in the space form their own containment relationship independently of the layer-stack, and indeed have no direct knowledge themselves of the layers. The layer that any object resides on is handled by the polar geometry based on the object's 3D coordinates, not by the individual objects.
+
;Container
*see [[Wikipedia:Octree]] - recursive subdivision used for collision detection in OpenGL.
+
:''Containers are device-independent nodal structures with no language-specific representation''
##Polar parent methods & properties
+
*x,y
:''(these are still in the process of being migrated to the nodal conceptual structure)''
+
*w,h ''(min,cur,max)''
*'''create'''
+
*units ''(%|px|mm...)''
*'''reduce'''
+
*layout ''(U|D|L|R|none)''
*'''active'''
+
*align ''(L|R|C|J) - relative to layout direction''
*'''rotation'''
+
*wrap
*'''zbuff'''
+
*clip
*'''zbLength'''
+
*fill ''(colour, alpha)''
*'''children'''
+
*sprite
*'''template'''
 
*'''zSCREEN'''
 
*'''zcmp'''
 
  
##Polar child properties
 
*'''space'''
 
*'''time'''
 
*'''create'''
 
*'''reduce'''
 
*'''motion'''
 
*'''die'''
 
*'''x,y,z,scale'''
 
*'''colour,alpha'''
 
  
#The rectangular geometry (BoxModel)
+
----
This model extends the base-geometry in a slightly different way, in this case the layers follow the same hierarchy as the object's own containment and an object can create and remove layers from their context (by creating or removing child objects), and can directly manipulate which objects are assigned to which layers.
+
;Collision detection and redraw tree
 
 
In this model, the parents rectangular bounds can be enforced onto the children (ie a window), and then various specific layout mechanisms applied within this context. There are two fundamental rectangular layouts used for the interface, ''table'' and ''paragraph'', which are both designed to be conceptually compatible with the ''[http://www.w3.org/TR/REC-CSS2/box.html W3C Box Model]''.
 
 
 
The nodal BoxModel implimentation uses standard properties to determine border and spacing metrics and styles and allows the organisation of the child objects into ''rows'' within the bounding rectangle. This level also handles the layout issues involved with the children occupying a larger rectangle than the parent (eg. scrollbars etc).
 
 
 
##Rectangular parent properties
 
*'''dimension'''   ''(horizontal or vertical, order is the z dimension)''
 
*'''direction'''   ''(iterate list with prev or next)''
 
*'''border'''
 
*'''margin'''
 
*'''padding'''
 
*'''background'''
 
*'''children'''   ''(the items in the list to be laid out)''
 
 
 
##Rectangular subclasses
 
:Rectangular :: Table
 
:Rectangular :: Paragraph
 
 
 
 
 
#Collision detection and redraw tree
 
 
Collision detection and the tree of redraw work use the recursion already inherent in the [[Nodal Reduction]] environment, but are essentially doing exactly the same process as the currently accepted ways, see [[Wikipedia:Collision detection|Collision detection]] and [[Wikipedia:Octree|Octrees]].
 
Collision detection and the tree of redraw work use the recursion already inherent in the [[Nodal Reduction]] environment, but are essentially doing exactly the same process as the currently accepted ways, see [[Wikipedia:Collision detection|Collision detection]] and [[Wikipedia:Octree|Octrees]].
 
 
  
 
'''See also:'''
 
'''See also:'''
 
*[http://www.w3.org/TR/REC-CSS2/box.html Box Model] ''(W3C)''
 
*[http://www.w3.org/TR/REC-CSS2/box.html Box Model] ''(W3C)''
 
*[[Wikipedia:List_of_layout_engines|Layout Engines]] ''(Wikipedia)''
 
*[[Wikipedia:List_of_layout_engines|Layout Engines]] ''(Wikipedia)''

Revision as of 23:38, 5 September 2006

The conceptual structure of the initial interface is a 2D layer model (see geometry, but its a bit out of date), where layers are stacked in z-order and can exhibit transparency. Layers are arranged as a tree allowing each to contain a list of n child layers. The position and clipping area of a layer is governed by its parent.

The interface uses SDL's OpenGL context for final rendered output, but composes the root-child layers into surfaces and then transfers the surfaces to OpenGL textures. Later we'll allow any layer to be cached as a texture, rather than only the layers at the root level. This way processing load would be reduced by utilising the large unused resource of texture memory on the video card - usually around 256MB. These cached layer-composites are 32bit having alpha and are called sprites.

The root level layers are hooked in to the reduction loop permenantly and they in turn hook in various children based on redraw or collision queries or metrics updates which need to be resolved. These queries are guarunteed to be resolved by the end of the frame. These queries exhibit workflow and so are passed around amongst the nodes to be processed and passed on again until resolved.

Each layer receives a quanta and does the following set of operations which is considered reasonably atomic:

  • If absolute metrics are invalid, set from state of relative metrics
  • If sprite invalid, render background colour and or bg image
  • If collision query, calc and pass on if unresolved
Sprite
Sprites are runtime caches, device specific and represented non-nodally (as a spriteInfo struct in interface.c)
  • x,y,w,h (pixels)
  • scale
  • rotation
  • dynamic (if dynamic, sprite is root of new texture structure at runtime)
  • tile, next (maybe move these into container)


Container
Containers are device-independent nodal structures with no language-specific representation
  • x,y
  • w,h (min,cur,max)
  • units (%|px|mm...)
  • layout (U|D|L|R|none)
  • align (L|R|C|J) - relative to layout direction
  • wrap
  • clip
  • fill (colour, alpha)
  • sprite



Collision detection and redraw tree

Collision detection and the tree of redraw work use the recursion already inherent in the Nodal Reduction environment, but are essentially doing exactly the same process as the currently accepted ways, see Collision detection and Octrees.

See also: