kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

I know everyone's busy chasing bugs for the release, but I thought
I may as well post my ideas on the 3D model refactoring and get
some comments so I can get stuck into making changes. The idea
is to have a maintainable and extensible method for handling different
3D model data and to improve usability.
Proposed changes include:

    1. Removal of S3D_MASTER from Class BOARD and replacement with simple
       class (S3D_ENTRY) containing data for the model: T,R,S data +
filename

    2. Introduction of an S3D_FRAMEWORK class owned by Class BOARD and with
       the following responsibilities:
       a. solely responsible for the instantiation of S3D_ENTRY
       b. manage caching of 3D display data in memory; in the future
          cache data may also be written to files if it helps speed
          up model loading/rendering. Only a single instance of data
          will be cached; when rendering, the display software shall
          request scene data which will consist of suitably located
          instances of the cache data; the display software shall be
          responsible for destroying the scene data.
       c. manage parsing of models by selecting an appropriate parser
          instance. This feature will be similar to the io_mgr of
          pcbnew.
       d. manage path resolution. Initially this will implement
          legacy behavior by using the KISYS3DMOD environment
          variable in an attempt to resolve a partial path. In the
          expanded implementation it will attempt to resolve partial
          paths by searching a configurable list of directories in a
          similar fashion to the use of fp-lib-table. Behavior can
          easily be extended to provide access to resources on the
          network via URNs.
       e. manage browsing/selection of models and the specification
          of the offset, rotation, and scale parameters

    3. Modification of the following features to work with the
       implemented changes:
       a. 3DViewer: a substantial rewrite will decouple the 3DViewer
          from the details of all model data on file. The 3DViewer will
          create the board and its features as it currently does, but
          for the display of model data from file it will simply request
          the data from S3D_FRAMEWORK.
       b. VRML Exporter: minor changes will be required to handle the
          switch from S3D_MASTER to S3D_ENTRY. It should be possible to
          extend S3D_FRAMEWORK to reformat its cache data as VRML2
          data which can in turn make it possible to create VRML output
          which has self-contained models rather than the current
          scheme of referencing models by URN, but this will require
          substantially more work and is only a wishlist item. However,
          supporting this wishlist item will make it possible for the
          VRML output to include rendering of non-VRML models such
          as IDF or IGES.
       c. IDF Exporter: minor changes will be required to handle the
          switch from S3D_MASTER to S3D_ENTRY.

Given the strong coupling of software in some parts, I believe the
work must proceed in parallel with all other KiCad development and
that once the refactoring is at the stage where it can provide all
of the currently available features, a very large merge request
is inevitable. With the strong coupling of software I do not see
how the changes can be staged in small parts. For example, replacement
of S3D_MASTER with S3D_ENTRY and S3D_FRAMEWORK within class BOARD
can be simple enough and the change not too big, but 3DViewer will
be unusable until some extensive refactoring is performed, and I
do not consider it reasonable to lose 3DViewer while this work is
in development.

Any comments/suggestions?

- Cirilo