kicad-developers team mailing list archive

[Mário Luzeiro <mrluzeiro@xxxxx>]

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;

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.

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)

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

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

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.

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