Closed GoogleCodeExporter closed 9 years ago
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
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
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
[deleted comment]
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
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
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
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
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:
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
Original comment by snailr...@gmail.com
on 27 Jun 2010 at 5:00
Original issue reported on code.google.com by
xavier.thomas.1980@gmail.com
on 16 Jun 2010 at 10:25