-
Notifications
You must be signed in to change notification settings - Fork 71
Roadmap to v3.3
- Find out what's the best way in blender to do automated testing
- Programatically and manually create testing environments (blend files)
- Test outputed OBJ-files against fixtures
- Write functional unit tests (only where test driven development is needed)
Related issues: #120
Once this is done, we are save to continue on rewrites/refactures.
-
Determine what kind of transformation is really necessary and at wichh state of the export process to get from Blenders coordinate system to X-Planes In theory, the transform should be a simple swap-and-negate at the time of outputting the objects. We can determine this by:
- Setting the Blender->X-Plane transform matrix to identity (to essentially disable transforming) and
- Confirming that OBJ export is normal "except" for the object being rotated 90 degrees due to the Y vs Z = up. (Both coordinate systems are "right-handed".)
- Add swizzling "just-in-time" to each export file writer function. This is how the 2.49 script works. (The strategy makes development simpler by keeping all calculations in Blender's coordinate system and only changing at the last minute.)
- Once the refactor is done, the old B->XP transform can be stripped out, since it is identity.
-
Move animation export into the XPlane-Objects as proposed here: Proposed-redesign-of-animation-export
Basically create an XPlaneBone which is representing it's own structure/hierarchy for animations. Creates a XPlaneBone hierarchy during Export. XPlaneBones know which X-Plane object they belong to.Open Issue: is it easier to build a new bone structure as a second assembly on the side and swap over,
or to refactor the existing exporter in steps? -
Once the system is rewritten we have to test regression files made with the old version to see if the results are the same or if we need to provide (automatic) upgrade paths
Related issues: #127, #126, #108, #72, #69
-
The 2.49 exporter allows multi-export-by-OBJ where empty displays indicate that everything within the empty (in the hierarchy) will go to one file. The DNA needs to be extended to put an XPlaneLayer on those empties.
Open Issue: in 2.7 how do we know which empties are object containers? In 2.49 this is done by a prefix naming convention, but this strategy is typical of 2.49, where we can't actually create real UI for much of anything.
-
The 2.49 exporter also allows for per-scene export; the XPlaneLayer object needs to be analyzed to see what properties (if any) can be scene-wide in 2.49 that aren't represented anywhere in 2.70. (This may be a very short list - from what I can tell almost every airplane feature we need is already in the XPlaneLayer, and the main issue is automation of texture detection.)
-
We need a script that find all string key-value pairs that have special meaning on a Blender 2.49 object and puts the properties in the right DNA in 2.70. First task is for Ben to write a master ref of the 2.49 dictionary and create sample test cases.
Open Issue: Blender 2.49 uses per-face flags, which are deprecated in 2.70; a 2.70 project has the mesh broken into pieces with multiple materials to work around this. So the spec work to figure out what transition we want is non-trivial.
One option is to create a pre-export script that runs in 2.49 that copies the data to 'safe places' before Blender translates the file - this is a work-around of last resort.
This will support another workflow where one OBJ-File is created for all objects that are parented under a root (Empty) Object.
This workflow is especially interesting for scenery asset development, while the layer workflow fits more to airplane development.
Find a way to support both workflows:
- For the new workflow the XPlane-Layer Object could be attached to the root Objects, instead of the the vector of Blender-Layers within the scene.
- At the beginning of a project one should decide upon the type of workflow to use. This will be stored as a "global" property on the scene. (Question: can we determine at export time what work-flow was used?)
- This way workflows could be switched on a per-scene basis which could have it's own benefits.
- For the hierarchy workflow support LODs using layers.
Texture and material validation: the 2.49 exporter supports a more 'automatic' material work-flow:
- The actual texture used in Blender by the author is selected for export, providing roughly WYSIWYG export.
- Lit and normal maps are discovered automatically by naming convention.
- Global attributes are applied automatically based on the user's stated instancing preference.
- If the rules for material compatibility are violated, the export fails, alerting the user.
The 2.49 automatic work-flow could benefit from helper tools to build appropriate materials (see step 6 - nice to have). Details to work out:
- How to tell if we are using automatic or manual materials (E.g. 2.49 or 2.50 mode)?
- If the user specifically maps a specular map that violates the 2.49 naming convention in their material, should the exporter use it? Probably, but we need to determine how we detect this case.
Probably there are three possible options: hand-enter in properties (2.50), find on disk (2.49) and use the Blender material (new).
Related issues: none yet
- Minimize state changes
- Be intelligent about X-Planes default states and do not write them again
- More user controll about what kind of states will be written (especially for materials and only in a global context)
- Copying of X-Plane related object properties from one object to another (especially manipulator properties) #82
- Material helpers: add tools/presets to easily create materials that reflect in-game graphics as close as possible
- Support array datarefs #68
- Tool for combining normal maps with grayscale specmaps #51
- ...