kicad-developers team mailing list archive

[Mário Luzeiro <mrluzeiro@xxxxx>]

Hi Cirilo,

> I think we have fairly different ideas about a few things.

>From the other emails, I saw that I agree with most of your ideas and the necessities that need to be changes.
which ones do you think I have different ideas?
I am very flexible and open to discussion. Also, I will be happy if I can get the model data as soon as possible to start doing experiments in other parts, so no problem how that is made for me by now as long as it is easy to work.

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

I agreed with that.
As I explain, we can put the parser (and whatever manager) outside 3d_viewer in a proper place.
Also, as I explained in last email, that structures that I propose are not related with the display data.
The display part will convert it at some point..That is not yet defined what it will be.


> In the case of IGES for example, the display data must be calculated from the various surface
> descriptions
> In the case of IGES for example, the display data must be calculated from the various surface descriptions
> but in most cases it will be surfaces described by polynomial B-splines.

I am not sure what you describe here.
Are you propose that we will need to parser a IGES and store their "vectorial data" ?
That could be done, for example extended the XV3D_GEOMETRY_NODE (see my class_diagram_3dXV3D%20.svg)
As you see there are already boxes, cylinders, cones, spheres (parametic objects) so it could be extended to toher surface descriptions.

I believe that we may need a common structure to store this information, instead of a different one to each file ext.
my point is that we may not have a single "display data format" to convert too (since this is not designed yet and there could be different formats that it must be converted)


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

Why do you want to discard the model loaded if the propose is to keep it in cache for reuse in the future?
The display data will depend a lot of the board size, position, etc, so it can change a lot of times (rotation,scale,translation.etc)
But the original data should be the same.

> 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

IMO, we don't need to have in mind what will be the render data by now.
In my current design, I consider that we can have multiple implementations of visualization / render type. So each one can use different data structures.

This implementations, should convert (in accord with my current design) a XV3D_NODE_PTR model, to his internal data structure to be displayed.


> 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 had that in mind too. Too much work now to rewrite again the parsers.
however, the parsers must be adapted to the new classes and model structure
But that will be easy.

Mario Luzeiro

________________________________________
From: Cirilo Bernardo [cirilo.bernardo@xxxxxxxxx]
Sent: 28 August 2015 08:28
To: Mário Luzeiro
Cc: KiCad Developers
Subject: Re: [Kicad-developers] proposed future changes for 3D model handling

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