kicad-developers team mailing list archive

[Mário Luzeiro <mrluzeiro@xxxxx>]

Hi Cirilo, see below
________________________________________
From: Cirilo Bernardo [cirilo.bernardo@xxxxxxxxx]
Sent: 30 March 2015 05:32
To: Mário Luzeiro
Cc: kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] 3d-viewer future discussion

>To be able to introduce IDF models without changing the file format, some
>small changes were made to 3DViewer so that it can select a VRML./X3D
>or an IDF file; of course 3DViewer only cares about VRML/X3D and will
>ignore IDF files.

That is true.
But, in the end, this is more a feature of the pcbboard structure.
Then.. 3d-viewer will only use what it understands / is capable of.




>The structure holding an IDF file essentially only stores
>the filename and the rotation/translation/etc parameters; at the moment
>it never actually loads a model, but if someone wants it can always be
>modified to load a model and create the point set for display. So the idea
>was that there is this concept of a '3D model' - and it can be VRML/X3D,
>IGES, STEP, or even a native MCAD format if anyone had a reason to
>implement a native MCAD exporter. In reality I believe only IGES and STEP
>will be added to the list.

There is no problem to add whatever file in that list. Right now 3d-viewer filter it by extension and only consider to open the VRML/X3D files.
That can be extended of course in future for other file formats.




> One thing all 3D models share in common is the arbitrary (0,0,0) reference
> and orientation. All 3D models also have the potential to create a point set
> for rendering. A consumer of 3D models may also potentially mix models;
>for example a STEP exporter might accept (and translate) IGES models.
>The VRML exporter or 3DViewer may decide to render an IGES or STEP
>model. There are many possibilities and I don't believe we should make the
>design so rigid that these possibilities are excluded.

I think that is related with 3D export features.
In case of 3d-viewer, it will only display what it can from the information it receives.

I understand that 3d file formats are capable of multiple instances /views / configuration options?
For example, some VRML models have information to render it with just points, lines, .. or the normal mesh. but IMO, and related with 3d-viewer, I don't think we should care or manage all this options. it will create too much complexity.. and it will be specific for each file formats.. that will be too much work with no much revenue.
That management should be pre-processed in a proper CAD software.
So, it is not making the "design so rigid" but, IMO, we shall not consider it because of the amount of work that will be needed to deal with all specific situations... when it can be solved previously by a 3rd part CAD software.

Ideally for 3d-viewer, you want something simpler.. closer as much as possible to a triangle mesh model..
What I am seen this days, is that the VRML models that you can get online, converted from CAD models, come in a very high complexity and most of the times, not a good conversion and with useless features inside the VRML file.
Simpler and tailored VRML models, as your models, are the best to be handled.




> The most important point I have to make at the moment is that we can
> continue to support an arbitrary number of 3D model types with no
> change to the file format but we do need a coherent system for
> registering the modules which can store extra parameters (currently
> translation, scale, orientation) and model filename. If no one does this
> I will eventually get around to it since it is needed by the IGES exporter
> which I am working on, but if more people work on this feature I
> certainly wouldn't complain.


OK, that is not my department ;)

But yeah, of course that should be handled if you really want to add some specific options to different types.. but again (like the previous point) you have to deal with each specific case.




> i. allow only 1 'scale' parameter for VRML models; since it is so easy
> to generate nice models using tools like my 3D VRML parametric
> modeler I see little value in reusing existing models by distorting their
> dimensions, especially now that there are so many high quality models
> available and when more people seem to be using VRML to obtain
> more realistic images of the final product. The remaining 'scale' should
> be used to scale the model to KiCad's 1U = 0.1inch model space.

I am not sure if I understand why you only want 1 scale parameter.
I think the way it is now is OK with translation, scale, rotation.
In the end, every single 3d point will be transformed by a matrix, so, it is not a problem to have all 3 options.

