kicad-developers team mailing list archive

[Oliver Walters <oliver.henry.walters@xxxxxxxxx>]

Cirilo,

Some great ideas there - I was being more than slightly facetious by
suggesting it would be the work of a weekend :)

Should we have separate repositories for MCAD models and wrl? And a third
for scripts?


On 26 Feb 2017 08:31, "Cirilo Bernardo" <cirilo.bernardo@xxxxxxxxx> wrote:

On Sat, Feb 25, 2017 at 3:53 PM, Oliver Walters
<oliver.henry.walters@xxxxxxxxx> wrote:
> Simon,
>
> Are you saying we should host the models and provide them on demand?
>
> I would agree. This way we can provide models independent of the source
> (scripts, etc).
>
> It also makes it way easier for users.
>
> I like the idea of a KiCad-integrated model wizard but I'll leave that for
> Cirilo to code when he has a free weekend.
>

I'm sure it would take more than a weekend. Whatever your solution for
now, I think it is important to separate the old Wings3D/VRML models
from any models generated from MCAD. Better still, if there can be some
text file associated with each STEP/VRML pair (or script) stating the
author, source of data, and whether or not the mechanically important
dimensions were verified (and by who). Such text files with a 'checked by'
entry could also be useful for footprints and schematic symbols as well.

I'll put scripted STEP model generation on my list of things to do, but
given that existing bugs have the highest priority and then the PCB API
after that, I have no idea when I'll get around to it. For me the ideal
scripting solution would consist of (a) compiled C++ parametric tools
(b) python scripts (c) XML schema for describing the scripts and how to
invoke them (d) GUI for searching the XML files and magically creating
the menus for controlling parameters on the selected XML file. It's an
awful lot of work for what would be only a small improvement on Maurice's
current tools, but once (a) and (b) are done we will at least be in a
position to ship scripts rather than models and we could always have
some hard-coded tool for selecting and executing scripts in the short
term.

- Cirilo

