249: Create the 2.49 to 2.79 converter!

[tngreene]

Many artists are, in 2019, stuck using 2.49 because their work is locked away. We need a way to open a 2.49 project in Blender, scrape and correct previous properties, and map them to new ones. This is a major undertaking and so it shall be split into multiple parts. I envision this as part of the addon, like a button you press to cleanup a file.

This bug serves as the central hub for finding (some) other parts of the project

Major Parts

General Steps

• 249: Obtain 2.49 projects from the commnuity! #397 Obtain Community Projects (we do, however, have many examples to work with)
• 249: Any string value from 2.49 may result in UnicodeDecodeError #476 Fix UnicodeDecodeError problem
• 249: Remove SKIP workflow code and fix unit tests, API #440 Convert every object, not just the ones that would have exported

DataRefs Conversion

None!

Materials

• 249: Convert materials and textures #425 Convert materials, specifically, split meshes into small groups to account for TexFace, Material pairs, so each special area has its own Object, Mesh, and single Material
• 249: Convert Aircraft and Cockpit properties #443 Convert material game props - aircraft specific
• 249: Convert Scenery and Instanced Scenery properties #444 Convert material game props - scenery specific
• 249: Split Faces with Panel Texture #447 Convert panel information
• 249: Convert Panel Region Information #469 Convert Panel Region information

Textures

• 249: Find textures used from UV editor for all OBJs #445 Set override textures box to Texture used in UV editor

UI

• 249: Implement Import-Convert Dialog Box #383 Make user facing nice front end to converter instead of a command-line script
• 249: Make 2.49 script to print all Objects that share Action datablocks #442 Make 2.49 script to help show what Action Datablocks are linked to which Objects

Features

• 249: Convert Workflows #381 Convert Regular and Bulk Workflows
• 249: Preserve 2.49 draw order With Groups and heuristics #441 Ensure Draw Order not massively inconvenient to keep or preserve (also, use Groups feature)
• 249: Use basic hueristics for choosing between Aircraft/Cockpit or Scenery/Instanced Scenery #446 Use heuristics to decide between Aircraft and Scenery Object
• 249: Bulk Converter does not match Bulk Exporter behavior #477 GRP, VRT, END not recursed as expected
• 249: LODs not converting properly #478 LODs not converting properly
• 249: Magnet Conversion uses Lamp location literally #479 Magnets need to use BakeMatrix
• 249: vname not implemented #488 Converter vname properties for Laminar Research library

[tngreene]

XPlane2Blender Documentation Sources

• 2.49 Repo
• blender_props.txt is a long relevant (I hope) document
• 2.49 Tutorials
• 2.49 Blender Tutorial
• 2.49 ReadMe.html pages
• XPlaneExport.py
• XPlaneExport8_ManipOptionsInterpreter.py

In a conversation with Ben about manipulators he said

Key values map of properties is fixed, not a hash table, class with members.
Members always have value. Scheme is fixed, unlike in 2.78

Blender 2.49 Documentation Sources

• 2.49 Manual (Download a copy before its gone!)
• 2.49 Manual PDF
• 2.49 Game Properties
• 2.49 Extensions and Python Scripting!!!
• 2.49 Python API
• 2.49 Game Engine API
• 2.49 Keyboard Shortcuts
• Backwards compatibility info

[tngreene]

Plan Of Attack

(In a slightly ordered list)

• Learn enough of how Blender 2.49 works to get around the UI, make cubes
• Learn enough of 2.49 XPlane2Blender to make OBJs with cubes
• Dig into source code and try to identify where how settings and values are taken
• Start making the 2.49 to 2.78 translation guide of how 2.49 settings get turned into 2.78 properties
• More to come

[der-On]

Dig into source code and try to identify where how settings and values are taken

The old blender 2.49 exporter is basically a giant heavily nested loop. "Magic" values and settings are taken from various strange settings mainly in the game-engine and face-properties site of blender.

Beware from single or two letter variables all over the place and if else constructs of darkness. ;)

[tngreene]

Talking with some developers on #blenderpython it seems that the conversion happens in
blender\source\blender\blenloader\intern\versioning_(250|260|270).c. The legacy and other properties are copied and transformed in those files.

Edit: versioning_legacy is actually unused!

In versioning_legacy.c see bl_do_versions_pre250, in versioning_250.c see blo_do_versions_250, etc etc.

These are called in blenloader\intern\readfile.c, line 8500 - 8503 as part of it's do_versions method (which is part of the you, guessed it, reading file sequence)

[tngreene]

Overview of Animation System

Important classes

• XPlaneExport.Anim
• XPlaneExport
• XPlaneAnimObject.doapply

  # The dataref values are encoded into properties here
  # datarefs values
  for boneno in range(len(datarefs)):
      ref=datarefs[boneno].split('/')
      name=make_short_name(datarefs[boneno])
      #name=ref[-1]
      if indices[boneno]!=None: name='%s[%d]' % (name, indices[boneno])
      if len(ref)>1 or name in lookup:
          # write vals for ambiguous and unusable datarefs, but not invalid
          for frameno in range(len(vals[boneno])):
              if not ((frameno==0 and vals[boneno][frameno]==0) or
                      (frameno==(len(vals[boneno])-1) and vals[boneno][frameno]==1)):
                  props['%s_v%d' % (name, frameno+1)]=vals[boneno][frameno]
              if loops[boneno]:
                  props[name+'_loop']=loops[boneno]

[bsupnik]

Notes from Ted's first successful animation translation:

• The STATIC animations induced by this import have no dataref names I don't no whether this is actually a latent (or always present) output bug in 2.78 or due to missing data in the translion, but

  ANIM_trans 5 0 0 5 0 0
  ANIM_rotate 1 0 0 90.00020741 90.00020741

There should be some kind of dummy dataref name for both of these, e.g. no_ref or none. MAtching existing 2.78 dummy dataref convention would be sane.

Every animation brought forward shows optimization bug #331 - not surprising since all 2.49 projects are armature based. We probably need to resolve #331 to consider 2.49 import comparable performance-wise.