[GSoC 2008 - Accepted] OgreCollada

Threads related to Google Summer of Code
User avatar
nanocell
Google Summer of Code Student
Google Summer of Code Student
Posts: 37
Joined: Wed Oct 25, 2006 6:03 pm
Location: Stellenbosch, South Africa.
Contact:

[GSoC 2008 - Accepted] OgreCollada

Post by nanocell »

I know this is not directly part of Ogre, but heck, OgreCollada can be a major asset to the Ogre community. It's a fantastic replacement for the dotScene format (which we know needs an update) and I'm sure most of us have been plagued at one stage or another by getting that dang camera animation from [insert your 3D animation package here] to Ogre or animate all those objects in place or just to get the general feeling of "gee, that was easy to load the whole scene and all it's animations",

At the moment things that needs to be finished on the project:
*animation support – both skeletal and morph/pose.
*Collada Viewer - which will also double as an editor and exporter
*Throw a multitude of different Collada files at the OgreCollada to make sure it works ;)

Any comments?

-----------
Here is the latest edit of the proposal (April 1st):

OgreCollada - Digital Asset Exchange for Ogre.

OgreCollada Overview:
---------------------
The OgreCollada project (written in C++, utilising the FCollada API) was started by Gregory "Xavier" Junker. The idea is to use COLLADA as intermediate format the Ogre content create pipeline. OgreCollada has a command line utility, ColladaConverter, which is used to convert COLLADA files to production ready content, e.g., using COLLADA as a scene graph format while storing mesh data in Ogre's binary format and writing COLLADA FX shaders to Ogre materials scripts (Note that the ColladaConverter utility is not yet functional). Another utility in the OgreCollada toolset is the ColladaViewer. The purpose of the viewer is, at the moment, mainly to preview COLLADA documents (meshes, shaders, animations). This GSoC will mainly focus on implementing skeletal animation support for OgreCollada.

Motivation:
-----------
The main advantage that OgreCollada provides is an improvement in Ogre's content creation pipeline. Many popular 3D modelling / shader authoring software sports COLLADA and/or COLLADA FX exporters. This relieves Ogre users of the burden of having to develop specialised exporters, intermediate file formats and parsers. OgreCollada would allow Ogre users to gain access to as much authored content as possible and can then selectively use whatever they need.

OgreCollada Scope for GSoC 2008:
--------------------------------
This will be a continuation of the OgreCollada project started by Gregory Junker. The biggest piece missing in the puzzle is support for skeletal animation. It has been mentioned on the Ogre forums that "skeletal animation" on its own does not sound ambitious enough for a full GSoC term. This has been discussed with Gregory Junker, who already attempted to implement skeletal animation support, and he advised that it may easily take up to 80% of the GSoC term to implement it. To emphasise the fact it is difficult consider that the original ColladaPlugin (see Ogre addons) had no animation support whatsoever. As for other 20% (or maybe a bit less) of the GSoC I'd like to spend 10-15% of that time testing skeletal animation support with various COLLADA documents and other 5% to writing proper documentation for OgreCollada explaining the inner workings as well as illustrating how to use OgreCollada. The documentation should include a list of features that are currently implemented, features that are pending and COLLADA features that is not of interest (similar to this page: http://colladablender.illusoft.com/cms/ ... ory/18/44/).
A DAE repository will be created with sample COLLADA files demonstrating the major areas of functionality. Each major functionality will have a sample file exported from Maya as well as 3D Studio Max. (XSI testing will follow at a later stage. Not in this GSoC term). Each .DAE file will have an accompanying text file that describes the data contained within, including the program, exporter and version numbers used to create the file as well as any additional information that might be relevant.

DAE Repository: Major areas of functionality
--------------------------------------------
The repository will have one sample file each illustrating a major area of functionality in OgreCollada. For each major area a sample file will exported from 3D Studio Max and another from Maya (more files will be added in the future as the application testing base expands, starting with XSI).

- Shaders: Single pass programmable CG shaders.
- Shaders: Multi pass programmable CG shaders.
- Scene node animation: nodes with transformation, scaling and rotation animations.
- Animated cameras.
- Animated lights.
- Skinned mesh with skeletal animation.

License:
--------
OgreCollada has been developed under the MIT license.

Current State of OgreCollada:
-----------------------------
The OgreCollada plugin can load triangulated mesh data (ignores other types of mesh data for now), textures/materials, lighting, scene node animations (translation, rotation, scaling), uv coordinates and COLLADA FX shaders. The COLLADA FX shader support is quite mature and very usable. OgreCollada already supports single and multipass programmable shaders but the COLLADA FX support for setting render targets, performing scene blending, etc., has not yet been implemented. Note that only the CG shading language is currently supported. OgreCollada also has a nifty callback mechanism that would allow the programmer to process content in a custom manner. This can be used when a programmer might want to put all the scene nodes who's names start with "trigger_" to be grouped under a specific scene node called "Triggers". Another use of the callback mechanism might be when using some sort of editor that would alter the actual COLLADA document (by using the FCollada API) in order to write it back out again. Note that callbacks are implemented as support for Ogre's resource types are added to OgreCollada.
The ColladaViewer can currently open Collada documents and allow the user to rotate/zoom as well as play the scene node animations. The ColladaViewer is developed with wxWidgets for portability. OgreCollada's command line converter, ColladaConverter, is a work-in-progress which is not usuable at the moment.

Things not part of the GSoC 2008 scope:
---------------------------------------
The most important thing to not that falls outside of the GSoC 2008 scope is vertex animation (morph/pose). Skeletal animation has proved itself a daunting adversary and implementing vertex animation has not yet been explored therefor the complexity of vertex animation is unknown. Note that the vertex animation if a potential rabbit hole (who knows how deep it may go).
The ColladaConverter will also fall outside the scope of the GSoC 2008 because skeletal animation has the highest priority which runs the risk of occupying the whole GSoC term.

