OBJ converter should support materials

[GoogleCodeExporter]

Should parse MTL files (and understand textures)

Should batch geometry by material

Original issue reported on code.google.com by wonchun on 13 Aug 2011 at 3:06

[GoogleCodeExporter]

Original comment by wonchun on 13 Aug 2011 at 3:09

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Whole MTL may be messy to handle in UTF8 format. 

For start, it would be nice just to get material ids for triangles (and for 
this OBJ is enough). Then at least materials could be reconstructed on 
JavaScript side.

For example for our old binary format in three.js we just used JSON to deal 
with materials (which are not that large), and binary was only more or less 
equivalent to current UTF8 (buffers with vertices, normals, uvs, material ids).

Original comment by postfil...@gmail.com on 13 Aug 2011 at 2:28

[GoogleCodeExporter]

Yeah, a token handling of usemtl in the OBJ is probably going to be very 
helpful. I'd like to batch meshes by material, which will also help 
optimization performance because of my terrible, quadratic-time algorithm.

Eventually, I do want to at least understand colors and texture images, for a 
few reasons:

1) when you quantize texcoords, you are warping the texture. I'd like to 
optionally resample the source texture to correct for that. It's also a good 
time to do some kind of rescaling/atlasing, which could help batching.

2) I'd like to implement a kind of vertex baking, which would actually have to 
read the texture images. The plan is to store texture-like values (e.g. albedo, 
object-space normals) in low-precision per-vertex, then store deltas in the 
actual texture files. The idea is to be able to aggressively encode images.

For example, heavily quantized JPEGs/WebP, uploaded in a 16-bit color format. 
I'll need to come up with custom JPEG quantization matrices for that, and maybe 
even get some help on the WebP end. And of course, when texture compression 
becomes an option you can use that, too.

Vertex baking is nice since it means you get kind of a per-vertex preview 
before the textures come up, and it will attenuate encoding artifacts of the 
texture, which is an issue if they are heavily/multiply compressed/quantized. 
Said differently, it might be a nice way to save vidmem.

Original comment by wonchun on 13 Aug 2011 at 8:26

[GoogleCodeExporter]

Original comment by wonchun on 14 Aug 2011 at 5:43

• Added labels: Priority-Critical

[GoogleCodeExporter]

Was fixed in r54.

Original comment by wonchun on 11 Oct 2011 at 10:37

• Changed state: Fixed