two issues which my optical nerve picked out immediately:

I'm trying to do this as well. I'm successfully generating geometry and exporting an STL with toxiclibs, but I'm not succeeding in getting colors to come along. I followed the example posted in this thread, but the results stayed the same. My code is here: https://gist.github.com/4638679#file-brightness_3d-pde-L177 and the results end up looking like this:  http://www.flickr.com/photos/unavoidablegrain/8416055380/in/photostream (as viewed in Meshlab). The relevant lines, where I'm trying to apply colors to the face are like this:

2. stl.beginSave(sketchPath("wave_color.stl"), mesh.getNumFaces());
3.   List<Face> faces = mesh.getFaces();
4.   int k = 0;
5.   for (int i = 0; i < mesh.getNumFaces(); i++) {  
6.     Face f = faces.get(k);
7.     stl.face(f.b, f.a, f.c, f.normal, meshColors.get(k));
8.     k++;
9.   }
10.   stl.endSave();

where "meshColors" is an ArrayList of Integers into which I've stored colors pulled from the pixels of an image.

The relevant declarations and instantiations look like:

3. WETriangleMesh mesh = new WETriangleMesh("wave");
4.  
5. MaterialiseSTLColorModel colModel;
6. STLWriter stl;
7. colModel = new MaterialiseSTLColorModel(0x112233, true);
8.  colModel.enableFacetColors(true);
9.  stl = new STLWriter(colModel, 64);

I've also tried the DefaultSTLColorModel with no improvements.

What am I missing? Thanks.

http://en.wikipedia.org/wiki/STL_(file_format)#Color_in_binary_STL

2) Whilst Toxiclibs supports both known color models, hardly any of the popular viewers do (e.g. Meshlab doesn't) and you'll have to resort to those viewers offered by the vendors related to each color model:

http://www.solidview.com/Products/SolidViewLite

http://software.materialise.com/minimagics

So far I've only managed to test the MiniMagics viewer...

Btw. You'll be disappointed if you're planning to use colored STL for 3D printing at Shapeways, since they also don't support any of those color models, but instead require a texture mapped mesh or different 3d file format...

http://postspectacular.com | http://toxiclibs.org

Since, I'm not trying to fabricate, but instead generate assets for use in a Unity game, I've started going down the road of generating a texture and a material file instead. I know you don't use textures that much. I noticed that your saveAsObj() function doesn't write texture coordinates. I whipped up some functions to append them as well as a reference to a material file:  https://gist.github.com/4638679#file-brightness_3d-pde-L241

For some reason, though this isn't working. Even though it displays correctly in Processing with Toxiclibs:  http://www.flickr.com/photos/unavoidablegrain/8418456838/in/photostream When I try to view it in Meshlab, Meshmixer, etc. the texture coordinates seem to be wrong in some way. If you've got any tips on how I could fix that, they'd be highly appreciated!

Thanks!

PS -- I've been talking with the guy behind Meshmixer on twitter http://twitter.com/meshmixer and he's considering adding support for per-face colors in his STL loading. That wouldn't solve the problem I'm working on here, but would be a great way of previewing the results that come out of Toxiclibs.

Re: Your UV export isn't working is because just adding "vt's" at the end of the file is only half of what's needed. The actual face definitions themselves need to include the UV indexes too, just like with normal vertices. You'll also need to place the "vt's" ahead of the face list, since most OBJ loaders parse data directly and so expect those texture coords to come *before* the face list...

If I were you, I'd just create a patch for the saveAsOBJ() method and put the UV export in the right place (i.e. between vertices and faces) and update the face list format. There's not much code as is: source  I also believe the mtllib reference should go in the beginning of the file. It might help to study the OBJ file format some more before diving in: 

http://en.wikipedia.org/wiki/Wavefront_.obj_file#File_format

http://www.martinreddy.net/gfx/3d/OBJ.spec

Hth!

http://postspectacular.com | http://toxiclibs.org

So, I've made some progress on this, but getting a little stuck on the texture coordinates.

I added my own OBJWriter class to my sketch, based on the one in toxiclibs, but adding functionality for including texture coordinates and an external materials file into the .obj (the goal being to eventually submit a patch, but not wanting to deal with hg stuff right now). I added faceWithNormalsAndUVs(), uv(), and addMaterialFile() functions and I wrote my own saveAsObj() function in my main sketch (which should eventually get contribute to TriangleMesh). Here's the code:

I'm running into a problem where the y-coordinate of my UV coordinate has a limited range. Only from about 0.48-0.58. The result is that the texture gets applied wrong. This screen shot taken from Meshlab shows the result as well as a visualization of which UVs are being pulled in from the texture:

http://www.flickr.com/photos/unavoidablegrain/8420388353/in/photostream

The strange thing is that these UV coordinates render correctly in Processing using ToxiclibsSupport texturedMesh():

http://www.flickr.com/photos/unavoidablegrain/8418456838/in/photostream

I think the problem is coming in how I'm scaling the coordinates:

2.   Vec2D scaleUV=new Vec2D(tex.width, tex.height).reciprocal();
3. ...
5.       Vec2D uva = new Vec2D(points.get(nw).pos.x, points.get(nw).pos.y).scaleSelf(scaleUV);

http://gregborenstein.com/assets/chunk_extruder.zip

Press 's' to save out the obj.

Let me know if anything doesn't make sense. The code is pretty messy :)

Thanks for taking the time to look at it!

Okay, mister... I found it easier to just rewrite the key parts (mesh generation) than trying to debug yours. I hope it's still what you were after and I haven't misinterpreted a crucial part. I also made some changes to the new saveAsOBJ() method to first build an index of UV coords. The other thing worth noting is that the exporter now supports the optional flipping of the V coordinate, since it seems MeshLab (and possibly others) use the OpenGL coordinate system for UV coords, with the origin at bottom-left, rather than top-left...

I've added a bunch of comments to key parts, but all should be pretty straight forward:

http://postspectacular.com | http://toxiclibs.org

Just to make sure I understand the key changes here, it looks like there are two:

1) Limit the texture to the bounding rectangle of the part of the image we actually want to use.

2) Create a HashSet to make sure that each uv is only in the "vt" section once and to do the bookkeeping on which uv is at which index for the "f" section of the obj file.

Is that right? Am I missing anything else important?

Is this something you'd consider adding to the Toxiclibs OBJWriter class?

...and I will update the OBJWriter & saveAsOBJ methods sometime soon as well! With the changes above I've already added exporter versions for all 4 cases (normals & uv's). There're another 2 possible cases for using face normals only. One more reason to push out that release which has been waiting for sooo long now!

http://postspectacular.com | http://toxiclibs.org

And also, you shouldn't hijack this thread for your issue... I know it's gone off-topic already, but no need to take it even further away...

http://postspectacular.com | http://toxiclibs.org