kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

On Wed, Jun 17, 2015 at 8:02 AM, Mário Luzeiro <mrluzeiro@xxxxx> wrote:

> Hi Tom,
>
>
> > - a cleanup of the 3D model loading/storage code: a clean mesh class
> > (holding the geometry/assembly info) and refactoring of the 3d-viewer
>
> Ya, I started already thinking/working on some ideas for a future
> 3d-viewer (not only the model parsers) [3].
> As I explained before [1][2], I am not thinking to contribute more to the
> current 3d-viewer as it is. Instead, I would like to spend time develop
> this new version.
>
>
>
> > (and further on, exporter code) to use it.
>
> 3d-viewer is something a bit aside from the rest of the kicad.
> The only thing 3d-viewer is exporting are .png and .jpg files :) The
> "model exporters" ("supported by Cirilo") is related with pcbnew.
> One of my ideas is that the "3d-viewer model parsers library" could be
> used in the future by the other parts of the code (eg: the importers /
> exporters... of the pcbnew).
> So we could have something like:
> 3dmodel = modelparser.Load( "full path file name" );
> 3dmodel.GetBBox(); ...
> 3dmodel.MeshTriList()...
>
> Probably something like that could be possible now or not (I don't
> remember :| ) but I remember that all that code (I mean .. the
> architecture) is ugly and I dont like to look on that :)
> (well.. I believe that thankfully this is an opensource project and I can
> have the option to choose not do it :) )
>
> I found useful this discussion so I can get a more clear view for a future
> design.
>
>
I think we will need a base class with a consistent API for handling the 3D
data and
a "manager" class to instantiate appropriate derived classes. The base
class will of
course store the name of the 3D file and if we wish to keep the memory
footprint
small we should also maintain a list of pointers to the components which
reference the model and the associated scale/rotation/offset data. I see at
least 2
use cases here:

1. VRML/IGES/STEP/IDF Export: only the file names and position data will be
needed
2. 3D Viewer/3D model selection dialog: facets must be generated for
display,
    implying that the model must be loaded by the derived class and
converted for
    display. Since a single model can be instantiated many times, the
derived class
    must store all data for the nominal definition and create the
structures for each
    instance on demand. In the case of the model selection we simply
display the
    nominal definition. With this scheme, if a footprint is altered to
remove a model
    (instance deleted) or another instance is added, the derived class can
quickly
    recalculate the new set of vertices etc to represent all instances.

So I would not include a modelparser.Load( "path" ) at all, but leave the
derived class
to decide when to load the model data. The GetBBBox() will be useful, but
for the
actual data to display I would have 2 functions: GetMeshDef() to copy the
nominal
definition and GetMeshInstances() to get data to display all instances. In
the manager
class we will need Add3DModel( [pointer to footprint], [path], [orientation
data] ) and
also Del3DModel( [pointer to footprint] ). The [pointer to footprint] is
really only
intended as a unique ID for managing the list of orientation data; we can
pass in an
invalid pointer value if we wish to load a model for display in a model
selection GUI
as long as we call Del3DModel() using the same invalid pointer value.



>
>
> > I see you made the S3D_MESH class, which is already quite clean and
> could be easily integrated with the STEP mesher.
>
> S3D_MESH was already there when I started, I don't remember exactly what I
> changed.. but added more support and capabilities. However, that is still
> very ugly.
>
> Any way, It should be easier to add some importer, if you have a library
> that gives you a list of triangles already magically processed.
> It should be just fill the (not elegant) S3D_MESH data.
>
>
>
> > One thing that might be needed is storing same
> > sub-meshes with different transforms (imagine a BGA footprint with 1000
> > identical balls - the current design of the class requires copying the
> > mesh data 1000 times, correct me if I'm wrong please).
>
> I don't remember the details, however I believe that it not an issue *see
> note below..
> The issue, that I will also try to address properly in the future, is the
> loading and processing of the model files.
> Right now there is already a simple mechanism that will load just once a
> model that repeats in the board (per reload).
> What I plan is to have a cache between "reloads" so that cache can be
> reused if you are opening (or maybe using) different boards.
> Right now, the model loader spend some time to calculate the normals of
> the files (ideally we have cache files) so keep the cache (at least between
> refresh / reloads of the board) will help speed up the things.
>
> *note: "the 1000 BGA balls"
> That could lead to a bigger discussion, but I believe it doesn't matter
> much.
> It should depend more on the engine that is rendering the model.
> Lets say an example this two situations:
> 1. use one instance of the BGA ball and send it to the (memory of the)
> GPU. Then ask the GPU (passing all transformations every time it need to
> redraw) to render all the BGA balls one by one.
> 2. use one instance of the BGA ball, transform (on loading time) all the
> 1000 BGA balls and send it already transformed to GPU. Then ask the GPU to
> render "all balls".
>
> So.. I am not sure which will be faster, but, I believe both options are
> faster so we shouldn't care much now.
>
>
For me it is best to create the data for all 1000 balls at once; this way
the
data is in a flat format rather than in hierarchical structures. A flat
format
will also allow the derived classes to use some kind of cache folder to
store
the flat binary data in a way that is much easier to load; this can be
especially
important when rendering STEP or IGES models since generating a visual
representation is computation intensive; in the case of IGES for example
even a planar surface is represented by rational polynomials.


>
>
> > - improved way to associate a STEP/IGES/VRML/whatever with the PCB
> footprints.
>
> What do you mean? You mean the "pcbnew footprint 3d library association
> UI" ?
> That is related with pcbnew :)
> However, as I discuss before, I plan (for a future version) that it will
> be possible then to "instantiate" (by a widget / canvas...) a 3d-viewer so
> it will be possible to add it to the UI and adjust "in real time" the
> module to the footprint.
> So user will get immediately the feedback.
>
>
If we follow the scheme I mentioned we can abuse the 3D model manager to
obtain
the mesh to display; there will be no need to invoke the 3D viewer just to
display
a single component (note: the component may be a complex subassembly).

If there are no objections I'll work on the 3D Manager and base class for
3D models. I should be able to move the existing VRML/X3D code into
this as well as the IDF code. I should also be able to generate display
data for the IDF models, though I may also need to refactor the IDF
framework code to do it.

- Cirilo