User:Someonewithpc/GSoC2019/Schedule

Project Schedule
Before official begin:


 * Initial OBJ exporter, with support for:
 * Vertices
 * UVs
 * Normals
 * Applying modifiers and triangulating the mesh
 * Moved common code to
 * Started STL exporter, to evaluate what needed to be made generic

1st week (27/05 - 03/06)

 * Added axis remapping
 * Fixed compile bug where  depends on   but doesn’t include it directly
 * Added option to disable deduplication object, which might be faster but produces larger files

2nd week (03/06 - 10/06)

 * Major refactoring to use C++ style iterators (based on )
 * Working on STL export
 * Lots of bug fixing related to iterators
 * Review of the iterator code and some documentation
 * Bug fixing in STL export
 * Fixed UI for STL, making it separate from OBJ
 * Added binary STL

3rd week (10/06 - 17/06)

 * Ran clang-format
 * Bug fixing
 * Merged master (bug I was trying to fix was due to a regression in master)
 * Refactoring iterators to not depend on
 * Temporary code to instead just copy the data, instead of using iterators, to test performance. ~50% hit and higher memory usage

4th week (17/06 - 24/06)

 * Testing performance of using C-style output on OBJ. Very significant, especially on Windows (32.4s to 19.4s)
 * Fully removed the  dependency
 * OBJ exporter handles materials and animations
 * Added path mode to materials, which controls if and how image textures are copied
 * Added NURBS export

5th week (24/06 - 01/07) - 1st evaluation

 * Refactored ExportSettings so settings specific to each exporter are stored in another struct, with a pointer in the original
 * Added unit scaling
 * UNRELATED Had to look for an appartment, after being given a short notice to leave
 * Writing this schedule
 * Bug fixing in
 * Refactor to use depsgraph iterator for obtaining objects, per Sybren’s suggestion
 * Explore current crashes

6th week (01/07 - 08/07)

 * Fix, as it doesn’t seem to apply transforms
 * Add exporting of vertex groups, smooth groups
 * Add option to keep vertex order
 * Add option to sort faces by vertex group, material, etc, as per the python OBJ exporter
 * Add operator presets

7th week (08/07 - 15/07)

 * Write tests and ensure everything in the OBJ exporter works
 * Understanding previous attempts at writting an OBJ importer
 * Start implementing the OBJ importer

8th week (15/07 - 22/07)

 * Continued work on the OBJ importer

9th week (22/07 - 29/07) 2nd evaluation

 * Continued work on the OBJ importer

10th week (29/07 - 05/08)

 * Understand the Blender threading interface
 * Refactor to make each section of exporting write to a temporary buffer, enabling concurrency of exporting either between different objects or between different properties of each object (vertices, normals, uvs). This could be done by representing an export job with a type, an iterator, and a resulting buffer, and adding to a queue

11th week (05/08 - 12/08)

 * Implement PLY exporter and importer
 * Implement STL importer

12th week (12/08 - 19/08)

 * Documentation and bug fixes

13th week (19/06 - 26/08) - final week

 * Bug fixing

Open Questions:
Should this whole project be added as an optional dependecy?

How to best compare similarity of vectors?

What order are the vertices of a face stored in? Clockwise?

Should  take into account  ?

When creating a matrix for rescaling and remaping the object’s axis, does the homogenous component need to be set to the scale? According to the implementation in Alembic, it seems to also scale transforms.

How do I apply a transform to the evaluated object (without modifying the real object)?

How do I flip an object’s normals?

How do I get the version string describing the Blender build?

How do I properly lock the scene while exporting? ? ?

When exporting, does -0 need to be converted to 0?

Is T47010 still relevant?

How should an object be evaluated? Using  seems to break

Do I need to create a new file type for each exporter? What’s preventing the proper files (i.e. files ending in “.obj” in the case of OBJ) from showing in the file selector?

Is it ok to add the version info after a # in STL and ignore it in importing? The current exporter just uses the place where the object’s name goes to add the Blender version information, thus losing the object name

Original schedule
1st week: Extend the OBJ exporter to include missing functionality like Nurbs

2nd week: Extend it further to include materials. Regression testing

3rd week: Implement the OBJ importer. Initial exploration of parallelization

4th week: Implement the ASCII STL exporter and importer. Evaluation

5th week: Extend the framework to generalize common tasks. Bug fixing

6th week: Implement the ASCII PLY exporter and importer

7th week: If parallelization is worth it, implement it

8th week: Implement the binary variants of PLY and STL exporters and importers. Evaluation

9th week: Refine the framework and bug fixes

10th week: Final documentation of the framework

11th week: Finalizing regression tests

12th week: Buffer week. Finalization and evaluation