Thread 1020784

What do you consider best practice when it comes to vehicle modeling? Especially for games?

Do you prefer to have super clean topology and make sure everything always connects properly, or do you say fuck it and not even bother connecting tubes, framing, bolts, standoffs, and similar details and just leave them floating on the model while leaving texturing to solve the rest?

>>1020784 (OP)
Depends on the game genre. A vehicle in a racing game or in an open world don't have the same needs

Depends on what's going to be seen
and how important it is

>>1020784 (OP)
thinking you have to connect things is the hallmark of a super beg

>>1020822
Less verts = more graphic
No clipping
Pc happy

>>1020836
"Less" verts in a modeling program does not translate to less verts on export to a realtime 3d format. 3d formats, that aren't DCC formats such as .max or .blend, can't handle more than one set of vertex data (such as uvs, normals, vertex colors) per vertex. What this means is that wherever you have a uv seam - that's 2 or more actual vertices (depending on adjacent uv islands) fed to the gpu. Same goes for vertex color "seams" and split normals. The vertices are simply split on export to standard mesh formats meant for realtime. Since you're unlikely to actually merge logically separate parts of machinery on a uv level, you're not winning anything at all by merging them. You'd only do this for ease of editing the mesh and nothing more.
And there's obviously the thing where you'd have to actually cut your geometry to support "merging everything" in a manifold fashion, which would result in more gemometry than otherwise. So it's actually less efficient to merge stuff, not more.
By not merging things, you also ensure that logically separate mechanical parts have logically separate normal smoothing.
Lastly, people vastly underestimate the amount of vertex data you can stuff down a gpu, even an older one. While it doesn't mean that you should abuse it, "saving" a couple thousand verts by making geometry manifold where it doesn't need to be won't net you any real performance gains.

>>1020784 (OP)
I refuse to help poojeets learn 3d modeling.

>>1020784 (OP)
>not even bother connecting tubes, framing, bolts, standoffs, and similar details and just leave them floating on the model
For me it's this. I made pic rel and there are non-connected meshes everywhere (i.e. without merged vertices), I recommend doing things this way because you can simply "glue" pieces onto the chassis of the vehicle (for example, the ladder in the back, the frame of the awning and more) which helps should you wish to make variants: just remove some pieces and swap them out with other new pieces, which would be a problem to do if everything was "fused-in", so to speak.
Vehicles are a great candidate for non-connected meshes, unlike organic characters for example which MUST have continuous topology. Non-organic characters such as robots for instance are another example of good candidates for non-connected meshes

>>1020841
Good effortpost, you learn pretty quickly that not everything has to have connected meshes and that it's more beneficial in this case

>>1020857
The van looks like shit.

>>1020857
The van looks OK

>>1020841
>Since you're unlikely to actually merge logically separate parts of machinery on a uv level
you think i have more than one UV map?

