Topology in Production, if it doesn't deform, does it matter?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Search this Thread Display Modes
  05 May 2013
Originally Posted by Laa-Yosh: The main reason for all quads is Zbrush which doesn't support n-gons and triangles can screw with it too.

Gotta say these days even that's kinda gone, gone at all in fact for many.

ZBrush hasn't given me issues with tris in quite a while, in fact it now uses them internally itself in many cases. It's also the case that a model can live inside of ZB for so long until it's literally time for just final output that you rarely have to worry about it going in and out and what might happen to Nsided polys if you have any.
Whether you have spatial transfer tools and re-indexing tools though makes a big difference there, especially if you hop in and out of interim exports a lot, which while not as bad as the constantly reshuffled indexing of old, can still throw a curveball and require some assets to be reconformed.

I routinely use, and encourage the use of, triangles and have yet to have any issues with it, and we're talking quite a few years and movies with a variety of apps at this point.

The only place where they can get a bit annoying is in working with derivatives, but compared to the nightmare of some all-quads topologies that become time and half denser and twice as convoluted to just save a couple tris on the ends of a seam everybody from rigging to surfacing seems to be much happier this way.
All of this pales compared to the spanner in the works you get with 7 edges converging to a point or even worse (and I want to punch in the face every and any person who ever promoted the F'in idea) "4sided triangles".
Come, Join the Cult - Rigging from First Principles
  05 May 2013
Here's an interesting thing for all the quad fans who hate triangles - if you have a model that's 100% triangles and apply a polysmooth to it (exponential, not linear), you end up with quads, although there will be a lot of 6-8 sided poles.

Also consider that when subD's are tessellated at render time, depending on the tesselatoin algorithm, they'll might produce massive amounts of poles - though they're tiny - or should be if they're smoothing out enough.

Your extruded branches need to come out exactly 90 degrees from a poly surface, otherwise you're going to stretch or shrink polygons somewhere to get curves. To even out the polygon sizes and distribution, you'll have to add some edges and that'll introduce triangles and thus poles at render time into the model.

The whole idea of good topology is efficient crease points for deformation, convenient selection, or simple to manage UV's. At render time you're still going to get a ton of tiny trianglesthat are hopefully so small that you can't see them bend in their mechanically-faceted way.

Last edited by sentry66 : 05 May 2013 at 06:20 AM.
  05 May 2013
Originally Posted by Laa-Yosh: Nowadays we still prefer to keep our organic stuff all quads for the first reason. Fortunately it's always possible to get rid of triangles by adding another edgeloop. Poly counts no longer matter that much.

Wait, why would you add a whole edge loop just to get rid of 1 triangle? This makes no sense. Unless I am missing something obvious?
Art Station - Tumblr
  05 May 2013
Originally Posted by sentry66: People might say to just use SubD's or mental ray's approximation editor to smooth a mesh until the polys are small enough to be gone, but they make renders super long on heavy models since it has to recalculate massive smoothing for all objects every render job/frame. I'm at the point now that subD's/approximation editor literally makes the geometry disappear in the render as if it was hidden. Mental Ray apparently doesn't like 100+million polygon renders and just says no. Even on machines with 64 gigs of ram.

Absolutely NOT that.
That is not how SDS limit surfaces at render time works and the second geometry you posted would crap itself horribly the moment the first order derivative is needed, and that being by far one of the most commonly accessed shading attributes it's reason enough to prefer a topology like the first.

MRay should also not be taken as an example of defining your source data (mesh) before rendering in practically any case, PARTICULARLY not for SDS. There's a reason if PRMan, 3Delight, Arnold and VRay sell like hot cakes every day despite practically everybody and their dog having access to MRay for free.

It's misguided to suggest that to render a pixel perfect limit surface a hundred million triangles would be generated, that's simply not the case even a fairly malformed topology, not to mention that it wouldn't be a problem anyway, as even 100 million tris don't really impact memory much (MRay's inefficient sorting and sampling would have the same overflow issue in many cases, the cause is unrelated to what you describe).

I understand what you describe works in your specific domain, but it's swapping a mistake for another to be honest, and it's largely misinformed as far as the notions behind it go.

This thread is becoming one to one an exact repeat of the last topology thread we had, at this point OP is probably better off using the search function and look up this recurring infinite loop of replies anyway

P.S. the second geometry posted seems choke full of poles, not sure why you would say it doesn't have any.
Come, Join the Cult - Rigging from First Principles

Last edited by ThE_JacO : 05 May 2013 at 06:38 AM.
  05 May 2013
I just meant the geometry in the triangle sphere is unbiased. No triangle is noticeably larger or shaped different than another. What I was trying to get at was it doesn't have different sized stretched quads all over the surface and then have a couple poles with long thin triangles on each end.

You're right, the triangle sphere is all made of 100% 6-edge triangle poles, just as the quad based sphere is made of 4/8-edge poles (depending on how points flip the triangles inside the quads, plus two 128-edge poles at the top and bottom.

I know a n-gon pole is problematic because of the weird creasing that can happen because of the surrounding points not always maintaining a smooth tangent when deforming. Consider that a quad-pole has 8 points that surround it while tri-poles have 6 points of surrounding influence and therefore less crease distortion potential. See below:

My point is that a pole is really only a "pole" because the topology of it is different from the rest of the model. By having one topology directly next to a different topology, it becomes a focal point and made worse by having more influence points. By having the entire surface be made of evenly distributed poles with an equal number of influence points, you have to ask yourself are there really any "poles" anymore?

When deforming quads, the diagonal line that makes the 2 triangles inside the quad can flip at any point because of the deformation. That can create a visible pop from frame to frame. Triangles can't dynamically restructure themselves by dragging a corner. They're consistently predictable.

The purple and yellow lines along with the blue dots are variables that may or may not influence the black point

Back before maya's point-on-polygon constraint existed, I made several successful deformation rigs based on this principle with locators geometry-constrained to a triangle who's points were getting deformed.

Last edited by sentry66 : 05 May 2013 at 08:28 AM.
  05 May 2013
The definition of a pole is quite unlike what you mention. It's not really arbitrary as you make it seem, and therefore there's no 4 edge pole

Where latitude and longitude meet, every coupling of points can always be rationalized into a directional walk, therefore it's not a pole.
When a different number of edges than 4 meet at a vertex, it's a pole, because in a Cartesian rationalization of the space it's a discontinuity.

Therefore your mesh is practically entirely discontinuous in any remapping to a 2D space commonly used, impossible to walk, and would create huge issues with practically any common algorithm out there (since most of them are the culmination of years of research dealing with a topological scheme that's exactly your first picture, and not the second) , which is a nightmare, and one of the reasons why you don't see geodesic primitives winning any contests in any industry, unless it's strictly unavoidable to produce one, or you deal with the rare, almost singular cases where it's useful.

I remember your chain of posts on this line in another thread, and I know in the context you use them in and all they work for you, and that's great, nothing wrong with it, but as far as being the tiniest bit more abstract than your very specific experience, they would make most rigging and surfacing supes hang themselves before they even passed the assets on to their staff

The re-triangulation issue you mention is also non-existent. Triangulation schemas have preferred paths, and the only time that would happen is if a quad turns non convex and by pure chance it was triangulated the other way previously. At that point you have other issues anyway, and on top of that, if you want to explicitly triangulate a mesh consistently from a longitude/latitude schema, you always can, and it's also easy to reverse back, the same can't be said for what you propose.

I don't know if you actually encountered those issues, or are just theorizing they might, but they are all solved and have been for a long time, therefore non-issues and not worth considering.

I'm not trying to antagonize you btw, just this practically a textbook thread about why topology discussions can be infuriating. The subject has been mistyfied and turned into philosophy and tricks passed around in the fashion of oral tradition in tribes centuries old, when in actuality there are perfectly sound, reliable, proven and mathematically consistent rules behind choices.
Come, Join the Cult - Rigging from First Principles

Last edited by ThE_JacO : 05 May 2013 at 08:33 AM.
  05 May 2013
You're talking about latitude and longitude as if it's the earth spinning in a single direction. What if the object is arbitrary randomly spinning in any direction without any bias?

What if we threw the idea of latitude and longitude out the window? What if we threw out the idea of UV's?

What if we wanted the flexibility to add new polygons to a model- add two more arms to a character and not be limited by how much UV info a fixed bitmap resolution can hold? What if it wasn't a bitmap and just a serial text file of color number values and polygon coordinates that you can make as long or short as you want?

Maybe we won't need 2D photoshop in the future for painting 2D textures. Maybe we'll be using a 3D photoshop-like program capable of doing the "UV" unwraping with the actual triangles instead of 2D pixels.

Textures are just a temporary shortcut anyway - pictures of rough surfaces instead of geometry roughness. Painting dirt on something instead of having dust particles attached to the geometry. My procedural shaders don't rely on 2D textures because those are finite and incorrect. I would have had to throw away bitmap textures 50 times over the years as I improve our anatomy models, add internal structures, etc or any time we started rendering at the next higher video resolution.

I know UV's and quads are the current standard right now and people like opening their textures in photoshop and not have it be a jumbled mess of pixels.

I'm not doubting the existing optimizations for quads, but I see no reason something like ptex couldn't texture map one of those triangle-only objects since it's already a triangle-aware oriented format

Last edited by sentry66 : 05 May 2013 at 09:12 AM.
  05 May 2013
Sorry, but are we talking about a hypothetical future, or current times?

I'm talking Cartesian space and remapping, concepts unlikely to die any time this year or the next and, believe it or not, not strictly related to geotopography only.

You also talk about UVs in narrow terms, as if all UVs are were a flat 2D unwrap of a 3D hulls for someone to go pixel-art in photoshop on, which is a tiny subset of what they do.

And even if texturing was to become entirely 3D painted tomorrow, we still use UV and UVW for other space re-mappings that require human readability (IE mapping attributes between meshes of different resolutions that later needed editing past the initial binding).

Basically, it feels like arguing for the sake of arguing.

Topology used to be the FIRST concern when you started to model, now, thank Gods, Men and whatever atheists elect to thank, topology isn't a constraint to shape anymore, we have sculpting. Good, one down.

Topology used to be the first concern after sculpting for UVing. Now, some times it still is, or almost always -partially- is at least, but a mix of great UV tools have made density less of a concern, and painting apps going the way of sculpting might soon enough rule out 2D painting for film (for games, I doubt it just yet), so maybe in film surfacing/texturing will be free of topological constraints soon, but alas, not yet.

Topology still IS a concern, even if much, much further downstream and less of a concern than it used to be, for rigging, but many tools have surpassed the density constraints, and even flow can be more relaxed, and with the higher density and binding tools, uniform density instead of making every loop count is now viable.

So, if you don't need to shade it any particular way, light it any particular way, texture it any particular way, rig it any particular way... well, then why bother with topology AT ALL? Just render the sculpt. I know I do just that when all I want is a render of my model, if I ever re-topo it's to re-distribute things for better detail handling, and it's 20 minute jobs with QR and then topogun, not the painstaking attention we dedicate to the matter at work. But then, this was my first statement in my first post.

Living in the now though, and not in this Utopian future you describe where even the games people will simply shit a mesh out of ZBrush 6 into a PS7 Unreal 5 autobind, topology is a concern, and should be discussed in current terms, and when I see it, yet again, mystified and argued like it was a matter of opinion, I will, once again, pitch in with the reality of things we deal with in production

It's symptomatic of a narrow and short sighted perspective to think topology and UVs are simply slave to manual unwrapping of hulls and linear skinning bindings. If it was, we would have transcended it years ago, as neither of those is affected (in the high end of the industry) the way people seem to think it is. But even at the lofty heights of where you have an RnD department and your own proprietary technologies and million tiny facilitating tools, it's a game of whack-a-mole, and whenever you suppress the constraints somewhere, you realize they pop up somewhere else. Changed, maybe, ever so slightly, but still slave to the same fundamentals. So learn those fundamentals, and you will be good for years to come, no matter what department is qualified as a client to your output, or what tech has moved where.
Come, Join the Cult - Rigging from First Principles
  05 May 2013
just read your PS

The retriangulation issue does happen when a you use complex/noisy deformers and one of the corners is pushed far away

I barely moved the vertex vertical on the right and it snaps

If it's set up to render smooth, then it doesn't do as much flipping. Smoothing by 1 iteration will cut the flipping down to 1/4, but it still flips, though the deformation needs to be more extreme for it to happen:

This is obviously a non-issue with triangles

If you have something going on where that quad's shape is deforming in and out of that threshold, you get snapping from one shape to the other and it can look like micro-noise assuming the triangles are small.

I fully admit though that this sort of thing is rare and rarely noticeable, but at the same time I probably wouldn't say it couldn't still happen.

Last edited by sentry66 : 05 May 2013 at 09:50 AM.
  05 May 2013
yeah I fully agree with everything you just said. It's like MasonDoran said on the last page with knowing the rules before you can (wisely) break them. You have to understand what you're trading off when you choose a different path.

I wouldn't use any of my modeling/texture techniques in games because in that context they wouldn't work or would have some serious shortcomings.

On the flip side, the standard modeling/texturing methods for gaming wouldn't hold up for long in my line of work where the models and textures are continuously being upgraded. I'd spend more time playing catch-up adjusting topology, UV layouts, and redoing textures than moving forward by not having to worry about that stuff.

Last edited by sentry66 : 05 May 2013 at 09:53 AM.
  05 May 2013
It's a non-issue if you refine to the fragment, which if you use SDS or even just fine level displacement is the case.
When you interpolate from the vertices across barycentric space it simply doesn't happen, as there is no need to divide a quad in two triangles that early to begin with.

It's only an issue with that small level of distortion you indicate if the mesh is triangulated with no rule-set every frame, basically only in the viewport (or in the crappiest engines).
If there's a vertex precedence rule it won't happen until the polygon goes non convex, and if that happens the modeller or the TD (whoever made it so, possibly even both) need to be shot before they procreate anyway

Rest we seem to be back in line with, so that's that I guess.
Come, Join the Cult - Rigging from First Principles
  05 May 2013
Well when we model cars we use tri's and n-gons as well but placed strategically.. With a car in particular you don't want a very dense mesh since the lighter the mesh is the higher the surface tension is going to be when you smooth it which gives you far crisper reflection lines and makes it much easier to adjust the model while keeping good reflection lines..

Adding tons of edge loops to avoid a tri or n-gons really sucks cause you introduce room for surfaces with wrinkles in them and given cars have flat area's its quiet easy to place poles where you get no pinching.
Vizual-Element | Automotive Superstore
  05 May 2013
I don't know about you guys, but with me Zbrush strokes get silly when there's a triangle in the base mesh and the quads resulting from subdivision aren't aligned with the rest of the mesh. The results are just wrong.

It also has problems using the Smooth brush on pole areas and creates pinching that looks ugly. Which is why the usual solution is to add more geo to get rid of a pole that's not necessary.
Oh and 5+ sided polygons get broken down to triangles and quads, bad thing again.

But if it works for you then what do I care?
Tamas Varga
  05 May 2013
yeah you end up adding polys in that problem area until you can get enough resolution there to get that area to smooth out.

At some point you have to make a decision if it's better to just subdivide the whole object or keep adding local subdivisions to the problem area. Because to get the problem area perfect, it might need to have 4 or 8x the polygons there as the rest of the model. Then you end up with with a strange flowing object with bare minimum polygons everywhere else and tons of polys in the problem area.

Before you know it your model is covered with little patches of denser polygons and 5-sided ngons where a quad was subdivided next to a quad that wasn't. You can end up spending a lot of time trying to split up those ngons into quads and triangles.

If you don't fix all those ngons, eventually you as you fine tune the surface and smooth brush things, you get problems where those ngons don't smooth right because they cause a little pinch crease. If you try adding more polys locally there to cut that down, but it doesn't really fix it.

And if you need to do editing later, sometimes major editing changes like pull a shape way out - stretching the polygons there. You can't have those polygons stretched that much, so you end up selecting that local area and smoothing it to add polys.

For me, I decided to import my models into zbrush, subdivide them a million times until the polys are crazy small. I then sculpt exactly what I want down to micro levels of detail. Then I rely on zbrush's decimation master to auto-triangulate the model using unbiased polygons, placed exactly where they need to be.

I don't worry about topology and don't spend time fixing a million ngons as I make a major modification to the shape later.

It might be considered sloppy and might not have some of the optimization benefits that quads have, but decimating is a quick process that gives me a great looking model. I know zbrush has all sorts of topology tools - I also have 3dcoat and have used their tools as well, but those tools take time with some trial and error and you still might not get an ideal model or the density you're after.

What I like about the decimation method is I get evenly distributed polygons that get every nook and cranny that I sculpted into the ultra dense version. The polygons get placed exactly where they're optimal to preserve the shape.

From a pure shape sculpting perspective, the only thing better would be point clouds or the auto-poly generation ability of Pixologic's Sculptris. Maintaining quads is tedious and a compromise you have to make for the sake of simpler UV's and in order to take advantage of the quad-based optimizations or current hardware limits.

Last edited by sentry66 : 05 May 2013 at 08:29 PM.
  05 May 2013
Okay, here's some all quads topo. I don't think there's anything wrong with them, we had no trouble in either modeling or sculpting/rigging, which is why I don't get the fuss here.

Background character:

Hero character:

Hero meshes take longer, but we've managed to get background guys to a level I'm pretty happy with. The concept sculpts may actually take longer than the retopo, so the modeling aspect is not a problem, I consider it to be solved for a few years. The next step would be when we can just take 500K to 1-2mil meshes directly into Maya for rigging, at which point even retopo may get obsolete - but that'll take another, say, 5 years from now.
Tamas Varga
Thread Closed share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 07:26 PM.

Powered by vBulletin
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.