supertuxkart / stk-code

The code base of supertuxkart
Other
4.39k stars 1.03k forks source link

Blender 2.5 Support #216

Closed supertuxkart-sourceforge-migration closed 10 years ago

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria

Blender 2.5 Support is a current WIP. What's left to do :

1) The kart script is not started 2) The property browser (a skeleton is available) 3) Fix bones in the B3D exporter (the rotations are all wrong) 4) Complete the track exporter 4.1) The curves are wrong (see FIXMEs in code) 4.2) The file selector by default proposes a name ending in .blend

Also when I opened Hacienda in Blender 2.5, the drivelines and checklines were at totally wrong coordinates, seems like there is a little glitch there when opening Blender 2.4 files, we'll need to be careful...

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Actually, I discovered that it's the exporter that moves checklines and drivelines around.

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria The exporter moving drivelines and checklines around is fixed as of r8282.

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria The B3D exporter also has issues with scaling; the Hacienda sky has a small mesh but it's scaled up; but the 2.5 B3D exporter exports it very small

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria IPO export mostly fixed in r8363. The main problem left is that interpolation is no more set per-curve but is not set per-point; do we update STK accordingly or restrict users to using a single IPO type?

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria '''Status Update''' :

1) The kart script is not started 2) The property browser (a skeleton is available) 3) Complete B3D exporter

3.1) Fix bones (the rotations are all wrong)
3.2) Try exporting Hacienda; some cacti and palm tree are exported upside-down.
     Find why.
3.3) Scale issues : the Hacienda sky has a small mesh but is scaled up 700%;
     but the exporter seems to export it small
3.4) Normals issues : the Hacienda pots are exported with inverted normals
     (this is maybe a track export bug, do we export with negative scale??)

4) Complete the track exporter

4.1) Curve interpolation must be clarified : do we support per-point IPO types?
4.2) The file selector by default proposes a name ending in .blend
supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Rotations and scale improved in r8406.

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria In r8406, r8407, r8408, r8409, r8413, r8414

'''good news''' : I managed to make the B3D exporter in 2.5 export all of the same coordinates and rotations for bones as the 2.4 exporter did (on limited tests)

'''bad news''' : the in-game visuals are still broken

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria item 4.2 done in r8431.

'''Status Update :'''

1) The kart script is not started 2) The property browser (a skeleton is available) 3) Complete B3D exporter

3.1) Fix bones (the rotations are all wrong)
3.2) Try exporting Hacienda; some cacti and palm tree are exported upside-down.

    Find why.

3.3) Scale issues : the Hacienda sky has a small mesh but is scaled up 700%;

    but the exporter seems to export it small

3.4) Normals issues : the Hacienda pots are exported with inverted normals

    (this is maybe a track export bug, do we export with negative scale??)

4) Complete the track exporter

4.1) Curve interpolation must be clarified : do we support per-point IPO types?
supertuxkart-sourceforge-migration commented 10 years ago

Author: auria As of r8497, exporting animated meshes with the 2.5 B3D exporter now actually WORKS \o/ (*only if armature and mesh have no rotation or scale). More testing may be needed

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria More testing is indeed needed. See attached Tux screenshot

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Issue 3.3 fixed as of r8570.

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria With r8676, r8677, r8678, r8679, all Hacienda problems are now corrected

'''Status Update :'''

1) The kart script is not started 2) The property browser (started but not tested much)

2.1) conversion scripts to go from 2.4 to 2.5 will be needed

3) Complete B3D exporter

3.1) Fix bones (the rotations are still mostly wrong)

4) Complete the track exporter

4.1) Curve interpolation must be clarified : do we support per-point IPO types?
supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Bone rest position issues massively improved in r8730, r8733, r8734. (However the animations are quite broken)

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Hmm, forget my last comment about animations not working... actually now they seem to work very well!! Not sure why yesterday they didn't

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Kart exporter support done in r8736, r8737, r8738, r8739, r8740, r8741, r8742

Status update :