Other think that I am not sure if you are considering it:
KiCad consider that "1U = 0.1inch" conversion, but, that is just an assumption and convention, there is no way to validate from the model that the coordinates points are really in that unities.
So, what happen now, is that you will get unknown scale unities from other online models sources.
And that is why you need to scale it / translate / rotate...
And that is why using VRML models cannot be used for formal validation.. because they don't have an embedded scale that comes from the model.. and you are just adjusting it visually by "trial and error".




> ii. treat the X,Y,Z rotation and X,Y,Z offset as a set of parameters to
> normalize the orientation and (0,0,0) reference of the model. Once
> someone has worked out the parameters used for a specific model
> then there is no need to change these values. Now there are times
> when you want to add several models to a single component - for
> example a ZIF socket + DIP. For that we will need a 'board offset'
> parameter which is essentially a second Z offset.

If I understand you correctly, you mean that you have to setup each offset/scale/rotation every time when you add a 3D file to a footprint.

3d (VRML and other formats) files have embedded transformation information.. and.. the polygon mesh data.. 
In case of VRML, if someone would like to fix that "offset" you can add text information to the file (translate, scale, rotation)
and that is correctly processed by 3d-viewer.
So, In this case, you will fix it directly in the 3d VRML model file. And that is the proper way to do it.


If you mean that we shall have a global "offset" to apply to all assigned 3D models in one footprint? Its doable but don't see much use.




> We will also need
> to specify the units for the offsets; I would suggest only permitting
> units of inch, mm, 0.1inch, and maybe mils; this way each user can
> specify the offsets in whichever unit they are most comfortable with.

I think that are the types of improvements for the "manager".




> iii. to control the potential rendering of non-VRML/X3D models in
> 3Dviewer, add a 'visible' flag. Naturally such a flag may also be
> used to suppress a VRML model from being displayed in the
> 3Dviewer.

Yes, I think it misses that flag.
Last project I was working with KiCad I need to have an enclosure.. so it was very difficult to use the 3d-viewer to see the board with or without the enclosure (show/hide)
You can think how to add it when you make that changes you have in mind for the file format...

But.. but.. and now I back to my initial point, the way the things are right now with pcbnew + 3dviewer that will be annoying because you will have to generate everthing again and wait a lot of time!
So, that is another example of things that will not look nice and cannot be handled properly right now.
It would be nice in the future to click show/hide/show/hide in that manager... and see it change in real time in 3d viewer! so you can "visual evaluate" it.. and not waiting minutes to see the render image changes..




>>> In addition all models of course may have an arbitrary orientation and position
>> If I understand correctly, we have it already now, that how they are added to the footprints..etc.
>> As Wayne suggest, I miss a better management for this in Pcbnew, and, as in my idea, you can tune it in that management windows and see the result in real-time in the 3d-viewer!

>That would be a very nice addition - perhaps a previewer with a mark at the
> (0,0,0) position? If there is a 3D scale grid as well that would also help determine
> if the model scale is correct.

Yes, what I was checking with other 3d software packages, is that they have a "tool manager" to add the 3d models to footprints.. and you can do a "visual real-time validation" of the adjustments.. so you can scale it.. translate.. and see if the pins fit the holes.. for example.
Not sure if this is already possible in the current KiCad when you are editing a footprint, you may have to save the changes and open / refresh the 3d-viewer.. 
but it is not "automatic interactive" and you have to do it manually.




>> The 3D viewer already supports it in the 3D Mesh/Models architecture, so, it will work for for VRML and X3D..etc
>> Because you can make a tree of sub-modules, each model have his own transformation (offset, scale, orientation) and it will do it recursively.
>> Most of the VRML models files have their data split in a tree of sub-triangles models.

>If a single object can store the basic data for all instances and calculate the point
>sets for each instance I think this could be a huge improvement to the 3D model
>loading and rendering time.

As I explained before, loading of the models files don't take much time. In fact it is what 3d-viewer spend less time. (Remember pcb board with holes extracting and smooth normals will take almost all the huge time)
I think what you describe could be related with cache (that can be used to store the computed normals).
I think I will need more time to think on it, or post-done it. If may need to add new .cache files to the project .. maybe that will be a controversial thing to do.




>> What units do we use for the translation?

> The 3d-viewer only work with one unit... the 3DUnit :)