> I'll let all this percolate. Thanks for the input.
>
> On 25 Feb 2017 1:41 PM, "Simon Wells" <swel024@xxxxxxxxx> wrote:
>>
>> i don't see why on-install and if it can be done at install time why
>> not just do it on-demand of the model... if its slow cache but still
>> ondemand,
>>
>> providing models that we gen will likely require a full stack of
>> development as git/github isn't really ideal for stuff like this
>>
>> On 25 February 2017 at 15:15, Oliver Walters
>> <oliver.henry.walters@xxxxxxxxx> wrote:
>> > I personally find the idea of on-demand model creation appealing.
>> >
>> > I think that if we are to "promote" this as the preferred method, it
>> > should
>> > be improved through simplification and consolidation.
>> >
>> > Scripted models have only been added in the last week. Most of the
>> > models
>> > are legacy (poor quality wrl made in wings etc). There are also now a
>> > lot of
>> > models that have been generated via the spreadsheet functionality in
>> > Freecad.
>> >
>> > So already there are two competing scripting methods. What I want to
>> > achieve
>> > is a simplified and unified library structure.
>> >
>> > I realise that due to file size this is not so practical for the 3D
>> > models.
>> >
>> > Perhaps a good idea is to dictate a scripting architecture that allows
>> > us to
>> > be somewhat forward-compatible, and not actually provide 3D models.
>> >
>> > The current scripts could be made more generic and "publish" their
>> > parameters in such a way that an external tool can have some
>> > introspection
>> > of the scripts. Much like the python footprint wizards currently work
in
>> > KiCad.
>> >
>> > Then, a "helper" script can parse the generator scripts, and the user
>> > can
>> > select which models to generate. This could even be run on KiCad
>> > install.
>> >
>> > e.g. a list of checkboxes to install "all JST connectors" or "R0603".
>> >
>> > Alternatively, we host all the generated models, and provide a download
>> > tool
>> > which downloads models as required.
>> >
>> > Thoughts?
>> >
>> > On 25 Feb 2017 10:48 AM, "Cirilo Bernardo" <cirilo.bernardo@xxxxxxxxx>
>> > wrote:
>> >
>> > Hi Oliver,
>> >
>> >  The scripts will easily generate many GB of data in time and for me
>> > it's
>> > not
>> > reasonable to download that amount of data. I think new users should
>> > simply
>> > learn to read documentation and generate the models rather than
>> > downloading
>> > them. Package maintainers can automatically run the scripts. Users will
>> > still
>> > have access to all the old VRML models and if they want to use the
newer
>> > models, especially the STEP+VRML models, they should learn to set up
the
>> > required tools. As I said, this requires a lot more thought.
>> >
>> >  I suspect we can indeed develop our own parametric 3D modeling tools
>> > for
>> > KiCad based on OCE and provide a scheme to specify good material
>> > appearances for the VRML export as Maurice's tools do, but it's really
a
>> > question of time and planning.  Having scripts available in the
official
>> > repo
>> > I think is a good start and will keep the expert users happy until
>> > someone
>> > gets around to creating these specialised tools for kicad.
>> >
>> > - Cirilo
>> >
>> >
>> > On Sat, Feb 25, 2017 at 10:10 AM, Oliver Walters
>> > <oliver.henry.walters@xxxxxxxxx> wrote:
>> >> Cirilo,
>> >>
>> >> Unless we made script generation of models completely idiot proof, I
>> >> think
>> >> that requiring another niche toolset would only serve to increase the
>> >> already high barrier to entry for new users.
>> >>
>> >> The 3D scripts require, currently:
>> >>
>> >> - Freecad
>> >> - cadquery plugin
>> >>
>> >> Plus the scripts themselves are a bit opaque to use.
>> >>
>> >> I think that if we are going to distribute recipes for models rather
>> >> than
>> >> the models themselves, that should be integrated into KiCad?
>> >>
>> >> You're the expert on the 3D code, is there any possibility that we
>> >> could
>> >> have a 3D wizard that operates in a similar way to the footprint
>> >> wizard?
>> >> Then it would be fantastic to have the repo contain scripts as you
say.
>> >>
>> >> Connectors are an obvious use for parametric scripts as it takes lots
>> >> of
>> >> space to store each of hundreds of variants.
>> >>
>> >> Oliver
>> >>
>> >>
>> >> On 25 Feb 2017 8:44 AM, "Cirilo Bernardo" <cirilo.bernardo@xxxxxxxxx>
>> >> wrote:
>> >>
>> >> On Sat, Feb 25, 2017 at 1:12 AM, Simon Wells <swel024@xxxxxxxxx>
wrote:
>> >>> why should packages be a subfolder of modules, it seems that they
>> >>> don't really belong in there and should be directly in the
share/kicad
>> >>> folder
>> >>>
>> >>
>> >> That would certainly be my preference. Since the root of the 3D models
>> >> is
>> >> determined by KISYS3DMOD and hasn't had a hard-coded relation to the
>> >> *.lib files for quite a few years now, I would move it out of
'modules'
>> >> and
>> >> into
>> >> a 'packages3d' directory. Looking at the structure on github,
>> >> 'packages3d'
>> >> is currently the only directory within 'modules' so the modules
>> >> directory
>> >> seems silly.
>> >>
>> >>
>> >>> On 25 February 2017 at 02:00, Adam Wolf
>> >>> <adamwolf@xxxxxxxxxxxxxxxxxxxx>
>> >>> wrote:
>> >>>> Yeah, let me clarify--by "wouldn't be a problem" for OS X, I meant
>> >>>> "if
>> >>>> you did it without saying where it's going and when it's changing",
>> >>>> it
>> >>>> would break the OS X package, but the change would only take a
minute
>> >>>> or two, and would be quickly testable.
>> >>>>
>> >>>> On Fri, Feb 24, 2017 at 6:57 AM, Wayne Stambaugh
>> >>>> <stambaughw@xxxxxxxxx>
>> >>>> wrote:
>> >>>>> On 2/24/2017 3:45 AM, Oliver Walters wrote:
>> >>>>>> Hi everyone,
>> >>>>>>
>> >>>>>> Recently I raised this issue:
>> >>>>>>
>> >>>>>> https://lists.launchpad.net/kicad-developers/msg27922.html
>> >>>>>>
>> >>>>>> There were some good responses, thanks for the input.
>> >>>>>>
>> >>>>>> First task is going to be moving the 3D models, as this will be
>> >>>>>> significantly easier.
>> >>>>>>
>> >>>>>> e.g. something like GitHub.com/KiCad/packages3D
>> >>>>>>
>> >>>>>> To this end, I'd like some further information from those in the
>> >>>>>> know:
>> >>>>>>
>> >>>>>> A) is there any impediment to having the KISYS3DMOD envvar point
to
>> >>>>>> somewhere different? e.g. ./KiCad/share/packages3D/
>> >>>>>
>> >>>>> I believe you mean share/kicad/modules/packages3d.  Why would
change
>> >>>>> the
>> >>>>> install path?  Irregardless of what repo the 3D models are in, they
>> >>>>> should always get installed in this location.  Where else would be
>> >>>>> appropriate to install them?  Changing this path would most likely
>> >>>>> break
>> >>>>> everyone's 3D viewing experience.
>> >>>>>
>> >>>>>> B) To the package managers, how much effort to package 3D models
>> >>>>>> from
>> >>>>>> a
>> >>>>>> separate repo?
>> >>>>>
>> >>>>> I'll leave this to our package devs.
>> >>>>>
>> >>>>>> C) to the docs maintainers, would there be much to change if we
>> >>>>>> redirected the 3D repo?
>> >>>>>> D) Generally, what other considerations would be required?
>> >>>>>>
>> >>>>>> Essentially, if I made this change right now without telling
>> >>>>>> anyone,
>> >>>>>> what would I break?
>> >>>>>
>> >>>>> I'm sure all of the package builders.  You would need to coordinate
>> >>>>> this
>> >>>>> change with the package devs.
>> >>>>>
>> >>>>>>
>> >>>>>> As a side note there have been some great recent contributions to
>> >>>>>> the
>> >>>>>> 3D
>> >>>>>> data, with a fair bit of momentum over at the forums.
>> >>>>>>
>> >>>>>> Regards,
>> >>>>>> Oliver
>> >>
>> >> Some thought is needed about how to handle the 3D model repository in
>> >> the
>> >> future. In the past we only had VRML which was pretty but next to
>> >> useless
>> >> for mechanical verification. Now we have IGES and STEP in all the
>> >> gloriously
>> >> ugly MCAD color schemes. Personally I only use IGES and STEP, but some
>> >> people like to have a STEP model for mechanical verification and a
VRML
>> >> model for eyecandy. At the moment various scripts written to work with
>> >> Maurice's StepUp tool are the only scheme I'm aware of which make it
>> >> easy
>> >> for people to have a STEP file while having improved material
>> >> appearances
>> >> applied to the surfaces in a corresponding VRML file. I suspect it is
>> >> inevitable
>> >> that we start to have a diverse collection of 3D model sources:
>> >>
>> >> a. old VRML models with no corresponding MCAD model
>> >> b. IGES/STEP models from manufacturers with no aesthetic coloring
>> >> c. script-based parametric generators which produce STEP models and
>> >> corresponding VRML models with aesthetic material appearances
>> >>
>> >> For (c) it really makes no sense to store the models themselves
because
>> >> these can really waste storage space. My preference is for the scripts
>> >> to
>> >> be made available for various tools (StepUp being the only one so far)
>> >> and for the end user to install the tools.
>> >>
>> >> - Cirilo
>> >>
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> Mailing list: https://launchpad.net/~kicad-developers
>> >>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>> >>>>>> More help   : https://help.launchpad.net/ListHelp
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Mailing list: https://launchpad.net/~kicad-developers
>> >>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> >>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>> >>>>> More help   : https://help.launchpad.net/ListHelp
>> >>>>
>> >>>> _______________________________________________
>> >>>> Mailing list: https://launchpad.net/~kicad-developers
>> >>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> >>>> Unsubscribe : https://launchpad.net/~kicad-developers
>> >>>> More help   : https://help.launchpad.net/ListHelp
>> >>>
>> >>> _______________________________________________
>> >>> Mailing list: https://launchpad.net/~kicad-developers
>> >>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> >>> Unsubscribe : https://launchpad.net/~kicad-developers
>> >>> More help   : https://help.launchpad.net/ListHelp
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~kicad-developers
>> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> >> Unsubscribe : https://launchpad.net/~kicad-developers
>> >> More help   : https://help.launchpad.net/ListHelp
>> >>
>> >>
>> >
>> >