Fix some issues in filling zones normals.
Fix an issue with some models that have materials but didn't defined the diffuse color.
Workaround for Bug #1443431.
Implement some missing "code logic" for pervertexperface normals.
Remove some not used functions.
Calculate normals using double type.
wxUpdateUIEvent events can be sent to parent frames, when opening a menu in a child frame, if parent and child frame share same ID fro menuitems (or tools)
The wrong menuitem can be used in some cases ( because there are more than one menuitem with the same identifier), by a wxUpdateUIEvent event function run in a parent frame.
The plan goes like this:
- eeschema still uses int in decidegrees
- all the other things internally use double in decidegrees (or radians
in temporaries)
- in pcbnew UI the unit is *still* int in decidegrees
The idea is to have better precision everywhere while keeping the user with int i
angles. Hopefully, if a fractional angle doesn't come in from the outside, everything
should *look* like an integer angle (unless I forgot something and it broke)
When the time comes, simply updating the UI for allowing doubles from the user should
be enough to get arbitrary angles in pcbnew.
- Removed spurious int casts (these are truncated anyway and will break
doubles)
- Applied the Distance, GetLineLength, EuclideanNorm, DEG2RAD, RAD2DEG
ArcTangente and NORMALIZE* functions where possible
- ArcTangente now returns double and handles the 0,0 case like atan2, so
it's no longer necessary to check for it before calling
- Small functions in trigo moved as inline
In particular the new mechanism for handling extended color palettes is in place,
included renaming the ini keys and saving the color name instead of its index; this means better forward compatibility with palette changes.
Since ini keys are changed, colors will be reset
and therefore tracks are now dragged when a end point is inside a pad, not necessary on the pad position.
However, drag functions still need more cleanup.
* serious code cleanup (remove duplicate code)
* shows (option in 3D preference menu) the copper items (tracks, zones...) in 3D, using 35 microns copper thickness.
However, because there are a lot more3D data to show (roughly 4 times more), this is slower.
jean-pierre charras
Tomasz Wlostowski
Maciej Suminski
unknown
Mario Luzeiro
Lorenzo Marcantonio