kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

Hi Miguel,

  Thanks for the feedback, it's much appreciated.




>________________________________
> From: Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>
>To: Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx> 
>Cc: "kicad-developers@xxxxxxxxxxxxxxxxxxx" <kicad-developers@xxxxxxxxxxxxxxxxxxx> 
>Sent: Sunday, May 27, 2012 10:58 PM
>Subject: Re: [Kicad-developers] Future of 3D models in KiCAD
> 
>
>Hi Cirilo!, 
>
>
>   Your proposal seems quite good to me, I think KiCad has a very nice 3D support, but still weak when it comes to integration to MCAD tools, so some work on this would be veeery very nice :)
>
>
>2012/5/26 Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>
>
>Hi everyone,  I'm looking for some comments from interested parties on some suggestions of mine regarding future directions for 3D models in KiCAD.
>>
>>
>>I have spent some time thinking about the future of 3D models in KiCAD and how things need to evolve to provide useful features for users. One feature which would be very useful (in fact indispensable in many professional shops) is the ability to produce a solid model which a second party can use for other purposes such as designing the packaging. To provide such functionality to the largest number of users, I have investigated a number of free mechanical CAD packages.  I have put some thought into how the scheme can be developed so that (1) the current VRML support remains and can be extended and (2) others can add support for their favorite CAD.
>>
>
>
>This is an important feature, I've been playing recently with .step in FreeCAD, and the .step support worked quite well. It also seems to be the standard for 3D exchange for mechanical CAD.
> 

Yes, STEP AP203 (and more recently AP214) and the much older IGES are perhaps the most widely supported formats for exchanging 3D shapes.


>
>> What I propose is to maintain a separate set of MCAD tools to achieve the desired outcome. This would allow users maximum flexibility in their choice of MCAD package (provided they write tools for it) while keeping KiCAD free of the burden of maintaining code which is highly specialised for a particular MCAD and also free KiCAD of any MCAD related configuration options. However, KiCAD will need to provide some minimal support to achieve this goal. I'm not asking that developers take on this extra work; I'm happy to get stuck into the code some time in the future after I have a more substantial proof of concept to present. For now I am posting this to get feedback on some proposals before I proceed and possibly come up with a scheme which no one likes.
>>
>
>
>I think that the use of a common format (.step, .stl or similar) would be a good way, just reading and exporting to.
>
>
> 
>
>> As I imagine it, KiCAD need only provide minimal support for MCAD integration. Specifically, (1) items in the PCB file format specifications which allow the user to enter information for MCAD packages and (2) a few menu items to allow users to link a particular component to the related MCAD files and edit properties such as scale and rotation. Using the old PCB format as an example, (1) can be achieved by adding some sections to the $SHAPE3D section such as:
>>
>>$MCAD
>>      File 'cad_file.step'
>>      Color 'color_file'
>>      Offset x,y,z
>>      Rotation x,y,z,a
>>      Scale x,y,z
>>$EndMCAD
>>
>
>
>Look at the new s-expr file format (kicad_plugin.cpp file inside pcbnew directory), 
>

Thanks for the advice; I think I should just put in the extra effort now and pull in the latest KiCAD.  It's good to know exactly where to look for the information I want.


>
>I think that also embedded STEP/STL/VRML models inside the library parts or PCB would be an advantage, as you can share your PCB or library without the need to keep a separate file with the 3D model.
> 
>
>>A number of MCAD sections can exist within the SHAPE3D section to allow support for multiple CAD formats. For example, the list of MCAD sections may contain the ubiquitous 'step' model as well as a file for, say, FreeCAD - it will be up to the (non-KiCAD) tools to decide which models it can make use of and which one is best to use.
>>
>>
>
>
>In fact, as FreeCAD is deeply python based, it should not be complicate to even write a pcbnew file reader (that reads the PCB basic data + linked CAD models)
> 


I'll think about that, but I'm not a Python programmer.  


