kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

Thanks Mario,

 I think we have fairly different ideas about a few things.  I would
separate
the display data from the parser since the parser may contain very large
amounts of data which you really don't want.  In the case of IGES for
example, the display data must be calculated from the various surface
descriptions - these may be vertex sets as in the case of VRML but in most
cases it will be surfaces described by polynomial B-splines. My idea is
that if a model's display data is requested then the model is actually
loaded
and the display data is produced and any other data is then discarded.
The parser itself may occupy a significant amount of memory. In the case
of IGES this is currently around 3MB but it will grow as the actual display
features are implemented in the future, and STEP will definitely be much
larger, especially if we initially use OpenCascade to implement it.

 Once the display data is created it's easy to instantiate a component and
it's also easy to write that display data to file as a VRML object. I think
the
model manager should be responsible for such things or perhaps another
class so that we can limit the responsibilities (and code size) of the
manager.

 My idea for the display data structure at the moment is that it will
contain
only the data needed to render an object. The actual rendering routines
will be in a separate class, unlike in the current system where the
S3D_MASTER contains the rendering routines.

 My other plan was to make use of the existing parsers for the initial
implementation, just to demonstrate how it will work. I think interfacing
new parsers to replace the older ones shouldn't be difficult, but at
the moment I can't give a fixed API for it.

 I would suggest that I start on the refactoring and we keep in touch to
discuss ideas as the code develops so I can be sure that we're not
making incompatible plans. Initially I will put the manager into the
BOARD class for convenience, but we can relocate it at a later
time if we wish.

- Cirilo



On Fri, Aug 28, 2015 at 10:44 AM, Mário Luzeiro <mrluzeiro@xxxxx> wrote:

> Hi Cirilo,
>
> > We would probably have to create more
> > dummy class headers or class diagrams to explain what we want to
> > do before we do it
>
> have a look at this header:
>
> http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/view/head:/3d-viewer/3d_parsers/s3d_model_manager.h
>
> it declares the S3D_MODEL_MANAGER as it is represented here:
>
> http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/download/head:/class_diagram_3dpars-20150617081727-l1z78oarbyy7ps7n-2/class_diagram_3dparsers.svg
>
> That is the only source I have so far related,that class have only two
> public functions.
> bool GetModel(const wxString &aFileName, XV3D_NODE_PTR aDstNode_Ptr)
> void SetCacheSize(size_t aNewCacheSize)
>
>
> XV3D_NODE_PTR structure is sketched here:
>
> http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/download/head:/class_diagram_3dxv3d-20150617081727-l1z78oarbyy7ps7n-1/class_diagram_3dXV3D.svg
>
> The GetModel would implement and hide the parser it will switch between a
> parser based on the class S3D_MODEL_PARSER and on the filetype extension.
>
>
> Mario Luzeiro