kicad-developers team mailing list archive

[Mário Luzeiro <mrluzeiro@xxxxx>]

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


> I think the 3D positioning of components is nothing more than a marketing gimmick.

In the end, it will all be just eye-candies :)
In the end, it is just smoke and mirrors :P

Yeah I don't like / plan use as a user this "3d placement" feature, it was just ONE example to illustrate what is not possible to implement in the way the things are right now.




> The component courtyards are probably one of the best assets for helping with placement
> and in the case of mechanical devices + electronic components if the designer
> cannot handle the information without a 3D viewer then they should be working
> with MCAD people to do formal checks rather than relying on what they imagine
> they see. It is not unusual for mechanical components to obscure so much that
> you cannot possibly see the interference and you need to perform volume collision
> tests and take tolerances into account; you cannot do that with 3D visualization
> and the users will be fooling themselves. 


I agree, that was in the line with my explanation to Wayne.
In my experienced, I worked in one PCB / mechanical project, and in the end, it was the Mechanical eng. that will make the formal check, not the 3D from pcb designer tool.
And so yes, I agree that no matter as good as 3d-viewer could become, it shall not be used for formal mechanic checks, because it is not dealing with 3D data.




> From my perspective what needs to happen to the 3D model component is for some
> thought to go into how we handle different model formats and how we determine
> what code module makes use of different types of 3D models.

I didn't understand, is it related with 3d-viewer / VRML/X3D models?




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




> and in the case of VRML models even an arbitrary scaling. Handling the orientation is trivial but
> how about the translation (offset)?

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.




> What units do we use for the translation?

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

In the footprint 3d module editor (footprint name, position, scale, rotation), position is in inchs. scale is a float, rotation is in angles.

Internally, the VRML file is transformed to whatever the coordinates information it have. In the end, it is converted to the 3DUnit.. 
Sorry if I am not explain in detail, anyway.. but what all it means is that "it render models in a relative size and position to PCB board mesh data" and.. thats why you cannot use this type of 3d-viewer to a proper mechanical evaluation. (3d-viewer deals with 3d triangle mesh models, not 3D CAD data)




> The VRML models for example use 0.1inch = 1 unit but for IDF models what would we use and how do we ensure the correct translation on the PCB whatever
> the selected output units is (mm/inch/mil). Any other MCAD model will share the same issue as the IDF models.

Sorry I didn't understand it (the relation with IDF models and 3D viewer).

I am not sure, but "0.1inch = 1 unit" was something that was defined by KiCad (and thats what is bases to make the transformations to display the models)
If in the case a real CAD format would be used, the units used in that other formats.. shall be converted in a way that it have the same (visual) meaning and dimensions as the others..
.. again.. thats why in the end nobody should use it for formal verification.
or in the another way, if in any time, someone would like to make the 3d-viewer a trusted CAD viewer and real validation tool, much care must be taken with this subjects.. and of course.. VRML/X3D files will not be the proper file formats for that.
It would be too much work and effort and thats why an external proper software should be used for that (using your future! IGES files :) )




> So I imagine we need an API for specifying what type of model to load and what orientation/offset is required; this can be similar in many ways to the File IO plugin.

I don't think we need anything much more fancy, considering 3d-viewer is not a CAD tool. VRML/X3D shall be the only formats for the visualization proposes..




> Each model, whatever it is, must be the member of a base 3D model class. This
> class will present other code modules with information about the type of model
> it is storing - perhaps even a simple enum to let you know if the model is
> VRML(1,2)/x3d(ascii, binary)/IGES/STEP/whatever.

I believe you are thinking something different from me.

By the way,right now, there is someway in the viewer that check the extension type of the model, so I believe other file formats can be added to the list of the footprint but they will not be processed.




> Another function should let you know if the object supports display of the model. For example the VRML/x3d
> models all support display; the IDF models currently do not but it is not a big
> job to create a representation for display. The IGES models will not create a
> representation for display, but if someone had the time to implement one it
> can certainly be done (though nowhere near as simple as displaying IDF).
> But a future 3D viewer for example might have access to IDF and IGES modules
> which will support display, so your 3D view can be a mix of models. Do we
> even entertain such a thing or just say "no, only VRML/x3D shall ever be used
> for 3D model display", in which case only the VRML/x3d modules will say that
> they support display?

If I understand it correctly, yes VRML/X3D support a scene definition that you can set camera position and so on (was that what you mean?)
But, I think we don't need it, because we are render the model, not the scene it have embedded declared.

3d-viewer is (and shall be) basically a 3d triangle render engine. So, no matter which type of plugins / files import we have support, in the end.. it must be just triangles!




> One thing which many of us agreed should happen with the 3D model, and
> VRML/x3d in particular, is that model data needs to be cached rather than
> loading a model 1,000 times if there are 1000 instances of a component
> and also to save time when reloading the board data and refreshing the
> display.

That (avoid multiple instances loading) was already implemented by me during this month.

That is one of main things that I would have in mind: speed up .. i.e. for real-time change of the position of the footprints and update immediately in the 3d-viewer.

Right now, the main consume time of loading is: generate the PCB board triangle mesh (with option remove the holes), (optional)calculate the smooth vertex and rendering all the triangle mesh data.
The way the things are right now, it is very difficult / impossible to speed up whatever we want.. major changes would be needed... thats why I am bringing this discussion without first make any major change! :)




> Another thing which would be nice is better support of the VRML
> and x3d specifications, but I cannot imagine a good way to do this without
> a major refactor.

I spent this latest weeks almost just working on VRML2 parser issues. I believe it is now covering most of the VRML files sources (wings3d, FreeCad, etc..etc)
Still there are some issues and bugs.
Implement a full VRML will be very time consuming, so until now, I am following just the different cases we can found from the different sources (exporters). I found already some exporters that I believe are making incorrect VRML files.




> In cases where there are no normals we would need to somehow create cache files of the normals.

The regular normals are very fast to calculate. The smooth normals in huge models can take time. I think we discuss already something about the cache.. It may come again this discussion in the future.




> What features would you want to add and how will they be useful?

Related with my self and 3D, I am a guy from "3D entertainment" (gamedev, demoscene, 3D realist rendering...) so I like to "just look to it" and get amused :)

When I start to contribute to this 3D-viewer, I was missing some "visual" validation of the PCB with the components / enclosure ("looking good"? "looking bad"?. I am not from CAD, so, for me just a quick visualization of the board and components will be fine.
Then, I missed a good way to make 3D-renders of the board for "marketing proposes" (I dislike a lot some of the very old renders of KiCad that are spread in the web.. they look very primitive comparing to what the 3d-viewer render is today.. )

So, that is OK now, we can load several VRML types of models and have a better looking rendering.

What I special don't like it now is the time it takes to update/render any change..
I miss some real-time interaction with Pcbnew (for adjust the component position and instantaneously see the result).
I think it is useful for planning the design... testing positions of the components.. evaluate the on going results (as a second/ third way of view your board.. )

I have in mind some other features after that, but it will be mainly render-eye-candy or fancy not so useful things that people will have fun and kill the productivity :P


Thanks for you comments!

Regards,
Mario Luzeiro