>>One step towards supporting MCAD is to define a directory heirarchy which can be used by any external MCAD tool. I present a suggestion below and would appreciate any comments.
>>
>>1. TOP LEVEL 3D MODEL DIRECTORY STRUCTURE
>>The current organization (or lack thereof) of the 3D models directory needs some work in order to easily support intergration of external tools. I propose the following structure:
>>
[snip]
>
>You mean the directories that are bundled with KiCad, right?
>


I mean the directories bundled with KiCAD as well as any user directories.  While I play with the demonstrator I will maintain a user directory organized in the proposed heirarchy.  When the demonstrator is mature enough I can copy the existing VRML files into the new directory structure or something similar.


[snip]

> 
>Other comments (though unrelated to what has been proposed above):
>>
>> I have already investigated a number of free CAD packages and I have settled on FreeCAD since (a) it can produce STEP files (personally I like BRL-CAD much more but it does not export to STEP or IGES) and (b) support for drawings is being developed - for small shops and hobbyists who may wish to use a free tool to do all their mechanical manufacturing and assembly drawings, this seems the way to go.
>>
>
>
>It has a high python integration degree, as I expect KiCad will have soon (kicad scripting branch), so that means easier interaction.
> 
>


That's a great convenience. :)  I'm going crazy with the numerous scripting languages - TCL/TK, Ruby, Python, etc - it's good to have the same scripting language shared between tools.


>> I am working on my demonstration of the concept and have produced simplistic STEP assemblies which I have successfully imported into SolidWorks and checked for correctness. I intend to work with the old PCB format for my demonstrator and I want to get the code to a stage where people can edit their existing PCB files (by hand, just to check out the tool) and run the tool to generate a STEP file before I present the actual concept 
>
>
>Wow, that's great? please let me know when it's available, I'd like to try it :-)
>
>
>That could also lead to very nice renders via freecad->povray->
> 

No problem, I'll probably post on kicad-users and send you an email.  It may be a few months yet since I have so little spare time.  Ultimately I do want to see scenes rendered by povray, but I think FreeCAD needs a lot of work with its data model; the current model is not good for automating the job of assigning material appearances.



>demonstration to people. I hope by that stage that the new PCB file format would be well tested and I can easily adapt the tools to work with the new format.  If enough people are interested in the tool I intend to produce free MCAD models and slowly populate the directory structure to make the tool useful to more people. At the start I expect that people should at least be able to set up their own directory structure with non-free STEP models and quickly export a usable STEP assembly.
>
>
> 
>However, I believe that in the
>> long-term, using free MCAD models contributed by users will be the way to go; I made extremely simple hand-assembled models using FreeCAD and STEP models available from RS Components and boards containing literally only a handful of components blows out to tens of MB - that suggests to me that a realistic simple board with a mere 200 components will result in a ridiculous size STEP assembly if people rely on the STEP files provided by suppliers like RS; using native CAD formats for the models should hopefully produce much more sensible STEP files.
>>
>
>
>I've been lately working to convert STEP(freecad)->STL(wings3D)->VRML and it worked quite well, but it's painful, and the original model size (from step) was totally lost.
>
>
>I think that the 3D model placement method in kicad could also be quite enhanced (now you modify the coordinates and then reload the 3D view), may be some simple hotkeys to move on axis and rotate would make the thing much more user friendly (I was planning to setup a little patch at some time but I want to finish my scripting-footpring-wizard first).
>
>


I actually started work on parametric generation of VRML models for KiCAD and created some DIL packages. I think for now my time is best spent on creating the STEP support; so many people on the kicad-users list ask how to generate STEP files from VRML and while some people have done it, it is not a simple process. At the moment my opinion is that the VRML models will be around for a very long time (perhaps always) and when the MCAD support is finally integrated I would like to spend time creating more parametric  VRML models (because the computer can generate very beautiful models) as well as FreeCAD models.  VRML will always be good for quickly generating nice 3D scenes; FreeCAD + povray can do the more realistic but procesor intensive scenes.


- Cirilo