For example, fan control could be made volumetric, based around how much filament is below the extrusion, not just the whole layer time. The bridge detection in Slic3r is a very restricted form of this - done more generally, fan speed would be increased for bridges, overhangs and non-first layers of bridges.
Another example, the physics of the extruder operation could be taken into account, to prevent fat corners and similar. I know some firmware can do this already, but I've never found it sufficient. I know it is somehow unclear whether this goes into the firmware of the g-code - but if it goes in the g-code, that means it should work with all firmwares. I think that ideally you could program anything you want in g-code, without the need to change firmware.
Bridge sagging could be accounted for in some way. I've seem cases where you have very sparse infill, and the first filled layer after that is very sagged - up to 3 top layer may be needed to get the top straight.
Finally, slicers are generally buggy (just check the Slic3r issue tracker!). I may sometime get a bit more involved with slicer development, but it's a whole new area, and lots of existing code that needs to be understood until I can make proper improvements.
For example, fan control could be made volumetric, based around how much filament is below the extrusion, not just the whole layer time. The bridge detection in Slic3r is a very restricted form of this - done more generally, fan speed would be increased for bridges, overhangs and non-first layers of bridges.
Another example, the physics of the extruder operation could be taken into account, to prevent fat corners and similar. I know some firmware can do this already, but I've never found it sufficient. I know it is somehow unclear whether this goes into the firmware of the g-code - but if it goes in the g-code, that means it should work with all firmwares. I think that ideally you could program anything you want in g-code, without the need to change firmware.
Bridge sagging could be accounted for in some way. I've seem cases where you have very sparse infill, and the first filled layer after that is very sagged - up to 3 top layer may be needed to get the top straight.
Finally, slicers are generally buggy (just check the Slic3r issue tracker!). I may sometime get a bit more involved with slicer development, but it's a whole new area, and lots of existing code that needs to be understood until I can make proper improvements.