Skip to content
This repository
Newer
Older
100644 73 lines (36 sloc) 6.648 kb
c742d851 » Brad Beer
2012-12-13 Update design.org
1 * CLinch Design
3b5a8133 » Brad Beer
2012-12-11 Added design.org
2
3 ** Overview
4
c742d851 » Brad Beer
2012-12-13 Update design.org
5 CLinch is a simple, yet powerful 3d graphics engine for Lisp. In true Lisp fashion, it is more a build-your-own-engine hobby kit rather than striving to be a full graphics panacea. Much of the design is based on Horde3D. Although Horde3D is a very good design, it has limitations which it attempts to solve by adding domain specific languages. Items such as shaders, entities and, most importantly, the pipeline are specified using an XML language. Lisp, by being self-compiling seemed like a better fit than requiring (yet) another language.
3b5a8133 » Brad Beer
2012-12-11 Added design.org
6
c742d851 » Brad Beer
2012-12-13 Update design.org
7 Eventually I hope that CLinch becomes a stable and fast workhorse tool for developing games, visualizations and productivity software. Eventually I have plans for a graphical shell which incorporates the strengths of Lisp, the command line and 3D. This is a first step towards this (and other) goals.
3b5a8133 » Brad Beer
2012-12-11 Added design.org
8
9 ** Design Goals
10
d3e897f1 »
2012-12-14 Update design.org
11 *** Integration with 2D Tools for future REPL and Live Coding
12
13 Integration with 2D vector graphics with Cairo
14
15 Integration with fonts and positioning with Pango
16
17 File loading and saving with FreeImage
18
19
3b5a8133 » Brad Beer
2012-12-11 Added design.org
20 *** Fast
21
c742d851 » Brad Beer
2012-12-13 Update design.org
22 CLinch should be as fast or faster than most script-based graphics engines while requiring much less development time. While it may never rival professional C libraries, the ability to modify the 3D engine and environment from the REPL will allow skilled developers to create applications in a fast, intuitive, flexible way.
3b5a8133 » Brad Beer
2012-12-11 Added design.org
23
24 *** Simple
25
c742d851 » Brad Beer
2012-12-13 Update design.org
26 CLinch should be as simple as possible for someone familiar with 3D graphics programming to understand. I still remember how easy it was to write a single pixel to the screen in DOS and while I can't simplify to that degree (without losing modern power and flexibility), I can remove many of the most common difficulties. These include texture and vertex buffers, shader compiling and linking, shader variable passing, drawing text and 2D graphics, pipelines and 3D transformations.
3b5a8133 » Brad Beer
2012-12-11 Added design.org
27
28 *** Intuitive
29
7b79c9bc »
2012-12-13 Update design.org
30 Time spent looking for solutions is time spent, period. It ruins developer flow and can stop a project (especially a small one) indefinitely. CLinch should have few basic primitives which solve the general cases well and allow for easy replacements when necessary. It should be well documented and have a consistent interface. I will strive to keep abstraction leaks at a minimum.
3b5a8133 » Brad Beer
2012-12-11 Added design.org
31
32 *** Flexible
33
c742d851 » Brad Beer
2012-12-13 Update design.org
34 CLinch should not depend on any one library. Currently it only supports OpenGL, but the framework can (in theory) support others. It should not rely on a particular windowing library and should work as a simplified replacement for the original graphics library interface. It should not be designed for any one type of application such as games, but should support any 2D or 3D application. It should be cross-platform (wherever possible) and not inflict any particular design onto its client applications.
3b5a8133 » Brad Beer
2012-12-11 Added design.org
35
36
37 ** Architecture
38
c742d851 » Brad Beer
2012-12-13 Update design.org
39 Although CLinch can be used as a complete graphics engine, most parts of CLinch are independent. You can use most objects by themselves as best suits your application. For example, you can use a buffer object by itself. This also helps with testing by isolating the various parts of CLinch. The following is in hierarchical order based on the default configuration. This is to explain it as clearly as possible, not to indicate a necessary design.
3b5a8133 » Brad Beer
2012-12-11 Added design.org
40
41 Most objects have children method which tries to behavior intelligently based on their type. Most objects also have a render method which will render itself then its children.
42
43 *** Transforms
44
6e18e964 »
2012-12-14 Update design.org
45 A transform is a 4x4 matrix which is used to hold and apply a C array of 16 floating values. Currently only single-floats are supported. It encapsulates the CFFI memory management using trivial-garbage. It also has basic arithmetic operations for 4x4 linear algebra and 4x1 vectors. (Note: only m*v is currently implemented) There are functions for rotate, translate, scale, multiply (m*), make-identity (or reset), transpose, determinate, invert, make-orthogonal-transform, make-frustum-transform, make-perspective-transform, multiply by vector (m*v), use-transform (for the OpenGL matrix stack) and get-current-gl-matrix. Modern transform functions for passing values to a shader are not yet tested, but should be soon.
3b5a8133 » Brad Beer
2012-12-11 Added design.org
46
47 *** Nodes
48
49 Nodes are not usually the topmost objects in the hierarchy, however they are the most important. Nodes abstract 3D transform "chains" and hierarchy. Nodes subclass transforms and can be modified the same way as transforms. They also may have children. Nodes are multiplied together in a hierarchy to create an effective transform which it stores in a hash by a list of all its parents. This allows a node to be reused in any way necessary. A node can be used in multiple places within a hierarchy (or tree) or even in several different ones. This is done by passing a list of parents to the update function. It will then append itself and call update on its children. In this way, the transforms are only calculated when they or their parent(s) have changed.
50
51 *** Entities
52
53 Entities are what are rendered and are also a subclass of node. They bring together the shader, buffers, textures, attributes and uniforms and transforms together into something which can be rendered on the screen. A shader and a (currently) an index buffer is required although they would be useless without at least one vertex buffer. Each member of values can be either an :attribute, :uniform or :vertices.
54
55 *** Viewports
56
c742d851 » Brad Beer
2012-12-13 Update design.org
57 An application can have several viewports. As CLinch does not force any particular windowing implementation, it can not have a window class. Once your window is set up, however, you can use the viewport handle drawing an area on screen. The most common children the cameras, which will be rendered in order unless then are not enabled.
3b5a8133 » Brad Beer
2012-12-11 Added design.org
58
59 *** Shaders
60
61 Shaders are the compiled output from text-based vertex and fragment shaders. They require a name, vertex shader source code, fragment shader source code, a list of uniforms and a list of attributes. Vertices and index buffers need not be specified if you are using them.
62
63 *** Pipelines
64
65 A pipeline is a series of commands which create the scene with every call. Generally they clear the screen, render the root node and sorting items into the proper sequence. Unlike Horde3D, any set of Lisp can be used. Usually there is only one pipeline per viewport or application.
66
67 *** Buffers
68
69 Buffers abstract the shared data on the graphics card.
70
71 *** Textures
72
73 A subclass of Buffer, textures abstract the 2D textures and allow easy access to them from Cairo, Pango and Freeimage.
Something went wrong with that request. Please try again.