@sacboi I am planning to do two sets of renders, the 'skinned' one will be a bit more stylised and is a bit of an opportunity to play around a little bit.
This is what i'm looking at for the main renders.
I have cooled it a little bit in post-process, and I've had to tweak the saturation a bit to compensate for the colour-space curse. I am wondering if this is too dark of a tone, and that maybe I should brighten things up - although the deep contrast is nice at the moment.
And for the skinned version. Background is very WIP at the moment, although I want to set a bombastic kind of tone.
Thanks!
Lots of examples and some good advice in this thread.
There's a few different topology layouts that can work well for this kind of shape and a lot of different ways to approach the modeling part of the process. If the project requires subdivision modeling and the goal is to have sharp corners, while also using the minimum amount of geometry required to hold the shapes, then what's already been said about using the existing geometry as support and offsetting the intersecting shapes is good advice. It's also important to preserve as much of the shape accuracy as possible, since any unintentional deformations in the base mesh will tend to carry over into the subdivided model.
Below is an example of what this could look like. This simple topology layout can support some very sharp edges without generating any major smoothing artifacts. It's also worth noting that, after a certain point, there's diminishing returns on edge sharpness in the high poly. With baked normals the sharpness of the details is generally constrained by the size of the textures. Once the edges of the high poly drop below a couple pixels in size there's very little information for the bake to capture.
Here's a close up of the topology routing in the corners. Any abrupt changes in the edge loops that define the shapes is limited to the transitional area around the shape intersection. In the first row: the highlighted edges are used to control the relative sharpness of the rectangular shape. In the second row: sharpness of the shape intersection is controlled by the highlighted edge on the rectangle's side of the shape intersection. This helps preserve the shape accuracy of the larger cylinder and helps constrain any potential smoothing issues to the flat areas on the intersecting shape.
Here's what the shapes look like when viewed from glancing angles. The shaded subdivision preview can be used to evaluate the surface quality.
Here's another set of shaded subdivision previews. When working with lower density base meshes, it may be necessary to adjust the position of certain support loop segments to counteract undesired corner edge smoothing stresses. It's generally preferable to do this in a way that maintains the shape accuracy of the base mesh geometry but it's sometimes necessary to move a small portion of an edge loop out of alignment to control for smoothing behavior when the subdivision is applied. As long as the base geometry is relatively consistent and subdivides without creating visible artifacts then this type of subtle adjustment is generally a non-issue.
As far as modeling processes go, provided the individual operations don't cause any undesired deformation of the shapes, there's very little practical difference [in the final product] when comparing a boolean union style processes with an inset and extrude process. One is just a bit quicker and cleaner.
Extruding directly off the existing geometry of certain shapes can lead to unintended surface deformation and loop routing issues. Which is why this modeling strategy can be problematic for certain types of subdivision modeling tasks. That said, there still are certain situations where it can work well on subdivision models. It just comes down to whether or not the tradeoff between shape accuracy and modeling time makes sense for the project.
A more in-depth write up on topology and shape accuracy can be found here: https://polycount.com/discussion/comment/2746328/#Comment_2746328
The majority of 3D artists make this mistake. A lot can be said for what kind of geometry to use in this situation, but the fundamental problem is straightforward:
You fell for the temptation to simply extrude the quads straight off of the cylinder. As a consequence, your transition geometry (the part going from cylinder to box) is the size of one of the segments of the cylinder. If you simply offset the extrusion you can hide the transition shading errors in smaller geometry.
In sub-division modeling you are bound to get shading errors. That's sub-d. The trick is knowing where to place them.
Left: Transition geometry is large polygons
Right: Transition geometry is small polygons
They both have shading errors, but the ones on the right are less visible simply because they are smaller,
When people do not understand this principle, they end up adding an unmanageable amount of sements to their cylinder (or whatever shape), which technically works because it has the effect of limiting the affected area. Here the area is limited without adding segments, It is exactly the same add adding a ton of segments, without adding a ton of segments.
Hey guys,
I'm glad to share with you my latest one.
here you'll find my portfolio:https://www.artstation.com/wisegold
C&C are always welcome.
"That's all folks" 🤘
Take care
its very rare that being 100% dogmatic is the best approach
your uvs want to look something like this (but not crudely drawn with a mouse while eating soup)
Some updates, I will start now to work on the Sculpt of the portal
So... much... dust!
It's been forever since I posted on Polycount, which is a shame. But It's a new year and time for a new project, and to help keep myself honest I thought it would be good to start a thread here on Polycount to track my progress on my next character project.
This adorable dude is Parson, the Delivery Snowman! The concept art is by Nicholas Kole, who was gracious enough to grant me permission to take a crack at modeling and texturing this guy.
I'll be posting here as I make progress. More to come soon!