kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

Hi Mario,

On Thu, Aug 27, 2015 at 7:40 PM, Mário Luzeiro <mrluzeiro@xxxxx> wrote:

> 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.
>
>
I'm not very happy with the 3D manager being inside BOARD either; we can
remove
it as long as we have a good mechanism for accessing it and don't pollute
the
global namespace.


> 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.
>
>
I think the model parser should be completely separate from the display
data.
The parser should read the file and put the display data into a structure;
the
instance of the parser can be destroyed after that and perhaps we even
dynamically load/unload the parser classes. This can be useful in the case
of solid model parsers since they can require a lot of memory. Another
advantage to removing the display data from the parser is that you can
choose to create a single instance of each and use it to populate any
number of display data structures.


> 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.
>
>
Model manager sounds better. I would not associate it with 3DViewer though;
for me the manager should also do the work of selecting and previewing
models and setting the scale, rotation, and offset. The manager may also be
invoked by any 3D exporters such as the existing VRML and IDF exporters.


> 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.
>
>
I'll pull in your branch and see what changes you've made so far. We
will undoubtedly have some different ideas about things and I think
it can be very difficult collaborating on a task like this when we are
in very different timezones. We would probably have to create more
dummy class headers or class diagrams to explain what we want to
do before we do it, but it could work. With the work I planned I think
it is possible to write large parts of it without integrating with
pcbnew, so I suspect I can create headers, Doxygen documentation
and maybe even class diagrams.

- Cirilo




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