Do quads matter when detaching to element?

Chase

I'm constructing a modular window piece, but am building it in pieces and attaching them as a whole. Does it matter that the verts don't form quads this way like they would need to be if I made the window as one solid mesh? I've gotten use to make the model as one whole piece so this is uncharted territory for me.

Here's the element I've attached.


But here are the verts that aren't creating quads with the rest of the mesh

Meteora

Judging from what I'm seeing, it should not matter. As long the pointed verts aren't directly affecting the faces of the windows, that should be a quad. If you somehow seemingly attached the verts to the edge to form a n-gon, then you should undo what you just did.

Combining two objects is simply a matter of telling the computer "this is one object". Unless there's something else I don't understand from Max or what you're describing, as long as there isn't any n-gon formed it should be fine.

I apologize in advance if I didn't quite understand your question or answered sufficiently. For all I know I may be wrong.

Chase

Yeah attaching different meshes together is what I was wondering. I was just trying to apply it to my specific model. Depending on the model if you make its components out of different elements it's easier to build. This much I know. I've never gone that route so when it came down to attaching each component I was a little confused since there ended up being verts that would lead to ngons. If I build this whole mesh as one element then technically these ngons would be welded. But there are certainly tones of examples where you would want to make pieces separately and then just attach them together. Especially when it comes down to the unwrapping/texturing phase. The ngons are what I'm still confused about since I've always seen that you don't want to have them in your model.

Meteora

Sorry if this offends your intelligence, let me explain to you why its fine, in a simple example.



You may need to open the gif in a new tab, it doesn't cycle here on Polycount for me.

In the example above, there are two separate cubes. I selected both of them and combined them into one solid mesh. However, this doesn't suddenly make the face on the bottom cube a N-gon. As long as you don't attach the verts to a edge and make it an N-gon or whatever else method you may do, combining two or more objects will not generate N-gons on their own.

You will notice that when I pull the face downwards that its not attached to the upper cube and the face is still in tact as a quad.

Now on unrelated notes about N-gons, there are some certain situations where you actually may need an N-gon, specifically the Pentagon (5 sides). This usually involves doing Sub-D modelling. Its used strategically and I don't have much experience in Sud-D modelling to make a comment on when to use it. But the general rule of thumb is no N-gons for video game art.

s6

What is the model going to be for? if your sub dividing, this will not end well. Once welded (or before) you will have to run 4 loops(1 for each edge you have ending in the middle of a segment) down and around the cross section to create all quads.

If its a low poly game model, You should have less geo than is here, and probably stay away from floating intersections and ngons. That not to say you can't get away with either, But they aren't common practices from what I've seen. if its the same object irl, its generally the same object in low poly geo.

If this is just sub object modeling for a render, it should be fine as long as you don't need to have shading between the bottom (horizontal) piece and the vertical piece.

Would you mind post a picture of the entire model? It sounds a bit like you may be over complicating the modeling as well but maybe that's just how it sounds. I often model things in separate parts, Then weld. but they are general more complex shapes.


Edit: if you're subdividing, you want something along these lines. If its just a blockout or for a render or something, The above will work fine. Delete the face underneath the top cube, even. Just to be picky

Chase

That definitely helps Meteora. I think it was a little more confusing then it needed to be cause I have my model fully optimized in terms of deleting unnecessary faces.

s620ex1 - I should probably fill you in on the back story of what me and the guy I'm working on this with are trying to accomplish. I'm doing the block out of an abandoned school so I've been working on one building at a time. Initially my model was too blocky looking with all the extrusions I made. Also, my window was modeled as one whole mesh. That's what I've been use to, but that's not a preferred way of modeling nor is it the most vert friend I'm finding out.

Here's the model


Here's the wires


My partner recommended for me to get a more visually appealing model that would read better in game I should apply 1 smoothing group to the whole model while adding support loops to control the smoothing/shading. This would be instead of subdividing and baking. The reason we aren't subdividing is because we're using UDK and from what we've gathered in the Handplane thread UDK doesn't like the smoothing from normal maps. By no means am I an expert. So we opted for a higher polycount vs bad shading. Anyways, the 1 sg does the exact same that turbosmoothing would do just without the texture but a little bit more cost in verts. I have to optimize the edge loops I put in most definitely, but this is the stage I'm at.

That brought me to detaching and reattaching elements. Because we're smoothing the entire model we then need to detach some components so that the smoothing looks good. Here's how I broke things apart. The model on the far right...


This is how the smoothing looks with the detached parts in specific area with 1 sg/edge loops


This is what it looks like when the parts are welded with 1 sg/edge loops


This isn't a problem if I just use multiple sg's


But it looks pretty blah just doing this now compared to the other method. I've never seen a model purely smoothed using this 1 sg method or turbosmoothed to have a more beveled look, but it certainly reads better. Hopefully that all makes sense. I know it's pretty image heavy

s6

Yeah. Your intent makes sense, But I can't speak to whether or not there is logic to it. I'm curious, Are you guys planning on going completely texture-less? Only procedurally generated materials? or will you still have Diffuse, Specular, Possible mask textures?

Should be an interesting turn out, to say the least.

