Blender file version conversion

[GoogleCodeExporter]

It as been agreed that the preferred way to handle multiple file version 
loading is the following:
-The scene loader only load the latest stable format
-The blend file reader upgrade the data of the old file to match last stable. 
(gkBlendFile::doVersionTests() )

While investigating the upgrade of the blender animation system (2.4 to 2.5) I 
had a chat with Ton about the possibility the reuse some code (with agreement 
of the original author and contributors) but it appears that this is not 
possible because the code use the DNA API which is GPLed; and removing the code 
that use this API is equal to removing everything.

So I will finish what I started and write my own conversion code. However as 
this conversion is very tricky  (specially with linked libraries) I really need 
to read and understand each step of the blender conversion and the main 
algorithm will be very similar. I would like to make sure that this will not 
cause further legal issue.

I am trying to contact aligorith (the original author) to inform him about my 
work but I did not managed to catch him yet. 

By the way here are Ton' advises:
- Be careful, small confusion with licenses can cause big problem later.
- Forget about a doversion() and use a script that launch blender to do the 
conversion in case of older file. As there is no point for game developers to 
redistribute this kind of conversion utility with there games this is not 
problematic.

Original issue reported on code.google.com by xavier.thomas.1980@gmail.com on 16 Jun 2010 at 10:25

[GoogleCodeExporter]

I can see Ton's point RE: using a separate application to convert them over... 
but it does make GameKit a little more painful to use.

For example, there are things that can (still) only be done in Blender 2.49b 
(some modelling tools for example). I can easily see people wanting to use that 
version of Blender until the developers add the missing functionality. Having 
to run the blender files through the converter each time could be very painful 
(especially when library blends enter the equation later).

Personally, a doversion() would be more useful but I can understand the issues 
involved so will not push for it.

Original comment by BenT.Sol...@gmail.com on 17 Jun 2010 at 2:00

[GoogleCodeExporter]

Hey, I would prefer to stay away from reusing any code from blender, and only 
stick to whats contained in the file DNA.

I need to familiarize myself with the newest DNA, but from what I gather 
actions are now sorted into reusable groups of FCurves. 

My first guess in converting to the new system would be to re-index a set set 
of FCurves for the older bActionChannel. (by extracting the 
Blender::IpoCurve::bezt and bone name) 

Then rebuild the rna_path variable in a manor that the curve can be extracted 
in the same way as the newer code in the converter.

Original comment by snailr...@gmail.com on 17 Jun 2010 at 11:07

[GoogleCodeExporter]

snailrose, I also think having our own converter is better and as we do not 
need all the data we do not need to convert it all. I am already working on a 
converter (that I completely wrote myself but I inspired myself form the 
blender ipo.c code). The FCures groups are optional and some blend could not 
use them, although when converting 2.4 files the blender doversion add groups 
that correspond to the old actionchannel, files created in 2.5 could not have 
groups.

Form what I saw for now in GK is that the only used animation are actions, so I 
am working on actions only for now but we might want to convert the object 
curves also (location rotation, material, ...)

It will take me a few days to finish the converter and test it but I would like 
to make sure that reading blender code and rewriting my own code that follow a 
similar algorithm is OK.

Original comment by xavier.thomas.1980@gmail.com on 17 Jun 2010 at 1:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Indeed, we cannot use any (L)GPL code in the runtime, it needs to stay 
BSD/MIT/Zlib licensed.

>> The scene loader only load the latest stable format

Why do we need to add this restriction?

GameKit currently loads older .blend files, and I see no problem of supporting 
2.5 and 2.49 (and older) .blend files. We just need to extract the new 2.5 
animation data (and keep support to extract the existing 2.49 and older 
animation data)

Is there any problem with this?

Original comment by erwin.coumans on 21 Jun 2010 at 6:08

[GoogleCodeExporter]

Absolutely no problem with gamekit loading both versions, but there is 2 ways 
to do it:
-Having the loader functions that create/sets up the gamekit objects to 
"undestand" the DNA of both version. This is how it is right now in svn with 
function like that:

gkBlenderSceneConverter::convertObjectActions () {
    if (verion<=2.49) {...}
    else {...}
} 

-Using the DoVersionTest function to convert the needed DNA data, and the 
functions that create/sets up the gamekit objects do so according the last 
(That is what I meant by "The scene loader only load the latest stable 
format"). I have working code for this but still have problem freeing the old 
IPOs after.

Sorry for the confusion certainly caused by my bad English.

Original comment by xavier.thomas.1980@gmail.com on 21 Jun 2010 at 7:36

[GoogleCodeExporter]

I haven't followed all discussions, but would like to understand the 
differences/benefits.

Either way you need to support both old (2.49) and new (2.5) data, such as 
animation data.

What would be the benefit of such DoVersionTest, converting the DNA data?

Original comment by erwin.coumans on 21 Jun 2010 at 7:43

[GoogleCodeExporter]

Yes, the DoVersionTest would be there to convert DNA data just like the blender 
do_version.

I think both method would require the same maintenance effort but the DoVersion 
method centralize all the version related changes in one place; while growing 
the loader functions (that creates gamekit objects), to handle all DNA 
versions, will result in several "growing" functions that with time (and DNA 
changes in blender) may become bloated and difficult to maintain.

With the doversion method only one function keeps growing (DoVersionTest), 
hopefully with small incremental changes.

Original comment by xavier.thomas.1980@gmail.com on 22 Jun 2010 at 6:26

[GoogleCodeExporter]

Here is a basic patch that does convert the blender animation data (2.4x to 
2.5x). It is really basic and for now only support:
-Pose actions 
-Normal IPO curves (no bitflag curve)
-No constraints

I took quite some time to understand the blender conversion while debugging 
then write some code and clean it and it still needs work but:
-It works
-I wrote everything myself (no copy paste) so there is nor license problem
-It should be easy to expand when gamekit will use more animation data

I tried several ways to free the old data (not needed after conversion) like 
action channels, IPO, IPOCurve and BezTriple but if I do so I get a double free 
crash on exit in BlendFile destructor while freeing m_pool. So I just kept a 
commentary line that I will replace when I will figure how to do it correctly. 
For now this does not have other effect then memory consumption but in the 
future it might be needed to avoid converting some data more then once.

Original comment by xavier.thomas.1980@gmail.com on 22 Jun 2010 at 9:06

Attachments:

• doversion_animsys_01.diff

[GoogleCodeExporter]

Thanks for the patch,
Unfortunately there was a mix up on my part. My impression was the 
bActionChannel would be removed from the Blender DNA, therefore we would be 
forced to use only the FCurve structures. 

It has been pointed out to me that Blender is only breaking forward 
compatibility with the DNA. The bActionChannel will still be kept for loading 
older .blend versions.

For simplicity, it would be best to skip the intermediate step of converting 
from 249->250->Ogre, and just go to 249->Ogre and 250->Ogre. Then use the 250 
conversion routine to add more of the newer animation features from Blender.

I apologize for the inconvenience this has caused.

Original comment by snailr...@gmail.com on 24 Jun 2010 at 12:57

[GoogleCodeExporter]

Original comment by snailr...@gmail.com on 27 Jun 2010 at 5:00

• Changed state: Fixed