kicad-developers team mailing list archive

[Mário Luzeiro <mrluzeiro@xxxxx>]

Hi Cirilo,

I agree in generally with the necessities you pointed. Except the ones I will comment below :)

Still don't agree with the necessity of tracking a pointer to display data in S3D_ENTRY, special if you also agree that we need decoupling.

Your S3D_ENTRY, the (current/old) S3D_MASTER was used by 3d-viewer, the 3d file parsers, the pcbnew dialogs, 3d exporters, etc
https://github.com/KiCad/kicad-source-mirror/search?p=1&q=S3D_MASTER&utf8=%E2%9C%93

The S3D_ENTRY content have data in relation of the description and parameter definition.
Removing all that "3d model data related" from the S3D_MASTER we get the S3D_ENTRY.
And I believe the propose was to decouple any relation between that description with any 3d-viewer data.
If you search in that link for the use of S3D_MASTER you will see that pcbnew is using it for other internal proposes that will not be related with handling any 3d-model data. (ex: the pcbnew dialogs just use it to store the transformation information and filename..etc.)

So keeping that pointer to 3d-data in S3D_ENTRY is forcing an relation with the use of that data.
It will force a relation with 3d-viewer(that will display that data), a relation with module manager and parses, etc and there is no need for that relation because it is not the main propose of the use of the S3D_ENTRY.

I will add some more of my points below.



> 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 don't see why "ridiculous amount of time searching for the related data in other places", you said yourself later:
"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;"

I believe a normal use of kicad, you will never have more than 100, 1K, (10K..) modules to search. So should be in any case any problems search for any relation.


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

My previous suggestion was to implement it as a "singleton pattern" and put it in a global space.
In that case it will be instantiated only the first time someone use it and it there will only be one instance of that module "model manager". (So it will be available for other boards..etc)
I think that is a design decision that can be made at this point.




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

IMO the only cue the model manager need is the fullPathFilename/URL to pass it to the parser and store the "whatever structure, original scale, model data".
I will explain again below.




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

IMO only the original reference data need to be created and cache managed, the specific necessities in relation with how to display in relation of the parameters in a S3D_ENTRY are for the responsibility of who will use that data/information (ex some 3d-viewer implementation, or a 3d-exporter).

I don't see any complex relation, I see no relation at all.

If I understand it, if you mean that
store a "needs a specific instantiation" = ApplyTransformation( S3D_ENTRY, "original reference" )

That will not be needed and should be avoided. That will be assume a lot about the use of that 3D Data and we should let it to the implementation (of a 3d-viewer, or a exporter, etc) that will use the original data to decide what is the best way of handle it. Also, there is no noticeable penalty to apply the transformations "on the fly" because:
- You will only apply the transformation when you will really use it (ex: the 3D display convert the model data to be transformed to display at pre-load before start the rendering)
- Apply transformations with CPU is fast and the models are not huge complex, (and you do it only once when load the model to GPU in case of 3dviewer)
- If you consider use GPU shaders, that transformation can be performed by the shader on the fly, so no CPU is used at all (this is specific to an implementation)
- If you consider using GPU memory, a 3d-viewer implementation can implement its own cache manager, so while you have your (ex: opengl) context you can cache the it GPU to be reused latter. (this is specific to an implementation)

That is why I give the example that you can pass a S3D_ENTRY (without the model data pointer) to some visualization implementation and it will request to the model manage the original reference data model .. if need it.. because that implementation can have its own internal cache.

Another hypothetical example: you have a module that exports to VRML and lets say that the user do / request a lots of exports
That exporter will get the information from the board, will get a S3D_ENTRY with the file name and transformations. Now consider that: VRML can store/declare instances of model data and reused latter.
So the exporter should request (passing the file name) to the model manager the original data file and convert it (or request to other module or function) to convert that original data to VRML string.

If the board use the same filename model, the exporter will only keep one VRML string of that module and just reuse the transformations from S3D_ENTRY.
Also, if you be really inventive, that exporter can implemented its own cache manager of VRML strings of the original data model... so it could be reused with different projects while the kicad is not closed.


> 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

I think the model manager should be global. There is no force relation with "generic viewers". It will be used by whatever 3dviewers and 3d exporters so should be generic for this type of use.
The module manager should be only visible by who need to use the 3d model data (ex: any 3d viewer implementation or any 3d exporter implementation)
The pcbnew, the BOARD and the MODULE classes will not use the 3d model data so I see no point to associate it.

For example If the pcbnew wants to do a "3D ECR", it should be implemented by another module. That module, will use S3D_ENTRY (file name and transformation) and will request (by full file name) to the "model manager" the original reference model data that it needs. Note that it probably would like to make some pre-processing of that data, for example, create a "hierarchical bounding boxes" (associated to that model full file name) that it could reuse to test the other references of the same model file in the board. Still in this case, there is no relation with BOARD/MODULE/pcbnew and the "model manager". The relation will be with "3D ECR module" and the "model manager".

Cheers,
Mario Luzeiro