1) conversion scripts to go from 2.4 to 2.5 will be needed 2) Curve interpolation must be clarified : do we support per-point IPO types? 3) test, test, test!

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Another TODO: probably the kart exporter should now also write the materials.xml file

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria And yet another TODO: allow to see the "wheel" type through the panel

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Small issue : for the GUI, I use additional properties like

sound_effect="no" use_slowdown="false" use_sfx="false"

unfortunately they get exported to materials.xml

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Actually material export will need to be completely revamped :( at this time it exports all values it finds, and that often includes outdated values; in 2.4 values contained dashes (-) which in 2.5 were replaced by underscores (_). So material files from the 2.5 exporter contain e.g. "below_surface" and not "below-surface" and thus STK doesn't load them correctly. Furthermore, since the new property browser will create every ID property for every material, this means every setting is always exported, even when using the default.

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Material export mostly dealt with in r8844.

Status update :

1) conversion scripts to go from 2.4 to 2.5 will be needed 2) Curve interpolation must be clarified : do we support per-point IPO types? 3) Kart export improvements

3.1) the kart exporter should now also write the materials.xml file
3.2) allow to see the "wheel" type through the panel

4) test, test, test!

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Item 1) pretty much done. Some manual conversion may be needed but in a minor way (for instance, some number properties used to be strings, the scripts don't fix that; and sky cubes may need to be manually re-entered)

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria A new problem has surfaced : for materials, the exporter just exports all properties it finds.

unfortunately I have no idea how to delete an ID-property; this means after the conversion script has been run, there may be some old properties left behind that nonetheless get exported.

We should perhaps think about at least adding a "whitelist" to the exporter so it stops exporting everything. Even better would be a script to cleanup unused ID properties but that would be more difficult to do right

SO status update :

1) Stop exporting all ID-properties for materials, we may end up with old leftover properties getting exported 2) Curve interpolation must be clarified : do we support per-point IPO types? 3) Kart export improvements

3.1) the kart exporter should now also write the materials.xml file
3.2) allow to see the "wheel" type through the panel

4) test, test, test!

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Status update :

1) the ghost in crescent crossing exports all wrong 2) Curve interpolation must be clarified : do we support per-point IPO types? 3) Kart export improvements

3.1) the kart exporter should now also write the materials.xml file
3.2) allow to see the "wheel" type through the panel
supertuxkart-sourceforge-migration commented 10 years ago

Author: auria As of latest SVN, the ghost now exports like in blender 2.4 (it's still twisted but that's another issue)

Status update :

2) Curve interpolation must be clarified : do we support per-point IPO types? 3) Kart export improvements

3.1) the kart exporter should now also write the materials.xml file
3.2) allow to see the "wheel" type through the panel
3.3) test kart export to make sure armatures export correctly
supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Status update : 2) Curve interpolation must be clarified : do we support per-point IPO types? 3.1) the kart exporter should now also write the materials.xml file

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria 3.1 done in r9645.

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria What's left :

2) Curve interpolation must be clarified : do we support per-point IPO types?

Since IPO was handled by Joerg, I feel tempted to move this problem back to Joerg :) basically the novelty in Blender 2.5 is that interpolation mode is set per-point, and no more per-curve. So we need to check if we can code per-point IPO, and if not decide how to determine which IPO to use

supertuxkart-sourceforge-migration commented 10 years ago

Author: hikerstk While it would be possible to support different curve interpolation type for each points, I don't think that there is any need at this stage to implement this. So I'd suggest to support only a single IPO style, and pick the 'smoothest' one (e.g. if linear and bezier is defined, use bezier for everything; perhaps display a warning in this case). Once IPOs work, I would close this ticket. If we need different IPO styles a new enhancement ticket should be opened.

Handing this back to auria now ;)

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Actually Joerg it's more complicated than that, since Bezier interpolation requires 2 handles, and if a point is linear the right handle is missing. I could try to come up a reasonable handle when finding a "linear" point

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Did something in r9776, I guess this is sufficient, especially considering that a warning is printed in the case that mixed IPO types are used