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
