Let's talk about Polygons

[Malo]

Hi raskrodi,

I have made a video (I have not time to ameliorate it this week end, sorry) But the big explication is in it.
I notice that big model freeze the browser. (I am not a programmer, and HTLM5 is not optimised for that)
http://treser.net/AnimationMaster/2015/export/AMBLender.flv

The tool is simple to use, you click on index.htlm file. (it work with firefox, but it is possible that Chrome stop the program (the htlm5 is generated with construct2 so it is not made to be used outside the web))
when the page is open, clik on the first image if you use an obj with no subdivision, and the second if you use a subdvised model. after you call the Obj format (that you have changed the extention in ".txt")... after save the model generated big model can freeze the programm, so copy the windows and stick the text in an text format, that you will changed in Obj extention.

 

There is a problem in Obj and MDD export in AM when there are more than one hook by patches. the topology is crazy. And can't be repair in extern.

The code is simple. If you are interested, I can explain it.

[rasikrodri]

Yes please explain the code, only if you have the time. The is no rush, I understand that you are busy.

[Rodney]

...The tool is simple to use, you click on index.htlm file...

 

That is very impressive Malo.

[Malo]

I will try to explain :

As you can see on the picture, I parse the Obj format, to change Faces's lines.

 

The hooks in Obj generated by AM is write with 3 lines with the same vertices in the last vertices of each lines. (so it easy to found them)

I write this 3 lines in one lines with 5 vertices (in the order you can found in the graphic, blue)

 

For triangles. AM write them with 4 vertices, the last vertice is the same of the the first vertice of the line (so it easy to found it)
I elimnate the last vertice of the line. (green in the graphic)

 

For 5gones, AM write them with a line with 4 vertices, and a line with 3 vertices. The first and the last vertices of the first line is the same of the first and second vertices of the second line.

I write them in a line with 5 vertices. as in the graphic (red)

 

When the model is subdivised, the hooks is the same change. No need to change the 5 gones, for the 3 vertices I close two triangles in a polygones.

For that I found two lines with 4 vertices with the same vertices in first and last vertices of the two lines.

 

and voilà.

 

If you want more explication, don't hesitate to ask.

[NancyGormezano]

Bravo Malo!

[Malo]

thanks Nancy and Rodney...

It is just a "correction" of the Obj generated by AM... But the model is not optimised... There are some reflections to be done to optimised it.

For example for the hooks export, actuelly hooks have problems, I think it come from in party of that it don't affect the patches which is cut by hooks, but affect the neighboring patch). In affect the good patch, This reduces the possibilities for subdivision (3 possibilities against 12). Here a graphic to explain what I try to explain and a suggestion for create a simple topology (I don't know if this topology is possible to be applicated) :

I think triangles have to be rethink too... All program that use AM patches, when they export them they use the same topology, 3Dpainter use this topology too. So the code exist somewhere.

[pming]

Hiya.

 

I can understand wanting poly's in AM (I did at one point too). I can see the benefit to sticking "with hash patches", though.

 

That said...there really just needs to be a way to "model more quickly" in A:M. In short, I think if we got the ability to model on not just CP's, but with "segments" and "patches" themselves, it would make A:M modeling *significantly* more pleasant for those of us who have been modeling with polygons for 15+ years.

 

For example, being able to click on a segment between two CP's, then right click and choose "Modeling --> Add Segment Loop (even) // or // Add Segment Loop (w/control)". If I wanted a nice even split down the middle, it would do so...just like adding an "edge loop" in a polygon modeler. Or maybe I want to extrude a patch. As it stands now, I have to select the CP's, hit extrude, then go in an detach splines, delete them, reattach and hope for the best...using Peak and Smooth to see which ones I now have to go in and "fix". To put it another way...not worth the effort.

 

I have seen some pretty amazing modeling come out of AM...but I've also heard the people say stuff like "I've been working on this for a few hours every day for the last couple of months". That is terrifying! I can see the same level of detail and quality in "polygon based" modelers and I hear stuff like "Something I did over the weekend seeing as the wife and kids were visiting grandparents". So...MONTHS, vs. a couple of days. 'Nuff said, really.

 

