Research: find out if we can keep visual objects and their materials in Collada

[GoogleCodeExporter]

Before we have any scene, we should decide what format to use. In Mahjong1 we 
used custom Ogre format which allowed to keep visual objects and their 
materials separate.
OSG supports Collada, so may be we can utilize it for the purpose.

Original issue reported on code.google.com by korn...@gmail.com on 25 Oct 2012 at 9:34

• Blocking: #579
• Blocked on: #582

[GoogleCodeExporter]

Original comment by korn...@gmail.com on 25 Oct 2012 at 9:35

• Now blocking: #579

[GoogleCodeExporter]

Build instructions: 
http://www.openscenegraph.org/projects/osg/wiki/Support/KnowledgeBase/Collada

Original comment by korn...@gmail.com on 25 Oct 2012 at 9:37

[GoogleCodeExporter]

Asked about Assimp support by osgRecipies ( 
https://github.com/xarray/osgRecipes/tree/master/integrations )
We might have a chance to use Blender files directly.

Original comment by korn...@gmail.com on 25 Oct 2012 at 11:18

[GoogleCodeExporter]

collada-dom library tgz takes 40M. That's quite a lot. Have not yet tried to 
compile it.

Original comment by korn...@gmail.com on 25 Oct 2012 at 11:19

[GoogleCodeExporter]

I haven't found anything related to 'collada' in Debian and Ubuntu packages.

Original comment by korn...@gmail.com on 25 Oct 2012 at 11:20

[GoogleCodeExporter]

AUR uses libsrc collada dom (13M) to build 'collada-dom'. 13M is better, but 
might not be good enough. We'll see how it (collada plugin) performs.

Original comment by korn...@gmail.com on 25 Oct 2012 at 11:24

[GoogleCodeExporter]

I'm not sure we need collada. It's like cracking nuts with hydraulic press.

Original comment by Kai.Saerthen.Darker on 25 Oct 2012 at 11:30

[GoogleCodeExporter]

assimp, on the other hand, is present in both Debian and Ubuntu.

Original comment by korn...@gmail.com on 26 Oct 2012 at 4:13

[GoogleCodeExporter]

Try to load some collada model from the bank ( 
http://ourbricks.com/khronos/colladarepository ) through the assimp OSG plugin.

Original comment by korn...@gmail.com on 26 Oct 2012 at 4:26

[GoogleCodeExporter]

The bike was imported fine into Blender.

Original comment by korn...@gmail.com on 26 Oct 2012 at 4:52

[GoogleCodeExporter]

Can't load the file through osgdb_assimp plugin, OSG says it can't find a 
plugin for 'dae'. Add logging.

Original comment by korn...@gmail.com on 26 Oct 2012 at 5:23

[GoogleCodeExporter]

It searches for osgdb_dae instead:
    Warning: dynamic library 'osgPlugins-3.0.1/osgdb_dae.so' does not exist (or isn't readable):
    osgPlugins-3.0.1/osgdb_dae.so: cannot open shared object file: No such file or directory
    DynamicLibrary::failed loading "osgPlugins-3.0.1/osgdb_dae.so"

May be I need to load plugin manually somehow.

Original comment by korn...@gmail.com on 26 Oct 2012 at 5:26

[GoogleCodeExporter]

Loaded it. Cool.

Original comment by korn...@gmail.com on 26 Oct 2012 at 5:47

Attachments:

• osg_assimp.png

[GoogleCodeExporter]

Try to convert it to blend and load it instead.

Original comment by korn...@gmail.com on 26 Oct 2012 at 5:48

[GoogleCodeExporter]

Couldn't load the blend. Try simple cube.

Original comment by korn...@gmail.com on 26 Oct 2012 at 6:02

[GoogleCodeExporter]

box.blend didn't appear too, but box.dae (exported in Blender from blend) 
appeared just fine.

Original comment by korn...@gmail.com on 26 Oct 2012 at 6:04

[GoogleCodeExporter]

Re-read the list of supported object/image formats by OSG.

Original comment by korn...@gmail.com on 26 Oct 2012 at 7:01

[GoogleCodeExporter]

Have just successfully loaded MDL from Black Mesa Source using default MDL 
loader (AssImp couldn't handle HL2 MDL).

Original comment by korn...@gmail.com on 26 Oct 2012 at 7:22

Attachments:

• osg_mdl.png

[GoogleCodeExporter]

Think how to best go about object + material in MJIN2.

Original comment by korn...@gmail.com on 26 Oct 2012 at 7:24

[GoogleCodeExporter]

I've just realized it depends on the answer to the following question: do we 
create materials ourselves or is it done with external tools?
If we do it ourselves, we're bound for some format to implement.
If not, we're better off with some standard format.

For meshes I see no reason not to use Collada.

Original comment by korn...@gmail.com on 26 Oct 2012 at 7:36

[GoogleCodeExporter]

We might use py - pyc way of Python with dae and osgb: if dae (py) is present 
and it is newer than corresponding osgb (pyc), then generate osgb (pyc) from it 
and then use it.

Original comment by korn...@gmail.com on 26 Oct 2012 at 10:48

[GoogleCodeExporter]

The release will be shipped with osgb files only, so assimp dependency won't be 
necessary. Thus, dae to osgb conversion can be handed to a separate utility 
that is only run on a developer machine when game starts (even from script???)

Original comment by korn...@gmail.com on 26 Oct 2012 at 10:50

[GoogleCodeExporter]

As for the material, looks like there's no easy way to export it from Blender 
into appropriate format. This means I have to invent the material format 
myself, and load it in MJIN2 myself, too.
I think we may go with Ogre-like material format, but in XML.

Original comment by korn...@gmail.com on 26 Oct 2012 at 10:52

[GoogleCodeExporter]

Kai said he wants something like Blender/UE material editor. Study it.

Original comment by korn...@gmail.com on 26 Oct 2012 at 11:34

• Now blocked on: #582

[GoogleCodeExporter]

osg StateSet's for the mdl model above: http://pastie.org/pastes/5118463/text

Original comment by korn...@gmail.com on 26 Oct 2012 at 11:42

[GoogleCodeExporter]

We won't use collada, we'll use native osgb (binary) format for meshes.
As for materials, we'll try to extact osg::StateSet into separate files.

Original comment by korn...@gmail.com on 10 Nov 2012 at 8:13

• Changed state: Fixed