Scope Constraints / Development Plan:
-------------------------------------
In order to make the skeletal animation implementation more managable, the following constraints will be followed. Implementation will focus on the COLLADA 1.4.x specification. It will also only support loading of animation clips (unnamed animation sequences will be ignored, for now). The skeletal animation will the tested against Maya and 3D Studio Max exports (using the ColladaMaya and ColladaMax plugins from Feeling Software, respectively).

1) Startup Phase: Familiarise with FCollada API and existing source code (2-4 days)
2) Implementation Phase: (from 30th of May onward)
- If this is functional by 21st of July, then start the testing phase.
- If it is not functional, then work until 4th August then start the documentation phase.
3) Testing Phase (2 Weeks: from 21 July to 3 August):
- Perform rigorous testing with COLLADA documents containing a single skinned mesh and multiple skinned meshes from both 3D Studio Max and Maya.
- Fix skeletal animation bugs uncovered by testing.
- Document known bugs that still requires fixing by the end of this phase.
4) Documentation Phase (1 Week: 4th of August through 10th of August)
- Write a user manual explaining the usage as well as the inner workings of OgreCollada
- Clearly document implemented features and missing/pending features and known bugs.
5) Soft pencils down (11th of August to 17th of August)
- Scrub the code and finish up the documentation if it is not complete already.

Deliverables:
-------------
* Support for animation of skeletal structures: First due date: 21st July. If not completed yet then the final due date is: 4th August.
* DAE repository: Sample files with descriptive text files. Part of the testing phase. Due 4th August.
* Documentation: User manual, feature list, known bugs list. Due 10th of August.

A Note on various application exports:
--------------------------------------
Different applications may export their accompanied by extra or profile tags that may require interpretation in order to correctly load the data. This will be application specific and would require that many application exports be tested. Also, there are many ways of exporting the same thing so different applications will export the data differently (although it may still be according to specification). OgreCollada simply has to be tested thoroughly with various exports to make sure that the widest range of COLLADA documents are supported.

Additional Work:
----------------
If it happens, by some miracle, that the skeletal animation is done before the GSoC term is complete then some more work can be picked from this list:

* Fix bugs in the ColladaViewer and make sure skeletal animations can be previewed correctly. Also check that the animation menus are cleared and populated correctly when a new COLLADA document is loaded.
* Start working on vertex animation support (first morph, then pose animation).
* Implement/fix support for XSI scene node animations.
Last edited by nanocell on Mon Apr 21, 2008 8:52 pm, edited 5 times in total.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

I actually have a new version of the Collada plugin to upload from a student at TU Wien - I've been meaning to review it but hadn't yet, I'm going to do it now. I know some others here were working on an FCollada-based system too (xavier?).
User avatar
nanocell
Google Summer of Code Student
Google Summer of Code Student
Posts: 37
Joined: Wed Oct 25, 2006 6:03 pm
Location: Stellenbosch, South Africa.
Contact:

Post by nanocell »

The OgreCollada plugin I was refering to is actually the one that Xavier is busy working on. I was hoping to see that in the GSoC :). Very nice one.

Xavier's OgreCollada plugin makes use of the FCollada API for loading Collada files as well.
A programmer is someone who solves a problem that you didn't know you had, in a way that you don't understand.
kex
Google Summer of Code Mentor
Google Summer of Code Mentor
Posts: 49
Joined: Thu May 24, 2007 8:57 am

Mentor Application

Post by kex »

Mentor Application
====================

I work for a company called NetAllied Systems based in Tettnang, Germany, near Lake Constance.
As we have experiences with OGRE and COLLADA we are very interested in mentoring this project.

First I want to give a short overview of what we have done so far. For the past 1.5 years we have been involved
in COLLADA development. Big parts of the upcoming COLLADA 1.5 specification have been
worked out by us. We also took part in the development of COLLADA-DOM, an alternative to fCOLLADA.
One of our (soon to be opensourced) projects is a COLLADA-DOM based, extensible conversion framework
for different 3D file formats e.g. SketchUp, U3D, OpenCascade. We already have a plugin for that framework to write OGRE
meshes that is not complete (supports not all of COLLADA) and has potential for being improved. Furthermore we
are the maintainers of ogre4j and provide Eclipse RCP based applications which utilize ogre4j to render 3D content.

Here are some YouTube videos of what we have done so far:
- http://www.youtube.com/watch?v=YKCnxPGFF0Q
- http://www.youtube.com/watch?v=PqStc51Gago
- http://www.youtube.com/watch?v=MXj8__Ow0zg
- http://www.youtube.com/watch?v=kCLocWJgN4s


Design issues for this project
=================================
One point is the COLLADA parser to use. Currently there are two available: FCollada and COLLADA-DOM.

Another question is if conversion should take place at runtime and/or before with an external tool. I prefer
the latter because of the following benefits:
OGRE is designed to load its own, optimized mesh files, while other formats (e.g. Blender, Maya) are
handled by external tools. COLLADA is designed as an exchange and not as a runtime format. There are some things in the
COLLADA spec which may be difficult to map to OGRE (e.g. shaders, animations, physics, effects,
LineStrips) and thus conversion may take longer as an user would be willing to wait at runtime.

There are some problems to solve with the external tool approach, too. An important question is where to
store the scene graph. I could imagine to load 3D objects from mesh-files while loading the scene from COLLADA.
Another scene related point is which scene manager and shadow technique to use. That could be stored
in the COLLADA extra-tag.