small crit on the geometry would be stuff like this:

Chase

There's no wasted verts there if you're thinking there are faces underneath. Check out the 3rd pic I posted of the parts moved out. Yep we're going with the diffuse, spec, etc with dynamic lighting. Were designing the level based on pc performance. I'm trying to get this model done cause I have the blockout of the main school building laid out. I just need to replace the simplistic window meshes with these. I'm also missing vents and other window pieces I forgot to include in the image so there's a little more to the overall shape.

Like I mentioned I'm use to using multiple sg vs just one. Its been a little difficult wrapping my head around the idea that edge loops kinda act like a sg if that makes sense. Can't wait to start modelling more complex shapes cause I really need the practice. Can't do the boxy shapes anymore

s6

It cost vertices to cut a hole in the middle of that cross piece, where the vertical portion intersects with it. You could just run the same face all the way through there and have no hole, right? same with the end. You are using verts to match the profile of the frame it meets, when you could just run the faces into each other. Maybe I'm missing something here, or that interferes with smoothing maybe...

Chase

I see what you mean. Yeah, that was just a product of detaching from the middle frame. So inititially there wasnt a gap. Still getting use to attaching pieces. I think its have everything the same material color cause then it looks like the verts need to be connected ya know.. Also, as a whole we're trying not to waste texture space either, but this would be such a small space I'm sure it wouldn't be that big of a deal.


What'd you mean by you don't know if there is logic to it? Do you not normally smooth your models in this way or normal mapping?

Meteora

s620ex1 wrote: »

If its a low poly game model, You should have less geo than is here, and probably stay away from floating intersections and ngons. That not to say you can't get away with either, But they aren't common practices from what I've seen. if its the same object irl, its generally the same object in low poly geo.

I'm curious, why is this practice not common? I was taught that it should be fine to have floating intersections/objects like in my example, or that the object would be running/crashing through another object. I can't really see the advantages, unless you were doing Sub-D or planning to smooth the mesh like what Chase is doing.

I'm having a little bit of a hard time following the posts, but I'm going to guess its better if there wasn't a hole, because as s620ex1 explained, you're introducing additional verts just for the hole. Unless those verts are welded there's no reason for the gap to be there.

But hey what do I know, I only recently graduated from my school.

Obscura

So. I am his partner, and let me explain why and how everything will works. Because of the problems with baked meshes in udk( we know there are methods to reduce the artifacts but they cant be 100% fixed) we try a new approach to have smooth looking. We will make supported but optimized meshes (everything will be welded except the two supportloops next to the edges). A few smaller detail (like screws, surface detail,small extrudations,etc) will be still normalmapped. Like on this (this is just an example, we will make more details from the another textures and sometimes from some zbrushed stuff):

We make the supported lowpoly mesh, and we make a palette from the small details like the extrudations and we bake it to a plane.Then we make an empty purple normalmap in ps and copy the previously baked details to it. We make diffuse/spec and gloss, and possibly masks for a few mesh and we make an another normalmap from the modified diffuse/spec, and we copy this too to the normalmap of the mesh. We know that a totally baked, totally optimized mesh would be more optimized, but hey, its for pc specs and pcs can easily handle this. Also, we are going to make lods. We use these supported meshed only for lod0. We will remove every support edge for the lod1, and we will use smoothing groups on it. The lod level changing will be set to the furthest distance where you can see the smooth edges first. So the supported meshes will be displayed only from close.

Differences between the usual way and this:

This method:
Pros:

- Smooth edges all the time in all engines
- Impossible to get bad shading, if you are supporting the mesh in the way how you would support a highpoly mesh.
- Dont need to make two mesh for everything (you dont need to make a subdivided highpoly, just for the floating details that you want to add to the supported mesh later.)
- Can be RELATIVELY optimized
- Easy to make lods
- You can modify the mesh after adding a normalmap to it

Cons:

- More polygons
- Sometimes its taking time to optimize it properly

Usual way:
Pros:

- The most optimized

Cons:

- Normalmapping can be problematic with some engines
- Normalmapping with lods can be problematic
- Needs 2 complete meshes for everything
- You cant really modify the lowpoly mesh after baking and adding the normalmap to it, so you have to rebake

s6

Meteora wrote: »

I'm curious, why is this practice not common? I was taught that it should be fine to have floating intersections/objects like in my example, or that the object would be running/crashing through another object. I can't really see the advantages, unless you were doing Sub-D or planning to smooth the mesh like what Chase is doing.

I suppose I shouldn't have been quite so broad. I was referring to the traditional baking workflow, where you could eliminate this floating intersections and keep the entire outward facing portion of the frame on the same UV island, and same SG, and have less hassle on the bake. anything that can share shading i would say is better off unbroken.

Could be wrong though. Just appears from all the models I've studied, Not many do floating intersections within the same object. Meaning a bolt could and generally is floating on the side of a optics mount, But the entire optics mount is a solid piece of geometry. Because they are "Their own" objects. I see a window frame as its "own" object.

But seeing as these guys have chosen a different workflow, its neither here nor there.

@Obscura: Very. Interesting. To say the least Looking forward how this idea looks in game.