1st thing you need to understand, You can’t remove the pole completely. You can change its position. Now removing or moving poles to different locations from existing positions required adding or removing edge loops. And it changes the density of topology. So better is to plan required poles in advance. You should try to move poles to flat areas, less visible areas. Here in the sphere case there is not a flat area but in the plane case there is the flat area. Hence I can't change the position of the pole efficiently in the sphere case. I have explained these points in a video. You need to watch the video carefully.
It’s all well and good isolating a small area to fix a local ‘problem’ and improve topology but you’ve added more edges which makes adds problems and makes the model more complex and irregular. Would be good to see how these tips could be useful in context rather than a small isolated area.
@@filipstamate1564 depends on use case, localized topology is the cleaner option of course. with respect to the original comment, there are dozens of videos on topology fundamentals and retopologizing.
Yes u have erased the Pole, but u ve also introduced irregular topological density. Adjusting the edge loops until they have no pinching in the sub d result, can take a huge effort at the end on complex surfaces
so close to useful tutorials on base case remediation, but then you ruin it by changing the edge of the newly created hull faces by subdividing the borders by introducing full loops, making them no longer exemplars of base cases. Honestly, the only way to actually eliminate a pole and not siply slide it around to a new, less inconvenient location or addnew ones would need to entail a partner pole, or a hull/symmetry border edge to be subdivided. If you have a second pole, the 2 can have edge loops bridge across to each other the way your trailing loops extend off here, and the loops created by that bridge can regularize the edge loop density. It's less helpful to worry about pole elimination for base cages than to consider ideal locations where the irregular behaviors become preferable descriptors. Ultimately, you need to treat it more like a game of old fashioned nurb patch modeling, letting patches join along natural seams and folds so that the puckering, creasing and shading codependencies also describe the form.
Yoy clearly dont understand topology. Poles are bit bad in general. In fact for a sphere like shown in the video they are unavoidable. You just want them on mostly flat geometry so at times you need to move them.
@@angulinhiduje6093 this is not about topology, this is about shading, because no matter what topology have an object if it looks nice in render (and causes no problems during animation) 😂 don’t teach anyone if you are not pro. it is much better to make a new topology in this case (what I usually do). This method doesn’t solve the main problem and this is fact
can't blame you for trying, but yes: poles are inevitable unless you have a simple, flat (or at most, bent), quad plane. It's just a question of where you have them, as you say. One can run a retopologize algorithm, but that won't get rid of poles, only move them procedurally by angles of volumes formed, and without your consideration. By his own admission, there is more to consider in any triangle mesh than a single frame of animation, and if you have a reason to care about a base cage, you have a reason to care about those factors as well.
I taught myself topology by accident, by modeling out of large cubes first. This automatically creates the proper poles in the corners. Then I loop cut the cubes into smaller divisions and smoothed out the shape.
@@OpenGL4ever as to my understanding, regardless of how the center looks, it cannot be a triangle fan if there are no triangles in the geometry. just like rectangular ngons are no quads, triangular quads are no triangles. youtube keeps removing my links as spam, if you replace the space of the link in the bracket with dots ive uploaded an image of the same topology on a 8 and 16 vert cylinder. its the same method but dosent look like a fan. (ibb co /8xwPRsF) im just going through these length in case my understanding is wrong. could you explain how or why this is bad topology?
given your handle, you may be knowledgable enough with EBOs to know, but technically, he is correct: not a fan, just following a fan pattern in isolation. Would be quite hard for the cylinder to define it's triangles in a fan just for the cap of an otherwise half-edge mesh model structure. Not that it matters, your meaning is clear enough. That said, your point is not: triangles in a mostly quad based mesh aren't intrinsically slower: adding irregular math for deformer stacks is what's usually slower, but that's not even close to relevant here. At the root level, all quads are merely triangle pairs with fewer edges in that secondary EBO
@@angulinhiduje6093 I am talking about "OpenGL primitives". You will find examples if you do an image search for these two words. There you will find a OpenGL primitive type called triangle fan. This was okay in the old days because it saved vertices and thus even accelerated the rendering in the old days. But our modern hardware and 3d APIs are designed for brute force rendering of triangles. A special case in which you render such a surface as a triangle fan would need special treatment and thus would therefore be slow. The problem here doesn't have to be Blender, but the 3D engine that uses the mesh geometry afterwards. It could interpret it as triangle fan. A triangle fan is not the same as multiple individual triangles; the latter is another OpenGL primitive type. And the latter is what GPUs and modern 3d APIs are optimized for. In Blender, all quads are broken down internally into triangles, which is how the GPU works. The representation as quads is only for the graphic designers who create the 3d models.