Date: Sat, 28 Mar 2015 05:28:43 +0000 (UTC)
From: Cirilo Bernardo <cirilo_bernardo AT yahoo DOT com>
To: "geda-user AT delorie DOT com" <geda-user AT delorie DOT com>
Message-ID: <435039979.124044.1427520523995.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <mf4sfo$f8j$1@ger.gmane.org>
References: <mf4sfo$f8j$1 AT ger DOT gmane DOT org>
Subject: Re: [geda-user] 3D view
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk

----- Original Message -----

> From: Kai-Martin Knaak <knaak AT iqo DOT uni-hannover DOT de>
> To: geda-user AT delorie DOT com
> Cc: 
> Sent: Saturday, March 28, 2015 11:35 AM
> Subject: Re: [geda-user] 3D view
> 
> Peter Clifton wrote:
> 
>>  Out of curiosity, what is your need / requirement for the 3D view? There
>>  are many possible reasons and I'm curious what people actually want.
>> 
> Well, you certainly know what I want: A reliable way to communicate pcb 
> data to my 3D CAD application and back. This should include positions and 
> orientation of components. The use case is straight forward -- make sure 
> that the end product fits into its enclosure.
> In this scenario a nice 3D preview comes almost automatically as a bonus.
> 

The simplest way to communicate that information is via IDFv3 - an
ancient specification but still widely used and supported by most
MCADs. KiCad has had an IDF framework for over a year now; if anyone
felt the urge they could take that framework (aka preprocessor) and
implement IDF import/export. The only catch is that it's C++ so you'd
also have to design a wrapper. Another potential issue is that the
IDF support is usually an added component to the MCAD - for example
you'd need at least SolidWorks Premium if you wanted CircuitWorks and
IDF support; the basic version does not have the tools. I'm currently
working on an IGES preprocessor (https://github.com/cbernardo/libIGES)
so that any MCAD can work with an output model, but this is a 1-way
communication. Given arbitrary (0,0,0) positions and orientations of
models, the ECAD can't really make sense of what an MCAD might send
back unless you had some scheme to create mappings associated with
specific items in the assembly - and here we have yet another problem,
the MCAD can hand back your assembly with completely different names
for the components and subassemblies. Worse still if you use FreeCAD
since the exported assembly will not have parts and subassemblies -
simply hundreds or tens of thousands of features in a single
top-level *part*. The same applies if you use STEP + FreeCAD; I think
OpenCascade does provide a module to manage STEP assemblies but it
is a non-free module.


> I'd rather not put 3D models in the realm of pcb. An UI infrastructure to 
> design in 3D is far beyond the scope of a EDA layout application. But even 
> a good render engine is non trivial. These are tasks that are better 
> relegated to 3D CAD applications and specialized render engines. 
> 

I agree; after all this is not the task of an EDA. For over 2 years I've
had some software to create parametric VRML models
(http://kicad3dmodels.sourceforge.net) and since the models seem to get
very little exposure and use I proposed to merge it with KiCad but was
rejected.

> With these considerations in mind I still think that communication to and 
> from freecad would be advantageous. freecad can read python code natively 
> and interpret it as a geometrical data. I haven't looked into it in 
> detail. But I bet, it is possible to pass position and orientation of 
> components in this python code. Even if it isn't, the devs are probably 
> happy to add support for it.
> See the freecad python topological scripting manual for details:
> http://freecadweb.org/wiki/index.php?title=Topological_data_scripting
> 

You can use IDF since someone wrote a FreeCAD IDF importer in Python
(this can be vastly improved by using KiCad's IDF preprocessor).
However that communication is 1-way since FreeCAD will not export to
IDF.

> Once in freecad, the road is open to STEP, IGES or VRML. So you could turn 
> to blender or povray for polished rendering. Or you could do your actual 
> 3D design in solidworks or inventor. Since freecad is fully scriptable, 
> this would not need to involve starting the freecad UI.
> 

Not really. I would never accept an IGES or STEP model generated by
FreeCAD since it will not have a sensible assembly structure. I tried
exporting a STEP model of a moderately complex electronic assembly
once and when SolidWorks converted to native format I had *thousands*
of parts representing features of components - for example many
thousands with names like "pin-8(12).sldprt" .. "pin-8(1752).sldprt".
It is not reasonable to expect mechanical designers to work with such
nonsense. In contrast as a proof-of-concept, the 'mergetest' program
in my IGES library can create assemblies with various parts and
subassemblies and those subassemblies in turn (as you would expect)
may consist of other parts and subassemblies. SolidWorks imports
such hierarchical assemblies without any problems at all and a
moderately complex assembly will only have a few dozen to a few
hundred files; better still if I grab and move that QFP-100 the
entire QFP-100 part moves rather than the case of a FreeCAD model
where I have to grab and move each of the 100 pins as well.
IGES was finally abandoned in 2006 (last specification v5.3 ~1996)
but is still viable for 1-way communication due to its widespread
support in MCAD and the sheer volume of legacy models.


STEP of course is what must be used in the long term; various
STEP Application Protocols are used in PSI-5 which has been
*the* mechanism for ECAD-MCAD collaboration for over 15 years.
However, STEP is also the undisputed king of standards complexity

and it gets more complex with every revision. Even emitting a
simple assembly with PCB + components will require a Herculean
effort. Programmers joke about how difficult it is to represent
a simple cube in STEP.

- Cirilo

> ---<)kaimartin(>---
> PS: I can't help to note the coherent style and readability of their 
> documentation. You may also take a look at the start page
>     http://www.freecadweb.org/
> IMHO, the mix of presentation and documentation is exemplary in many ways.
> -- 
> Kai-Martin Knaak                                  tel: +49-511-762-2895
> Universität Hannover, Inst. für Quantenoptik      fax: +49-511-762-2211    
> Welfengarten 1, 30167 Hannover          http://www.iqo.uni-hannover.de
> GPG key:    http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get
>