Calculate volume of 3D media

[Rodrigo Rodrigues da Silva]

It would be desirable to have mediagoblin calculate a STL/OBJ file's volume. It is a useful piece of information for 3D printer users.

I've written some code that addresses this partially: it uses admesh to calculate a STL file's volume, since admesh currently doesn't support OBJ files. If admesh is not installed, it just bypasses the volume calculation cleanly.

[Rodrigo Rodrigues da Silva]

Please apply patch #906 to visualize the results in the rendered media page, or just check stl__mediadata.volume in the database.

[Christopher Allan Webber]

So this is a good looking patch, structurally. My main concern about it is that the library admesh it uses isn't very well packaged for python. It looks like the python package actually includes the whole original C code, in addition to the python, and it looks like it's a bit behind. Because of this, I'm hesitant to pull this into MediaGoblin itself.

What we could possibly do is add some sort of hook so this could be easily packaged as a plugin in the meanwhile? What do you think?

Also, we can probably avoid a migration by adding this as a field to the MediaFile's metadata json dict.

[Christopher Allan Webber]

I'm removing the 0.7.0 milestone for now, until we've got some answers there.

[Rodrigo Rodrigues da Silva]

Replying to cwebber:

What we could possibly do is add some sort of hook so this could be easily packaged as a plugin in the meanwhile? What do you think?

I think it would be a good idea if the feature were more complex, but it looks like the burden of maitaining a plugin won't pay off.

So this is a good looking patch, structurally. My main concern about it is that the library admesh it uses isn't very well packaged for python. It looks like the python package actually includes the whole original C code, in addition to the python, and it looks like it's a bit behind. Because of this, I'm hesitant to pull this into MediaGoblin itself.

It isn't well packaged, indeed. In fact, there isn't a .deb or whatever for the C part, so what the python package does is it builds the C part then generates a plain SWIG wrapper around it. There was a new release since it was packaged but they say they won't be adding any new features for now, so we don't need to expect many changes.

I wrote it in a way that if admesh is not present it just ignores the volume calculation at all. It is not the best practice in the world, but I don't think that "just disable a side feature if you can't find a library it depends on" is inherently bad.

Also, we can probably avoid a migration by adding this as a field to the MediaFile's metadata json dict.

That makes sense. Should we migrate other fields such as height, width and depth as well?

[Rodrigo Rodrigues da Silva]

Hey, @cwebber, what do you think?

I've been thinking of adding new features such as mesh fixing. Admesh provides that. That would pay off maintaining a plugin - although I am not sure if our plugin infrastructure as is lets us do what we need - but that could be part of the stl processor's core as well.

Good news is that there is a new release of admesh. Now the python bindings are completely separated from the C library part. Do we have anything like per-plugin prerequisites?