Best Of

Using support loops /single smoothing group on hard surface stuff is a terrible idea if you plan to LOD your object on the same texture maps -  you just end up with expensive LODs that look shit.

Generally speaking,  if you're going to be  close enough to notice the artefacts caused by hardening a 90 degree edge you're close enough to need geometry to represent the bevel across it

You're simply in that weird state where you already know quite a bit of technical things, are being influenced by a highly specific tool that is not "standard practice" (HardOps) ... while also lacking experience to get some perspective on things.

A few things : 

• A HardOps/Boxcutter model can look fantastic, but it will not be a "regular" game asset (in the sense that it will not be suitable for clean/regular UV and texturing). Meaning that anything that you read online about game assets and good practice to build them/bake them/texture them will not apply.

• If you want to embrace a HardOps/Boxcutter workflow (which indeed can look fantastic), you absolutely can, but you will have to forge your own path embracing all the limitations of the technique. The issue is not about tris or quads, but about what you can and cannot do with the assets. For instance you won't be able to give them subtle textured wear and tear carried by regular UVs, because clean UVs require models with each and every vertex and edge carefully crafted by hand. Which in turn means that you likely have to embrace a certain hyper clean/synthetic look (typical of HO/BC models shown without clever rendered materials) without regular UVs.

• Now all that said, you can also treat your HO/BC models as pseudo highpoly sources, and create "regular" lowpoly models (with traditional UVs) to bake them down to. But in that case you have to be ready to spend hours/days/weeks working on these models and it will likely "feel boring" in contrast to the speed of creation allowed by the boolean workflow. But on the plus side, it will make you familiar with the asset creation pipeline that any game like Doom/Fortnite/Overwatch/The Division uses (with the difference that in these projects the sources tend to be created in full highpoly rather than mediumpoly booleans). And then there's also the Wolfenstein games, in which many of the mech/weapon assets are made by relying on the Modo round edge shader (and then baked to a regular low anyways). Blender does have such a shader/node too.

The TLDR is that you have two paths : either embracing "non-regular" assets with all their limitations (HO/BC), or, finding ways to make them work within a regular pipeline.

The answer lies probably somewhere in between with some clever compromises, but to find that you will likely need to master the regular baked workflow first. So in a way, in the context of a game art career the HO/BC workflow can add some confusing friction to an already complex topic.

If anything I'd recommend a completely different approach, which I notice is being used by Nintendo with great success. That is to say : modelling very clean "traditional" lowpoly assets (with expertly crafted geometry, hard edges where needed, and so on) with all the needed primary and secondary details, which takes longer to create than using a bruteforce boolean workflow but still 10x faster than highpoly+retopo+baking. And then texturing them traditionally, adding bump/normalmap details where needed, and so on. In my opinion this is 100% the best compromise, as shown in the Metroid Prime games, Smash4, Labo. With a bit of elbow grease you might be able to start from your HO/BC models, spend a day to merge verts/redirect edge flow/do all kinds of cleanup, and unwrap/texture such models in a regular way.

Good luck !

On a different topic : after years of writing off the Blender implementation of Metaballs as unusable because of the seemingly non-sensical way it handles negative shapes (as opposed to how other software does it), I've finally made sense of it. Nothing in the UI suggests it : Blender metaballs have a concept of "stacked value", using hidden positive and negative numbers and resulting in a behavior quite differently from that of Booleans.

- If two positive Metaballs objects overlap, the common volume hidden inside the resulting volume (which would be called the intersection in Boolean terms) is now a "double positive".
- When a Metaball gets set as "negative" in the Metaball properies panel, it is set as "single negative". You see where this is going ...
- ... this means that bringing a subtractive Metaball over two positively blended Metaballs will *not* remove the volume where the two original volumes intersect.
- To get rid of it, the subtractive Metaball needs to be duplicated, for the resulting negative volume to reach a value of -2.

Like so : 





I for sure have never ever seen this explained anywhere, and I don't think this is self evident to anyone - and this unusual behavior (compared to other Metaball systems relying on an outliner/relationship tree) is what led me to write off this tool as unpredictable originally.
I hope this helps !