kicad-developers team mailing list archive

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

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