Quote - Hope you get going soon and hope to see something in writing.

Ok, got a quick and basic proposal in writing, a lot more detail to add as I go but this will give you the basic groundwork and scheduling I have in mind.  Feel free to peruse it (indeed, this includes not only yourself but any other interested parties) and get back to me with any questions, suggestions or concerns you might have.

**
Figure Animation Studio (FAST)**

Project Proposal and Design Notes

 

 

Overall Design Philosophy:

 

The overall design philosophy of Figure Animation Studio is to provide 3d graphics artists with a set of well integrated, easy to use tools to pose, render and animate 3 dimensional objects with particular emphasis on human figures.

 

The project will be designed as an alternative for commercial programs like Poser and Daz Studio. It will be fully compatible with files that were created and designed for use with either of these aforementioned programs, giving it a huge base of available content and allowing those who have already invested a great deal of time or money into building a large amount of content for Poser or Daz studio to make use of said content without the need for either Poser or Daz studio.

 

Since Figure Animation Studio is a 3d graphics program, particular emphasis will be placed on two areas when designing or reviewing code submitted for this project.   The first an most primary concern will be in the area of memory management. 3d applications of this nature utilize a great deal of memory to perform certain tasks, and as such routines/functions/modules/classes should all be written in such a way that memory is used in the most efficient way possible.

 

Requiring a few additional “passes” when, for example, reading an object file, is far preferable to a method by which the file is only read once, but a great deal of memory is wasted filling variables with blank statements or null data. Whenever possible the code should follow the simple axiom, if memory is not actually necessary, it shouldn’t be allocated. When an object in memory is no longer necessary, it should be destroyed. 

 

The second area of particular concern in the design of this particular program will be cross platform compatibility. Figure Animation Studio will be coded from the ground up with the expressed purpose of being able to run on either Windows or Linux as a native app, and the possibility that it might at some point be ported to the Macintosh system as well.

 

Thus any libraries chosen should be chosen with this design criteria in mind, that they should provide cross-platform capability whenever possible. Coding that is specific to a single platform should be avoided, the source code should be able to compile on either linux or windows (and hopefully eventually mac) without source code changes or branches if at all possible.

 

Last but not least Figure Design Studio will be coded with the idea of keeping the GUI separate from the actual inner workings of the program whenever possible. OOP is a must, functions/features should be encapsulated into logical classes and the actual graphics interface should be a separate concern.

Design Stages:

 

Stage I:  Project Beginning to Alpha Stage

** **

The Figure Animation Studio Development will begin with the very basics. To start with it will require a module to read in all files (CR2, PP2, PZ3, etc) designed for use with Poser and utilize them just as Poser or Daz Studio would.

 

This will include being able to load and display all of the various figures, the ability to load morphs, injections, poses, materials, etc.

 

The alpha stage development will concentrate on the very basics of being able to read in Poser/Daz studio files, being to be able to pose/manipulate/design a scene using these objects and then being able to render them as a static image.

 

All geometry information that would cause a Poser or Daz Studio figure to change such as INJ files or character morphs should be readily accessible and functional in the alpha stages of the project. At this stage FAST must also be able to pose the figures, requiring it to understand Posers bone structure, mesh deformation and additional considerations such as ERC and JCM’s.

 

Figure Animation Studio must also be able to save these files either in it’s own native format, Poser format or Daz Studio format for maximum compatibility with both programs.

 

Should this stage of development prove to be progressing too slowly support for Daz Studio might be pushed back to a later stage of development, however support for Poser files is a requirement for the Alpha stage to be considered complete. 

 

Also, while I would like to have at least the basics of an internal render engine complete for the Alpha release, again should initial coding fall behind schedule this is something that can be moved back to a later stage, provided FAST can be successfully integrated with other Open Source rendering options such as yafray, sunflow, etc.

 

Eventually I would like to have fully featured, network aware, internal rendering engine in addition to having the ability to transfer render data quickly and easily to external rendering engines like the ones mentioned above, giving the end user a multitude of rendering engines available for use with FAST.

 

As such I think it would be prudent for FAST to be able to send render data in “Blender” format, since at the moment most open source projects of this nature are designed to work with Blender.

 

 

I’d like FAST to be able to read and write as large a variety of 3d file formats as possible. It’s own internal library should be able to read Poser runtimes and store information like path’s and file locations as well as file references within the database itself.

 

One of the features that FAST will have is the ability to open CR2 or other files of that nature and check all of the internal references (obj files, material files, etc) and build a database of these file locations.

 

