kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Since this is most likely going to be one big merge, I will not merge it
until I've had a chance to build it and test it on windows and linux.  I
will also have to review the code which will take a while since it's
such a large change set.  I will also need and OSX dev to build and test
it.  The code needs to be stable and well written before I will merge it
into the development branch.  As you can see, this is a lot of effort on
my part so it most likely wont happen any time soon.  If anyone else has
time to build, test, and review the code and give Cirilo some feed back,
I would appreciate the help.

On 12/1/2015 8:16 PM, Jon Neal wrote:
> My gut instinct would be to merge sooner so the number of changes is
> smaller and bugs in the merged code can be more easily targeted.
> 
> I personally like smaller changes for stuff like this rather than
> humongous all in one changes, but looking at the commit log I can see
> that not all people agree with this. :)
> 
> Jon
> 
> On Tue, Dec 1, 2015 at 5:30 PM, Cirilo Bernardo
> <cirilo.bernardo@xxxxxxxxx <mailto:cirilo.bernardo@xxxxxxxxx>> wrote:
> 
>     Hi folks,
> 
>      I'd like people's opinions on how to introduce the changes in the
>     management of
>     3D models. The existing refactored code introduces the following:
> 
>     1. configurable model filename resolution: this allows the user to
>     have model files
>     in different root paths, for example the model directory installed
>     by kicad plus the
>     user's own model directory + system-wide non-kicad model directory
>     etc. This
>     model resolution scheme also includes the current project directory
>     in the search
>     path for additional flexibility. The resolver paths can be
>     configured via a GUI which
>     is accessible from the File Browser.
> 
>     2. 3D model parser plugin: the data for rendering a 3D view within
>     kicad can now
>     be managed by plugins. This allows the development/debugging of
>     plugins without
>     recompiling the bulk of kicad. In contrast the current system makes
>     changes to
>     the 3dviewer library which forces the re-linking of pcbnew and cvpcb
>     while touching
>     any related headers can force a broader recompile. It is possible to
>     develop the
>     plugins out-of-tree and versioning control can be used to ensure
>     compatible APIs.
> 
>     3. 3D model caching: model data can now be cached in a binary file
>     format; this
>     can speed up loading of some model types, for example any MCAD model
>     which
>     uses NURBS to describe surfaces. The cache can also write its data
>     to a VRML2
>     compliant file thus providing an automatic conversion from the
>     plugin's model type
>     to VRML.
> 
>     4. Model preview: in the Footprint Properties dialogs you can see
>     the 3D model in
>     a window and interactively adjust the scale/offset/rotation
>     parameters. The original
>     concept was to provide a 3D preview within the File Selector dialog
>     as well but
>     that would require much more work (patching wxWindows + additional
>     testing on
>     Linux/MSWin/OSX) so I'll drop that idea.
> 
>     Ultimately 3Dviewer will be replaced by a new rendering system which
>     Mario is
>     working on and there will be great improvements in the
>     maintainability of the code
>     as the entire 3D rendering code is cleaned up and its entrails
>     removed from other
>     code such as MODULE. However, that it a large task and may not be
>     ready for
>     quite a few months. So I propose we take advantage of the current
>     improvements
>     by pulling in a subset of the new code. The code will provide
>     everything listed
>     above in 1-3 but will not yet provide the much desired removal of
>     S3DMASTER
>     from MODULE - that step depends on the rewriting of the Renderer.
>     Part 4 above
>     depends on the implementation of working 3D parser plugins; this is
>     a work in
>     progress and it will take a few months to reimplement the existing
>     X3D/VRML
>     parsers as plugins.
> 
>     I estimate 2 or 3 weeks to prepare a branch to merge a subset of the
>     existing
>     code which will provide improved 3D file browsing. Model parsers are
>     currently
>     in development but should be ready in the first quarter of 2016.
> 
>     What do people think - should we introduce the current changes as
>     soon as
>     possible, providing improved browsing, or wait a few months so that
>     we can
>     include the preview window in the Footprint Properties dialogs?
> 
>     - Cirilo
> 
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers
>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto: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
>