Re: [Kicad-developers] Plugin plans (post-stable release)
On 6/15/2015 9:20 PM, Cirilo Bernardo wrote: On Tue, Jun 16, 2015 at 8:33 AM, Tomasz Wlostowski tomasz.wlostow...@cern.ch mailto:tomasz.wlostow...@cern.ch wrote: On 14.06.2015 13:35, jp charras wrote: Le 14/06/2015 12:01, Tomasz Wlostowski a écrit : On 14.06.2015 02:35, Cirilo Bernardo wrote: 7. STEP: (future plans) the plugin will only provide an Export I'd also like to add STEP visualization in the near future (post-stable ofc) Tom PS. It is possible to export a hierarchical assembly in STEP from OCC. No need to write a special library for that. We all agree (at least guys like me who make designs with very strong mechanical constraints) step import/export is a major feature. However, OCC is a very heavy dependency for Kicad. I am not especially thrilled by OCC dependency. Jean-Pierre, OCC is at least a complete thing. It can read/write STEP, provides all boundary representation algorithms we need for making a PCB model from layout (extrusion, boolean ops, chamfering/filleting) and can triangulate BRep items for rendering purposes. Moreover, OCC despite being big is pretty self-contained, it brings no additional dependencies. If stepcode is usable, this is a (by far) preferable dependency, even it is not perfect. The above is not true for stepcode - AFAIK it only reads/writes STEP, but has no geometry algorithms which we would need to take from other libraries. That's correct; stepcode is only a preprocessor - it will read or write data and ensure that the file conforms to standards specifications but it is entirely ignorant of what the data means. Everyone needs to add their postprocessor and application code to interpret or place data into the STEP object. Tom, have you got a small example of an assembly created by OCC? I would like to see how SolidWorks imports the file and if the results will be acceptable. From what I could read, OpenCascade offer the software to manage assemblies as a paid extension and from the documentation in OCC I couldn't work out how to extract or create hierarchical information. As for rendering STEP models that would certainly be a large task if we did it ourselves, but I believe the SISL library contains all the algorithms we need to calculate vertices and the painful details of rendering are a matter of interpreting STEP data to determine the vertices on surfaces and their boundaries. Still, if OCC will do the job I would concede that such a large dependency may be worthwhile since we can concentrate on other aspects of KiCad rather than having our time dedicated to reimplementing something which is already freely available. If we use OCC, it needs to be an optional dependency. I don't have any experience with OCC and how easy it is to build on other platforms so initially I would require that it be a build option. Also, I know to some of you I sound like a broken record but none of this can happen until the underlying 3D model library code is fixed. Trying to add STEP or any other 3D model format on top of our current design is a recipe for disaster. - Cirilo Best, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plugin plans (post-stable release)
On 16.06.2015 12:40, ea...@katamail.com wrote: Hi Cirilo and Tom, I tried OCC to import a stl shape (to263 from kicad lib generated from wings3d) and generate step and iges models and render it in wxpython... please find attached the py code used for conversion and IGES and STEP generated Hi Maurice, This is cool! I did more or less the same in C++. There are few caveats with OCC though: - dealing with colors when loading STEP needs some extra code (OCC doesn't handle color correctly if the color is an attribute of an assembly instead of a single shape), - when exporting a hierarchical STEP assembly, the hierarchy must be build bottom-up, - In order to get the names of the parts OK I had to dive in the internal STEP representation of the data. It's not very complex, it just takes a few extra lines of code. For the moment, I'm thinking of making a wx IPC service that would include OCC, mesh cache models and export assemblies. It could be built as an option. Other possibility is to use DLL plugins, but I'm afraid it's a much bigger endeavor to get them to work reliably on all OS platforms. Certainly not for the stable release. Tom Maurice On 6/16/15 12:20 PM, Tomasz Wlostowski wrote: On 16.06.2015 12:02, ea...@katamail.com wrote: Hi Cirilo, it seems that Peter Clifton has added AP214 support: http://comments.gmane.org/gmane.comp.cad.geda.user/43517 Hi Maurice, It looks like just a hack to me (just the board shape). Adding components will be IMHO more complex... Besides Peter's approach does not solve the problem of meshing/visualization of STEP component models (see [1] for an example - this is all STEP). Regards, Tom [1] https://edms.cern.ch/file/1158539/1/EDA-02189-V4-0_3D-top.jpg ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Show bus entry joining two wires as dangling
Patch committed in product branch r5758. Thanks. On 6/15/2015 11:07 AM, Chris Pavlina wrote: if a bus entry is drawn between two WIRES (not a wire and a bus, or two buses), it looks like it's connecting the wires together, but doesn't actually represent a connection. This patch makes it display as dangling in that case, to make it clear to the user that a connection has not actually been made. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plugin plans (post-stable release)
Hi Tom, that would be great! If you are planning to make a wx IPC service including OCC, please consider to add also vrml import option that is missing in OCC I found at http://www.opencascade.org/org/forum/thread_18400/?forum=3 there is some code about it... That could add the ability to convert vrml to the right STEP format as an intermediate phase in the evolution of the 3d-viewer (converting vrml to stl and then to step it is a bit messy for the plain pcb board) Maurice On 6/16/15 2:00 PM, Tomasz Wlostowski wrote: On 16.06.2015 12:40, ea...@katamail.com wrote: Hi Cirilo and Tom, I tried OCC to import a stl shape (to263 from kicad lib generated from wings3d) and generate step and iges models and render it in wxpython... please find attached the py code used for conversion and IGES and STEP generated Hi Maurice, This is cool! I did more or less the same in C++. There are few caveats with OCC though: - dealing with colors when loading STEP needs some extra code (OCC doesn't handle color correctly if the color is an attribute of an assembly instead of a single shape), - when exporting a hierarchical STEP assembly, the hierarchy must be build bottom-up, - In order to get the names of the parts OK I had to dive in the internal STEP representation of the data. It's not very complex, it just takes a few extra lines of code. For the moment, I'm thinking of making a wx IPC service that would include OCC, mesh cache models and export assemblies. It could be built as an option. Other possibility is to use DLL plugins, but I'm afraid it's a much bigger endeavor to get them to work reliably on all OS platforms. Certainly not for the stable release. Tom Maurice On 6/16/15 12:20 PM, Tomasz Wlostowski wrote: On 16.06.2015 12:02, ea...@katamail.com wrote: Hi Cirilo, it seems that Peter Clifton has added AP214 support: http://comments.gmane.org/gmane.comp.cad.geda.user/43517 Hi Maurice, It looks like just a hack to me (just the board shape). Adding components will be IMHO more complex... Besides Peter's approach does not solve the problem of meshing/visualization of STEP component models (see [1] for an example - this is all STEP). Regards, Tom [1] https://edms.cern.ch/file/1158539/1/EDA-02189-V4-0_3D-top.jpg ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Autosave assertion failure workaround
When eeschema attempts to autosave a schematic that hasn't been saved before, an assertion (common/basicframe.cpp:656) fails. Here's a patch that works around that. I call this a workaround rather than a fix because I'd rather autosave still work for things that don't have a filename yet, but that has to be done more carefully. It would require a check at startup for a backup file saved to a predetermined location (ideally somewhere within either /tmp or ~/.kicad on Linux, and the equivalent locations on other systems). -- Chris commit f56c975823f66fa690ca44a35a2dd96f0dc6d831 Author: Chris Pavlina cpavl...@binghamton.edu Date: Tue Jun 16 11:36:51 2015 -0400 Workaround for autosave assertion failure diff --git a/eeschema/files-io.cpp b/eeschema/files-io.cpp index 4ef6572..39922f5 100644 --- a/eeschema/files-io.cpp +++ b/eeschema/files-io.cpp @@ -509,6 +509,9 @@ bool SCH_EDIT_FRAME::doAutoSave() tmp.AssignDir( fn.GetPath() ); +if( !tmp.IsOk() ) +return false; + if( !IsWritable( tmp ) ) return false; ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plugin plans (post-stable release)
On 16.06.2015 17:35, Mário Luzeiro wrote: From: Kicad-developers [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of Tomasz Wlostowski [tomasz.wlostow...@cern.ch] Sent: 16 June 2015 17:13 To: Wayne Stambaugh; kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] Plugin plans (post-stable release) Also, I know to some of you I sound like a broken record but none of this can happen until the underlying 3D model library code is fixed. Fully agree. AFAIK Mario was volunteering to work on the 3D models? Tom Is Mario == Me ? Hi Mario, Yes, I meant you. I am following this discussion but I am having difficult to understand some parts here and the relation with 3d-viewer. Basically, we need (just a brain dump below): - a cleanup of the 3D model loading/storage code: a clean mesh class (holding the geometry/assembly info) and refactoring of the 3d-viewer (and further on, exporter code) to use it. I see you made the S3D_MESH class, which is already quite clean and could be easily integrated with the STEP mesher. One thing that might be needed is storing same sub-meshes with different transforms (imagine a BGA footprint with 1000 identical balls - the current design of the class requires copying the mesh data 1000 times, correct me if I'm wrong please). - improved way to associate a STEP/IGES/VRML/whatever with the PCB footprints. - @Wayne - anything else? Regards, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Autosave assertion failure workaround
On Tue, 16 Jun 2015, Chris Pavlina wrote: When eeschema attempts to autosave a schematic that hasn't been saved before, an assertion (common/basicframe.cpp:656) fails. Here's a patch that works around that. I call this a workaround rather than a fix because I'd rather autosave still work for things that don't have a filename yet, but that has to be done more carefully. It would require a check at startup for a backup file saved to a predetermined location (ideally somewhere within either /tmp or ~/.kicad on Linux, and the equivalent locations on other systems). /tmp would be a bad choice on Linux - some (many?) (all?) distros cleans /tmp by default during boot, so the autosave file wouldn't survive e.g. a power failure or a system crash ... or even a normal (re)boot. -- Chris Øyvind. ** * Øyvind AablingEmail: Oyvind.Aabling@ DeIC.dk / i2.dk /~\ The ASCII * * DeIC / i2 Phone: +45 35 88 82 00 \ / Ribbon* * DTU Building 304 Phone: +45 35 88 82 15 (direct) X Campaign * * DK-2800 LyngbyFax : +45 35 88 82 01 / \ Against * * Denmarkhttp://www.deic.dk/ http://www.i2.dk/HTML Email! * ** Quidquid latine dictum sit, altum viditur.___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plugin plans (post-stable release)
On 16.06.2015 14:16, Wayne Stambaugh wrote: On 6/15/2015 9:20 PM, Cirilo Bernardo wrote: On Tue, Jun 16, 2015 at 8:33 AM, Tomasz Wlostowski tomasz.wlostow...@cern.ch mailto:tomasz.wlostow...@cern.ch wrote: On 14.06.2015 13:35, jp charras wrote: Le 14/06/2015 12:01, Tomasz Wlostowski a écrit : On 14.06.2015 02:35, Cirilo Bernardo wrote: 7. STEP: (future plans) the plugin will only provide an Export I'd also like to add STEP visualization in the near future (post-stable ofc) Tom PS. It is possible to export a hierarchical assembly in STEP from OCC. No need to write a special library for that. We all agree (at least guys like me who make designs with very strong mechanical constraints) step import/export is a major feature. However, OCC is a very heavy dependency for Kicad. I am not especially thrilled by OCC dependency. Jean-Pierre, OCC is at least a complete thing. It can read/write STEP, provides all boundary representation algorithms we need for making a PCB model from layout (extrusion, boolean ops, chamfering/filleting) and can triangulate BRep items for rendering purposes. Moreover, OCC despite being big is pretty self-contained, it brings no additional dependencies. If stepcode is usable, this is a (by far) preferable dependency, even it is not perfect. The above is not true for stepcode - AFAIK it only reads/writes STEP, but has no geometry algorithms which we would need to take from other libraries. That's correct; stepcode is only a preprocessor - it will read or write data and ensure that the file conforms to standards specifications but it is entirely ignorant of what the data means. Everyone needs to add their postprocessor and application code to interpret or place data into the STEP object. Tom, have you got a small example of an assembly created by OCC? I would like to see how SolidWorks imports the file and if the results will be acceptable. From what I could read, OpenCascade offer the software to manage assemblies as a paid extension and from the documentation in OCC I couldn't work out how to extract or create hierarchical information. As for rendering STEP models that would certainly be a large task if we did it ourselves, but I believe the SISL library contains all the algorithms we need to calculate vertices and the painful details of rendering are a matter of interpreting STEP data to determine the vertices on surfaces and their boundaries. Still, if OCC will do the job I would concede that such a large dependency may be worthwhile since we can concentrate on other aspects of KiCad rather than having our time dedicated to reimplementing something which is already freely available. If we use OCC, it needs to be an optional dependency. Sure (PS.b y IPC I meant a separate kiface dealing with mechanical I/O and providing meshes for the 3D viewer.) I don't have any experience with OCC and how easy it is to build on other platforms so initially I would require that it be a build option. On Linux: git clone https://github.com/tpaviot/oce cmake make Also, I know to some of you I sound like a broken record but none of this can happen until the underlying 3D model library code is fixed. Fully agree. AFAIK Mario was volunteering to work on the 3D models? Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plugin plans (post-stable release)
From: Kicad-developers [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of Tomasz Wlostowski [tomasz.wlostow...@cern.ch] Sent: 16 June 2015 17:13 To: Wayne Stambaugh; kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] Plugin plans (post-stable release) Also, I know to some of you I sound like a broken record but none of this can happen until the underlying 3D model library code is fixed. Fully agree. AFAIK Mario was volunteering to work on the 3D models? Tom Is Mario == Me ? I am following this discussion but I am having difficult to understand some parts here and the relation with 3d-viewer. Perhaps you may would like to better explain the idea and I would be happy to contribute with my ideas and opinion (in relation of 3d-viewer). Mario Luzeiro ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] LIB_TEXT bounding boxes
Hi all,
While working on that field autoplace feature, I noticed that
LIB_PART::GetBodyBoundingBox was returning incorrect bounding boxes when
the parts contained a LIB_TEXT. Further investigation revealed that
there was an extra negation of the vertical dimension somewhere in the
mix. The trouble is, there appear to be multiple of these, because
adding or removing negations would fix it in this place, but would cause
other troubles (text rendering in the wrong spot in libedit, or clicks
not being received). The only way I found that worked was to
special-case LIB_TEXT inside LIB_PART::GetBodyBoundingBox, negating both
the Y position and Y size. Ugly hack attached.
Anyone familiar enough to have a guess as to what the real problem is,
without me spending hours digging into the entirety of the bounding box
code? The ugly hack works, but... ew.
--
Chris
commit c2a1607092013825312608a454f3861fd4b07547
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Tue Jun 16 17:59:28 2015 -0400
Preliminary fix for eeschema text bounding boxes
diff --git a/eeschema/class_libentry.cpp b/eeschema/class_libentry.cpp
index 2ba8989..81429c8 100644
--- a/eeschema/class_libentry.cpp
+++ b/eeschema/class_libentry.cpp
@@ -1142,6 +1142,7 @@ bool LIB_PART::LoadFootprints( LINE_READER aLineReader, wxString aErrorMsg )
const EDA_RECT LIB_PART::GetBoundingBox( int aUnit, int aConvert ) const
{
EDA_RECT bBox( wxPoint( 0, 0 ), wxSize( 0, 0 ) );
+bool first = true;
for( unsigned ii = 0; ii drawings.size(); ii++ )
{
@@ -1157,7 +1158,21 @@ const EDA_RECT LIB_PART::GetBoundingBox( int aUnit, int aConvert ) const
if ( ( item.Type() == LIB_FIELD_T ) !( ( LIB_FIELD ) item ).IsVisible() )
continue;
-bBox.Merge( item.GetBoundingBox() );
+EDA_RECT item_bb = item.GetBoundingBox();
+
+if( item.Type() == LIB_TEXT_T || item.Type() == LIB_FIELD_T )
+{
+item_bb.SetY( -item_bb.GetY() );
+item_bb.SetSize( item_bb.GetSize().x, -item_bb.GetSize().y );
+}
+
+if( first )
+{
+bBox = item_bb;
+first = false;
+}
+else
+bBox.Merge( item_bb );
}
return bBox;
@@ -1167,6 +1182,7 @@ const EDA_RECT LIB_PART::GetBoundingBox( int aUnit, int aConvert ) const
const EDA_RECT LIB_PART::GetBodyBoundingBox( int aUnit, int aConvert ) const
{
EDA_RECT bBox( wxPoint( 0, 0 ), wxSize( 0, 0 ) );
+bool first = true;
for( unsigned ii = 0; ii drawings.size(); ii++ )
{
@@ -1182,7 +1198,21 @@ const EDA_RECT LIB_PART::GetBodyBoundingBox( int aUnit, int aConvert ) const
if ( item.Type() == LIB_FIELD_T )
continue;
-bBox.Merge( item.GetBoundingBox() );
+EDA_RECT item_bb = item.GetBoundingBox();
+
+if( item.Type() == LIB_TEXT_T )
+{
+item_bb.SetY( -item_bb.GetY() );
+item_bb.SetSize( item_bb.GetSize().x, -item_bb.GetSize().y );
+}
+
+if( first )
+{
+bBox = item_bb;
+first = false;
+}
+else
+bBox.Merge( item_bb );
}
return bBox;
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plugin plans (post-stable release)
Hi Tom, - a cleanup of the 3D model loading/storage code: a clean mesh class (holding the geometry/assembly info) and refactoring of the 3d-viewer Ya, I started already thinking/working on some ideas for a future 3d-viewer (not only the model parsers) [3]. As I explained before [1][2], I am not thinking to contribute more to the current 3d-viewer as it is. Instead, I would like to spend time develop this new version. (and further on, exporter code) to use it. 3d-viewer is something a bit aside from the rest of the kicad. The only thing 3d-viewer is exporting are .png and .jpg files :) The model exporters (supported by Cirilo) is related with pcbnew. One of my ideas is that the 3d-viewer model parsers library could be used in the future by the other parts of the code (eg: the importers / exporters... of the pcbnew). So we could have something like: 3dmodel = modelparser.Load( full path file name ); 3dmodel.GetBBox(); ... 3dmodel.MeshTriList()... Probably something like that could be possible now or not (I don't remember :| ) but I remember that all that code (I mean .. the architecture) is ugly and I dont like to look on that :) (well.. I believe that thankfully this is an opensource project and I can have the option to choose not do it :) ) I found useful this discussion so I can get a more clear view for a future design. I see you made the S3D_MESH class, which is already quite clean and could be easily integrated with the STEP mesher. S3D_MESH was already there when I started, I don't remember exactly what I changed.. but added more support and capabilities. However, that is still very ugly. Any way, It should be easier to add some importer, if you have a library that gives you a list of triangles already magically processed. It should be just fill the (not elegant) S3D_MESH data. One thing that might be needed is storing same sub-meshes with different transforms (imagine a BGA footprint with 1000 identical balls - the current design of the class requires copying the mesh data 1000 times, correct me if I'm wrong please). I don't remember the details, however I believe that it not an issue *see note below.. The issue, that I will also try to address properly in the future, is the loading and processing of the model files. Right now there is already a simple mechanism that will load just once a model that repeats in the board (per reload). What I plan is to have a cache between reloads so that cache can be reused if you are opening (or maybe using) different boards. Right now, the model loader spend some time to calculate the normals of the files (ideally we have cache files) so keep the cache (at least between refresh / reloads of the board) will help speed up the things. *note: the 1000 BGA balls That could lead to a bigger discussion, but I believe it doesn't matter much. It should depend more on the engine that is rendering the model. Lets say an example this two situations: 1. use one instance of the BGA ball and send it to the (memory of the) GPU. Then ask the GPU (passing all transformations every time it need to redraw) to render all the BGA balls one by one. 2. use one instance of the BGA ball, transform (on loading time) all the 1000 BGA balls and send it already transformed to GPU. Then ask the GPU to render all balls. So.. I am not sure which will be faster, but, I believe both options are faster so we shouldn't care much now. - improved way to associate a STEP/IGES/VRML/whatever with the PCB footprints. What do you mean? You mean the pcbnew footprint 3d library association UI ? That is related with pcbnew :) However, as I discuss before, I plan (for a future version) that it will be possible then to instantiate (by a widget / canvas...) a 3d-viewer so it will be possible to add it to the UI and adjust in real time the module to the footprint. So user will get immediately the feedback. [1] https://lists.launchpad.net/kicad-developers/msg17605.html [2] https://lists.launchpad.net/kicad-developers/msg17618.html [3] https://lists.launchpad.net/kicad-developers/msg17861.html Let me know anything else! Mario Luzeiro From: Tomasz Wlostowski [tomasz.wlostow...@cern.ch] Sent: 16 June 2015 17:58 To: Mário Luzeiro; kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] Plugin plans (post-stable release) Basically, we need (just a brain dump below): - a cleanup of the 3D model loading/storage code: a clean mesh class (holding the geometry/assembly info) and refactoring of the 3d-viewer (and further on, exporter code) to use it. I see you made the S3D_MESH class, which is already quite clean and could be easily integrated with the STEP mesher. One thing that might be needed is storing same sub-meshes with different transforms (imagine a BGA footprint with 1000 identical balls - the current design of the class requires copying the mesh data 1000 times, correct me if I'm wrong please).
Re: [Kicad-developers] patch for solder mask color in 3D viewer
Hi Cirilo, I tried the patch and I think it is nice and useful for realistic rendering... e.g. when the solder mask is black or red instead of standard green... so it is possible to get nice screenshots of the real board... thank you for the patch! I would suggest too to add it to the stable release... Maurice On 6/16/15 10:41 AM, Cirilo Bernardo wrote: There is a patch which was submitted to the bug list some time ago which adds a color chooser for the soldermask layer: https://bugs.launchpad.net/kicad/+bug/1437724/+attachment/4360153/+files/3dviewercopper.patch Some people like the feature and since it doesn't touch much code, could it be considered before the stable release? - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] patch for solder mask color in 3D viewer
Hi Maurice, It's not my patch; that's the work of Jeppe Johansen. - Cirilo On Wed, Jun 17, 2015 at 8:14 AM, ea...@katamail.com ea...@katamail.com wrote: Hi Cirilo, I tried the patch and I think it is nice and useful for realistic rendering... e.g. when the solder mask is black or red instead of standard green... so it is possible to get nice screenshots of the real board... thank you for the patch! I would suggest too to add it to the stable release... Maurice On 6/16/15 10:41 AM, Cirilo Bernardo wrote: There is a patch which was submitted to the bug list some time ago which adds a color chooser for the soldermask layer: https://bugs.launchpad.net/kicad/+bug/1437724/+attachment/4360153/+files/3dviewercopper.patch Some people like the feature and since it doesn't touch much code, could it be considered before the stable release? - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plugin plans (post-stable release)
On Wed, Jun 17, 2015 at 8:02 AM, Mário Luzeiro mrluze...@ua.pt wrote: Hi Tom, - a cleanup of the 3D model loading/storage code: a clean mesh class (holding the geometry/assembly info) and refactoring of the 3d-viewer Ya, I started already thinking/working on some ideas for a future 3d-viewer (not only the model parsers) [3]. As I explained before [1][2], I am not thinking to contribute more to the current 3d-viewer as it is. Instead, I would like to spend time develop this new version. (and further on, exporter code) to use it. 3d-viewer is something a bit aside from the rest of the kicad. The only thing 3d-viewer is exporting are .png and .jpg files :) The model exporters (supported by Cirilo) is related with pcbnew. One of my ideas is that the 3d-viewer model parsers library could be used in the future by the other parts of the code (eg: the importers / exporters... of the pcbnew). So we could have something like: 3dmodel = modelparser.Load( full path file name ); 3dmodel.GetBBox(); ... 3dmodel.MeshTriList()... Probably something like that could be possible now or not (I don't remember :| ) but I remember that all that code (I mean .. the architecture) is ugly and I dont like to look on that :) (well.. I believe that thankfully this is an opensource project and I can have the option to choose not do it :) ) I found useful this discussion so I can get a more clear view for a future design. I think we will need a base class with a consistent API for handling the 3D data and a manager class to instantiate appropriate derived classes. The base class will of course store the name of the 3D file and if we wish to keep the memory footprint small we should also maintain a list of pointers to the components which reference the model and the associated scale/rotation/offset data. I see at least 2 use cases here: 1. VRML/IGES/STEP/IDF Export: only the file names and position data will be needed 2. 3D Viewer/3D model selection dialog: facets must be generated for display, implying that the model must be loaded by the derived class and converted for display. Since a single model can be instantiated many times, the derived class must store all data for the nominal definition and create the structures for each instance on demand. In the case of the model selection we simply display the nominal definition. With this scheme, if a footprint is altered to remove a model (instance deleted) or another instance is added, the derived class can quickly recalculate the new set of vertices etc to represent all instances. So I would not include a modelparser.Load( path ) at all, but leave the derived class to decide when to load the model data. The GetBBBox() will be useful, but for the actual data to display I would have 2 functions: GetMeshDef() to copy the nominal definition and GetMeshInstances() to get data to display all instances. In the manager class we will need Add3DModel( [pointer to footprint], [path], [orientation data] ) and also Del3DModel( [pointer to footprint] ). The [pointer to footprint] is really only intended as a unique ID for managing the list of orientation data; we can pass in an invalid pointer value if we wish to load a model for display in a model selection GUI as long as we call Del3DModel() using the same invalid pointer value. I see you made the S3D_MESH class, which is already quite clean and could be easily integrated with the STEP mesher. S3D_MESH was already there when I started, I don't remember exactly what I changed.. but added more support and capabilities. However, that is still very ugly. Any way, It should be easier to add some importer, if you have a library that gives you a list of triangles already magically processed. It should be just fill the (not elegant) S3D_MESH data. One thing that might be needed is storing same sub-meshes with different transforms (imagine a BGA footprint with 1000 identical balls - the current design of the class requires copying the mesh data 1000 times, correct me if I'm wrong please). I don't remember the details, however I believe that it not an issue *see note below.. The issue, that I will also try to address properly in the future, is the loading and processing of the model files. Right now there is already a simple mechanism that will load just once a model that repeats in the board (per reload). What I plan is to have a cache between reloads so that cache can be reused if you are opening (or maybe using) different boards. Right now, the model loader spend some time to calculate the normals of the files (ideally we have cache files) so keep the cache (at least between refresh / reloads of the board) will help speed up the things. *note: the 1000 BGA balls That could lead to a bigger discussion, but I believe it doesn't matter much. It should depend more on the engine that is rendering the model. Lets say an example this two situations:
Re: [Kicad-developers] Plugin plans (post-stable release)
On 6/16/2015 11:58 AM, Tomasz Wlostowski wrote: On 16.06.2015 17:35, Mário Luzeiro wrote: From: Kicad-developers [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of Tomasz Wlostowski [tomasz.wlostow...@cern.ch] Sent: 16 June 2015 17:13 To: Wayne Stambaugh; kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] Plugin plans (post-stable release) Also, I know to some of you I sound like a broken record but none of this can happen until the underlying 3D model library code is fixed. Fully agree. AFAIK Mario was volunteering to work on the 3D models? Tom Is Mario == Me ? Hi Mario, Yes, I meant you. I am following this discussion but I am having difficult to understand some parts here and the relation with 3d-viewer. Basically, we need (just a brain dump below): - a cleanup of the 3D model loading/storage code: a clean mesh class (holding the geometry/assembly info) and refactoring of the 3d-viewer (and further on, exporter code) to use it. I see you made the S3D_MESH class, which is already quite clean and could be easily integrated with the STEP mesher. One thing that might be needed is storing same sub-meshes with different transforms (imagine a BGA footprint with 1000 identical balls - the current design of the class requires copying the mesh data 1000 times, correct me if I'm wrong please). - improved way to associate a STEP/IGES/VRML/whatever with the PCB footprints. - @Wayne - anything else? I'm certain I've mentioned this before but I expect a sane I/O manager design something like PCB_IO and IO_MGR used in Pcbnew. I want to see this design use either the base classes in richio.h, streams, or wxStreams for I/O and not be tied directly to reading and writing files. There also needs to be an intelligent way to handle different model library types (VRML, STEP, IGES, etc.) and abstract away platform path differences like the footprint library table used in Pcbnew. Once this is in place, we can port the current VRML I/O over to the new I/O code and begin adding new model types. Regards, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] patch for solder mask color in 3D viewer
Its a very nice feature, as a user it has my thumbs up, most of the boards I produce aren't green. Regards Marcos On Tue, Jun 16, 2015 at 8:23 PM, Cirilo Bernardo cirilo.berna...@gmail.com wrote: Hi Maurice, It's not my patch; that's the work of Jeppe Johansen. - Cirilo On Wed, Jun 17, 2015 at 8:14 AM, ea...@katamail.com ea...@katamail.com wrote: Hi Cirilo, I tried the patch and I think it is nice and useful for realistic rendering... e.g. when the solder mask is black or red instead of standard green... so it is possible to get nice screenshots of the real board... thank you for the patch! I would suggest too to add it to the stable release... Maurice On 6/16/15 10:41 AM, Cirilo Bernardo wrote: There is a patch which was submitted to the bug list some time ago which adds a color chooser for the soldermask layer: https://bugs.launchpad.net/kicad/+bug/1437724/+attachment/4360153/+files/3dviewercopper.patch Some people like the feature and since it doesn't touch much code, could it be considered before the stable release? - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plugin plans (post-stable release)
I see Peter's work as a proof of concept. Both Peter and I are working on the premise of being able to create assembly structures which users can verify with software like FreeCAD before sending off to mechanical designers. I believe I'm much further along (despite having written an entire IGES library for the job) since I can create a board with true form and also create an assembly; the only part missing, which has to wait until KiCad's 3D code is refactored, is the export code in KiCad. I guess if we add OCC as an optional dependency at some point we can always use OCC to display the IGES models. I may continue working on an IGES renderer though for a more lightweight solution. I still haven't ruled out eventual work with stepcode to provide a lightweight option to OCC in the future, but you can bet that will involve at least 2 more years work in whatever spare time I have. - Cirilo On Tue, Jun 16, 2015 at 8:20 PM, Tomasz Wlostowski tomasz.wlostow...@cern.ch wrote: On 16.06.2015 12:02, ea...@katamail.com wrote: Hi Cirilo, it seems that Peter Clifton has added AP214 support: http://comments.gmane.org/gmane.comp.cad.geda.user/43517 Hi Maurice, It looks like just a hack to me (just the board shape). Adding components will be IMHO more complex... Besides Peter's approach does not solve the problem of meshing/visualization of STEP component models (see [1] for an example - this is all STEP). Regards, Tom [1] https://edms.cern.ch/file/1158539/1/EDA-02189-V4-0_3D-top.jpg ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] patch for solder mask color in 3D viewer
There is a patch which was submitted to the bug list some time ago which adds a color chooser for the soldermask layer: https://bugs.launchpad.net/kicad/+bug/1437724/+attachment/4360153/+files/3dviewercopper.patch Some people like the feature and since it doesn't touch much code, could it be considered before the stable release? - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plugin plans (post-stable release)
Hi Cirilo, it seems that Peter Clifton has added AP214 support: http://comments.gmane.org/gmane.comp.cad.geda.user/43517 Peter Clifton | 10 Jun 01:12 2014 I've re-written my export code over the last week or so, and can now emit useful AP214 .STEP files containing a representation of the PCB board, complete with via holes. (And colour!) As of tonight, there is support for emitting multiple solid bodies, when the board outline has more than one piece. Maurice On 6/15/15 12:23 AM, Cirilo Bernardo wrote: Peter Clifton has been using stepcode for his work on creating STEP models for gEda; we agree that it is the best option to use which isn't very heavy like OCC. Peter has had to fix a few bugs in stepcode but has successfully created some models. I have a copy of the 2014 Step Module Resource Library but the SMRL does not include STEP AP214 which is one of the most common APs for parts models partly because it includes colors. The SMRL does have AP203e2, which is AP203 with parts like color borrowed from AP214, and AP242 which is the merger of AP203 and AP214 (and not yet commonly implemented by MCADs). For a functional STEP export we will need to support AP203 and AP214; I do not believe we will ever have to support AP203e2, but maybe in 5 years we will need to support AP242. - Cirilo On Sun, Jun 14, 2015 at 9:35 PM, jp charras jp.char...@wanadoo.fr wrote: Le 14/06/2015 12:01, Tomasz Wlostowski a écrit : On 14.06.2015 02:35, Cirilo Bernardo wrote: 7. STEP: (future plans) the plugin will only provide an Export I'd also like to add STEP visualization in the near future (post-stable ofc) Tom PS. It is possible to export a hierarchical assembly in STEP from OCC. No need to write a special library for that. We all agree (at least guys like me who make designs with very strong mechanical constraints) step import/export is a major feature. However, OCC is a very heavy dependency for Kicad. I am not especially thrilled by OCC dependency. If stepcode is usable, this is a (by far) preferable dependency, even it is not perfect. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plugin plans (post-stable release)
On 16.06.2015 12:02, ea...@katamail.com wrote: Hi Cirilo, it seems that Peter Clifton has added AP214 support: http://comments.gmane.org/gmane.comp.cad.geda.user/43517 Hi Maurice, It looks like just a hack to me (just the board shape). Adding components will be IMHO more complex... Besides Peter's approach does not solve the problem of meshing/visualization of STEP component models (see [1] for an example - this is all STEP). Regards, Tom [1] https://edms.cern.ch/file/1158539/1/EDA-02189-V4-0_3D-top.jpg ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
