[Bf-committers] Collada status

Toni Alatalo antont at kyperjokki.fi
Sun Aug 3 22:15:54 CEST 2008

Rodrigo Hernandez kirjoitti:
> I think adding a C/C++ API for plugins while keeping Python as an 
> alternative would really do a lot of good for situations like these.

Perhaps. Another solution though is to use Python as the C/C++ API. C 
libs you can nowadays use directly from Python, without bindings, using 
the ctypes modules which is included in the standard py lib since 2.5, 
http://docs.python.org/lib/module-ctypes.html (ctypes works also with 
older pythons (requires 2.3) and if we decide to use it we can bundle it 
in the Blender libs).

It seems that you can call c++ too, unfortunately one relatively resent 
example of it seems to be behind a dead link now - the c++ support of 
ctypes is not complete (i don't know the details but something about 
classes) but at least calling functions (also in classes, i guess?) is 
"quite straight forwards to do, with the extern "C" declaration." 
http://www.dzone.com/links/calling_c_from_python_using_ctypes.html (the 
link to the actual article there is dead)

It may be that in order to instanciate c++ classes in py you need 
bindings though, I don't know if Collada_DOM requires that. There are 
several easy ways to make c++ bindings, old/mature ones like swig and an 
apparently hot more recent one called py++ - 
http://www.language-binding.net/pyplusplus/pyplusplus.html (python-ogre 
is made using py++ and wraps huge amounts of c++ libs: not only all of 
ogre (which is not small) but also 4 gui libs, 2 sound libs, 4 physics 
libs .. total 30 libs it seems, http://python-ogre.org/index.php/overview)