Basic conversion problems arise from different design principles in OGRE and COLLADA. For example animations. OGRE
maps skeletons directly to meshes while in COLLADA these things are independet and can be brought together via
scene nodes. COLLADA scene nodes can be created in a library visual scene or directly in an instance visual scene.
Furthermore one has to decide which COLLADA geometries are combined to an OGRE mesh. Creating a mesh for each
single geometry may result in many (a few hundred thousand) meshes. Using the OGRE submesh concept would be more sane here.
As OGRE maps animation-skeletons to meshes, COLLADA animations may be destroyed when geometries are not combined as
submeshes. Scene node based animation is also possible in OGRE but not persistable. The approach of loading parts
from COLLADA at runtime could be used here, too.
To put this together: OGRE uses a straight forward direct mapping and two different structures (scene graph and mesh
internal structure) while in COLLADA everything is open, independent and combineable.

On the other hand, loading COLLADA at runtime has the advantage being easier to develop as the extra conversion step would not be needed.


Summary / ToDo
==============
1. FCollada or COLLADA-DOM decision (2 days)
2. Offline, Online or mixed implementation decision (2 days)
3. How to merge geometries to submeshes (2 weeks) /
alternative ManualMesh implementation
4. Scene graph parsing, optimizations (1 week)
5. Convert shaders (1 week)
6. Convert animations (1 week)
7. optional import physics (1-2 weeks)





Please share your comments with us and help to include COLLADA support into Ogre3D!
Last edited by kex on Mon Mar 17, 2008 9:59 am, edited 1 time in total.
User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2703
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 51

Re: Mentor Application

Post by syedhs »

kex wrote: 5. Convert shaders (1 weeks)
I would like very much this feature to be complete. Specifically, I would like to use FX Composer and export it for Ogre uses via Ogre-Collada.

1. Can you comment on how you are going to test this? I imagine using FX Composer and have it output via this tool and then test it in an Ogre. testbed application.

2. How sure you are to complete within one week? Because to my limited knowledge, it seems to be quite a big task.. but you know this better of course :wink:
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
kex
Google Summer of Code Mentor
Google Summer of Code Mentor
Posts: 49
Joined: Thu May 24, 2007 8:57 am

Post by kex »

FX Composer writes shaders to COLLADA in profile "COLLADA FX Cg" which contains a <code> element including
the CG code. Only parameter and return binding must be converted. Furthermore there is already a (COLLADA-DOM based)
sourceforge project to convert COLLADA CG shaders into COLLADA GLSL shaders (MIT license). With FxCleaner there is an
(COLLADA-DOM based) optimization utilitiy, too. Using these COLLADA refinery conditioners as libraries in
different applications is also pretty easy. All in all one week should realy be enough.
1. Can you comment on how you are going to test this?
No idea how automatic testing could be done. One have to watch the shader in some application, import it into OGRE and watch it again. As the shader code can just be copied, this should not be a big issue. To test if parameters are passed correctly, a test framework/application should be doable.

SourceForge project page:
- http://sourceforge.net/projects/collada-cg2glsl/
COLLADA wiki:
- http://www.collada.org/mediawiki/index. ... onditioner
- http://www.collada.org/mediawiki/index. ... onditioner
kex
Google Summer of Code Mentor
Google Summer of Code Mentor
Posts: 49
Joined: Thu May 24, 2007 8:57 am

Wiki update

Post by kex »

I added this project to the wiki page:
http://www.ogre3d.org/wiki/index.php/HelpRequested
User avatar
josiasjr
Gnoblar
Posts: 3
Joined: Thu Mar 20, 2008 5:58 am
Location: Goiania, Brazil
Contact:

Post by josiasjr »

Hi everyone! This is my first time in this forum. I'm always liked the content of this place, it's very rich in information. Excuse me if my english is like "All your base are belong to us" but I use a dictionary on my side to help me in writing my messages.
I just have a question about if I'm reinventing the wheel.
I have heard about FCollada API and COLLADA-DOM but never worked with them, instead I just trying to use the Expat parser (http://expat.sourceforge.net) to work with DAE files and it's arduous work to code because the API is very low level.
Do I want to know if i lost my time using the Expat or it worth my time for the experience to know new something?
Westheimer's Discovery:
A couple of months in the laboratory can frequently save a couple of hours in the library.
kex
Google Summer of Code Mentor
Google Summer of Code Mentor
Posts: 49
Joined: Thu May 24, 2007 8:57 am

Post by kex »

Do I want to know if i lost my time
Well, using fCOLLADA or COLLADA-DOM saves a lot time.
it worth my time for the experience to know new something
Of course, you can never know enough :)
By using a low level XML parser you get to know the documents much better.
User avatar
nanocell
Google Summer of Code Student
Google Summer of Code Student
Posts: 37
Joined: Wed Oct 25, 2006 6:03 pm
Location: Stellenbosch, South Africa.
Contact:

GSoC

Post by nanocell »

Okay people. This is my project proposal for the OgreCollada project (which have been submitted). Please have a look and do comment. Thanks!!

OgreCollada - Digital Asset Exchange for Ogre.

Abstract:
---------
The goal of this project is somewhat twofold. Firstly, the OgreCollada plugin will allow for 3D content to be imported to Ogre applications (as an intermediate format) from various 3D modelling / animation packages that support the Collada format. Second, the Collada format can double as a native scene graph format. A part of the OgreCollada project consist of the ColladaViewer which should eventually evolve into a fully fledged scene editor. The medium term goal for the ColladaViewer is to import one, or more, Collada file(s) and export the data again but in a production-ready format.

License:
--------
OgreCollada has been developed under the MIT license.

Project Details:
----------------
This project will be a continuation of the OgreCollada project started by Gregory 'Xavier' Junker, developed using C++. The OgreCollada project is still in a pre-alpha stage. OgreCollada utilises the FCollada API (which is compatible with Collada 1.4.x) to parse the Collada files and resolve references.

