kicad-developers team mailing list archive

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

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'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
> >>
> >>
> >
> >
>