>>1020879
You misunderstand. The issue isn't with having "more than one uv map". You can push a lot of arbitrary data per-vertex. The issue is when you have a vertex with multiple uv coordinates on the _same_ uv channel. Basically any uv seam. Or speaking more generally, when there's any difference between a vertex value on one face and a vertex value on another shared face. There can only be one vertex value _per vertex attribute_. The user-facing interface in DCCs allows this for editing convenience. But when exporting, when exporters see a discontinuity, they split the vertex into two or more. So that there is, in the uv example, only one uv coordinate per uv channel, per vertex. This happens internally in the modeling program as well, when it renders to the 3d viewport. Unless you project the model to 2d uv coordinates (which would prevent you from properly texturing anything), any closed shape (basically anything that isn't an essentially 2d plane) will need to have uv seams.

>>1020857
Disconnected meshes cannot be stripe-rendered in single call and would require either multiple rendering calls or non-stripe iteration, which in turn will require larger buffers for GPU to iterate over during rendering.

>>1020881
You can sorta cheat that by having an invisible triangle(s) connecting those mesh parts, so it shouldn't be more than two extra no-area polygons during the geometry construction phase. Generally a tool converting the model into vertex set + vertex index arrays should support that.

>>1020881
Are you talking about rendering with triangle strip calls? I dunno what you're smoking, but non-trivial/non-procedural meshes are never drawn with those. People normally render models using indexed drawing with index buffers, which do not require you to duplicate vertices for every single triangle.

>>1020884
Indexed drawing can do both triangle strip and isolated triangles, it's just the drawing mode that determines how indexes will be interpreted. In case of a triangle strip mode you can reduce the size of index array required.

>>1020885
Hmm, I guess that could work. Never heard of people resorting to that though. Sounds like you need to build your index buffers specifically for strip rendering in such a case, are there any exporters that actually do that?
Specific index array building and the downside of not being able to draw any arbitrary mesh just to save 8 bytes (-2 ints) per triangle? Maybe it's worth it in isolated cases, but I don't see much good in that. Also, how does that handle uv islands?

>>1020886
Blender gltf exporter does support that, but not the primitive restarts for true geometry disconnects, nor empty triangles to provide a bridge between disconnected geometry, or at least didn't when I last checked, so those may need to be added manually. Aside from the storage/memory, it also reduces the iteration time in geometry construction phase, which can be notable with lots of complex models. UV handling is no different from any other approach, it doesn't matter how polygon vertex was constructed when it gets to vertex shader to get attributes assigned.

>>1020887
Oh look, they added primitive restarts just recently https://github.com/KhronosGroup/glTF/pull/2478

>>1020887
>>1020888
Cool! Thanks for the info. Still doubtful on the actual performance savings since you tend to have 2 triangles for every vertex. A vertex is at least 12 bytes of position + 12 bytes of normals + 8 bytes of uv. Usually a lot more, but at least 32 bytes. And you roughly save 16 bytes for each vertex on the index buffer. I guess that's not bad. Though you don't need to reupload your index buffer every frame, only the vertex data if you do skin it. And most of your VRAM will still be textures, not vertex data. But I guess it's something that could be used.
>UV handling is no different from any other approach, it doesn't matter how polygon vertex was constructed when it gets to vertex shader to get attributes assigned.
The thing is that in any other approach, the mesh is split along UV seams because you need 2+ sets of uvs there. Though I suppose it could "remain" connected by zero area triangles while still using the doubled amount of vertices, so I guess that's not much of an issue.

>>1020841
Are you sure this applies to the Source Engine, relevant to OP's picture?

>>1020912
This applies to all realtime rendering. A vertex passed to the gpu is just a fixed set of numbers. Minimally in practice, it's: 3 position floats, 3 normal floats, 2 uv floats. You're free to add more "slots" (you can pass less as well, but that wouldn't be practical) when you're programming your engine, but you can't randomly have more "slots" in one vertex and less in another, or vice versa, in the same array. Vertices on UV seams, or any vertex data seams, need to have two sets of per-vertex data. Thus a split is unavoidable.
There are concieable ways to mitigate this, but none are practical. You could for example, store 2 uv "slots" on every single vertex and treat 0,0 as a null value, but that would require either branching in-shader or double the texture sampling and reserving the 0,0 pixel on every single texture to have all zeroes.
Importers and exporters may optionally handle this case for better DCC support. Exporters may keep the split vertices connected by additional triangles to indicate that there was a connection on export. Importers may re-merge such vertices and, for example in blender's case, re-convert the vertex data to face corner data. But that doesn't change the fact that when you're actually uploading data to the gpu, whenever you need more than one vertex value on its adjacent faces, you get that many splits.

>>1020923
You're 70% wrong. Literally

>>1020943
I'm open to corrections. Feel free to point out where I'm wrong.

>>1020880
Huh cool

>>1020784 (OP)
i prefer just painting the smaller details with height/normal alphas. box-modelling stuff down to the level of individual screws, welds and creases (though the latter can just be sculpted on and baked into the normal map) is just too much of a hassle