← Back to team overview

kicad-developers team mailing list archive

Re: proposal for introduction of 3D refactor changes

 

2015-12-02 14:21 GMT+01:00 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.

So I guess that is a yes on the part where he asks about introducing
the current changes as soon aspossible, providing improved browsing.

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


Follow ups

References