yang2218 / kettering-cs320-procedural-graphics Goto Github PK

http://code.google.com/p/kettering-cs320-procedural-graphics/wiki/ModuleInitialS
hape

Build the Control to represent a Module in a ModuleGraph. It is basically a 
floating control and a contains a vertical flow of EditorControl.

http://code.google.com/p/kettering-cs320-procedural-graphics/wiki/BackEnd

The back-end should be responsible for invoking modules and passing data 
between them.

Write the top-level class to create and manage the window, GUI system, etc.

I (Alec) will probably work on this, but if anyone wants to take this on before 
I've assigned myself, please talk to me and I'll be glad to share my thoughts.

EditorControl is the superclass for Module parameters which the user may 
specify a value directly inside the ModuleNodeControl. Each type which should 
be editable directly should have a subclass.

Please write editors for the following:
 - int
 - float
 - string
 - enum types (a listbox of enum choices found via reflection)

Except for the last type, writing these editors should be simple (just a simple 
container for a Textbox which validates and saves the entered value). The last 
type needs to use reflection to get the enum type and it's options (you can ask 
me [Alec] for some pointers on how to do this).

It would be a cool feature to have a graphical interface to let the user define 
what modules to run, how they're connected, and tweak the parameters to the 
modules.

Visually, I'd imagine something like I was drawing on the whiteboard in our 
first meeting, or the attached sample of Blender's node editor interface (found 
off google).

Prof wants 2-3 paragraphs for each algorithm by next week (4/27/2011)

When we decide to support external modules:

Define the file formats for the data types we use as parameters.

http://code.google.com/p/kettering-cs320-procedural-graphics/wiki/ModuleCirclesT
oHeight

Write a toolbar control (basically a container with horizontal flow containing 
buttons).

http://code.google.com/p/kettering-cs320-procedural-graphics/wiki/ModuleColorFro
mHeight

http://code.google.com/p/kettering-cs320-procedural-graphics/wiki/Module

Define the interface or superclass for internal modules. This should include 
writing the documentation for guidelines on writing a module: how input/output 
parameters are exposed to the framework, etc. Although work on modules can 
begin before this is solidified, it would be helpful to get this finished so 
people will have a starting point for developing modules.

http://code.google.com/p/kettering-cs320-procedural-graphics/wiki/ModuleApolloni
anGasket

Good luck with that Matt

We need to decide on a language for the project, or at least the core parts of 
it, before anything can proceed.

Additionally, we need to decide on the interface for the modules so work on 
those can start.

The standard choice of language would be C/C++, since this seems to be what the 
prof. will be teaching the class in. C# was also suggested as a language (which 
can interface with OpenGL through the wrapper library OpenTK, and should be 
pretty much the same interface as the native library).

After deciding on the language a template class or interface should be created 
so modules can be created that will actually interoperate. Alternatively, 
modules can be in the form of standalone executables which are simply invoked 
by the core program with parameters to read inputs (heightmaps, colormaps, 
etc.) from files and save outputs to files. In this case, the programmer of a 
module may choose any language they would like.

Discuss on the Language wiki page.

Write the control which shows the user a list of all Module types and allows 
them to add a Module to a ModuleGraph via click and drag.

Actually obtaining a list of modules would either be done via reflection (if 
possible), or by having the ModuleAttribute register the module in a static 
registry (thus making the Module attribute mandatory for modules).

Get a solution setup with some sample OpenGL code and checked into the 
repository.

Later document the process so others can learn to use the source control system.

Write the classes for containing and rendering objects in a 3D scene in part of 
the window. Some of the classes to be written under this issue:

Entity: a renderable object.
Scene: contains Entitys.
Viewport: references a Scene and represents an area of the window.
ViewportControl: placeholder for the GUI system to reserve a rectangle for the 
viewport as well as accepting input for moving the camera around, etc.