I like having Blender integration of external libs in Python for the 
ease of customization - am not sure if e.g. our company will need 
customization of the way how collada import/exports are there but am not 
surprisised if it happens. My rule of thumb is to do cpu intensive 
things in c/c++ and everything else in py, and use wrappers for libs and 
do integration in py. But of course tastes / needs there can differ .. 
i'm a bit curious to know though how the Collada_DOM integration goes 
w.r.t to performance bottlenecks, with a superficial glance it seems 
your BlenderCollada.cpp does not have anything cpu intensive but 
BlenderDae.cpp may have .. but better not to go into that too much here 
to not flood this list / waste your time if the question is irrelevant 
to you (feel free to reply to this on the bf-python list though if you 
want, but there's no need to).

Perhaps a more relevant question is whether the current Py API includes 
bottlenecks for exporters, and if yes, can those be fixed by e.g. using 
the buffer protocol (numpy style) - but that's another question and also 
better suitable for the bf-python list.

> The Windows Mingw COLLADA_DOM Dll release build is 4.71MB stripped of 
> debugging info, 1.459MB compressed, not exactly small.

yes, not large either but certainly not small compared to the overall 
size of Blender. i'm not sure how i'd vote about including it to the 
default Blender distro (perhaps a weak yes), we can of course install it 
by downloading too.

> As I said before, I have already done work on the import side using 
> COLLADA_DOM, I'd take ownership, but I just don't have the time, I can 
> help though, and if there is interest, I can make available a binary of 
> my plugin for testing purposes.

I'd bet there is interest. What was mentioned about not needing to do 
changes in the Blender import/export code when Collada versions change 
was a strong point I think. We (at http://www.playsign.net/) are not 
using Collada (yet), but it is quite probable we will need it in the 
foreseeable future (we are currently using Ogre exporters, and may start 
using what Apricot produces, but may at any time need Collada for 
Papervision and perhaps for other things too (who knows, perhaps for 
playstation some day :) - it may even make sense to switch the blender 
-> ogre pipeline to use collada at some point, dunno).

I wonder if your BlenderCollada/Dae thing would already facilitate 
porting the current exporter to it (if the author of the exporter also 
thinks it's a good idea), or would it be better either to to call 
Collada_DOM from py or make a py wrapper for it.

Thank you a lot in any case for doing and sharing this work! I hope when 
we start needing it we can contribute back too, but as we don't need it 
yet and are busy with other things can't really do anything now.


> Tom M wrote:
>> Hi Tim,
>> Collada_Dom is 'MIT' licensed
>> http://collada-dom.svn.sourceforge.net/viewvc/collada-dom/trunk/dom/license.txt?view=log
>> which is GPL compatible,
>> http://www.gnu.org/philosophy/license-list.html
>> so we are okay as regards the legalities.
>> The reason the majority of our import/export scripts are written in
>> python is that python is 'easier' to do them in, and easier to
>> maintain if the original developer disappears (which happens pretty
>> often).  That said, I personally wouldn't object to using Collada/DOM.
>>  Anyone know roughly how much it would add to our (zipped) binary size
>> to include Collada DOM?
>> Python bindings for a well defined API are pretty easy to do (I think
>> there are automagic bindings generators that work well).  However they
>> probably aren't necessary.
>> LetterRip
>>> And assuming we would go for Python, how difficult would it be to
>>> create the bindings ourselfs?
>>> Now: I would be inclined to take this on me, but you may understand I
>>> need lots of help on the Blender API side.
>>> Also, got a 'normal' daytime job, so things will take time.
>>> IRC meeting: anytime... I'm in The Netherlands.
>>> Tim
>>> 2008/8/3 Rodrigo Hernandez <kwizatz at aeongames.com>:
>>>> Hi Ton,
>>>> The problem I found with the current Illusoft scripts is that they are
>>>> parse the COLLADA "manually", meaning they access the file as pure XML
>>>> through expat, which makes updating to later specification versions and
>>>> adding functionality very tedious and time consuming.
>>>> If you want to keep the functionality as scripts I would suggest at
>>>> least getting a hold of some implementation of COLLADA_DOM or FCOLLADA
>>>> Python bindings/extensions (which sadly don't seem to be available), and
>>>> migrate the current parsing code to that.
>>>> Regards,
>>>> Rodrigo Hernandez.
>>>> Ton Roosendaal wrote:
>>>>> Hi Collada devs!
>>>>> There's a wealth of attention for this part in Blender, and that's very
>>>>> welcome. In the past months we had to disappoint many (professional)
>>>>> users with the message "sorry, it is not maintained well now".
>>>>> Here's some info:
>>>>> - the sourceforge project below has halted.
>>>>>    http://sourceforge.net/projects/colladablender/
>>>>> - that code is in our own svn, in:
>>>>>    blender/release/scripts/collada*.py
>>>>> Actions:
>>>>> - could people provide patches against our svn py scripts?
>>>>> - is here anyone interested in accepting 'ownership' for collada (Tim
>>>>> seems to qualify well, since he's got a job doing it apparently :)
>>>>> - we can also arrange an irc meeting together about this... dunno about
>>>>> you guys timezones?
>>>>>    Optimal would be to make it topic on our standard irc meetings, 4-6
>>>>> PM Netherlands time.
>>>>> -Ton-
>>>>> On 3 Aug, 2008, at 0:03, Dalai Felinto wrote:
>>>>>> Hi,
>>>>>> recently I used Blender Collada exporter to generate content for flash
>>>>>> 3D.
>>>>>> The script looks fine, the only problem is that the final file looks
>>>>>> bigger then the necessary.
>>>>>> (I tried to import some collada samples and export it and the final
>>>>>> file Blender-generated was much bigger.
>>>>>> Anyways, if you need some help for testing, please let me know.
>>>>>> My test result is here (take a little time to load the texture ...):
>>>>>> http://www.ecopath.org/nonewe/3DModelsDemo/3D_shark.swf
>>>>>> Regards,
>>>>>> Dalai Felinto
>>>>>> http://blenderecia.orgfree.com
>>>>>> 2008/8/2 Rodrigo Hernandez <kwizatz at aeongames.com>:
>>>>>>> Hi, I started working on a Collada importer/exporter of my own a while
>>>>>>> ago, it is really a Python extension that uses COLLADA_DOM, although
>>>>>>> it
>>>>>>> doesn't cover the full range of Collada possibilities (no export code
>>>>>>> at
>>>>>>> all yet), it does handle geometries and skins (what I really needed
>>>>>>> was
>>>>>>> a way to import characters) and materials to an extent, I am working
>>>>>>> on
>>>>>>> deciphering animation :).
>>>>>>> If there is interest the code can later be integrated into Blender, or
>>>>>>> kept as is (though it really just uses Python as glue code, why is
>>>>>>> there
>>>>>>> no binary API?).
>>>>>>> Anyway, all this is to say that if you're planning to start a new
>>>>>>> Blender COLLADA project, you may want to help out with the code base I
>>>>>>> already have so you don't reinvent the wheel, and the project moves
>>>>>>> forward faster.
>>>>>>> The code I am currently hosting on my private server at
>>>>>>> http://svn.aeongames.com/svn/BlenderCollada/trunk/ , but its open
>>>>>>> source, there is no license yet, but will probably be MIT or BSD, if
>>>>>>> needed be, I would move it to google code or sourceforge, but since I
>>>>>>> am
>>>>>>> the only one working on it, I just decided to keep it there while
>>>>>>> still
>>>>>>> a work in progress.
>>>>>>> Feel free to contact me for any questions you may have.
>>>>>>> Regards,
>>>>>>> Rodrigo Hernandez.
>>>>>>> Tim Knip wrote:
>>>>>>>> Hi list,
>>>>>>>> This is my first post here.
>>>>>>>> The reason I joined, is that I need 'good' Collada export and willing
>>>>>>>> to work on this.
>>>>>>>> I'm doing the Collada stuff - http://ascollada.org/?tag=collada - for
>>>>>>>> Papervision3D - http://blog.papervision3d.org/ - a 3D implementation
>>>>>>>> for Adobe Flash.
>>>>>>>> So I've got some understanding of the Collada spec.
>>>>>>>> My knowledge on Blender etc. is near zero, though I can handle
>>>>>>>> Python a bit.
>>>>>>>> I understand that Collada import/export is still handled by
>>>>>>>> http://sourceforge.net/projects/colladablender/ ?
>>>>>>>> Maybe I should simply join this one?
>>>>>>>> Anyway: just wanted to ask you how/if I should proceed and whether
>>>>>>>> there are already plans for Collada?
>>>>>>>> Thanks,
>>>>>>>> Tim
>>>>>>>> _______________________________________________
>>>>>>>> Bf-committers mailing list
>>>>>>>> Bf-committers at blender.org
>>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>>> _______________________________________________
>>>>>>> Bf-committers mailing list
>>>>>>> Bf-committers at blender.org
>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>> _______________________________________________
>>>>>> Bf-committers mailing list
>>>>>> Bf-committers at blender.org
>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>> ------------------------------------------------------------------------
>>>>> --
>>>>> Ton Roosendaal  Blender Foundation ton at blender.org
>>>>> http://www.blender.org
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list