GPL scripts with no restrictions on the generated models is perfect. - Cirilo
On Sun, Feb 26, 2017 at 12:02 PM, Oliver Walters <[email protected]> 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" <[email protected]> > 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 > <[email protected]> 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" <[email protected]> wrote: >> >> On Sat, Feb 25, 2017 at 3:53 PM, Oliver Walters >> <[email protected]> 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" <[email protected]> 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 >>>> <[email protected]> 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" <[email protected]> >>>> > 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 >>>> > <[email protected]> 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" <[email protected]> >>>> >> wrote: >>>> >> >>>> >> On Sat, Feb 25, 2017 at 1:12 AM, Simon Wells <[email protected]> >>>> >> 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 >>>> >>> <[email protected]> >>>> >>> 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 >>>> >>>> <[email protected]> >>>> >>>> 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 : [email protected] >>>> >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> >>>>>> More help : https://help.launchpad.net/ListHelp >>>> >>>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> Mailing list: https://launchpad.net/~kicad-developers >>>> >>>>> Post to : [email protected] >>>> >>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> >>>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> >>>> Post to : [email protected] >>>> >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> >>>> More help : https://help.launchpad.net/ListHelp >>>> >>> >>>> >>> _______________________________________________ >>>> >>> Mailing list: https://launchpad.net/~kicad-developers >>>> >>> Post to : [email protected] >>>> >>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> >>> More help : https://help.launchpad.net/ListHelp >>>> >> >>>> >> _______________________________________________ >>>> >> Mailing list: https://launchpad.net/~kicad-developers >>>> >> Post to : [email protected] >>>> >> Unsubscribe : https://launchpad.net/~kicad-developers >>>> >> More help : https://help.launchpad.net/ListHelp >>>> >> >>>> >> >>>> > >>>> > >> >> > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
