← Back to team overview

kicad-developers team mailing list archive

Re: 3D refactor branch

 

Hi Mario,

On Sun, Aug 30, 2015 at 9:29 PM, Mário Luzeiro <mrluzeiro@xxxxx> wrote:

> Hi Cirilo,
>
> I was looking in your sketch.
>
> The S3D_ENTRY is nice
> (in fact, it is very similar to what I said I was working in my branch [1]
> but it still need a clean review and refactor)
>
> but.. as I was discussing before, I believe it is not a good idea to
> associate any display data with S3D_ENTRY:
> boost::shared_ptr<DISPLAY_DATA_3D const*> m_DisplayData;
>
>
The display data is only a shared pointer and it will not be set unless a
parser has
loaded a module and created the display data. The pointer is in S3D_ENTRY
for
quick reference; otherwise we would waste a ridiculous amount of time
searching for
the related data in other places. In this design if display data is needed
and none is
available yet then it is requested from the model manager, and if the data
already
exists then it is used.


> I believe pcbnew doesn't need to know whether something will be displayed
> or not, or that a 3d-viewer exists at all..
> For me that S3D_ENTRY is just a structure to store the proprieties of a
> footprint module.
>
>
pcbnew will not know anything - not even what types of models can be loaded;
after all this should not be the responsibility of pcbnew. For convenience
pcbnew
will have an instance of the model manager, probably inside BOARD initially,
but personally I think we will need to think of a way to move it somewhere
else -
but that's a job for the future.


> In that case, pcbnew don't need to cache anything.
> IMO the cache (what I call model manager) should be separate (it can even
> be separate from 3d-viewer, since it maybe used by exporters etc..).
>
> That cache, can store (in the original model scale) the triangle data
> (tri,norm,colors,mat,etc) and only someone that need if will request it
> (ex:3d-viewer)
>
>
Only the model manager will cache data; it is the only sensible method to
manage
the data. The MODULE does not even need to maintain a list of S3D_ENTRY; it
can request such data from the model manager. Since we do not access such
data frequently, the O( sqrt(N) ) search operation should not be a problem;
if it is
then a MODULE can store a single pointer to another structure. Except for
the
code to parse and write the 3D Model entries in a pcb file, I expect pcbnew
to be
almost 100% ignorant of 3D models and their data.


> That was what I propose before, a 3d viewer(or other module that want that
> display data) just request a filename (or it can be a S3D_ENTRY if you
> want.. so it will get the file name from it) and the cache will return the
> (original file) display data.
> That data will be converted then as the consumer (3dviwer) internal need
> it. (that should be a fast operation).
>
> In this case, your concern at:
> "[...]the model manager must somehow update
>  *    information on some basis. Exactly when to update information is
>  *    something of an art.[...]"
>
> will not exist. because there is no association need between the cached
> (3D data) and the whatever pcbnew module/S3D_Entry..etc
>
>
I think you misunderstood the note. The model manager will need some cues to
help manage information since, for example, browsing for a model to use will
cause the manager to call the parser and create display data for each model
you preview in the file browser. But for me this is a detail which is not
important
at this stage; we will be able to come up with some reasonable compromise
in the future.


> Lets say that If we plan in future to have a 3d file browser/viewer, a
> 3D_model_viewer could be latter developed.
> You can send a S3D_ENTRY to that 3D_model_viewer, it will request to the
> cache, giving the filename, and the cache will return the original (scale)
> triangle data (if it manage to open and parse correctly the file..etc). It
> will apply the transformations from S3D_ENTRY (and the others need by the
> viewer it self.. ex: center the model in the view, perspective
> transformation, animation rotation, etc) and display it.
>
>
That is not quite how I imagine the relationships working, but at this
early stage
there is not enough detail to be discussed yet. The relationships will be
more
complex since there is the reference instance (DISPLAY_DATA_3D - maybe I
will change the name later) and each model actually displayed needs a
specific instantiation which is derived from the reference. Only the
reference is
cached; specific instances are created/destroyed as required.


> That cache can live as long the kicad is open and be reused by different
> pcbnew projects files.
>
>
> " * @file 3d_model_manager.h
>  * manages 3D models filenames and filename resolution, display data,
>  * and 3D model file selection. Additional wishlist items include:
>  * + display data caching
>  * + search path configuration
>  * + remote access/browsing via git
> "
>
> I am having some difficulties to understand the propose of this manager
> (and the association between MODULE and S3D_ENTRY)
> With the exception of the "display data" I think that it should be a
> utility for the pcbnew and to manage the files and associations that the
> pcb board have.
> That maybe replace the current dialogue where you edit the fine names and
> scale, so that will be improved?
> (something similar to a library browser and selection and configuration?)
>
>
A large part of the improvement will simply be decoupling code so that the
code becomes
easier to maintain.  Small changes have accumulated over the years and has
resulted in
too much code coupling and code maintenance is becoming more difficult. For
example,
adding another 3D model type requires touching many files in pcbnew which
in turn
requires a complete rebuild of the source code. It should be possible to
structure the code
so that adding a new 3D model type only requires an incremental build.

In the case of the 3D model file selection there will be many improvements;
for
example pcbnew no longer has to know about all the possible 3D model
filename
extensions. The file selector can also be extended in the future to support
multiple search paths and even resources on the network/internet; with the
current code structure it makes no sense to attempt such a thing.


> So if what I understand correctly, I think this should be more close to
> the pcbnew and the 3DViewer. As I said before, if then you need to display
> a 3DFile, it should be easy to develop a new module for that.. where you
> just give a S3D_ENTRY and it will give you a (canvas ?) render that you can
> put in a UI for visualization.
>
>
The model manager will still have a relationship with pcbnew and the BOARD
and MODULE classes; this is for convenience. It is possible to completely
decouple this, but I don't see any advantage in that unless you want to
develop
a generic 3D model file viewer independent of KiCad, but that is not my
objective. But even with the relationship I imagine with BOARD and MODULE,
it should be possible to develop a stand-alone generic 3D viewer using the
code - it is only a matter of creating a few dummy classes with the
appropriate
stubs and having a dependency on wxWidgets. In fact that is the strategy I
plan to use while devloping the code so that I can avoid touching any of the
existing KiCad code until I am sure the new 3D model manager works.

- Cirilo


> Mario Luzeiro
>
> [1]
>
> http://bazaar.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer/view/head:/pcbnew/s3d_master.h#L93
>
> ________________________________________
> From: Kicad-developers [kicad-developers-bounces+mrluzeiro=
> ua.pt@xxxxxxxxxxxxxxxxxxx] on behalf of Cirilo Bernardo [
> cirilo.bernardo@xxxxxxxxx]
> Sent: 30 August 2015 04:59
> To: KiCad Developers
> Subject: [Kicad-developers] 3D refactor branch
>
> I've created a branch for the 3D refactor work; if anyone is interested
> in checking on progress the branch is:
>
> https://code.launchpad.net/~cirilo-bernardo/kicad/3drefactor
>
> My current plan is for the vast bulk of the new code to
> sit independently in its own working directory and not to
> pull in any KiCad dependencies until the code can be
> demonstrated to work. I should be able to create a GUI
> test program for the new code and perform quite a bit
> of testing before I ever touch any of the existing pcbnew
> and 3DViewer code. This should force me to make sure
> that the code coupling with the rest of KiCad is very weak.
> To be able to write the GUI test code I will need to create
> stubs that mimic some features of the BOARD and
> MODULE classes; if I find myself adding too many
> features to the stubs then I know I'm doing things wrong.
>
> - Cirilo
>

Follow ups

References