This week I focus on research and creating a schedule for the creation of the tool. I figure that without research, I might not be able to accurately produce a workable schedule. We’ll start with the documentation creation process and how long this should take:
- Start date: 12th February 2014
- Due date: 28th May 2014
This in total is 15 weeks to do documentation, with a presentation on the due date.
|Week 1 to 5||Discuss and research initial ideas|
|Week 6||Finalise Preliminary Idea|
|Week 7 to 12||Research project and document drafting|
|Week 13 to 14||Final Drafts|
|Week 15||Final Documentation and Publishing|
Since I already have the initial idea, I’m going to start on the actual project and document drafting. Below is a plan of what I’ll need complete by the end of the planning stage:
- (W-7) 26th March – Create a plan. Then Research some more effects and specifics about realistic particle simulation.
- (W-8) 2nd April – Make a start on the documentation, making the templates for each document and make lists of the parts I’ll be doing.
- (W-9) 9th April – More research on things
- (W-10) 16th April – More research on things
- (W-11) 23rd April – Will be travelling at this time, but can do little things when needed.
- (W-12) 30th April – End of document Drafting – most of the documents should be complete by now.
- (W-13) 7th May – Final drafts to start.
- (W-14) 14th May – Back from Travelling – Knuckle down in final drafts. Start presentation.
- (W-15) 21st May – Final documentation and publishing. Finish presentation, Do mock recording etc.
- (W-16) 28th May – Due date! Everything should be done and handed in on this day. Everything should be done before this but leaving a week for any catch up.
On each of these days I’ll be writing a blog entry like this one. On the date of final documentation and publishing, I’ll copy all the blog entries into a document for handing in. As it is easy to track things online.
- Research Journal
- Learning Plan
- Peer Reviews
- Design Documentation
- Technical Design Documentation
- System Analysis Plan
- Project Management Documentation
- Financial Outline
These will need to be submitted both by PDF and a binded document. I’ll need to make sure I have enough printer ink and buy the binder.
For this task, I will need to use WordPress to log each week of what I’ve been researching and which peer reviews, information I can find about the system. At the end of the week I will need to copy them to a word document and spell check them. This will be printed and binded. I will be watching a lot of videos on real special effects like plane crashes and gun shooting to see how fire and smoke acts in real life, and then study images of fire to reproduce it.
Some ideas of learning objectives could be:
- Work out whether saving files to the server or directly to the user’s hard drive is better. Should I use a conbination of both?
- Learn how to optomise particle systems on the video card using researches methods
- Marching cubes / metaballs for water effects – maybe use normal maps and specular maps to add better lighting
- Volumetric for ckloud effectrs
- screen space ambient occlusion for smoke
- particle light emissions into smoke
- volumetric lighting inside smoke cklouds caused by particles
- Real life particle movement with wind and the best way to do this
- Creating normal maps
- Learn what industry people want
- Undo and Redo feature using “Memento pattern”.
I might need to elaborate on these more and explore / find new ideas as the documentation develops. Each of these will need to be saved as separate PDFs, and printed along with other material to be binded.
I would like to post on as many forums as I can and also ask at least 3 industry special effects designers what they like and dislike about Fume FX and as many opinions as I can get. These can be people on YouTube that post special effects demos and forums. Some things I could ask are:
- What are the best features of Fume FX? What are the things that you cannot live without?
- Do you find the interface overwhelming?
- Are all options used or are there settings that are mostly used and some that should be default anyway?
- Would you pay for software like this particle tool idea?
- Do you think having it run in a browser would be beneficial? Why / why not?
- What are the hardest special effects to create?
- What features do you wish were there / were easier?
- Would a GUI speed boost make workflow a lot easier?
- What sort of interface would work better? Is one like Photoshop a good choice? Would an interface that goes away from the trends of Photoshop be a burden?
The general idea is to prove my niche really. I need to know these things so I can design the interface around these. These will all be recorded and preseted as part of the peer review documentation. I will the end it with a conclusion.
This will be where the tool is explained in as much detail as possible. Some general things would be things like:
- Tool will run in primarily Google Chrome (and Firefox)
- Complete functionality. It will:
- Be able to save and load on the server
- Be able to save and load files locally
- be able to create, delete and edit “layers” (smoke on one and fire on another for example)
- Export a spritesheet that can be used in the Unity’s particle cool (must do more research about compatability with normal maps and different effects, alpha sorting issues and using multiply and additive together)
- Can export different channels, like a normal map, additive and multiply
- use the GPU to simulate the system
- can create frames
- Frames can be scrubbed through
- A frame can be chosen with a small box where the section will be exported per frame
- The “camera” can be moved around to center the frame
- The “frame” will be a square but a “fade out” can be applied in a spherical matter inside the frame, as this is a pre-particle exporter, the effects need to be technically sections of a larger particle system.
- Tools in the toolbar will be
- Brush to draw particles to the 3d world
- A pushing tool to drag particles around like the liquify tool in Photoshop
- A gravity tool for pulling particles towards the cursor
- Interface will be designed around simply the default styles that three.js comes with.
- Different interface view modes:
- Game engine preview – will show the rendered version with all effects added using a 3 point light system that can be customised. This will not be rendered, as lighjting in games can change. For example a water particle cannot have a bright light reflection rendered at the top-left because the game’s light might be under it.
- Real-time preview (slower to render but will try and make it at most 1 frame per second, each frame can be cached into a buffer on the canvas and displayed until he user moves the camera) This will be the main area that the game will use
- Normal mode will show 10% of the particles
- Motion vector preview – a normal map looking (x y z velocity represented as red green blue channels) as to visualize movement in a single frame.
- Depth buffer view (shows the depth texture, mainly for me debugging but may be useful for others
- Particles could light up when hovering over them
- The background can be customized to show the transparency in the screen
- Screen effects can be applied, like depth of field, screen space ambient occlusion on “smoke” particles (using the depth buffer), glow and
- Particles can be simulated using either vertices connecting a vertex colouring additive effect on each particle so make more realistic fire (will go into detail later, and after more research), smoke as volumetric, particle lighting and ambient occlusion (more research needed)
- Can add a game light to simulate how it would look in a game
- Server will need a database to store user data
- To be usable, the system needs to have an undo / redo feature. This should be done using the “Memento pattern” and should be implemented from the start.
- A status bar showing the particle count, some extra info and a status of the program (like loading or saving or exporting etc.)
- Toolbars, one on the left, the right, the bottom and top. I will try and make them simple without many options as one of the aims of this project is to have a program that’s less daunting and easy to learn.
The name of the program I’m leaning towards something like “Plasmation”. Because the word isn’t really a word, apart from being seen in some online places, which say it’s “forming or moulding” when this tool is like moulding a special effect particle. It also has “plasma” in it, which, to me, sounds special-effect-y.
Technical Design Documentation
This will consist of a lot of UML diagrams basically. Once I’ve sorted out the design documentation, done enough research on the formulas and ways to produce the effects, I’ll be able to do this properly. I think this section will be important to show how the web server and client-side parts will work together, as the barrier here is that because the program is working on a web server, the data needs to be transferred up and down to that and loaded in by users from their hard drives. A list of these would be:
- Component listing
- Pseudo code for all systems and components
- Program design diagrams in UML
- Data flow diagrams in UML
The thing to start off with will be the way the server and client could interact, but as I haven’t done the design documentation, this is just an example (Made with Lucidchart, a great example of an online tool): As you can see, this is a basic flow of data in the logging in / creating account / workspace.
System Analysis Plan
In this I will basically talk about why I’ll be using an agile type of development methodology. I will most likely use Scrum because it is what I’m used to. An issue with this is the morning meetings, which I can replace with the journals and discussion of my goals and blocks.
Requirement analysis will also need to be documented which is basically a document that describes the requirements of the program. This will be closely tied to the technical documentation. I will need to include this as a separate documentation with an introduction explaining briefly the purpose of the application, scope, objectives and success criteria of the project, and the usual glossary of terms.
The second part of the documentation will include requirement and the analysis model of the application. The documentation will finish with references.
This section will also include a test plan and test cases for requirements validation.
Project Management Documentation
This will consist of a Work Breakdown Structure (WBS), complete with resource allocations, and a gantt chart with critical path. I will be using gantt chart software for this and will discuss in my journals which software is best for this.
This part of the documentation will also include a risk assessment and contingency plan.
The application could either be free or a subscription-based program with advanced features unavailable. For this project, however, the program will be very basic, and adding user and subscriptions in there just makes another layer of difficulty. For the actual outline, I will be creating a mock one for industry professionals in a form of a pitch to get funding. The actual money involved will cover things like web servers, domain names, time food and workspace programs for myself to create at home, software, internet and power costs.