Let's talk about Polygons

[Willi]

Just imagine...

 

...A:M would have polygons and OpenSubDiv....

...and alembic support....

...and support of integrated 3rd-party renderers in the API / SDK...

 

with that, A:M could be a serious competitor to all the major 3d-applications out there...

 

A:M has the best data management, animation and rigging features that i ever seen in all the other major 3d-applications.

but the lack of not having polygons makes it really, really hard to interact with the other 3d products...

 

 

 

[Dpendleton77]

I would really like to see that happen down the line myself.

[nemyax]

the lack of not having polygons makes it really, really hard to interact with the other 3d products...

I don't agree that's the problem. Polygons are easily represented by patches, but not the other way around. Crank the geometry resolution in the viewport all the way down, and you'll have polygons.

In other words, polygons can be derived losslessly from spline and patch data, but the reverse is not true because of hooks and bias handles.

It's the lack of interchange format support that's really at the heart of the interaction issues.

[Willi]

i know.

but when it comes to hooks and 5-point-patches you get into trouble exporting that...

 

i would love to see a "polygon module" that can handle import/export and be able to apply all the animation features on it...

[robcat2075]

Three things:

 

1) The rigging features in A:M work well because spline models need very few CPs and it is practical to manually attach and weight individual CPs to bones.

 

Polygon models need so many vertices (CPs) to simulate smoothness that it is no longer feasible for a human to weight them between bones for smooth deformations. You would also have to add all the "deformers" that try to automate that process in polygon programs and those things are not simple.

 

There is a reason that most people who buy a polygon program never get any character rigged and end up just downloading characters some expert-users have donated on the web.

 

 

2) Not using polygons is not just an arbitrary decision like deciding whether to make something red or blue. Staying with splines from beginning to end of the pipeline is what makes everything in A:M work well.

 

About 9 years ago I was talking with Martin about this and he told me how he had hired a consultant who was an expert in programming for polygons to look at A:M's code and find a way to make polygons work alongside splines throughout the pipeline and the answer was like "well, it won't be easy... maybe for a million dollars of programmer time..."

 

 

3) Willi, if you can recruit a programmer who wants to put in the time and effort to make it work, go for it! Find that person who is expert in both splines and polygons and can make it all work together.

[Fuchur]

Just imagine...

 

...A:M would have polygons and OpenSubDiv....

...and alembic support....

...and support of integrated 3rd-party renderers in the API / SDK...

 

with that, A:M could be a serious competitor to all the major 3d-applications out there...

 

A:M has the best data management, animation and rigging features that i ever seen in all the other major 3d-applications.

but the lack of not having polygons makes it really, really hard to interact with the other 3d products...

 

 

 

 

I can see why people wish to have that, but Robert is right about many things. A:M's tool set work best because they can make advantages of very low CP counts. That makes the whole thing that easy to work with.

 

I could imagine a SDS- / NURBS-modeller in A:M which will use Spline-Data from A:M to create the cages, animate only the cages and just interpretes it differently.

