kicad-developers team mailing list archive

[Mário Luzeiro <mrluzeiro@xxxxx>]

Hello Cirilo,

I can only discuss this in relation of the 3d-viewer part.
I remember we had some discussion already about this: https://lists.launchpad.net/kicad-developers/msg18690.html
"I'll have a look at the documents you've written." Do you remember this post?
Did you get a chance to have a look on that?

I share most of your ideas related with 3D model loading (for 3dviewer), That is what I did in the "UML style" diagram I presented to you last time:
bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/download/head:/class_diagram_3dpars-20150617081727-l1z78oarbyy7ps7n-2/class_diagram_3dparsers.svg
That is much what you write in 2b, 3a.

In my idea, I had in mind to completely decouple 3D viewer models stuff from the pcbnew.
In fact, I already did it in my current work in my branch:
https://code.launchpad.net/~mrluzeiro/kicad/kicad
I took away the S3D_MASTER from 3D viewer, however, I agree with your points (and that is the thing pending) that something must be done to make it simpler and clear.
So I agree with your proposal of 1. (this is what I have pending or I will not do in my branch because is pcbnew side)

I do not agree much that the Class BOARD will deal with caching of 3D display..etc
In my idea, I was thinking to keep that as much as possible in 3D viewer side. And try to develop it as a "module", so 3Dviewer will use it, but some other part can access it also.
My idea was to implement is as a "singleton" so it will be present as long as you keep kicad running and available to all projects and boards..etc
So, it was not also board dependent.
In my diagram it is represented by the S3D_LRU_CACHE and class S3D_MODEL_MANAGER
So it represents your 2b.

For 2c (manage parsing of models) That is what I have in mind with S3D_MODEL_PARSER
That is a generic class that will deal to store a "X3D/VRML" type of data that will store the models.
Note that is is not to make a X3D/VRML standard parser/storage, it can be used to store also other formats.
I just based it in X3D/VRML as that is most what we will support. Also, I found that VRML1, VRML2, X3D are not total compatible in relation with data structures, so in order to support this three formats, we cannot go for a standard. So I design my own.

The S3D_MODEL_MANAGER, can be improved (internally implemented) with your suggestions from 2c, 2d

So for 3a, in my mind instead of using a S3D_FRAMEWORK (coupled with Class board) it will call the "S3D_MODEL_MANAGER" decoupled from anything from pcbnew and will be part of 3dviewer.

3b. Yes, that is a wish, something in my mind too..

"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."
"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."

Yes, that will need to be done in "one shot merge"
There is no way to make it progressive with the current 3dviewer (I discuss that already some time ago, so that is why I started working just in my branch)

I have been done some work in my branch and I have plans to start to develop the 3d manager part in some weeks.
If you agree with that structure or we can get a compromise, we can start working in a branch.. expecting in the future we can merge it in the main trunk.
I don't expect that I (we) can have something workable (i.e to be merged back to trunk) in 6m.. 1year

Let me know if we can start working together in the 3D model part.

Mario Luzeiro
________________________________________
From: Kicad-developers [kicad-developers-bounces+mrluzeiro=ua.pt@xxxxxxxxxxxxxxxxxxx] on behalf of Cirilo Bernardo [cirilo.bernardo@xxxxxxxxx]
Sent: 27 August 2015 06:44
To: KiCad Developers
Subject: [Kicad-developers] proposed future changes for 3D model handling

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