The ColladaViewer has been developed using wxWidgets for portability. As it stands the viewer allows the user to preview a Collada document in an Ogre render window. The viewer should, for the scope of this project, allow the user to preview scene node animations, select various entities in the scene and present the user with a list of skeletal animations that can be played. Optionally, the viewer should allow the user to rename the objects/entities and the animations and finally provide the option of saving the Collada document again.

Collada FX (shader effects) support is quite mature and usuable at this point and consequently it was decided that shaders should not form part of the scope of this project. OgreCollada already supports single and multipass programmable shaders but the Collada FX support for setting render targets, scene blending, etc., has not yet been implemented.

The largest part, and by far that with the highest priority, of the project scope consist of implementing support for animation. OgreCollada already supports scene node animation, i.e., rotation, translation and scaling of scene nodes. The highest priority with regards to animation is complete skeletal animation support. Skeletal animation has been partially implemented but is by no means functional (it's actually closer to unimplemented). The second, but optional, part of the animation scope is to implement support for vertex animation (both morph and pose). The reason why the vertex animation is optional here is that skeletal animation will most likely occupy most the development time and the two type of vertex animations are potential rabbit holes (who knows how deep they will go?).

OgreCollada also supports a callback mechanism that would allow the programmer to process content in a custom manner. This can be used when a programmer might want to put all the scene nodes who's names start with "mark_" to be grouped under a specific scene node called "Markers". Another use of the callback mechanism might be when using some sort of editor that would alter the actual Collada document (by using the FCollada API) in order to write it back out again. Note that callbacks are implemented as support for Ogre's resource types are added to OgreCollada.

And last, but not least, documentation. During the development all function prototypes will be commented with doxygen-style comments (similar to that of Ogre) and the source code will be commented where it is needed (existing code also needs commenting). A manual needs to be written explaining the inner workings and illustrating how to use OgreCollada, its callbacks and other little doodads.

Project Motivation:
-------------------
The main reason that I want to do this project for Google Summer of Code is because I'm working on a project (a game) that requires Collada integration with Ogre and I'll have to do it anyway. I enjoy working on anything related to 3D graphics and game development. The OgreCollada project will provide a practical alternative to the dotScene file format (which has been in dire need of improvement or replacement for some time now) and should prove to be a great asset to the Ogre community. OgreCollada will enable developers to load meshes, complete scene graphs, lighting, shaders, animations, etc., with minimal effort. This project is in production use at Hyperpia (www.hyperpia.com) which will help in tracking down bugs and will benefit Hyperpia as much as it will aid the rest of the Ogre users.

Platforms:
----------
The project is intended, as all good Ogre-related software, to be cross platform. I can only test this project on Linux and Windows, though.

Checklist:
----------
Mandatory
-----------
* Skeletal Animation - Support ColladaMaya and ColladaMax exports.
* Documentation - Document the API and write a user manual.

Optional (High priority)
---------------------------
* Support Collada files exported from SoftImage XSI's crosswalk exporter.
* Support Vertex (morph and pose) animation.
Optional (Low priority)
--------------------------
* Add renaming and saving facilities to the viewer.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

Mandatory
-----------
* Skeletal Animation - Support ColladaMaya and ColladaMax exports.
* Documentation - Document the API and write a user manual.
Doesn't seem very ambitious to me for a whole Gsoc, or Collada reading is that hard to implement ?

A gsoc should give enough time to read/write nearly all collada information and even be able to distribute it (to physic engine) when needed. Only shader conversion would be tedious, but as linked above some existing tool can help there.

Second, the Collada format can double as a native scene graph format
As said before gsoc really focus on core things directly useful to Ogre.
A part of the OgreCollada project consist of the ColladaViewer which should eventually evolve into a fully fledged scene editor.
People just want to integrate collada-ogre format conversion into their pipeline, and use their own tools rather than collada/ogre specific tools.
Scene and Mesh Viewer seems rather out of scope, as primary objective should be in-out command line converter like OgreXmlConverter. (still the cmd tool could link to a ogrecollada lib usable by a plugin/viewer/scene)

I think you should propose a planning that focus on that, making the conversion the most precise possible, including material/shaders, including multiple sub-implementations if any choices are to be made (depending on cmd line options) about geometries, sub meshes, etc.
SoftImage XSI's, ColladaMaya and ColladaMax exports.
Are they that different ? You need to make a reader for each ?!?!
Don't tell me they already broke the intercompatibility idea ?
User avatar
nanocell
Google Summer of Code Student
Google Summer of Code Student
Posts: 37
Joined: Wed Oct 25, 2006 6:03 pm
Location: Stellenbosch, South Africa.
Contact:

Post by nanocell »

I know simply stating "Skeletal animation" doesn't sound ambitious but I have thoroughly discussed with Xavier what the scope of the GSoC project should be and he said that skeletal animation support will easily take up 80% of the time. He spent an awful long time trying to implement it.

And the fact that it's difficult is most likely the reason why the first Collada plugin didn't have animation support at all.
People just want to integrate collada-ogre format conversion into their pipeline, and use their own tools rather than collada/ogre specific tools.
Scene and Mesh Viewer seems rather out of scope, as primary objective should be in-out command line converter like OgreXmlConverter. (still the cmd tool could link to a ogrecollada lib usable by a plugin/viewer/scene)
Xavier started working on such a command line utility but there are a few issues to sort out (one being the fact that Ogre needs a rendering window to load textures). But I understand what you're saying. Good point. I'll think about it for a bit and get back to you.
Are they that different ? You need to make a reader for each ?!?!
Don't tell me they already broke the intercompatibility idea ?
Each application exports it's data in a different way. Max and Maya's exporting is rather similar (Feeling Software developed both exporters) but XSI's exporter was developed inhouse which causes quite a few problems (breaking the specification and whatever).
It's not that you have to develop a different reader for each; you just have to make sure that the reader can handle all the different ways that data is thrown at you. And believe me, it's not that easy. I tried to tackle the scene node and skeletal animation before.

The problem with the skeletal animation is that it is a rabbit hole and it's quite deep. Anyways.
As said before gsoc really focus on core things directly useful to Ogre.
I got that part and I know that using Collada as a scene graph format is not a direct improvement on Ogre's core, but it's definitely an improvement on the content creation workflow part of Ogre. Is there any way I can make it sound more appealing?

Thanks for your feedback. I'll most likely make some adjustments accordingly.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

Xavier [...] said that skeletal animation support will easily take up 80%
Ok, now planning is more clear, but you have to elaborate and explain that.

Isn't there any way to make assumptions/constraints/choice so that it would be easier (stick to 1.4 only, make exporter use a particular way, etc...).
Tried to check any other opensource importer/exporter/viewer on that ? (isn't blender doing one?)
Does pose animation have same state/complexity ?

What's current state of ogrecollada ? material, shader, meshes ?
And any hope from what Sinbad received from a kind student ?
you just have to make sure that the reader can handle all the different ways that data is thrown at you. And believe me, it's not that easy.
Well, I'm really beginning to question myself on Collada is of any interest at all now...
User avatar
nanocell
Google Summer of Code Student
Google Summer of Code Student
Posts: 37
Joined: Wed Oct 25, 2006 6:03 pm
Location: Stellenbosch, South Africa.
Contact:

Post by nanocell »

Isn't there any way to make assumptions/constraints/choice so that it would be easier (stick to 1.4 only, make exporter use a particular way, etc...).
We are sticking to 1.4 only. As for using the exporter in a specific way: We mainly focused on exporting animation tracks for a skinned mesh (in Blender language: exporting an armature and it's mesh with all the armature's actions). That would actually be one constraint to simply things.

There is a Collada importer/exporter for Blender (although it does not import yet). As far as animation is concerned, it can only export a skinned mesh thus far. No actual animation yet. Not even scene node animation as far as I can tell. (http://colladablender.illusoft.com/cms/ ... gory/18/44)

We have no idea what the complexity of morph/pose animation is (and is anyway considered a much lower priority than skeletal animation, at the moment).

Current state of OgreCollada: It supports exporting of static scenes (meshes, textures, materials, cameras, lighting), animated scene nodes.
Shaders can be successfully exported from Maya and 3D Studio Max with the modified exporters in the OgreCollada repository. The exporters from FeelingSoftware only exported annotations that they knew about. Xavier modified them to export all the annotations to the ColladaFX shaders because the annotations were overloaded to pass through to Ogre shader parameter bindings.

All of the above mentioned works. The one crucial ingredient that is missing is the skeletal animation.
And any hope from what Sinbad received from a kind student ?
We weren't that interested in it mainly because it uses the Collada DOM directly (which is a pain). There is code for skeletal animation but there is nowhere an indication of whether it is complete or not. So, I'll mark this with a *maybe*.

The thing about Collada that is of interest if the fact it saves many developers from having to code export plugins, scene graph formats, intermediate shader formats, etc., for their respective 3D modelling software. And if a few people can put a bit of effort into making a something like the OgreCollada utility work then they have been saved a heap of trouble.
A programmer is someone who solves a problem that you didn't know you had, in a way that you don't understand.
User avatar
nanocell
Google Summer of Code Student
Google Summer of Code Student
Posts: 37
Joined: Wed Oct 25, 2006 6:03 pm
Location: Stellenbosch, South Africa.
Contact:

Post by nanocell »

There is a shimmer of hope for animation. There is an open source ColladaLoader (http://sourceforge.net/projects/colladaloader/) written with the FCollada API that supports skeletal animation. I didn't see any support for "animation clips" but it does play an animation sequence with a skeleton and skinned mesh and some other various animated objects (see the included sample files).

--edit--
Negative. The sample file does not contain skeletal animation :(. Back to square 1.0
User avatar
nanocell
Google Summer of Code Student
Google Summer of Code Student
Posts: 37
Joined: Wed Oct 25, 2006 6:03 pm
Location: Stellenbosch, South Africa.
Contact:

Post by nanocell »

Okay. OgreCollada proposal number 2. I rewrote the 90% proposal. Let me know what you think!!

OgreCollada - Digital Asset Exchange for Ogre.

OgreCollada Overview:
---------------------
The OgreCollada project (written in C++, utilising the FCollada API) was started by Gregory "Xavier" Junker. The idea is to use COLLADA as intermediate format the Ogre content create pipeline. OgreCollada has a command line utility, ColladaConverter, which is used to convert COLLADA files to production ready content, e.g., using COLLADA as a scene graph format while storing mesh data in Ogre's binary format and writing COLLADA FX shaders to Ogre materials scripts (Note that the ColladaConverter utility is not yet functional). Another utility in the OgreCollada toolset is the ColladaViewer. The purpose of the viewer is, at the moment, mainly to preview COLLADA documents (meshes, shaders, animations).

Motivation:
-----------
The main advantage that OgreCollada provides is an improvement in Ogre's content creation pipeline. Many popular 3D modelling / shader authoring software sports COLLADA and/or COLLADA FX exporters. This relieves Ogre users of the burden of having to develop specialised exporters, intermediate file formats and parsers. OgreCollada would allow Ogre users to gain access to as much authored content as possible and can then selectively use whatever they need.

OgreCollada Scope for GSoC 2008:
--------------------------------
This will be a continuation of the OgreCollada project started by Gregory Junker. The biggest piece missing in the puzzle is support for skeletal animation. It has been mentioned on the Ogre forums that "skeletal animation" on its own does not sound ambitious enough for a full GSoC term. This has been discussed with Gregory Junker, who already attempted to implement skeletal animation support, and he advised that it may easily take up to 80% of the GSoC term to implement it. To emphasise the fact it is difficult consider that the original ColladaPlugin (see Ogre addons) had no animation support whatsoever. As for other 20% (or maybe a bit less) of the GSoC I'd like to spend 10-15% of that time testing skeletal animation support with various COLLADA documents and other 5% to writing proper documentation for OgreCollada explaining the inner workings as well as illustrating how to use OgreCollada. The documentation should include a list of features that are currently implemented, features that are pending and COLLADA features that is not of interest (similar to this page: http://colladablender.illusoft.com/cms/ ... ory/18/44/).

Current State of OgreCollada:
-----------------------------
The OgreCollada plugin can load triangulated mesh data (ignores other types of mesh data for now), textures/materials, lighting, scene node animations (translation, rotation, scaling), uv coordinates and COLLADA FX shaders. The COLLADA FX shader support is quite mature and very usable. OgreCollada already supports single and multipass programmable shaders but the COLLADA FX support for setting render targets, performing scene blending, etc., has not yet been implemented. OgreCollada also has a nifty callback mechanism that would allow the programmer to process content in a custom manner. This can be used when a programmer might want to put all the scene nodes who's names start with "trigger_" to be grouped under a specific scene node called "Triggers". Another use of the callback mechanism might be when using some sort of editor that would alter the actual COLLADA document (by using the FCollada API) in order to write it back out again. Note that callbacks are implemented as support for Ogre's resource types are added to OgreCollada.
The ColladaViewer can currently open Collada documents and allow the user to rotate/zoom as well as play the scene node animations. The ColladaViewer is developed with wxWidgets for portability. OgreCollada's command line converter, ColladaConverter, is a work-in-progress which is not usuable at the moment.

Things not part of the GSoC 2008 scope:
---------------------------------------
The most important thing to not that falls outside of the GSoC 2008 scope is vertex animation (morph/pose). Skeletal animation has proved itself a daunting adversary and implementing vertex animation has not yet been explored therefor the complexity of vertex animation is unknown. Note that the vertex animation if a potential rabbit hole (who knows how deep it may go).
The ColladaConverter will also fall outside the scope of the GSoC 2008 because skeletal animation has the highest priority which runs the risk of occupying the whole GSoC term.

Scope Constraints / Development Plan:
-------------------------------------
In order to make the skeletal animation implementation more managable, the following constraints will be followed. Implementation will focus on the COLLADA 1.4.x specification. It will also only support loading of animation clips (unnamed animation sequences will be ignored, for now). The skeletal animation will the tested against Maya and 3D Studio Max exports (using the ColladaMaya and ColladaMax plugins from Feeling Software, respectively).

1) Startup Phase: Familiarise with FCollada API and existing source code (2-4 days)
2) Implementation Phase: (from 30th of May onward)
- If this is functional by 21st of July, then start the testing phase.
- If it is not functional, then work until 4th August then start the documentation phase.
3) Testing Phase (2 Weeks: from 21 July to 3 August):
- Perform rigorous testing with COLLADA documents containing a single skinned mesh and multiple skinned meshes from both 3D Studio Max and Maya.
- Fix skeletal animation bugs uncovered by testing.
- Document known bugs that still requires fixing by the end of this phase.
4) Documentation Phase (1 Week: 4th of August through 10th of August)
- Write a user manual explaining the usage as well as the inner workings of OgreCollada
- Clearly document implemented features and pending features.
5) Soft pencils down (11th of August to 17th of August)
- Scrub the code and finish up the documentation if it is not complete already.