This database can then be used for several things – first a safe move or delete feature. Should the user decide he wants to move a file from one poser runtime to another, he/she can simply select the file and select move. The database can then be accessed and all of the internal references checked. If another CR2 (or equivalent) file contains references to lets say the same texture file, FAST can then alert the user and ask them if they want to just copy this file, and let them know if they chose to truly move it that another CR2 will be affected should they try to access it at a later date in Poser or Daz Studio.

 

Safe delete will work in much the same fashion, it will check all the references in the CR2 and should no multiple references in the database be found it will delete all of the files associated with that CR2 from the runtime. 

 

This database can also be used for integrity checking, making sure that all of the files/objects referenced by the various CR2’s exist and are where they are supposed to be. 

 

This will also provide a method by which FAST can rapidly find and open files referenced by a CR2 or PZ3 file without having to search through all Poser runtimes for the correct files, which should speed up loading of Poser content a great deal.

 

The library interface should also allow you to move, create, delete or change directories/items within a poser runtime quickly and easily. 

 

The database will also give another added advantage in that by including a system by which items can be placed into various “categories” it would be possible to group items even across multiple runtimes by common themes, with the final library display being filtered by these categories when they are selected.

 

For example, you might have one runtime that included some clothes that could be classified in the database under the category “Genre” and the subcategory of “Sci Fi”, and has an additional category of “Type”, “Clothes”

In another category you might have some props, like perhaps a ray gun, that are also classified as “Genre” Sci Fi” and an additional category of “Type” “Character Props”.

 

This would allow you while working in the library to display everything in the “Genre, Scifi” and it would show both of these items, even though they are not in the same Poser runtime.

 

 

If you further limit the filter by adding “Type, Clothes” then only the clothing would appear, the prop would be filtered out because it has a different type than clothes.

 

A list of common, already available categories might include:

 

Figure (Which figure is this for, M3, D3, A3, A4, etc)

Type (What type of item does this apply to, clothing? A character? A prop for a character? Etc..)

Gender (Male, female, none or neutral)

 

 

So, one could find everything (Characters, mat poses, etc) for a Figure like M3 even across multiple runtimes by selecting a filter of Figure, M3.

 

If you were only interested in figures, props, mat files etc for clothes for M3 you could add an additional filter of Type:Clothes and then all of the additional items (Like character Poses, Mat files, etc) would be filtered out. Only those files that applied to clothing would be shown.

 

The categories themselves can be edited by the user, so they can change or add categories or subcategories to fit best with there own style of organization, however the “default” categories will be stored separately in an XML file so should the user ever desire to do so he/she can easily restore the default categories with the click of a mouse.

 

During the alpha stage I will also code a TCP/IP server for FAST, one that can be switched off should the user so desire. The TCP/IP server will allow any external program from a valid source (determined by IP masking if desired) to access FAST and make use of all of it’s features from an external program.

 

This way FAST can very easily be extended by Python, C++, Java, etc – any programming language that can send and receive information via sockets can be used to make “scripts” or “add ons” for FAST. 

 

 

Stage II: Alpha Release to Beta Stage

 

The Alpha release will be a good opportunity for people who are very interested in the project to peruse the work to date and offer feedback and hopefully additional support. Once the Alpha stage has been reached, development should then proceed into more difficult areas of the project. The internal rendering engine should be expanded to include abilities such as the ability to render across networks or make use of “clusters” of machines to render a single image.

 

In Stage II the ability to do animations will be examined and hopefully implemented. This stage of the project will concentrate on providing a simple animation interface and the ability to export a completed animation into various formats including mpeg and possibly flash as well.

 

This will also be the point in the project where the rigging tool is implemented, it should be easy to use and integrate well into the rest of the program. Unlike Poser or Daz Studio, users should NEVER have to resort to editing files like CR2’s in order to implement features if such a thing can be at all avoided.

 

The rigging interface should be able to do IK Chains, things like ERC and the like should all be able to be manipulated from within this interface. A product put out on Renderosity called “Easy Pose” should give you some idea as to the basic functionality I’d like to include all within the rigging interface. This is a primary focus of Figure Animation Studio and one that will set it apart from other programs, it will have a powerful but easy to use rigging interface that will allow figures to be made poseable with a minimum of effort.

 

Should work on the rigging interface be going well and should the time present itself I would also like to spend some time at this development stage to work on the morphing interface. I would like tools like “magnets”, “wind force”, and the “morphing brush” to be available in this area, as well as a basic modeler that is specifically designed to allow the user to work with human figures and create there own morphs quickly and easily.

 

This will not be a full blown modeling application persee, it will not have all of the features of say blender or 3ds max. This will be specifically designed to create character morphs, and it’s gui and features will be built for that purpose.

 