> That's fine for the VRML/X3D models, but as I said before I think it's
> best if VRML/X3D and other MCAD formats are all treated as a
> logical item,  the '3D model', rather than treating VRML/X3D as
> a special case. As I said, there is even potential for actual
> rendering of other model types so to me excluding this by
> treating VRML/X3D as a special case would be a poor design
> decision considering that nothing complex is required to treat
> all 3D models of any type as a single class. The logical grouping
> of 3D models is already done and is how IDF and VRML code
> use the existing file format. Of course having an improved class
> structure, rather than the current ad-hoc changes to accommodate
> IDF, would make the code more manageable.


I don't think there is any issue or special case treating, depends how do you see the things:

In order to render triangles, their coordinates need values to be displayed on the screen.

That coordinates are in the "3d viewer unities" because it is dealing with the final display processing.

The board data is converted to that unities, the models are converted to that unities.
In the end, visually, that "VRML 1U to 0.1inch" unities will match the board size.
So visually, the unities will match.

If you have any other file format in with whatever unities.. it will need to be converted to "3d unities" in order to be rendered.

The classes and structures in 3d-viewer, have in mind the final rendering process and not proper for any CAD format.

But, if you mean anything from pcbnew side, then yes, that should be manage in meaningful real unities (inchs or metric)
So, I agree that from the pcbnew side, whatever information it deals, it should be in a "CAD" format, but for 3d-viewer side, it must handle structures with a uniform internal unity in order to send it to GPU.





> No, I mean that in the current code only the VRML/X3D structures provide data
> needed for rendering, but that will not necessarily be the case in the future.

Right



> So the questions are
> (a) how will  3DViewer know if it can display a particular model

Only if it supports that file format. Right now, it checks the file .extension to identify the file format type.



> and (b) how will 3DViewer know if it *should* render that model. The current list
> of enumerated items which I initially added to provide IDF support will not be
> sufficient to decide what to render. We might also ask: how will the IDF exporter
> know if it can extract useful data from the 3DModel object?

You may want to add that suggested "visible / use" flag.



> At the moment it simply checks the to see if the object represents an IDF model, but it is possible
> to also use VRML data to determine a bounding box and produce an IDF model.

Yes, doable.. almost possible right now since all the models have now a bounding box.



> If we do not structure the code to allow for these possibilities in the future then
> people may not be able to provide such features without extensive refactoring
> again. 

You can think in that possibility of get a bounding box from a VRML file. I am not sure how that should be addressed in the architecture of KiCad.
I dont see it as a 3d-viewer related feature, but, they may share code to make that import and processing.
 
So.. maybe your exporter lets say specific call "Load me this VRML model and calculate the bounding box"
Then all you have to do is to keep in mind to use the transformations defined by the user (in the 3d models manager footprint .. translation.. scale.. position. .whataver)
and convert the final bounding box coordinates (that are in 3d unities) to imperial or metric to your CAD model.

That should work.

If that will be something desirable in future, yeah, we must keep open the discussion to be able to reuse the code and see how it fits the architecture code of KiCad.




> That's great, I think we really need more people with expertise in the 3D rendering
> support; the code has been begging for some attention for some time now. Even
> providing a more universal support for VRML's 'DEF .. USE' constructs would be a
> great help; I could really shrink the size of many model files with repetitive features
> such as pins if I could make use of USE/DEF/TRANSFORM.

It is already supporting USE / DEF / Transformations

As I explained before, what I found is that different exporters / model files sources, do it in a very different manner and cases.
As an example, I found a VRML2 model sources site, that their modules files have the data stored in a DEF (define) .. but. they never call any USE ! I am not sure if this is correct or not, but I handled it in the parser and in case there are DEFs but no USEs, it will force adding all DEFs.

So.. in this case I am going case by case to add more support to VRML2.

You can also use the URL keyword (load external model) right now to load external files (and have Transformation) .. you can try use it by exporting your PCB using your VRML exporter and try load it again to a footprint model and see it in the 3D-viewer!


Regards,
Mario Luzeiro