A Note on various application exports:
--------------------------------------
Different applications may export their accompanied by extra or profile tags that may require interpretation in order to correctly load the data. This will be application specific and would require that many application exports be tested. Also, there are many ways of exporting the same thing so different applications will export the data differently (although it may still be according to specification). OgreCollada simply has to be tested thoroughly with various exports to make sure that the widest range of COLLADA documents are supported.

Additional Work:
----------------
If it happens, by some miracle, that the skeletal animation is done before the GSoC term is complete then some more work can be picked from this list:

* Fix bugs in the ColladaViewer and make sure skeletal animations can be previewed correctly. Also check that the animation menus are cleared and populated correctly when a new COLLADA document is loaded.
* Start working on vertex animation support (first morph, then pose animation).
* Implement support for XSI scene node animations.
A programmer is someone who solves a problem that you didn't know you had, in a way that you don't understand.
kex
Google Summer of Code Mentor
Google Summer of Code Mentor
Posts: 49
Joined: Thu May 24, 2007 8:57 am

Post by kex »

Sorry that I did not participate in this discussion last week. From now on I will be faster. I promise!


FCollada
===========
First I want to talk a bit about FCollada. As stated in SF news (http://sourceforge.net/forum/forum.php?forum_id=794467) it is not further
developed by Feeling Software. SF lists 10 developers but some of them are from feeling who stopped working on this project. Last commit was
2 weeks ago (only maya) and 1 month ago for the other projects. I fear FCollada will not be continued at all and IMHO OGRE COLLADA should
use COLLADA-DOM. It is not such a pain, here are some promintent projects utilising it successfully:
- http://www.openscenegraph.org/projects/osg
- http://sourceforge.net/projects/colladarefinery
- http://www.nvidia.com/object/nvsg_home.html

I know, there is already much code in OGRE-COLLADA and porting this to COLLADA-DOM would take some time. But I believe it has to be done
anyway because FCollada is abandoned. So why not switch now instead of increasing the amount of code that has to be ported? Furthermore
FCollada supports not all of COLLADA and it must be extended manually while COLLADA-DOM is auto generated. As COLLADA 1.5 will be released soon,
FCollada will cause much work (this is important to make OGRE-COLLADA future proof).


Organisational
=================
As we have already reached the google deadline, you need a mentor comment to change your application (if you want to). I think
we should discuss this here and change the google pages afterwards.



COLLADA general
==================
Are they that different ? You need to make a reader for each ?!?!
Don't tell me they already broke the intercompatibility idea ?
COLLADA is very complex. It can store geometries as polygons, polylists, triangles, tristripps, trifans, lines and linestripps. You can have
libraries of different scenes, animations, ... which can be instanciated. It does not have a submesh concept as OGRE does. COLLADA uses geometries
and scene nodes therefore (mesh and material binding may be done via scene nodes, too). Moreover COLLADA allows different profiles and
the extra-tag which may contain application specific data.
This has led to the COLLADA-Refinery. It allows conversion of data inside a COLLADA document, e.g. polygons to triangles. It might be necessary
to use such a conversion in order to load a COLLADA file with a specific application (e.g. not all applications support trifans). BTW another
disadvantage of FCollada is that there are no conditioners using it.



Animations
============
Do I get you right that you want to support COLLADA <controller>/<skin> animations and not <animation>/<channel> ones?
This has been discussed with Gregory Junker, who already attempted to implement skeletal animation support, and he advised that it
may easily take up to 80% of the GSoC term to implement it.
Is this discussion public somewhere?
What must be done? In COLLADA you have <library_controllers> with some <controller> elements which reference meshes via <skin>. These <controller>s
have data sources, joints and vertex_weights. Then <controller>s are instanciated in scene nodes. This data must be converted into an OGRE skeleton
(COLLADA joints should match OGRE bones and vertex_weights are used in OGRE meshes). IMHO there could be problems with the hierarchy. It might be
that COLLADA meshes referenced in parent/child scene nodes must be converted into OGRE submeshes for animations to work.

(As I mentioned in a previous post, OGRE has to differentiate structures: the scene graph and the submesh structure while in COLLADA there is
only the scene graph)
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Post by xavier »

kex wrote: FCollada
===========
First I want to talk a bit about FCollada. As stated in SF news (http://sourceforge.net/forum/forum.php?forum_id=794467) it is not further
developed by Feeling Software. SF lists 10 developers but some of them are from feeling who stopped working on this project. Last commit was
2 weeks ago (only maya) and 1 month ago for the other projects. I fear FCollada will not be continued at all and IMHO OGRE COLLADA should
use COLLADA-DOM. It is not such a pain, here are some promintent projects utilising it successfully:
- http://www.openscenegraph.org/projects/osg
- http://sourceforge.net/projects/colladarefinery
- http://www.nvidia.com/object/nvsg_home.html

I know, there is already much code in OGRE-COLLADA and porting this to COLLADA-DOM would take some time. But I believe it has to be done
anyway because FCollada is abandoned. So why not switch now instead of increasing the amount of code that has to be ported? Furthermore
FCollada supports not all of COLLADA and it must be extended manually while COLLADA-DOM is auto generated. As COLLADA 1.5 will be released soon,
FCollada will cause much work (this is important to make OGRE-COLLADA future proof).
The primary reason for choosing FCollada is exactly the pain you claim is not so great. Between resolving and maintaining all of the cross-references to objects within a doc (as well as those in referenced docs) and the building and maintenance of a useful object model from the document's contents, I'd rather extend FCollada than (once again) re-invent the wheel in this case.

It is an extraordinary amount of effort trying to maintain an insulating layer between an application and the document structure. This issue you bring up about COLLADA 1.5 is PRECISELY the reason you do not want to use the COLLADA XML or DOM directly, and should use a layer between instead (such as FCollada). I already started down the DOM-API route, and the exact reason I chose FCollada is the intractable nature of the problems described -- rather than create a high-level abstraction layer every time a new COLLADA-based project is started, there should be one ready to go. FCollada fills that role.

Just because someone stops working on a piece of software, doesn't mean the software itself stops working. I should be asking you instead -- why don't you folks further a high-level library with tons of man-hours into it, rather than asking everyone, as it were, to go back to using assembly-language again? Instead of simply generating code from an XML Schema, make (or, I would rather, you further) an actual usable high-level library.

/rant=off
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Post by xavier »

kex wrote: Animations
============
Do I get you right that you want to support COLLADA <controller>/<skin> animations and not <animation>/<channel> ones?
This has been discussed with Gregory Junker, who already attempted to implement skeletal animation support, and he advised that it
may easily take up to 80% of the GSoC term to implement it.
Is this discussion public somewhere?
No; is that a problem?

And actually, no, controller/skin is *not* what I want to support. Building the skeleton works fine. Even doing bone weight assignments works fine. Assembling the animations is less easy. Maybe it's an exporter issue, maybe it's fundamental differences between how Ogre and COLLADA see the skeletal animation world, maybe it's just COLLADA being a bit too general to be straightforward in this area, but this turned out to be a major problem I found. In the end I left OgreCollada where it was because I had to move onto other problems, and for the time being OgreCollada served my needs.

Given that no other Ogre/COLLADA project has managed to implement skeletal animations, I would have to presume I am not the only one to run into this issue.
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
User avatar
nanocell
Google Summer of Code Student
Google Summer of Code Student
Posts: 37
Joined: Wed Oct 25, 2006 6:03 pm
Location: Stellenbosch, South Africa.
Contact:

Post by nanocell »

I think that if you seriously want to use the COLLADA DOM API as a parser, it can most likely be used as an FCollada backend. It's true that much effort has gone into FCollada to make the COLLADA data handling much easier and we shouldn't just throw that away.
A programmer is someone who solves a problem that you didn't know you had, in a way that you don't understand.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

@kex: keep in mind that planning has to be realistic: gsoc is about 1 student + 1 summer on one project.
I do agree with Xavier and Nanocell, using an opensource high level library rather to code for each collada version seems more adequate.

@nanocell: much clearer and complete application. Can you list deliverables (that could include test-suite checker application, dae test repositories, etc...)
kex
Google Summer of Code Mentor
Google Summer of Code Mentor
Posts: 49
Joined: Thu May 24, 2007 8:57 am

Post by kex »

FCollada
=================
Just because someone stops working on a piece of software, doesn't mean the
software itself stops working.
But using it is a dead end. COLLADA will be further developed, v1.5 is right before the door. Someday OGRE users will need new COLLADA files
and FCollada will not allow to load them. Okay, FCollada is open source so there might be someone who continues it but the probability
is quite low.

I should be asking you instead -- why don't you folks further a high-
level library with tons of man-hours into it, rather than asking everyone, as it
were, to go back to using assembly-language again? Instead of simply generating
code from an XML Schema, make (or, I would rather, you further) an actual usable
high-level library.
I think that if you seriously want to use
the COLLADA DOM API as a parser, it can most likely be used as an FCollada
backend.
Well, I understand your wish for a high-level API. An option might be the COLLADA-DOM Integration Templates.
They provide some assistance in the creation of a high-level API.
http://collada.org/mediawiki/index.php/ ... _templates


Why not continue FCollada?
- it is completely hand written
- it does not support the wohle COLLADA spec
- it is hard to maintain and extend
- it uses XML-DOM parsing and has thus a higher memory footprint (COLLADA-DOM uses XML stream parsing)
- it changes the loaded document in certain situations (when there are multiple libraries)
loading a file and writing it again may result in a changed document
- no i18 support. It replaces non-ASCII characters with underscores which may corrupt the document.



Animations
==================
No; is that a problem?
It would help me understand the problems with animations.
And actually, no, controller/skin is *not* what I want to support.
Ok, then I got you wrong on this.
maybe it's just COLLADA being a bit too general to be straightforward in this area
Yeah, I can imagine this.

So, where are the problems?
Is it conversion of COLLADA samplers & channels into OGRE vertex animation tracks?
I'll have a closer look on this.
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Post by xavier »

kex wrote:FCollada
=================
Just because someone stops working on a piece of software, doesn't mean the
software itself stops working.
But using it is a dead end. COLLADA will be further developed, v1.5 is right before the door. Someday OGRE users will need new COLLADA files
and FCollada will not allow to load them. Okay, FCollada is open source so there might be someone who continues it but the probability
is quite low.

I should be asking you instead -- why don't you folks further a high-
level library with tons of man-hours into it, rather than asking everyone, as it
were, to go back to using assembly-language again? Instead of simply generating
code from an XML Schema, make (or, I would rather, you further) an actual usable
high-level library.
I think that if you seriously want to use
the COLLADA DOM API as a parser, it can most likely be used as an FCollada
backend.
Well, I understand your wish for a high-level API. An option might be the COLLADA-DOM Integration Templates.
They provide some assistance in the creation of a high-level API.
http://collada.org/mediawiki/index.php/ ... _templates


Why not continue FCollada?
- it is completely hand written
- it does not support the wohle COLLADA spec
- it is hard to maintain and extend
- it uses XML-DOM parsing and has thus a higher memory footprint (COLLADA-DOM uses XML stream parsing)
- it changes the loaded document in certain situations (when there are multiple libraries)
loading a file and writing it again may result in a changed document
- no i18 support. It replaces non-ASCII characters with underscores which may corrupt the document.



Animations
==================
No; is that a problem?
It would help me understand the problems with animations.
And actually, no, controller/skin is *not* what I want to support.
Ok, then I got you wrong on this.
maybe it's just COLLADA being a bit too general to be straightforward in this area
Yeah, I can imagine this.

So, where are the problems?
Is it conversion of COLLADA samplers & channels into OGRE vertex animation tracks?
I'll have a closer look on this.
on animation: I don't know the problems, or there would be full animation support in OgreCollada already.

on integration templates (and DOM API in general): Kex, you act as if I have never heard of, or used, DOM API or anything related before. I'll repeat: I used the DOM API to the point that I was sick of it and looked for a high-level alternative. I've used every single bit of the DOM API already (including integration templates), and like I said, it's like using assembly language to code.

You also look at the DOM API with rose-colored glasses. You would have us all believe that it insulates us from future changes, but you don't explain how that is remotely possible when the DOM API is generated from the COLLADA XML Schema, and when the Schema changes, the API changes. That doesn't sound like insulation to me, that sounds like a guaranteed porting when the COLLADA spec changes again.

By targeting a high-level library instead of a low-level API like DOM API, you actually are insulating your code from low-level changes (such as the actual API you are using). In the end, you really aren't making much of a case for DOM API, and instead are sort of making my point for me. And IMO, it's a far better use of resources to fix, extend or finish FCollada since it's really the only high-level libraary option that exists at this point.
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
User avatar
okki
Halfling
Posts: 90
Joined: Mon Jan 03, 2005 3:14 pm
Contact:

Post by okki »

Cool down :lol:
Why do we encourage the use of the DOM API? Well probably because we did all of our conversion projects using it and are quite used to it now. We've developed some "Helper Classes" around it that eases usage and yes: you're right - it's still very close to the original XML document.

There are already lots of refinery tools based on the DOM API we're using (De-, Trifanner, De-, Tristripper, ...) and usage of the DOM assures that you have full control over the COLLADA document.

It's definitely more work to do and it was worth it in our case.

Let the student decide!
- ogre4j.org -
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Post by xavier »

I'm not getting upset -- I'm emphasizing. If I were getting upset it would be in capital letters. ;)

I had already started down the "helper classes" route when it occurred to me that someone must have done it already, and it was about that time I found out about FCollada.
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
Post Reply