That would make it possible to animate that cage (with A:M's tools, since in the end it animates splines there) but the renderered surfaces would be polygones.

I do not know how much work that might involve though.

 

A good interchange-format would be cool, but I am not sure where to start there. It only makes sense, if other software programs could handle splines (or better to say: Hash Splines).

Can they? I am not sure. Some have support for patch-modelling, but is that at least technically convertable or easier to convert than polygones? If not, it is really possible to use an interchange format?

 

3rd-party renderers by API is something, that would be very cool and sounds to me as the easiest stuff to do... I may be wrong... Steffen thought about LuxRender a while back and if it would be worth it writting an exporter for that one.

But I am not even sure if that ever was fully thought through...

 

See you

*Fuchur*

[nemyax]

Polygon models need so many vertices (CPs) to simulate smoothness that it is no longer feasible for a human to weight them between bones for smooth deformations. You would also have to add all the "deformers" that try to automate that process in polygon programs and those things are not simple.

Wrong. Firstly, the smoothness is provided by the subdivision algorithm. Secondly, you have the option of using a very lightweight deformation proxy mesh, which drives the deformations of the denser mesh like a lattice, and you only need to weight a handful of verts. Thirdly, a good spline model—I don't mean the likes of "Thom", but the really good stuff on display in the gallery and in this forum—is about as detailed as its polygonal counterparts would be.

Note: I'm assuming the case in point is prerendered animation, not real-time as in games. If it's animation for modern games, you are in the same kind of trouble in A:M—direct manipulation of dense geometry.

The "lots and lots of polygons" prejudice is common in this community, probably stemming from this bit of misinformation (and others like it) in the reference:

 

Without getting too technical, modeling technologies are divided into two camps: Polygons are prevailing, but patches are the future. Polygonal programs represent models, such as a vase, a gear, or a human head, as large numbers of tiny flat surfaces. At close inspection, the polygonal models appear to be made out of crystal, for example with many tiny facets forming the curvature of an eye. A polygon model that is composed of hundreds of thousands of polygons is not uncommon.

Polygons have a long history, they are easy for programmers to understand and implement (most computer hardware use polygons for this reason), and have a large installed base of existing models and tools to manipulate them. However, building the model in the first place is extremely difficult, and manipulating the thousands of polygons that make up a character’s mouth for lip-syncing is virtually impossible for a human. Consequently, polygon programs must provide an endless variety of tools to help move the large amounts of polygons indirectly. For example, you would associate the dozens of polygons that form the upper corner of the top lip of a character’s mouth with a bone, do this with all other parts of the mouth, then manipulate the dozens of bones to make the model talk. This explanation glosses over the difficulty in identifying the polygons that go with each bone, and the model distortion that occurs at the junction between the bones. Whatever the difficulties, many fine animations have been created with this technology by animators who sweat blood on every frame to make it look just right. Certainly, this is not something you want to do.

It reads like a 70's Pravda article. These things may have been somewhat true in 1995, but today it's utter FUD.

 

 

I could imagine a SDS- / NURBS-modeller in A:M which will use Spline-Data from A:M to create the cages, animate only the cages and just interpretes it differently.

A non-spline modeller in A:M will never happen, but if it did, this would be a waste of effort. Excellent polygonal modellers are a dime a dozen these days. Off the top of my head, at least four of them are free (Blender, Wings, Softimage Mod Tool, VoidWorld). And it's entirely possible to bring a polygonal model into A:M.

 

A good interchange-format would be cool, but I am not sure where to start there. It only makes sense, if other software programs could handle splines (or better to say: Hash Splines).

They never will, and any interchange would involve pretending that spline models are polygonal models and exporting them accordingly. And if you are animating for games, for example, you have no use for spline output anyway.

[robcat2075]

If the answer is actually easy and you know what it is, get a programmer to do it and tell him what to do to make it happen.

[Fuchur]

Wrong. Firstly, the smoothness is provided by the subdivision algorithm. Secondly, you have the option of using a very lightweight deformation proxy mesh, which drives the deformations of the denser mesh like a lattice, and you only need to weight a handful of verts. Thirdly, a good spline model—I don't mean the likes of "Thom", but the really good stuff on display in the gallery and in this forum—is about as detailed as its polygonal counterparts would be.

Note: I'm assuming the case in point is prerendered animation, not real-time as in games. If it's animation for modern games, you are in the same kind of trouble in A:M—direct manipulation of dense geometry.

The "lots and lots of polygons" prejudice is common in this community, probably stemming from this bit of misinformation (and others like it) in the reference:

 

Sorry, but it is not wrong. The final model is using heavy amounts of polygones in many cases. The fact that you can use a proxy and use something like weight-transfering from the proxy to the heavy object is not rendering that statement wrong. But even in A:M you can use weight-transfering with Transwer_AW (or in older versions WeightMover) so this might be solveable.

 

The problem are approaches like micropolygone modeling or voxel modeling with ZBrush, 3dCoat or MudBox which will create millions of polygones. Simple SDS-modelling will not create these complex control cages, but these micromodelling-models are close to unmanageable for A:M. I am not sure how well these models are animateable at all using even weight transfering, since these details would need a special form of rigging to animate perfectly, but I doubt that many people do that at all...

 

Of course if you use a Retopology-Tool this would work again, since you could decrease those millions of polygones too much less things using displacementmaps.

 

Anyway: I think the idea of rasikrodri is very valuable... using peaked, non-continuous patches to recreat polygones should get rid of many problems we are facing currently. I'll asked Steffen about the smoothing-algorithm for final rendering... since those are really around for a long time now, I can see that work quite easily...

 

One problem I can see with that is the refind normals calculation time (that will take a long time for heavier models) but maybe if you declare a group as peaked / non-continous it could work faster? I am not sure about that...

 

See you

*Fuchur*

[nemyax]

The problem are approaches like micropolygone modeling or voxel modeling with ZBrush, 3dCoat or MudBox which will create millions of polygones. Simple SDS-modelling will not create these complex control cages, but these micromodelling-models are close to unmanageable for A:M. I am not sure how well these models are animateable at all using even weight transfering, since these details would need a special form of rigging to animate perfectly, but I doubt that many people do that at all...

These models aren't normally supposed to be animatable. They are mainly for displacement map generation and material design.

 

If the answer is actually easy and you know what it is, get a programmer to do it and tell him what to do to make it happen.

Do you mean polygonal export? Styler implemented it recently in his 3D Coat link without much trouble. I believe he even used an external FBX library.

[Malo]

In my opinion, the export of information to the AM to a classic polygonal program is possible.
There are just two problems to solve.
The first problem is the triangle:
AM uses to the triangle, the patches 4 sides, and overwrites one of its sides, which creates a bad topology:

Is it possible to do otherwise ?, yes! The solution and the code is in Jpatch, the code is visible (in Java) (http://www.jpatch.com/)

The second problem are the hooks (3 types). the topology of AM or Jpatch gives no perfect solution. they create triangles. (with bugs in AM?)

One solution would be to get to create a topology like this:


Once solved this, I do not see what could block the export.



For import is more complicated ... There are different manner to do it for the purposes and different results.

Props, it could improve its ability for example by giving a subdivision level option and importing Mdd for animation.
patches, nemyax's plugin works well, it requires creating a retopology the model to fit the topology of the patches before the import.
Use AM to animate polygonal model, rasikrodri's plugin is promising for that.

The import/export of information of UV, bones, weigts, cameras, lights, scenes should not be a problem.

What is missing for AM is time, mathematicians and programmers.

[nemyax]

One solution would be to get to create a topology like this:

If you have to subdivide them, you may as well give them the regular Catmull–Clark treatment:

It's ugly, but at least it's consistent and expected.

[Malo]

that's right nemyax, the Catmull Clark Subdivision works like this ... And I thought to do this at the start.
But from what I understand, a good topology includes 3.4 or 5 edges by vertices, hence the choice of topology of a hook in the first level of subdivision, after the rules of subdivisions will be classic.

[nemyax]

a good topology includes 3.4 or 5 edges by vertices, hence the choice of topology of a hook in the first level of subdivision

That's true, but you get more "poles" close together that way.

[Fuchur]

the good thing about Malos way would be that reimporting would be possible more easily or am I wrong?

See you
*Fuchur*

[nemyax]

Fuchur

Do you mean reimporting them as hooks again? This would require agreeing upon a convention for what kind of polygon to treat as "hooked". For example, you might want to interpret the topology below as a patch with 3 hooks on one side. Looks easy enough.

 

 

But it's always going to be ambiguous. If you make the topology a tiny bit more interesting, it becomes unclear which way a hook should go. See the selected point:

 

 

I don't think you can support hooks using strictly topological cues.

[Rodney]

This topic will eventually move to the Open Forum... so if you imagine the topic has disappeared it'll be there.

[Malo]

yes, indeed ... but more poles with 5 or 3 edges, and there I don't know what is best 3 pole with 5 or 3 edges or one pole with 7edges.

I think Furchur want to make reference to the technicque you use in your script for Blender "Animation: Master Middleman".
If that is indeed this could work, but I was not thinking about that, because if it is for export to the outside of AM and reimport in AM, there is an easier way, which is to use the UVs as references to reconstruct the topology of the starting AM model.

[nemyax]

If the specifications for A:M's proprietary formats (which are plain text anyway) were made publicly available, that would be a huge step towards problem-free data interchange. That's the least Hash Inc. could do, and it wouldn't even cost them anything in development.

This is somewhat related to Rodney's question elsewhere:

where are the big guys coding bridges to Hash Inc?

The company isn't giving their specs away, so why should anyone bother?

Newtek document their formats, and as a result they are popular and well-supported.

 

[Rodney]

These topics usually get a few posts farther before folks see opportunity to pitch negativity.

[Wildsided]

Then let's stay positive. I know sod all about this kind of thing so I'm not gonna comment, but the people who do have every right to talk about it. To quote a tired old saying "If you can't say anything nice then don't say anything,"

[serg2]

Still closer to AM NURBS modeling, rather than to a polygonal approximation

[Fuchur]

Absolutely right...

Rhino and MOI are much closer...

 

How did you export Thom to these programs? DId you model it or which exporter did export spline/patch-data?

See you
*Fuchur*

[jakerupert]

quote:

About 9 years ago I was talking with Martin about this and he told me how he had hired a consultant who was an expert in programming for polygons to look at A:M's code and find a way to make polygons work alongside splines throughout the pipeline and the answer was like "well, it won't be easy... maybe for a million dollars of programmer time..."

 

i would say in times,when sculpting and external rendering have gotten standard tools, that would be fantastic.

 

Cant you all get together with Steffen and collaborate on this topic may be?

is there some kind of roadmap available somewhere, which way A:M is heading for the future?

 

[serg2]

PatchWorker - AM Export to AV2 >>>>> by Reserect Plugin for 3DSMAX import to 3DSMAX >>>>>> convert to IGES or SAT >>>>>> Export 3DM NURBS Model

[jakerupert]

how do i alter mypost here now?

 

Anyway just post it here: a possible workflow like this would be great

pipeline: highres sculpt >import retopo uvmap bakeing to patch > animation A:M >export to rendering external polyrenderer

[nemyax]

animation A:M >export to rendering external polyrenderer

For this part, you're probably best off using the existing export path through MDD. If you want to keep the curvature you have in your patch model, you have to give it a couple of subdivisions to apply the shape, so that the subsequent subdivision by the external renderer doesn't unexpectedly shave the model.

However, A:M's pre-export patch subdivision could use some improvement, as Malo suggests above.

[R Reynolds]

 

A:M has the best data management, animation and rigging features that i ever seen in all the other major 3d-applications.

but the lack of not having polygons makes it really, really hard to interact with the other 3d products...

 

Why is it important to you for A:M to interact with other 3D products? You like its rigging, animation and data management. This makes me guess you are less impressed with A:M's modelling and rendering. Why don't these features meet your expectations?

[Willi]

 

Why is it important to you for A:M to interact with other 3D products?

 

every 3d-app has its advantages and disadvantages.

some has features that other dont provide. there is no "all-in-one-app" out there. and if you use 3d apps in a professional way, you automatically have to use other 3d-apps than your favorite one...and you have to bring your data in and out...

 

 

 

This makes me guess you are less impressed with A:M's modelling and rendering

 

a:m´s modelling is great for its internal splines...i like it.

but if you dont stay in a "polygonal way of modelling" inside a:m (like not using 5-points, not using hooks, trying to decal without overlapping), you dont get your data out of animation master without rework...

concerning rendering, thats true...i am not impressed. its slow (no "real" multithreading, slow AO, slow and not usable GI, etc).

in the end of every 3d project, the final image is what counts. to get there i can use other renderers, but those are all based on polygons...and so i am back to modelling, where i have to try to get the spline-based model data out to my favorite renderer...

 

its possible to have a workflow of modelling, rigging, animating in a:m and then rendering in other renderers. a:m provides that tools (obj-export, mdd export, my custom cam-export tools). but there are a lot of things to consider (especially in a production enironment) before rendering the first frame out in that external renderer.

 

 

3rd-party renderers by API is something, that would be very cool and sounds to me as the easiest stuff to do

 

@fuchur, @steffen: what you think, is it possible to integrate "cycles renderer" in a:m as a plugin?

[Rodney]

Just so we're clear here... 'cycles' is your favorite renderer?

Or did you mean that more generically as 'the renderer I would like to use for the job at hand'.

[Willi]

no. cycles is not my favorite renderer. i meant it more in general.

but cycles is open source now...

[Rodney]

Thanks.

 

Follow up question:

Are there any other programs that use cycles besides blender?

 

 

R&D has to start somewhere.

 

Edit:

This is somewhat of a disregard to my previous question as I see info on the cycles standalone renderer here:

 

http://www.blendernation.com/2014/01/27/cycles-standalone-renderer/

 

This hints at the answer to the underlying question:

Thomas Dinges is working on a standalone version of the Cycles renderer. The current version is still very simple, but it paves the way for integration of Cycles in to other 3D apps.

Thomas Dinges writes:

 

Cycles is nicely integrated into Blender, but can also be build as a standalone renderer. The standalone application can be used for testing purposes but also allows an integration into other 3D programs.

The code is still experimental and the application is quite simplistic, but it can already be used and also works with features such as OSL or GPU rendering (if compiled with those features).

I'll add this link for reference also:

http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Standalone

I'd say that integrating cycles with A:M is certainly possible but cycles for other 3D apps (other than blender) is still very much under development and therefore wont meet your expectations yet. The xml format being used is certainly intriguing.

[Willi]

https://github.com/jesterKing/CCSycles

 

https://github.com/ShaderManager/MayaToCycles

[nemyax]

cycles is not my favorite renderer.

RenderMan? Arnold? Clarisse?

[Willi]

 

RenderMan? Arnold? Clarisse?

at the moment "Redshift".

[detbear]

"Redshift" has some amazing capabilities. It's not super expensive yet. But it is limited to XSI and I think Maya. So it

doesn't work on a large number of packages yet. Although I think they are attempting to expand.

 

DAZ studio has just added Iray to their latest beta release(4.8) and it's pretty amazing.

 

If possible, I don't think Hash should avoid this progress in the CG world. It will soon be out of reach. There is a huge need for Hash to be able to connect with

external sculpting and rendering engines.

 

Most of us here on the forums really like Hash and we understand how difficult it is to make the spline platform work in a poly saturated industry. BUT the

reality of where things are and are heading is staring all of us in the face.

[jakerupert]

thats true: at the exit side its the renderers we would like to use and at the entrance the sculpting tools.

cant live without it in the long run,so please make it useable.

[rasikrodri]

 

Wrong. Firstly, the smoothness is provided by the subdivision algorithm. Secondly, you have the option of using a very lightweight deformation proxy mesh, which drives the deformations of the denser mesh like a lattice, and you only need to weight a handful of verts. Thirdly, a good spline model—I don't mean the likes of "Thom", but the really good stuff on display in the gallery and in this forum—is about as detailed as its polygonal counterparts would be.

Note: I'm assuming the case in point is prerendered animation, not real-time as in games. If it's animation for modern games, you are in the same kind of trouble in A:M—direct manipulation of dense geometry.

The "lots and lots of polygons" prejudice is common in this community, probably stemming from this bit of misinformation (and others like it) in the reference:

 

Anyway: I think the idea of rasikrodri is very valuable... using peaked, non-continuous patches to recreat polygones should get rid of many problems we are facing currently. I'll asked Steffen about the smoothing-algorithm for final rendering... since those are really around for a long time now, I can see that work quite easily...

 

One problem I can see with that is the refind normals calculation time (that will take a long time for heavier models) but maybe if you declare a group as peaked / non-continous it could work faster? I am not sure about that...

 

See you

*Fuchur*

 

Not only for final rendering but for real-time rendering too, I think it is very possible because if you see the next screen shoots the first one is real-time and the second one is rendered the third one is the wireframe and solid real-time. They the same thing, it seems that AM uses the same algorithm in final render and real-time render in this kind situation.

This time is textured, my program can build the stamps too. But I haven't have the time jet to do some refining and add more stuff to the Collada converter. This is all fun but requires time.

[rasikrodri]

Actually if they can be treated as props when it comes to shading, that will do. Maby adding a button to set it to display and render as prop.

[Heiner]

After the post of Prolific with the Thom in Rhino, there is another thing I wanted to point out:

If whats in the end of Prolifics export/Import to rhino is in fact NURBS then there is another

big market where AM could score big time: Hard Surface Modelling! At the moment the NURBS

world is over exited about tools like T-Splines and Clayoo, which are basicly box modelling tools

with the ability to generate an real NURBS model. Nothing really new here but, the reason why

the customers rave so much about these programms (or rather plugins) is that the NURBs

world is looking for an easy and intuitive way to model.

I am doing a lot of NURBs modelling theses days and more than once i thought "Oh how nice

would it be to be able to do that in AM".

Like I said, if its really a convert of AM Splines to NURBS whats happening there, then AM

would not only be a great enhancement for the world of polygons, but also for the world of

NURBS too!

Regards

Heiner

[pixelplucker]

AM kind of does have a sub-d surface if you look at the models with poly mode.

For AM to implement this they might be better off with a hybrid system as not to disband the splines they already have.

Splines offer better manipulation but are much more difficult for modeling. The biggest drawback is they are very proprietary and converting quad models to and from AM and other programs is problematic with in particular Hooks and 5 point patches. Until Hooks and 5 pointers can be effectively translated it seems just about every converter out there falls short.

 

A hybrid system would allow other model types to be imported in without translation. Maybe FBX, maybe adopt Silo engine for the poly side of things.

There probably isn't any real need to import a nurbs model since all you need to do is manipulate and render not create brep surfaces etc. so most cad programs already export obj or stl etc that work fine in AM already.

[a.quaihoi]

Isn't there already polygon preview built in - I just noticed this, really good for pre visualising for 3D printing

[nemyax]

There is a polygon preview, but no subdivision surface preview. That would be a handy addition.
HamaPatch can display any of the three: patches, polygons and subdivision surfaces.
Default patch mode:


Polygons:


Patches as polygons:


SDS as polygons:


Smooth SDS:


Of course, HamaPatch had it a bit easier, because it didn't have hooks. But hook support doesn't look like a showstopper.

[Fuchur]

What he is talking about is this option, which is better suited for 3d printing in most cases, since you want precisely what you have modelled there.

 

I don't see what a SDS preview would help. Could you explain why you'd like that? It would be harder to control in these cases while modelling, because you always would have to guess how the SDS smoothing would behave (one of the things I always saw as a bad thing with SDS... yes it can be previewed quite nice, but still you are always working on a control cage instead the real deal there...

 

See you

*Fuchur*

[nemyax]

I don't see what a SDS preview would help. Could you explain why you'd like that?

In the absence of easy interchange, it wouldn't help much indeed. But if A:M were to be used as the animation part of a pipeline (and this topic shows there really is a need for that), it would be the right thing to have.

[Rodney]

All this talk of polygons makes me want to suggest a relook at Hash patches and spline technology as implemented in A:M.

Specifically the following:

 

Hash splines or Hash patches are not converted to polygons at render time. Hash patches are converted to tiny planes or flat surfaces. This is not the same thing as a polygon. A polygon is a plane delimited by edges joined by vertices. In A:M, at render time, the planes are just planes. They are not delimited by edges. Thus they are not polygon. We don't need to convert them to polygons because the planes are computed dynamicaly for each pixel. And because a pixel is infinitesimal in space, we don't need to know if the plane is delimited by edges or not. We only need to know the plane equation at that infinitesimal point.

 

I'm not sure how this jives with the term 'polymode'.

 

 

 

Added: It's worth noting that Simcloth once used a polygon modifier that was part of the SDK but then was rewritten as a Material and (presumably) no longer utilizes polygons. I assume the polygon modifier is still part of the SDK.

[nemyax]

Rodney

What you quoted deals with offline rendering, not with real-time GPU-accelerated rendering in the viewport.

[Malo]

By changing the Obj format created by AM, it is possible to have a good model in Blender.

The changes are as follows.

- rewrite the triangles (eliminate duplicate vertice in the faces).

- eliminate unnecessary edge in the face five sides

- Eliminate the two edges formed on single hooks to create 5gones.

The benefit is that it is possible to keep the Uvs and operate with MDDS.

If you want to see the result in Blender (and the trick to recreate volum lost in subdivision with low-poly): Thom walked. http://treser.net/AnimationMaster/2015/export/Thom.blend

 

I deepened my reflections on the conversion hooks, and here's a better solution to the one I presented above:

the trick is to convert hooks in 5gones. (the 5gones in subdivision create better topology than triangles.)

 

The explanation of patches is interesting (thank Rodney), it allows to better understand the problems of rendering normals, bumps, displacement, patches with 5 sides, compared to polygons that are attached to each other without being able to break away and create holes in them. But the advantage of the patches is that they can be dynamic and not be dependent on the topology for the density of polygons.

 

Nice to see the evolution of your plugin, rasikrodri.

[Malo]

I write a little tool to mofify the Obj format converted by AM, to import them in Blender.
You can download it there : http://treser.net/AnimationMaster/2015/export/objAM2OBJ.zip

(It is writed in htlm5, so it go slowly.)

I will try to do a video next week, to explain how to use it.

[rasikrodri]

How do you run it?