Welcome to the Goole Project Page!
Qoole-AID is a polygon mesh and patch based world and model editor designed for open-source and independent game developers. The primary focus of this project is to provide a robust set of tools to allow independent developers to create content for their projects. Qoole-AID is hosted on SourceForge!
Two projects are now hosted here. Qoole99 and the new Qoole-AID. Originally, the intent of this project was to extend the functionality of Qoole99, enhance the GUI, and allow developers an easy way to extend the editor for their own purposes. Unfortunately, Qoole99 has proven to be poorly designed and even more poorly written for this purpose and in light of these shortcomings Qoole-AID was born.
I can be contacted via email at digitalasp@yahoo.com
News for 11/11/2001: Then I saw her face!!! Now I'm a believer!
Ok, so I just got done watching Shrek! Cool movie! I think Ice Age will be better but probably won't pull in as much cash! Of course, the graphics and animation in Final Fantasy rocked even if the story sucked!
Seeing a trend here? I bet you are! I'm a fan of computer generated animations, which is probably why I feel the need to create a solid geometry editor for games with the power and flexibility of 3D Studio. Don't get me wrong, I'm not comparing Qoole-AID to 3DS, it's unlikely that we'll be that good anytime soon, but hey, who knows!
Even though it's not evident, a lot of things have been happening with Qoole-AID over the last few days. A lot of the design is complete, but there's still much to do. A lot of the utility classes and abstract interfaces are 100%. Even though these items comprise only 10% to 15% of the entire application, the other 85% to 95% rely on them being there. I still need to finish the primary GUI, applications components and the generic edit views, but those are on hold due to a heavy dependency on the state machine design. The problem here is that there is two way communication between the current state and several other objects such as the system independent view mechanism, the system dependant window, and the state machine itself. All of this needs to be done smoothly and with abstract observer/server/client mechanisms (depending on the scenario) in order to provide access to specific functionality without exposing the objects themselves (eliminating design specific dependencies). The follow is a quick example I whipped up to show the flow of information (MS Modeler doesn't supply state machines or anything other than basic UML - so it's not accurate in look)
There are several points of why this is so....
- Window mechanism needs to pass mouse movement, menu selection, button presses, and all other event types which cause states to change or states to perform operations.
- The view needs to handle these events, pass them on to the state machine, and handle the specific responses. Which is why the view will own the state machine (or be a state machine itself - still in discussion).
- The state machine of course needs to update states, alert states of changes, and extract information from the owner (in this case the view).
- The state itself operates at all levels, it needs to communicate with the view in order to get data to ensure that it can perform specific operations. It needs to alert the state machine if the state must be changed, reset, or nested. It also needs to perform certain operations which are system specific such as locking ownership of the mouse, redrawing the window, updating a toolbar, or setting the text in the status bar.
Is this going overboard? In some instances, yes, but it makes the interfaces and code a lot cleaner and a heck of a lot more reusable. It definitely allows the state components (and other code associated with the state) to be used in multiple scenarios (world editor vs. model editor, etc.).
All of this design work has also allowed me to research certain requirements and use existing open source components such as wxWindows, LibXML, and the 3D Studio file library. It has also allowed me to gauge how long it's going to take to develop certain items. In fact, after all of this I have probably shaved 6 months off the V1.0 stable release (I'm looking far ahead) while delivering new functionality every month. In fact, I expect that the Qoole-AID team will have the basics (and probably more) of the mesh editor done by the middle of March 2002.