Saving a full body morph or creating an injection channel when it is finished should be simple menu options, on click and it’s done. While it will still be possible to save the individual morphs to individual body parts one by one, it should not be necessary to save all individual morphs, dial them in, create a full body morph and then save. A simple click should allow you to select a list of morphs from all of those currently applied to a figure, group them together as a single morph and save them as either an INJ channel, a full body morph, or both.

 

The same philosophy will apply to saving MAT/MOR Poses – this should be a simple, one function that allows the user to select either all of the MAT’s for a figure, or even just specific mats/mors should they desire. There should not be a need for external scripts to perform these functions, the programs UI should make it easy to do from the get go.

 

The completion of the beta stage should provide a more or less complete but basic application that can be used to easily load, pose, and render either still’s or animations using the internal rendering engine, and make use of external rendering engines to the utmost of there capabilities.

 

Once this is accomplished a beta version can be released to the public, allowing them to find any potential problem areas and make any suggestions they might have for improvements.

 

 

Stage III: Beta to First Release

** **

At this stage we’ll have to start being a great deal more flexible to provide for both bug fixes and “user wish lists”. It is at this stage where I’d like to start looking at things like a second modeling applet, this one specifically designed with clothing in mind.

 

It would integrate with the rigging interface, and allow the user to quickly and easily select basic models for things like shirts, pants, skirts, shoes, etc and modify them to suit their individual needs and styles.

 

Again unlike conventional full blown modelers, this one would be specifically designed to model and manipulate clothing for human figures, allowing the artist to easily do things like “add wrinkles”, “create pleats”, etc, etc..

 

By first loading the figure and then a basic clothing type (long sleeve shirt, short sleeved shirt, etc) it would be possible to create a wide variety of clothing very quickly using a very simple modeling applet.

 

The rigging interface will be designed so that the clothing would already have the “basic” rigging of the underlying figure, and additional rigging for moving skirts, opening shirts, etc could be included with each basic clothing figure type.

 

Once the modeling is finished the user could then open the “rigging interface module” and make any adjustments they might need as far as rotation points, etc, should they want to do something a bit fancier than just the basic rigging already provided.

 

At this stage I would also like to integrate a cloth simulator, both for use in standalone mode and for use with the modeler to produce more realistic clothing effects.

 

Also if at all possible I would like this cloth simulator to work on full figures, not just single objects. It would treat the figure like an object for the purposes of cloth simulation, but retain all of it’s rigging data for later use, making the Poser requirement of exporting a figure to an obj, reimporting it and then running the cloth simulator obsolete.

 

Stage IV: Initial Release

** **

By this stage we should have all the major kinks ironed out and a very capable posing and rendering application that works out of the box on both Linux and Windows with both DS and Poser files.

 

After the initial release I can think of a lot of features I’d like to add down the road for additional releases – for example a face room that actually works on a variety of figures, allowing you to produce a usable 3d representation from 2d photographs in a much easier fashion that add ons like Face Shop Pro do now.

 

I would like to add a full blown modeling applet to be used for modeling items other than clothing or character morphs, again sticking with the easy to use interface of the original app but adding more generalized functions used by more traditional modeling apps as opposed to the very specific, tailored functions of the Morph Designer or Clothing Designer modeling applets.

 

C++ Libraries and Platform Info

** **

After investigating a myriad of possibilities I think the best 3d library to use would probably be OGRE, it provides most of the functionality needed for creating/editing scenes, cameras, lights, etc with a minimum of fuss, and is cross-platform capable.

 

ODE will be used for things like windforce, gravity, and other calculations that will prove very useful. While the initial releases will probably only make minimal use of this library, for future releases it will provide a wealth of capabilities particularly in the animation arena.

 

The main portion of the GUI will probably use a combination of OGRE and QT – again QT is cross platform, has a very easy to use form designer and should speed up development a great deal. While I actually prefer glade/gtk from a licensing standpoint, QT provides some advantages, such as Mac compatibility, that gtk does not.

 

At the moment on Windows I can compile for both 64 and 32 bit versions, and for Linux I can produce Debian packages for 32 bit. I’ll be looking for volunteers to compile and maintain packages for other Linux distributions and hopefully for Mac OS-X and hopefully I’ll be able to have them on staff prior to the initial release.

 

This covers most of the basic project information, there are other features that I’d like the program to have that are not covered yet in this document, it will be a work in progress like the app itself, but this covers most of the basic design elements and philosophy.

 

 

-Never fear, RenderDog is near!  Oh wait, is that a chew toy?  Yup. ok, nevermind.. go back to fearing...