In short, I would love to see some serious effort go into two things: First, get some hash-patch equivilent modeling tools working. Things like Select Loop/Ring, Bevel Edge, Bridge, Cut/Connect, Chamfer, etc. I think adding in "Multi-Bias Mode" may be the way to go (where, basically, each CP has a "bias" going out towards EVERY segment that is attached to it...so there is no more of this 'spline direction' stuff we have to worry about). Second, it would be a nice addition to have a rock-solid and option-riddled FBX export for animation in particular (I'd even be happy with a good, industry-standard-based BVH export). I would be quite happy to make simple character models in AM (hash patches and all) if I could animate it in A:M, and then export it as "animated FBX/BVH" so I could import/attach to my fully-detailed polygon meshes in whatever program I'm using at the time (Lightwave, XSI, Maya, 3DS MAX, etc).

 

I have seen some really creative modeling tools (usually Japanese-made), and some have made it into the core A:M. But if an "equivalent workflow" could be attained in A:M with using Hash Patches...I think a LOT of negative criticism would evaporate (and probably increase the number of A:M users a hundred fold...or more...).

 

 

Paul L. Ming

[nemyax]

I have seen some pretty amazing modeling come out of AM...but I've also heard the people say stuff like "I've been working on this for a few hours every day for the last couple of months". That is terrifying! I can see the same level of detail and quality in "polygon based" modelers and I hear stuff like "Something I did over the weekend seeing as the wife and kids were visiting grandparents". So...MONTHS, vs. a couple of days. 'Nuff said, really.

I've had exactly the same experience. It happens with every decent-looking WIP in A:M.

 

 

I have seen some really creative modeling tools (usually Japanese-made)

Which Japanese tools do you mean? I've played with hamaPatch and 3DAce. Both are neat, if basic. There's also Metasequoia, which is rather bland. Are there any others?

[Rodney]

Paul said:

"I've been working on this for a few hours every day for the last couple of months". That is terrifying!

 

Nothing too frightening there. Most folks who say this only have a short time to work on their projects outside their day jobs and other commitments; perhaps a hour after work on any given night.

In the end you'd likely find the process takes about the same time (give or take the individual skill/experience of the artist and the inevitable extra time needed to ramp up into longer term periodic projects).

And regarding the level of detail... as they say... most projects are never completed... just abandoned.

You can almost always find something worth tweaking and/or add further detail.

Knowing where to stop is as important as knowing when to begin.

I do think it best to tackle all major tasks in one sitting if possible... much time is wasted otherwise.

But this is a workflow issue that doesn't relate to the software in any meaningful sense.

if an "equivalent workflow" could be attained in A:M with using Hash Patches...

 

Workflow is certainly key. One thing folks can do is share a video here in the forum of their workflow or an approach that they would like to refine. When others see that they will make alternative (often very useful) recommendations.

 

You mention several processes that are intriguing.

It does make me wonder if you've used plugins like SplitPatch. I assume you have but if not... those are great time savers.

A:M has a lot of modeling bells and whistle that few people use (I think largely because we tend to forget they exist).

The use of external modelers can be both a blessing and a curse in that a workflow learned might give insight into a method in A:M but it also might frustrate because there are better ways to spline in A:M.

What is being modeled will also dictate.

 

 

Added: My gut feel is that if A:M Users focused more on what A:M uniquely brings to the table we'd see features appear that would be hard to match in any other application. Looking at other apps for inspiration (or comparison) can be useful but it doesn't play to A:M's core strengths.

[nemyax]

My gut feel is that if A:M Users focused more on what A:M uniquely brings to the table we'd see features appear that would be hard to match in any other application.

3DAce is interesting in that respect. Without being a spline modeller, it provides all the basic splining techniques of A:M (except hooks and five-pointers):

• Cage drawing (similar to the add point tool)
• Generating triangles and quads (unlike A:M, it's only semi-automatic)
• Fusing points by right-clicking during a drag
• Connecting edges one by one (as in the add point tool's split-me-slowly mode)
• Running a new loop through an edge ring (a plugin in A:M)
• Cutting through edges (again, a plugin)
• Removing a loop

And it also offers good interactive symmetry and edge/face selection, both of which would also fit in with A:M's toolset.

[Rodney]

it also offers good interactive symmetry and edge/face selection, both of which would also fit in with A:M's toolset.

 

You might have to demo that workflow for better understanding.

Barring that I assume you aren't familiar with modeling in a Choreography.

[nemyax]

I assume you aren't familiar with modeling in a Choreography

I am, but that's only a workaround: you still have two separate objects and you can't box-select.

Edit: Here's a demo: youtube.com/watch?v=XQsrIcEtzpc

[pming]

Hiya.

 

@Rodney. I get what you're saying...but I guess I wasn't clear enough. Generally speaking, I'd say it takes me x2 to x10 as long to make something in AM than it does in any of the poly-based programs I know and use most often (Softimage XSI, Hexagon, Lightwave, ZBrush). Now, I know I am MUCH more familiar with the poly-workflow, those programs, and polymodeling in general...so I'm sure if I had as much knowledge/experience in A:M those times would be closer together.

 

However, I don't think they will ever be more than "almost equal" for any but the most simplistic of models. I would LOVE to see an A:M pro-modeler do a time-lapse video of modeling something relatively detailed. Just pop over to something like the ZBrush forums ( http://www.zbrushcentral.com/forum.php ) for the kind of detail I'm talking about. Now, one caveat here... some of those are some seriously high-poly models (like millions to tens of millions of polygons). Those models are then "poly-reduced" to a much lower level (say, 75k or lower), but all that sculpted detail is written out as bump, cavity, normal, AO, etc. maps and applied to the "manageable poly" level models. If an A:M pro could show us all how he would go about doing something equivalent in A:M... I'd probably cream myself. (sorry for the graphic imagery! )

 

What I mean by "equivalent" is whatever it takes to get an A:M model to have the same level of detail as "detailed poly models", be they ZBrush, Maya, Softimage|XSI, trueSpace or whatever. Using all the tools one would use... mesh modeling, normal maps, area-occlusion maps, and all the other stuff. If the end result didn't take significantly longer than using another poly-based modeler, I'd be one happy camper.

 

As for my other comment about "japanese plugins"... I wish I could remember what site it was. It was a list of several plugins that I had found really useful for modeling in A:M. The guy was japanese, and his page was in japanese...but the plugins were "english". I have searched to no avail...I don't think I have all of them (lost somewhere over the years), but I know they're out there in the internet somewhere... sorry.

 

Anyway... one thing I still stand by; A:M's animation tools are just pure awesome! I got ok at animating in Maya (waaaay back when version 4.0 was new.... yeah, that long ago), and I animate in XSI when I need to (primarily, I just model nowadays)... but I fell in love with A:M's easy and intuitive animation tools back when I first bought it (errr....maybe A:M '98?). That's the one major reason I even pay up every year or two for the subscription; it's a nice, simple, breath of fresh air when all I want to do is just sit down an whip out a funky walk cycle. Relaxing. Enjoyable. Like sitting on my porch in the early morning, sipping a hot cup of strong coffee, listening to the birds and the stream in my backyard, and just soaking in the crisp, clean, air. ....ahhhh.....nice.... But then some yahoo comes along in his revved up car, blasting some gawds-aweful music so loud the bass starts to jar your fillings loose.... that last part is when I am at the end of animating in A:M and have a quick thought of "Man, I wish I could import my ogre character I did in XSI/ZBrush and animate him." That part always sucks.

 

 

Paul L. Ming

[Rodney]

I follow you Paul. No misunderstanding.

There are definitely going to be workflows with polygon modelers that will be nigh impossible to match with A:M. Understanding why that is helps dull the pain a little but doesn't stop us from imagining a world where that isn't the case. The technological hurdles though... are considerable. I occasionally refer back to some of Martin's articles in order to reset my expectations and realign myself with reality. Specifically that A:M (or more appropriately Animation Apprentice) started with animation first and foremost and splines/patches followed in order to serve that. The rendering then took several years more to resolve. But the point... all aspects of Animation:Master are driven by animation. It's not difficult to imagine what might happen when one models in most polygon programs that are not designed/optimized for animation... or where animation is an afterthought. The models may look great but how well will they animate?

 

BUT... one doesn't have to reference Martin Hash to recognize the obvious. A case in point might be a simple spline or set of splines that form a surface and another set of splines that form another surface that overlap each other. The desire would be to have the second cut a nice hole in the the first (or shave part of the surface away) but if those splines don't line up/intersect we have a problem. And this doesn't speak to a more common likelihood of one object being denser (with more splines and surfaces) than the other. This is one of the reasons why boolean cutter operations with minimal splines are relatively trivially computed at rendertime but extremely difficult to get right in modeling. The primary option would be to split the surfaces more densely in order to allow for the intersections but this would come at the cost of minimal (animation friendly) splines.

SO... the solution would appear to be one where we can iterate up and down through the density of splines/patches (currently the splitpatch plugin does fair job of splitting and ratcheting up the patch count... while exporting out at a lower resolution and reimporting back in does a similar thing in reverse (if using the PLH format). Pixar's Subdiv would seem to be a solution but even in that case there are many a pitfall to avoid especially if approaching from a nonoptimal mindset. I don't know enough to even guess here but since that has never stopped me before I'd say the difference may be as non-non-trivial as the difference between the constructs of approximation and interpolation. Pixar Subdiv being (at present) mostly of the former while A:M's approach primarily of the latter. It should be worth noting that Pixar's Subdiv 3.0 stops short of implementing some significant features still planned for future release. Ref: Subdiv 3.0 Notes:

Release Notes (3.0.0)

• Full support for bi-cubic face-varying interpolation is a significant feature which will be supported in future releases.
• Feature adaptive refinement for the Loop subdivision scheme is expected to be supported in future releases

 

The good news is that technology marches on and the situation is incrementally improving.

Save those models. If nothing else your great grandchildren may someday be able to animate your Zbrush models direcly in A:M.

 

I think I'll stop there before I hurt myself.

[Willi]

nobody will use the hires mesh of zbrush. there is always a retopology process in conjunction with all the detail maps to get the final model for the animation process...

 

the bottleneck in the animation-performance is always the "skin-deformer". it doesnt matter if its a spline-model or a poly-model. with a very dense spline-model you have also animation performance leaks.

thats why animation studios have several models, like a lowres animation model with only to the deformers parented, cut-out, bodyparts, wich avoids the "skin-deformer", and the hires model for rendering...

also its common to use vertex caches, like alembic, after the animation process, to avoid the preprocessing steps for rendering.

 

in a:m you cant avoid the "skin deformer" . you cant parent model parts to the bones...

also a imported mdd cache is always applied to all the model cps as keyframes, wich can end up in a very slow animation, when your model contains a lot of detail. the mdd is not dynamcly read from file during the timeline...

 

for a polygon-module inside a:m, i think the things for bringing this up, are more or less there...

-a spline model is also a bunch of cps connected together ( in this case with hash splines). lets them connect as polygons...

-you can import polygons as props and they are displayed and rendered properly, but you cant edit it, or assign bones to it, or smooth them as subdivisions...

-mdd importer/exporter is there (also a selfmade pc2 exporter)

[nemyax]

it would be a nice addition to have a rock-solid and option-riddled FBX export for animation in particular (I'd even be happy with a good, industry-standard-based BVH export)

An alternative would be a standalone application that converts A:M files to those formats. But that's also problematic, because the source formats can change without notice.

[Rodney]

there is always a retopology process

 

I'm not familiar with the algorithm(s) for seam carving but it seems to me a similar process could be used to remove and insert splines in a mesh via automation.

Prior to processing for carving/retopology all data would be saved in original form as well in extrapolated form in anticipation of reuse in final results

The first test then might be to find those splines that start and stop at the same location (a further test might determine to what degree these primary splines are linear, vertical, horizontal,, etc. as this dictates the meshes primary if not optimal orientation).**

The test might then move on to sort a list of spline lengths from longest to smallest.

The smallest splines then are tested for usefulness as patches; if not of valid use they would be flagged for removal/replacement.

The carver would then iterate through the list toward the longest splines with a goal of maintaining equal distances between splines.

Areas of increased density would be flagged for further testing; i.e. can that area be reduced further without negatively effecting the surface/smoothness/curvature of the resulting patches.

When the carving process is complete the higher rez model's decals would then be reapplied to the resulting mesh via platt projection.

 

Note that I am not really considering the conversion of models created in other programs specifically here as the perfection of the process of moving up and down the resolution scale inside A:M is of more interest to me. At first blush this would seem counter intuitive because splines are of infinite resolution in the first place BUT splines currenty rely on the user for optimal continuity, placement and orientation.

Once there is a known goal to strive for that can reliably be targeted and retargeted then the external conversions can be optimally built for it.

Futher, knowing how a converter works (or being able to adjust parameters of that conversion, would allow the modeler to create the model in other programs with a focus on 'modeling for animation'... and specifically for use in Animation:Master (which appears to be the ideal for those apt to use other programs but who prefer animation in A:M).

 

you can import polygons as props and they are displayed and rendered properly

 

I don't do that often but when I do I'm almost always impressed by how well that works!

 

(also a selfmade pc2 exporter)

 

Point cache conversion? Intriguing!

 

 

**This is where we would begin to fetch the UV data.

[zandoriastudios]

A workflow from ZBrush to A:M:

https://zandoria.wordpress.com/2013/12/24/642/

 

This works with textures too--so if you UV map in ZBrush and create Displacements and normal maps, you can use them in the decals in A:M

[nemyax]

Pixar Subdiv being (at present) mostly of the former while A:M's approach primarily of the latter.

It looks like OpenSubdiv 3.0 can represent A:M patches with Gregory patches.

[Rodney]

It looks like OpenSubdiv 3.0 can represent A:M patches with Gregory patches.

 

That's certainly good news.

 

Willi said:

...there is always a retopology process...

 

I believe the hope is that Subdiv techniques can eventually fully perform this process. The detailed mesh would then be an aid to the simple mesh and vice versa.

The goal being to automate the process so that no one has to do it manually.

[Rodney]

I note that OpenSubdiv could deal with Gregory patches before but as of 3.0 it deals with them differently. The 'legacy Gregory patch' methods are maintained for backward compatibility but no longer used in OpenSubdiv. Here's a bit from the docs that refers to that:

 

New Irregular Patch Approximations

While "legacy" Gregory patch support is still available, we have introduced several new options for representing irregular patches: Legacy Gregory, fast Gregory Basis stencils, and BSpline patches. Gregory basis stencils provide the same high quality approximation of Legacy Gregory patches, but execute considerably faster with a simpler GPU representation. While BSpline patches are not as close an approximation as Gregory patches, they enable an entire adaptively refined mesh to be drawn with screen space tessellation via a single global shader configuration (Gregory Basis patches require one additional global shader configuration).

 

The new implementations of the GregoryBasis and BSpline approximations relax the previous max valence limit. Legacy Gregory patch still has a limitation of max valence (typically 24, depending on the hardware capability of GL_MAX_VARYING_VECTORS).

Users are still encouraged to use models with vertices of low valence for both improved model quality and performance.

Source: http://graphics.pixar.com/opensubdiv/docs/intro_30.html

 

For those familar with OpenSubdiv 2.0 there is a porting guide to get you up to speed on 3.0 available: http://graphics.pixar.com/opensubdiv/docs/porting.html

 

Added: Regarding Gregory patches and OSD this is an interesting quote from the docs:

By default, OpenSubdiv uses Gregory patches to approximate the patches around extraordinary vertices at the maximum isolation level, this process is referred to as "end-capping".