<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Vertex Academy]]></title><description><![CDATA[Obsidian digital garden]]></description><link>http://github.com/dylang/node-rss</link><image><url>site-lib/media/favicon.png</url><title>Vertex Academy</title><link></link></image><generator>Webpage HTML Export plugin for Obsidian</generator><lastBuildDate>Mon, 19 Oct 2026 05:06:43 GMT</lastBuildDate><atom:link href="site-lib/rss.xml" rel="self" type="application/rss+xml"/><pubDate>Mon, 19 Oct 2026 05:06:31 GMT</pubDate><ttl>60</ttl><dc:creator></dc:creator><item><title><![CDATA[Index]]></title><description><![CDATA[<img alt="banner|upper" src="media/va_banner.png" target="_self">This guide was created as a means to compile all the knowledge I've shared on various social media platforms in hopes to provide a less fragmented resource for those seeking to learn subdivision modeling.For me, learning is an endless pursuit. Embracing mistakes, comparing notes with others, discovery though empirical study, and pushing myself into uncomfortable situations.It's also about enabling others to learn and discover for themselves. Knowledge shouldn't be hidden, but shared with those who have a desire to learn. Just as I did with the knowledge given to me, I encourage you to take from it, experiment, build on it, and expand your own horizons to create something new. And of course, I hope you pay it forward and do your best to teach others. This is especially important in this new AI-driven era where human knowledge is more valuable than ever.<br>Going forward, this guide is geared toward subdivisional modeling for game development, as it allows for learning all topics pertaining to subdiv, including unorthodox ones. There may be times where I call out exceptions for other industries if I feel it's important enough to warrant it. I recommend checking out the section on <a data-tooltip-position="top" aria-label="Considerations" data-href="Considerations" href="modeling/why/considerations.html" class="internal-link" target="_self" rel="noopener nofollow">considerations</a> first, as I touch on this topic in a bit more detail.<br><a data-href="Considerations" href="modeling/why/considerations.html" class="internal-link" target="_self" rel="noopener nofollow">Considerations</a><br>
<a data-href="Terminology" href="modeling/why/terminology.html" class="internal-link" target="_self" rel="noopener nofollow">Terminology</a><br>
<a data-href="Methodology" href="modeling/why/methodology.html" class="internal-link" target="_self" rel="noopener nofollow">Methodology</a><br>
<a data-href="Core Mechanics" href="modeling/why/core-mechanics.html" class="internal-link" target="_self" rel="noopener nofollow">Core Mechanics</a><br>
<a data-href="Common Misconceptions" href="modeling/why/common-misconceptions.html" class="internal-link" target="_self" rel="noopener nofollow">Common Misconceptions</a><br>
<a data-href="Modeling for Context" href="modeling/why/modeling-for-context.html" class="internal-link" target="_self" rel="noopener nofollow">Modeling for Context</a>Assessing Goals
Curvature
Density]]></description><link>index.html</link><guid isPermaLink="false">Index.md</guid><pubDate>Mon, 19 Oct 2026 04:50:04 GMT</pubDate><enclosure url="media/va_banner.png" length="0" type="image/png"/><content:encoded>&lt;figure&gt;&lt;img src=&quot;media/va_banner.png&quot;&gt;&lt;/figure&gt;</content:encoded></item><item><title><![CDATA[Methodology]]></title><description><![CDATA[This is the primary thing you need to worry about. Does it smooth without pinching? Are there no overlaps? Do the highlights look fine? If you answer yes to all those things, then you're good to go.
Caveats: <a data-tooltip-position="top" aria-label="Considerations &gt; Sculpted" data-href="Considerations#Sculpted" href="modeling/why/considerations.html#Sculpted" class="internal-link" target="_self" rel="noopener nofollow">Zbrush</a>]]></description><link>modeling/why/methodology.html</link><guid isPermaLink="false">Modeling/Why/Methodology.md</guid><pubDate>Mon, 19 Oct 2026 00:04:52 GMT</pubDate></item><item><title><![CDATA[Considerations]]></title><description><![CDATA[There are a few considerations of subdiv modeling that you need to be aware of if you're looking to master this workflow and navigate the feedback. This section will have reference links to more advanced methodology that you can explore if you're curious about them, though I also recommend stepping through this guide progressively. But as always, how you learn is your choice.The VFX industry is the most strict industry when it comes to subdiv modeling. Quad-only and evenly distributed faces are a necessity for most assets due to the pipeline tools and animation/deformation concerns. I don't have much to say about VFX modeling as I don't have direct professional experience with it. Suffice it to say, you can still use most of the concepts talked about in this guide, just without introducing ngons into your workflow. Or at least not without your supervisor's permission.Product Viz is VFX-adjacent, but also kind of lives in a middle ground where a lot of the same guidelines are less strict. This is probably the halfway point between modeling subdiv for games vs VFX. Ngons are acceptable for most things here, but the shading invites higher scrutiny than games. Tread lightly.Game dev is by far the most free-flow in terms of what you can do and get away with for subdiv. Minor shading errors are fine 90% of the time. Time and efficiency are the primary considerations when making high poly subdiv models and as such, knowing how to maximize your results with the least amount of work is the mindset you'll need to adopt. I would consider this the most aggressive industry for furthering your problem solving and optimization skillsets.This one is the newest of the bunch and is probably closer to game dev than product viz. Keeping faces regular with even distribution is a good way to go, through convex ngons are acceptable within the confines of "does it shade correctly?".Hell if I know. People do crazy shit with subdiv all the time. Fly headlong into whatever this place is and learn as you go. The world is your oyster. Try things nobody else has tried. Just be aware that any feedback you get is probably not going to apply to this new method and that shouldn't stop you because you're trailblazing now! Fuck the haters.For whatever reason, sculpting software like Zbrush do not support ngons (likely due to outdated subdivision algorithms). To get around this, export your base mesh with one level of subdiv applied. This will fully quad your mesh and allow Zbrush to import it without issue.]]></description><link>modeling/why/considerations.html</link><guid isPermaLink="false">Modeling/Why/Considerations.md</guid><pubDate>Mon, 19 Oct 2026 00:03:53 GMT</pubDate></item><item><title><![CDATA[Density]]></title><description><![CDATA[This might be one of the biggest factors to consider when troubleshooting subdiv shading errors. Not just of the face in question, but also the surrounding geometry.]]></description><link>modeling/why/terminology/density.html</link><guid isPermaLink="false">Modeling/Why/Terminology/Density.md</guid><pubDate>Sun, 18 Oct 2026 14:23:34 GMT</pubDate></item><item><title><![CDATA[Flow]]></title><description><![CDATA[When talking about subdivision flow, people will most often refer to it as "edge flow", but I don't feel that's an accurate description of what you're controlling, nor should it be something to focus on for subdivision flow. Edges are very important for controlling how the surface moves and density distribution, but not necessarily the flow of resulting polygons.This term makes more sense in the context of quad-only models (and tris), but once you introduce ngons, it's no longer valid. So my argument is if it's face-dependent, then flow is not about the edges at all.]]></description><link>modeling/why/terminology/flow.html</link><guid isPermaLink="false">Modeling/Why/Terminology/Flow.md</guid><pubDate>Sun, 18 Oct 2026 14:21:24 GMT</pubDate></item><item><title><![CDATA[Verts]]></title><description><![CDATA[Verts, other than being the base component of all 3D modeling, have a special role to play when it comes to subdivision. I like to think of them as the vehicles that drive the subdivision.]]></description><link>modeling/why/terminology/verts.html</link><guid isPermaLink="false">Modeling/Why/Terminology/Verts.md</guid><pubDate>Sun, 18 Oct 2026 14:05:57 GMT</pubDate></item><item><title><![CDATA[Common Misconceptions]]></title><description><![CDATA[This might be my biggest pet peeve when people comment on my subdiv ngon posts. It's not a wrong statement, but it's also a pointless one in context of subdiv. Yes, models are all triangles in the end in order for GPUs to render meshes. Nothing you can do will change this fact with the current software and hardware.But for subdiv, every face is divided into quads before becoming triangles. The distinction is important in understanding the workflow, and knowing that it's all triangles at time of render doesn't change how you work, nor should it because it's an underlying mechanic of 3D in general. It's like saying everyone needs to drink water when discussing whether Coke or Pepsi is better. This is a nothingburger of a statement.No. If it's shading bad on a curved surface, it's not because of the ngon itself. It's user error and/or lack of problem solving knowledge.Continuous edge loops are common in modeling, and they can make certain things easier in your model, but they are absolutely not required to make easy edits and I'd argue that more often than not, they make your mesh considerably harder to edit.Say you have a complex model like an engine block or transmission housing and are asked to make an edit to the model. You need to verify that any continuous loop you add or edit is not going to mess up any other part of your model. This results in a considerable time sink and I highly recommend either terminating the edge on a nearby <a data-tooltip-position="top" aria-label="Poles &gt; Regular Poles" data-href="Poles#Regular Poles" href="modeling/why/terminology/poles.html#Regular Poles" class="internal-link" target="_self" rel="noopener nofollow">regular pole</a>, or just cut the edge short with an ngon in a spot that won't hurt smoothing.<br>I've gotten this one a couple times and it's always confounding how people come to this conclusion. The base mesh triangulation has absolutely no bearing on the subdivided geometry as the resulting topology is categorically different from the base mesh. Refer to "<a data-tooltip-position="top" aria-label="Common Misconceptions &gt; &quot;It's all triangles in the end&quot;" data-href="Common Misconceptions#&quot;It's all triangles in the end&quot;" href="modeling/why/common-misconceptions.html#&quot;It's_all_triangles_in_the_end&quot;_0" class="internal-link" target="_self" rel="noopener nofollow">It's all triangles in the end</a>"For instance, in the base mesh, a quad is made up of two tris. But when subdivided once, that same quad is now 4 separate quads that consist of 8 tris in total. Similarly, a pentagon will be 3 tris in the base mesh but at subdiv 1, that ngon is now 5 quads (10 tris).Subdivided shading errors are largely a result of density disparity, concavity, or errant non-planar faces.]]></description><link>modeling/why/common-misconceptions.html</link><guid isPermaLink="false">Modeling/Why/Common Misconceptions.md</guid><pubDate>Sun, 18 Oct 2026 14:01:52 GMT</pubDate></item><item><title><![CDATA[Poles]]></title><description><![CDATA[The term "Regular" refers to uniformity. Regular poles consist of verts with each connecting edge being either the same length or very similar. Keeping poles regular means the vert of that pole will move very little or not at all in relation to those edges. If your goal is to get even surface shading distribution, you should aim for regularity. Regular poles are the most common and desirable, but irregular poles are not always bad and have great uses in more complex models.]]></description><link>modeling/why/terminology/poles.html</link><guid isPermaLink="false">Modeling/Why/Terminology/Poles.md</guid><pubDate>Sat, 17 Oct 2026 23:35:18 GMT</pubDate></item><item><title><![CDATA[Mesh Elements]]></title><description><![CDATA[<a data-href="Verts" href="modeling/why/terminology/verts.html" class="internal-link" target="_self" rel="noopener nofollow">Verts</a><br>
<a data-href="Edges" href="modeling/why/terminology/edges.html" class="internal-link" target="_self" rel="noopener nofollow">Edges</a><br>
<a data-href="Tris" href="modeling/why/terminology/tris.html" class="internal-link" target="_self" rel="noopener nofollow">Tris</a><br>
<a data-href="Ngons" href="modeling/why/terminology/ngons.html" class="internal-link" target="_self" rel="noopener nofollow">Ngons</a><br>
<a data-href="Quads" href="modeling/why/terminology/quads.html" class="internal-link" target="_self" rel="noopener nofollow">Quads</a><br>
<a data-href="Poles" href="modeling/why/terminology/poles.html" class="internal-link" target="_self" rel="noopener nofollow">Poles</a>Verts, other than being the base component of all 3D modeling, have a special role to play when it comes to subdivision. I like to think of them as vehicles.Edges are the roads that verts can travel on.]]></description><link>modeling/why/terminology/mesh-elements.html</link><guid isPermaLink="false">Modeling/Why/Terminology/Mesh Elements.md</guid><pubDate>Sat, 17 Oct 2026 23:29:36 GMT</pubDate></item><item><title><![CDATA[Recognition]]></title><description><![CDATA[One of the biggest confusions I see when sharing subdiv topology online are people mistaking it for low poly. This is largely due to the isolinear wireframe display which shows the base mesh wireframe with subdivision enabled, but hides the resulting wireframe.]]></description><link>modeling/why/recognition.html</link><guid isPermaLink="false">Modeling/Why/Recognition.md</guid><pubDate>Sat, 17 Oct 2026 20:38:24 GMT</pubDate></item><item><title><![CDATA[Isolinear Wires]]></title><link>modeling/why/terminology/isolinear-wires.html</link><guid isPermaLink="false">Modeling/Why/Terminology/Isolinear Wires.md</guid><pubDate>Sat, 17 Oct 2026 20:31:32 GMT</pubDate></item><item><title><![CDATA[Tris]]></title><link>modeling/why/terminology/tris.html</link><guid isPermaLink="false">Modeling/Why/Terminology/Tris.md</guid><pubDate>Sat, 17 Oct 2026 20:30:47 GMT</pubDate></item><item><title><![CDATA[Quads]]></title><link>modeling/why/terminology/quads.html</link><guid isPermaLink="false">Modeling/Why/Terminology/Quads.md</guid><pubDate>Sat, 17 Oct 2026 20:30:41 GMT</pubDate></item><item><title><![CDATA[Edges]]></title><description><![CDATA[Edges are the roads that verts can travel on.]]></description><link>modeling/why/terminology/edges.html</link><guid isPermaLink="false">Modeling/Why/Terminology/Edges.md</guid><pubDate>Sat, 17 Oct 2026 20:29:56 GMT</pubDate></item><item><title><![CDATA[Surface Density]]></title><link>modeling/how/surface-density.html</link><guid isPermaLink="false">Modeling/How/Surface Density.md</guid><pubDate>Mon, 05 Oct 2026 03:31:45 GMT</pubDate></item><item><title><![CDATA[Curvature]]></title><link>modeling/how/curvature.html</link><guid isPermaLink="false">Modeling/How/Curvature.md</guid><pubDate>Mon, 05 Oct 2026 03:30:20 GMT</pubDate></item><item><title><![CDATA[Flow Reroutes]]></title><link>modeling/how/flow-reroutes.html</link><guid isPermaLink="false">Modeling/How/Flow Reroutes.md</guid><pubDate>Mon, 05 Oct 2026 03:25:49 GMT</pubDate></item><item><title><![CDATA[Termination]]></title><link>modeling/how/termination.html</link><guid isPermaLink="false">Modeling/How/Termination.md</guid><pubDate>Mon, 05 Oct 2026 03:25:22 GMT</pubDate></item><item><title><![CDATA[Terminology]]></title><link>modeling/why/terminology.html</link><guid isPermaLink="false">Modeling/Why/Terminology.md</guid><pubDate>Mon, 05 Oct 2026 03:20:58 GMT</pubDate></item><item><title><![CDATA[Exercises]]></title><link>modeling/how/exercises.html</link><guid isPermaLink="false">Modeling/How/Exercises.md</guid><pubDate>Mon, 05 Oct 2026 03:19:30 GMT</pubDate></item><item><title><![CDATA[Assessing Goals]]></title><link>modeling/how/assessing-goals.html</link><guid isPermaLink="false">Modeling/How/Assessing Goals.md</guid><pubDate>Mon, 05 Oct 2026 03:18:57 GMT</pubDate></item><item><title><![CDATA[Modeling for Context]]></title><link>modeling/why/modeling-for-context.html</link><guid isPermaLink="false">Modeling/Why/Modeling for Context.md</guid><pubDate>Mon, 05 Oct 2026 03:12:12 GMT</pubDate></item><item><title><![CDATA[Core Mechanics]]></title><description><![CDATA[There are a few primary mechanics you need to learn about to master subdiv modeling. They all feed into each other and it can be a bit of a mind warp to try and think about them all the time, but the good news is you don't need to. They only matter when trying to problem solve or plan approaches to complex curvature.The best way I can explain subdiv is by thinking of edges as rubber bands tied to movable pegs (verts) and they are all trying to equalize themselves. The longer ones pull harder, and the more edges around the pole that are the same or similar length, the more stable that pole is. So say you have 5 edges on a pole where 4 of them are the same length. If the 5th one is longer, the vert is going to only move along that long edge because the others are pulling with equal strength.in order to work with poles on curves, you focus on the primary curvature goal, identify which edge you need the vert to move along the most to not upset the curvature, and which edges should be used to stabilize. If you need the pole to not move at all, you need to focus on using equal edge lengths.]]></description><link>modeling/why/core-mechanics.html</link><guid isPermaLink="false">Modeling/Why/Core Mechanics.md</guid><pubDate>Mon, 05 Oct 2026 02:43:14 GMT</pubDate></item><item><title><![CDATA[Fencing]]></title><link>modeling/how/fencing.html</link><guid isPermaLink="false">Modeling/How/Fencing.md</guid><pubDate>Mon, 05 Oct 2026 02:38:16 GMT</pubDate></item><item><title><![CDATA[Situational Awareness]]></title><link>modeling/why/situational-awareness.html</link><guid isPermaLink="false">Modeling/Why/Situational Awareness.md</guid><pubDate>Mon, 05 Oct 2026 02:37:52 GMT</pubDate></item><item><title><![CDATA[Ngons]]></title><link>modeling/why/terminology/ngons.html</link><guid isPermaLink="false">Modeling/Why/Terminology/Ngons.md</guid><pubDate>Thu, 11 Apr 2024 16:04:12 GMT</pubDate></item><item><title><![CDATA[VA_thumb]]></title><description><![CDATA[<img src="media/va_thumb.png" target="_self">]]></description><link>media/va_thumb.html</link><guid isPermaLink="false">media/VA_thumb.png</guid><pubDate>Thu, 11 Apr 2024 15:13:08 GMT</pubDate><enclosure url="media/va_thumb.png" length="0" type="image/png"/><content:encoded>&lt;figure&gt;&lt;img src=&quot;media/va_thumb.png&quot;&gt;&lt;/figure&gt;</content:encoded></item><item><title><![CDATA[VA_banner]]></title><description><![CDATA[<img src="media/va_banner.png" target="_self">]]></description><link>media/va_banner.html</link><guid isPermaLink="false">media/VA_banner.png</guid><pubDate>Thu, 11 Apr 2024 15:09:48 GMT</pubDate><enclosure url="media/va_banner.png" length="0" type="image/png"/><content:encoded>&lt;figure&gt;&lt;img src=&quot;media/va_banner.png&quot;&gt;&lt;/figure&gt;</content:encoded></item></channel></rss>