rvanee, you should look into applying a 3d noise to your meshes in the free program sculptris ( http://www.pixologic.com/sculptris/ ). I believe this program should allow you to add tiny details such as stucco to your mesh via a 3d-brush system.  If you need any help going forward PM me, I'm sure I can help you out. I do 3d modeling/texturing professionally.

For a more automated approach you should look for a "3d texture" to "bake" "displacement" into your mesh. Those 3 search terms should get you started on the right foot. "height map" and "noise modifier" would also be worth searching.

If you own Cinema 4d r14 they have sculpting built in now, so you could do it there too.  Also Zbrush, etc.  Autodesk has a free iOS app for the iPad that does sculpting too, but limited features.

For a more automated approach you should look for a "3d texture" to "bake" "displacement" into your mesh. Those 3 search terms should get you started on the right foot. "height map" and "noise modifier" would also be worth searching.

That seems perfectly reasonable to me. The processing software should have features like that.

Although a great feature I'd love to see having to do with post processing an stl model would be to take the wobble so much of us have seen in our prints and be able to compensate via software.

For example, If you notice that every 6mm vertically (or whatever, 4mm, 3mm, etc..) there is a shift from left to right, front to back (possibly from a bent rod), to be able to fine tune this in software over the length of the 6" z-print height.

I realize having a well tuned machine should come first, but as a quick reliable fix I cant see anything wrong with this idea. Please poke holes in my idea. thanks!

Since our printers are controlled by our computers, we can consider the file or gcode size to be unlimited.  What is lacking in this industry, at the moment, is a way to represent an assembly of parts along with their materials, textures, etc.  For instance, I can have an STL file, but there is no provision in that format for indicating different materials.  You could have the STL describe surface texture, but that is likely to be inefficient. What would be cool, though, is a format that allowed the specification of surface patterns and materials and then individual objects which reference those things by index.  Then you could include the unique pattern representing each surface and have the processing side apply them when the file was rendered, sliced and converted to gcode.

A slight extension to this allows things like mathematical expressions as textures so that you can obtain natural looking surfaces or at least add noise and randomness to a texture.  Kind of like procedural texture functions in graphical programming.

Here is the rub, even if these things existed today, most of our printers are not able to produce objects with the required surface resolution to observe that detail.  The closest you will find is a resin printer.

That being said, there is the possibility of taking a two step approach to achieve something better than what is possible with FDM alone.  The two steps I am talking about are printing, followed up with milling.  Say you combined a milling head with a printing head and do one pass that constructs the rough surface.  You could then follow it up with another pass that mills out the required material to produce textures that are impossible with our current technology.  It would also allow you to produce perfectly smooth, or as close as you could get, surfaces.

I believe there are some professional printers that have this capability.  None that the average hobbiest could afford, to my knowledge.

A current limitation of solid modeling for gcode & 3D printing seems to be the inability to do real textured surfaces easily (like adding a stucco surface finish to a part, etc. ). I would image the amount of gcode needed to specify those micro surface blips would be pretty impressively large.

Would it be possible/reasonable to encode an on-board printer firmware routine that would take over the task of generating a specified texture to a part's surfaces?

It's not a G-code limitation. It's an FDM technology limitation. Unless your part was massive you would never see detail like stucco.

Would it be possible/reasonable to encode an on-board printer firmware routine that would take over the task of generating a specified texture to a part's surfaces?