[Bf-committers] Collada status

Rodrigo Hernandez kwizatz at aeongames.com
Sun Aug 3 23:15:35 CEST 2008


Hi Toni,

Ok, I made an unofficial Windows release of BlenderCollada at 
http://aeongames.com/blendercollada/BlenderColladaWin.zip

Install instructions:

decompress, and copy the files to the Blender directory, you can copy 
only the COLLADA_DOM dll and the BlenderCollada.pyd files there and keep 
the script separate too, really all you have to make sure is that the 
Dll's are on Blender's path when you run the script.

Note that the size of the dll is half as large as I mentioned, thats 
because this is a Visual Studio Release DLL, not sure which compiler is 
used for Windows Blender Releases.

I included a dae file for testing, when you import it, the armature will 
look bad, but thats because the geometry lacks an armature modifier, add 
one to it and link it to the armature, you'll then see the pose.
Bone tails don't match children tails, I found that if I set them to do 
that the pose is messed up, we can work this later.
Don't try to import Collada files with <polygons> or <polylists> that 
contain polygons with more than 4 verts, won't work.


The rest of my reply follows

Toni Alatalo wrote:
> 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)
>
>   
Yes, COLLADA_DOM is strictly C++, it uses a lot of templates due to its 
heavy use of smart pointers.
> 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).
>
>   
BlenderCollada.cpp contains the glue between COLLADA_DOM and Blender's 
Python, it is a rather backwards C to Python binding, the meat of the 
code is indeed in BlenderDae,
nothing particularly complex aside from all the referencing and 
dereferencing and of course Py_* calls.
I'd like to note that all across the board, big Collada files take a LOT 
of time to load, plus the post load extra processing required, which is 
why I decided to keep it all into the BlenderCollada.pyd extension, and 
just expose the DAE_load and DAE_save functions, I could be wrong 
though, and having the extra processing done in Python could be just as 
good.

> 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.
>
>   
The VS DLL is half the size of the MinGW version, I take it it could be 
tweaked to make it smaller, also I compressed the 4mb file on normal 
compression, the one on this release on "best", that file is ~900k
> 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. 
>   
Well, its there :)
> 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.
>
>   
I envisioned my plugin as a replacement for the current one, so the call 
for exporting (DAE_save) is there, there is no code in it yet though, I 
think exporting may be a lot easier than importing, but as usual I have 
my priorities as does everyone else, and what I needed was the importer, 
I am writing a separate COLLADA->My Engine converter though, so maybe in 
the end I would make more use of the exporter than the importer.
> 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.
>
>   
No Problem :)

>> 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
>>   
>>     
>
> _______________________________________________
> 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