[Submitted] Visual .material Editor

Threads related to Google Summer of Code
Post Reply
tidalwv
Gnoblar
Posts: 23
Joined: Tue Apr 04, 2006 8:22 pm

[Submitted] Visual .material Editor

Post by tidalwv » Tue May 16, 2006 7:55 pm

(This is an extension of the app I submitted through Google per Sinbad's reply in http://www.ogre3d.org/phpBB2/viewtopic.php?t=20430)

Goal
The goal of my proposed project is to build a material editor application that allows the user to create and edit materials through a GUI and see changes made as they are made.

Final Product
The final product will be a single application made entirely from Ogre and CEGUI components. From the application, users will be able to load a mesh into the preview window and either load a .material file for it or make one from scratch. The user will then build the material through GUI widgets representing blocks of material properties (techniques, passes, texture_units, etc) and then link the blocks together in a coherient manner from which the program will be able to save the material into a .material file that can be loaded up by the engine outside of this application.

Pre-Process Work
  • Learn the .material file structure and properties -- My only Ogre experience to this point has not included .material files, other than some very simple ones for overlays.
  • Learn CEGUI -- I have not touched CEGUI at all yet.
What Would Be Needed
  • Read in and parse material file, being able to handle techniques, passes and other blocks of information, and store and display them in a meaningful way.
  • Output .material files that are human-readable
  • Preview window with moveable camera and adjustable environment properties, such as special lighting and cubemaps.
  • GUI process for stringing together material properties (Tentatively working from the example of Maya's Hypershade).
Rough Schedule
(If accepted, this may change once I get a better idea of what I'm going to be doing over the summer)
  • June 15
    Be able to read and store, and write to material files .
  • June 30
    Finished View environment, with mesh loading, cube/environment map and camera navigation.
  • July 15
    Started with GUI, particularly in regards to loading and saving of .material, mesh and image files; and viewing and editing property blocks (techniques, passes, texture_units, etc)
  • August 1
    Finish interface to string together property blocks. Rest of time for final testing and cushioning for earlier delays.
  • August 20
    Finished
Usefulness of the Proposal
While existing exporters for the major modeling packages can convert the package's materials into Ogre's format, they are tied to the package. With this tool, users would not have to have access to a modeling package to visually build the materials. They will be able to directly build materials as .material files are structured, and view the results in real-time in the Ogre engine.

Initial Thoughts on Execution
  • Stringing Together Materials
    During runtime, the blocks making up the material would be stored in objects that are tied together in doubly-linked list in ascending order of specificity (For example, techniques would be tied to the base material object, passes to techniques, and so forth). The objects would also know what they can and can not be directly tied to.

    To render the list with CEGUI, I could either create a wired block CEGUI widget that the material blocks are connected to, or have the material blocks be wrappers that handle the drawing of pre-existing CEGUI widgets to represent themselves. I will have to look into which one would be more efficient/desireable.

    As for the interface of stringing blocks together, the obvious -- and logical -- method would be to use the mouse to drag one block to another and, if possible, make the connection between the two blocks. There are two ways that I can think of to actually represent the list. The first, and the one I'd lean towards, would be to have a canvas on which the user can put the widets representing blocks anywhere he/she wants. When making a connection, the blocks would stay in position, and a line or arrow would follow the mouse from the initial block. The second method would involve the user actually dragging the block widget onto another block. If the connection is possible, then the higher block would take control of the other one and place it in an ordered heirarchy with all of the other blocks in the system. In either system, though, the order of the dragging would matter; for example, dragging a pass block to a technique (allowable) would be different than dragging a technique to a pass (now allowable).
Why me?
As a programmer attending a game design program at an art school (the Savannah College of Art and Design), I don't have access to training and experience that I would get in a computer science program, so this would be a good chance for me to put together a application with a real-world application. While I have experience with some aspects of the proposal -- such as writing and reading data to and from files and building scenes in Ogre -- this would bring together those aspects in a project that I would probably not normally do on my own. Also, being a programmer with an interest in visual arts, I am interested in the programming aspect of shaders; while this project does not directly deal with shaders technology itself, it is not too far off and is similar to something I might have to develop in the real-world for artists.

Experience
Portfolio: http://www.headlesschickenstudios.com

What I might need from a mentor.
My current experience with Ogre has not delt with anything more than bare-bones .material files, so I will have to learn all of the details of them and know about them enough to be able to read and write them proficiently. I have also not touched CEGUI at all (thus all of the time I give myself in the rough schedule for working with the GUI) and will undoubtedly run into problems there.
0 x

Post Reply