I started a new topic here, because the name of the old topic does not reflect the accepted version of my project (several changes were made while in negotiations at the "accept" step).
The major change was that I considered inclusion of standalone .fx material converter as an alternative to a plugin for FXComposer. Right now I am in the position to think about features to be implemented in the tool, so the "final" proposal was:
So, I would like some feedback on features, that might be useful in .fx exporter, so that I can select the best approach towards completing that one.[Project: OGRE]
[Title/Summary: RmOgreExporter (v2), FxOgreExporter]
[Name: Vladimir Sukhoy]
[IM: Google Talk email@example.com]
[Time Dedication for the Project]
3-4h (at least) on weekdays. 5-8h on weekends.
Existing RmOgreExporter code base will be used to enhance the tool to a newer
level of usability. A better level of integration between existing major
shader/material designer software and OGRE engine is a major goal.
Following features are to be completed as a part of the project.
* [pylogic] rewrite exporter logic in Python and bundle interpreter code
with the software, so that users will be able to contribute and tweak the
exporter for their tasks.
* [import] add import capabilities to the plugin, so that people can
edit their existing OGRE materials in shader designers (RenderMonkey) and then
export the result back into OGRE.
* [scripting] add scripting capabilities for 'batch' export.
* [previewer] add optional preview capability to the tool.
Following two features may not be completed together because of time
constraints and are in some way equivalent.
Therefore there is an alternative and a choice is between following
* [fxcomposer] design other features and adapt the codebase so that the tool
can be used with another shader designer and eventually implement FX
Composer plugin as the result of this effort.
* [fxexporter] Create a cross-platform .fx exporter with
capabilities similar to RenderMonkey plugin. Reuse the codebase which
will be developed e.g. for Ogre preview in RenderMonkey. The two tasks
are related, therefore there is some expected code reusage. The
exporter is to be coded mainly in Python to simplify tweaking for the
There is a similar SoC proposal in OGRE forums:
http://ogre3d.org/phpBB2/viewtopic.php? ... dbbe017e47
although it is not very detailed.
In case this SoC project is to be approved by OGRE, it is up to the
community to decide which capability is of more interest and value for
the future of the project.
* [doc] document the code being developed and come up with 'User's Manual'.
* [rmogl] support OpenGL branch of RenderMonkey (it is not supported in
* [exflex] - more flexibility to export scripts (different directories,
different material names...)
* [persistence] - make export/import options persistent in the workspace file.
* [zipbackend] - implement zip backend for export/import.
* [improv] - Improve tool intelligence to deal with inherent differences in
shader designer's material model and OGRE material framework.
* [idefiles] - More makefiles/project files/solutions for more IDEs
(e.g. MSVS .NET 2005, and MinGW support)
* [meshimport] - Import OGRE's mesh geometry files (.mesh) into Shader
* [varsup] - More variables supported by OGRE:
(camera in world space, ambient light color, ...)
* [installer] - Package the tool and provide installer.
May-June 2006: pylogic, rmogl, exflex, persistence, zipbackend,
exflex, varsup, previewer
July 2006: import, meshimport, improv, fxcomposer/fxexporter
August 2006: installer, scripting, idefiles, doc and catch-up.
[Background with OGRE]
The original version of RmOgreExporter was developed by me for VeritableSoft
LLC in 2004-2005. In early 2005 the exporter was made available for OGRE
community. A little later the source of the exporter was released under MIT
license (with me in the copyright holder list). After being released,
the code was somewhat modified by the community, but I couldn't detect any
The fact that I am the author of the existing codebase is the key element in
my assurance of being the best person to do this project.
I also did some development with OGRE before creating RmOgreExporter, but
I do not have proper authorization from related employers to disclose the
details of the work.
My resume is available at http://sukhoy.public.iastate.edu/soc2006/resume.htm
* I have background in C/C++ development for Windows and long-term
experience using major tools involved (All Microsoft IDEs and make-like tools).
* I have some long-term experience with Python scripting language.
* I have some long-term experience with 3D Programming.
* I am familiar with CVS and newer source control systems, like Subversion.
* I have prior experience with Summer Of Code as a participant.
* I have experience writing FOSS since 1998.
* I am a graduate student for PhD in Applied Maths at Iowa State University,
I developed proactive I/O library for Python. The description is available at
http://pyasynchio.berlios.de/pyasynchio-about.htm. My mentoring organization was
PSF (Python Software Foundation) and Mark Hammond (the author of PyWin32)
was my mentor for SoC 2005. The project was reported successful to Google.
The idea was to generalize asynchronous I/O capabilities present in today's
OSes and create useful and convenient interface for Python and maybe
other scripting languages. Existing designs (most notably, ACE Proactor pattern
by Doug Schmidt) were studied. Eventually a poll()-like interface was
implemented and the library was released (unfortunately only the
of the library is currently available, although I believe the interface
developed is both general and useful enough to be reimplemented on other OSes).
I had an excellent experience with SoC 2005 and Mark was extremely helpful as
a mentor. He provided invaluable insight on Open Source and Python development
community besides mentoring my project.
I hope to devote more efforts and release new versions of pyasynchio in
future (I have a lot of interest in resuming pyasynchio once coroutines will
be properly supported in Python, because there may be extremely interesting
implications on the way I/O processing is done in applications!). I also think
about implementing asynchio for Common Lisp (the language I am currently
learning on the background).
Meanwhile you can look at the updated wiki http://www.ogre3d.org/wiki/index.php/SoC2006_RmExporter
If there is any interest, I can release "midterm" binaries of RenderMonkey stuff somewhere. "RenderMonkey SDK for python" is pretty much there, so just in case some of you want to do some python plugin for RenderMonkey...