kicad-developers team mailing list archive

[Simon Wells <swel024@xxxxxxxxx>]

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