kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #21516
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