-
Notifications
You must be signed in to change notification settings - Fork 1
Ideas for Development Tasks
This is a list of ideas for relatively stand-alone development tasks which would be possible to tackle for new developers.
There are a lot of open issues with very varying difficulty and time needed to solve. It would be very helpful and also very educational to spend some time managing issues.
Suggesions:
- Device a scheme to categorize issues making it easier to choose tasks.
- Handle incoming issues and communicate with reporters to be able to categorize issues to the point where it's possible to fix it without further communication.
- Select issues with suitable difficulties and fix them.
- A document or other means to ensure essential information is logged with issue reports (version, OS info, checklist etc) - maybe a Help/Dump command to output relevant state info??
Once issues reported by users are being fixed, we can push out snapshot binaries daily, to provide users with the opportunity to test and give feedback on fixes. This would be a very nice positive feedback loop for students.
Difficulty: Easy to get started, can scale to any difficulty as wanted
We have a black-box regression-testing framework in place. It includes ca. 700 tests, testing various output from a number of test drivers, including using the OpenSCAD binary itself as a test driver. Most of the tests actually render 3D models into images and do a fuzzy (ImageMagick) image compare to check for regressions. Some tests also look at text-representations of evaluated CSG trees to look for front-end regressions.
Since the test framework was retrofitted into OpenSCAD, there are a number of features not being tested. This includes basic language features, function implementations, and probably some modules.
A preliminary list of missing tests is maintained at the bottom of https://github.com/openscad/openscad/blob/master/doc/TODO.txt
Difficulty: Easy to get started (no C++ needed), next level would cmake/ctest/python to handle the test framework
The user interface could need a general brush-up (it's written in Qt). While at it, improvements could include
- Improve code editor (look for external components): indentation, improve syntax and error highlighting
- Improve 3D interaction: better mouse interaction, render grids, better wireframe
- Add more GUI items to Preferences
- Rework menus (they're a bit messy)
- Add literal increment/decrement via keyboard shortcut and key-modified scrollwheel.
Difficulty: Relatively easy - especially if there is already Qt experience.
OpenSCAD caches intermediate results in memory (polygon meshes and CGAL objects). The cache keys are hashes on the evaluated CSG trees themselves. We'd like to implement a file-based cache which is persistant over time, as well as having the potential of being shared between users (by making it available online).
Difficulty: Medium. Caches are relatively well handled internally, so a similar interface could be used.
Work towards separating the front-end and the back-end, to the point where their interfaces are reduced to exchanging evaluated CSG trees and resulting polygon meshes (or image snapshots). This gives us the opportunity to slowly move towards having a web-based UI, removing the need to maintain platform-specific front-end packages.
There are a number of projects out there which have partially implemented the language front-end in JavaScript, mostly under the MIT license, so a large part of this task is to pull together the best among them, structuring the code and hook it up to a unified testing framework.
Suggestion: Use node.js to help glue together server and client parts and start off spawning OpenSCAD processes from node.js. We can then gradually work towards librarification of OpenSCAD, which the core developers can tackle this while the work is being done on the front-end.
Difficulty: Could be almost pure web dev, but requires some software architecture experience
These require deeper refactoring of the existing code base, longer discussions with subsequent consensus, as well as defining their scope in the first place:
- Multi-material support: https://github.com/openscad/openscad/wiki#wiki-multi-color-support-for-3d-printing
- Rewrite OpenCSG with using modern OpenGL and OpenGL ES2 support, including WebGL
- Experiment with improvements and/or alternatives to CGAL for performing time-consuming operations
- Research possibilities for replacing our evaluation engine with an existing one (V8, scheme, Lua etc.)
Sometimes, it's important to be able to prove near instantaneous previews, while rendering heavier components in the background. We want support for using placeholder objects which are successively replaced by real objects as they finish rendering.
Difficulty: Relatively hard. Might require a fair bit of refactoring. Rendering would be done off-screen. Threading might be an issue.
OpenSCAD fails on border-case STL models. This is typically caused by things like co-incident vertices caused by floating point inaccuracy. To improve this, this is the suggested path:
- Refactor the internal mesh representation (core developer task)
- Write some simple mesh-repair methods; e.g. co-indicent vertex removal (look at e.g. MeshLab for typical operators, as well as implementation hints)
- Look at opportunities for implementing surface optimization techniques (e.g. null-decimation)
- Extend the mesh representation as needed
Difficulty: Medium, but could be relatively isolated once the refactoring is in place
An often requested feature on the Mailing-List is to allow more interaction in the text editor. One example is to change number literals while the cursor is positioned at the number.
Keyboard: Command-Up/Down key +1 / -1 Command-Shift-Up/Down key +0.1 / -0.1
Mouse (quote from the post): "For example if I had a literal of 1.02 and the cursor was between the 0 and the 2, pushing the mouse wheel should increment the literal in 0.1 increments. The mouse wheel would normally scroll the text so perhaps this functionality should be via a keyboard modifier (alt?)."