kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

GPL scripts with no restrictions on the generated models is perfect.

- Cirilo

On Sun, Feb 26, 2017 at 12:02 PM, Oliver Walters
<oliver.henry.walters@xxxxxxxxx> wrote:
> The licence on the legacy models I am unsure about.
>
> Maurice, Rene, Jan and myself have been discussing the licence for models
> that we create (script). It is GPL with an explicit exception stating that
> models can be freely used and shared without normal GPL requirements.
>
> If you look at Maurice's scripts (https://GitHub.com/easyw) he has already
> implemented this.
>
> Oliver
>
>
> On 26 Feb 2017 11:25 AM, "Cirilo Bernardo" <cirilo.bernardo@xxxxxxxxx>
> wrote:
>
> I think one repository for the old VRML models, another for MCAD
> models, and a third for scripts. In cases where an MCAD model has a
> corresponding VRML model which has been specially crafted to look
> better in the 3D viewer, that VRML model should be alongside the MCAD
> model and in the MCAD directory.  I think this scheme gives us a path
> to eventually deprecate the old VRML models as we build up
> replacements on the MCAD side.
>
> Package maintainers can decide what to offer on each platform and sort
> out the dependencies. I imagine the old VRML will be included simply
> because so many people use it; MCAD+VRML would probably be a separate
> option due to the sheer volume, and some package maintainers might
> decide to offer the scripts instead and pull in all the dependencies.
> At any rate, the scripting option is definitely not for beginners.
>
> There is also the issue of licenses for the models. A few users have
> expressed concerns that some models are licensed under GPL (whatever
> that means for something which is not software) but in general people
> are concerned that kicad models may be of no value to them because (a)
> licensing might be mixed and difficult to determine and (b) some
> licenses may prevent them from using models in their commercial
> projects.
>
> - Cirilo
>
> On Sun, Feb 26, 2017 at 10:02 AM, Oliver Walters
> <oliver.henry.walters@xxxxxxxxx> wrote:
>> 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
>>>> >>
>>>> >>
>>>> >
>>>> >
>>
>>
>
>