yes, this is a fundamental tool to have to be able to do real engineering. Also, this measurement tool should be App::Link aware (be able to measure stuff between 2 App::Link-ed objects)
GSOC 2020 has been Green Lit! (GSOC is over, thanks to everyone involved!)
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)
Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)
I think that's already the case: the Transform tool applied on an object changes the Placement of that object, in the same way as if you'd change the Placement manually.
- Joel_graff
- Veteran
- Posts: 1949
- Joined: Fri Apr 28, 2017 4:23 pm
- Contact:
Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)
As I'm reviewing these suggestions, it made me think a bit about what, exactly, the scope of a GSOC project should be. Obviously, it has to be tightly constrained - these are students and they only get a few months to work on something they likely have little or no previous exposure with.
So, if you ask me (and no one has ), the needs of FreeCAD *could* be roughly prioritized as follows:
1. Code maintenance
a. Abstraction
b. Standardizing the API across different parts
c. Eliminating or fixing dependency and packaging issues
2. Bug Fixes - fixing what doesn't work or was implemented incorrectly / incompletely
3. New module implementations (adding entirely new subsystems that are in really good shape, like PyFlow)
4. New feature implementations
Of course, within each priority are very complex problems as well as low-hanging fruit. Thus, an easy feature implementation would likely be a better candidate than a complex code maintenance issue, even if we need the code maintenance badly.
Still, I get the feeling we *really* need to just be fixing / maintaining what we've already got, especially if we want to be serious about releasing FreeCAD v1.0 in the near future... If I had to choose, I'd emphasize only the proposals that addressed #1 or #2. Werner and Kurt could use a few favors, after all.
So, if you ask me (and no one has ), the needs of FreeCAD *could* be roughly prioritized as follows:
1. Code maintenance
a. Abstraction
b. Standardizing the API across different parts
c. Eliminating or fixing dependency and packaging issues
2. Bug Fixes - fixing what doesn't work or was implemented incorrectly / incompletely
3. New module implementations (adding entirely new subsystems that are in really good shape, like PyFlow)
4. New feature implementations
Of course, within each priority are very complex problems as well as low-hanging fruit. Thus, an easy feature implementation would likely be a better candidate than a complex code maintenance issue, even if we need the code maintenance badly.
Still, I get the feeling we *really* need to just be fixing / maintaining what we've already got, especially if we want to be serious about releasing FreeCAD v1.0 in the near future... If I had to choose, I'd emphasize only the proposals that addressed #1 or #2. Werner and Kurt could use a few favors, after all.
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)
Can I suggest improving Coin3D?
Since we are going to stay with Coin3D and OpenGL forever (there is too much dependent code to make a transition to different scenegraph), maybe we could make Coin3D a bit more modern?
FreeCAD have to render viewport much faster to be competitive to any commercial CAD. There are some notes how OpenGL rendering performance can be improved:
OpenGL like Vulkan - there is a "cad scene" example inside
Approaching zero driver overhead
The OpenGL-based implementation can be replaced by a Vulkan-based one slowly, bit by bit. There is OpenGL-Vulkan interoperability example https://github.com/jherico/Vulkan/blob/ ... nterop.cpp
Since we are going to stay with Coin3D and OpenGL forever (there is too much dependent code to make a transition to different scenegraph), maybe we could make Coin3D a bit more modern?
FreeCAD have to render viewport much faster to be competitive to any commercial CAD. There are some notes how OpenGL rendering performance can be improved:
OpenGL like Vulkan - there is a "cad scene" example inside
Approaching zero driver overhead
The OpenGL-based implementation can be replaced by a Vulkan-based one slowly, bit by bit. There is OpenGL-Vulkan interoperability example https://github.com/jherico/Vulkan/blob/ ... nterop.cpp
- wandererfan
- Veteran
- Posts: 6309
- Joined: Tue Nov 06, 2012 5:42 pm
- Contact:
Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)
This is a bit self-serving, but it sure would be nice to do all those HLR edge intersection calculations in parallel.
Could be changing the OCC code, could be writing a new FC HLR routine. C++, multi-threading, multi-core.
Could be changing the OCC code, could be writing a new FC HLR routine. C++, multi-threading, multi-core.
Re: GSOC 2020 has been Green Lit! (Voice your opinion and ideas about what to propose for the next gsoc)
Importatnt Note: GSOC 2020 is officially Green Light
Per @yorik in https://forum.freecadweb.org/viewtopic.php?f=8&t=42452
Per @yorik in https://forum.freecadweb.org/viewtopic.php?f=8&t=42452
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)
I still think that this is an absolute priority, it's quite visible and fun for newcomers, and since it doesn't interfere with other modules — it's only an observer — it's a very good candidate for GSOC. And also since it's non-intrusive, anything that they can come up with will be an improvement.
Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)
Actually, there are already 2 measurement tools available:Zolko wrote: ↑Tue Jan 21, 2020 3:05 pmI still think that this is an absolute priority, it's quite visible and fun for newcomers, and since it doesn't interfere with other modules — it's only an observer — it's a very good candidate for GSOC. And also since it's non-intrusive, anything that they can come up with will be an improvement.
- in the Part workbench
- in the Manipulator workbench (Caliper tool)
Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)
That's why i called it a proper measerment tool
measuring is a very important work and i do it a lot in my daily work... but with FC this is horreble!!
-
- Veteran
- Posts: 7790
- Joined: Tue Jan 07, 2014 11:10 am
- Contact:
Re: GSOC 2020 has been Green Lit! (Voice your opinion and ideas about what to propose for the next gsoc)
Draft Array Fuse True needs a lot of time, please see:
https://forum.freecadweb.org/viewtopic. ... 02#p172802
https://forum.freecadweb.org/viewtopic. ... 78#p160178
Perhaps this can be significantly improved.
https://forum.freecadweb.org/viewtopic. ... 02#p172802
https://forum.freecadweb.org/viewtopic. ... 78#p160178
Perhaps this can be significantly improved.