Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Got your cohost ask.
Unfortunately asks aren't DMs, so the only way to respond to one without blasting it to the timeline is basically send back a new ask to the person if they have asks enabled.
Anyway, not relevant to your problem.

Which version of HammUEr on which version of UE4 are you using?
What kind of map format are you trying to import?
With what kind of texture sizes?

I'm guessing you don't have a repeatable repro case that I can try here, where you have a single map that has misaligned textures every time it's imported...

But yes, screenshots and map snippets would help, but if there's no repeatable thing (even if it's "every 50th time I import this file", that's fine), it's unfortunately going to be very hard for me to try and figure out what's wrong, besides "there's a sneaky error in the math, somewhere" which doesn't really narrow it down.

Sorry if I used cohost incorrectly - frankly, I've never heard of it before. Just wanted to get in touch in case you don't check in here anymore, as this is very important to my project.

I'm using HammUEr 2.2 for UE4.27.2. I create maps in Hammer++ (standard HL2 config), so I import them as vmf files.

Regarding the texture warping, I think I have it partially figured out - it seems that faces that aren't rectangles or triangles (even if they're still neat quads) have a chance of being warped to various degrees. The bigger issue is that putting different shapes next to each other can yield slight discrepancies in the texture scale/alignment, which can become increasingly obvious if they're part of, say, one big floor:


I assume this is still due to the geometry not being simple rectangles and triangles everywhere, but making everything so neat requires a lot of additional vertices, and it's unfortunate that a tradeoff like this needs to be made. Still, this is relatively minor compared to the real issue:


Sometimes, textures are just misaligned for seemingly no reason, even on simple rectangles on basic planes (slanted surfaces might make this worse, but I'm not sure). I can copy the exact same mesh to a different location, import both and get different texturing on both of them. Other times, the texture is just clearly off by a large amount:


This becomes a serious problem on small geometry (say, a 2-6 hu wide beam), where you can end up with the completely wrong part of a texture being visible.


I've checked to see if this is affected by brush grouping, texture alignment options (world/face alignment and decimals in the offset) - nope. I kind of feel like this issue has got worse over time, but I don't know what that means - is it the increasing offset from the center of the map as I build outwards? I can copy a brush that was imported correctly before to a different part of the map and get the issue there. I should also point out that my Hammer textures are just proxies and they have a different size (powers of 2, as opposed to more random values in UE - so my real UE texture may be 200x200, while the Hammer version will be 256x256), but I've tried replacing the UE textures with ones of the same size as the Hammer proxies, and the offset was the same, so I'm pretty sure it's not the conversion between sizes that's the problem.

As for import settings, my scale conversion factor is 41 and I'm not using any of the experimental or legacy options, though I have tried most of them, with no change.


The "good" news is that I most certainly can replicate the problem. I don't know what causes it, but once it's there for a face, it's there for good. I can get rid of it sometimes by changing the offset to some arbitrary different value, but that's about it. I'd like to send you a chunk of my map so you could see the examples I showed yourself, but I don't know how to do it here, as all the textures are fully custom.

Thank you for responding so promptly and I hope we can work this out - other than this one issue, this tool has been immeasurably helpful and it's just that one problem preventing it from being perfect for my needs.

Hey, no apologies necessary, not on you but on their weird design.


That looks... weird and bad, yes.
The slight texture warping has been mentioned once before years ago, so I was sort of aware it was a possibility (back then), but that was it. The completely offset stuff is definitely not intended, and needs investigation.

Feel free to send me a Cohost Ask with part of your map (or link to a google drive that has it or something if it's too big), and maybe the dimensions for the problem texture(s) so I can generate something appropriate for testing on my end.


Fair warning, my body is doing Bullshit Things again, so I can't promise anything, but I'll _try_ to take a look at it this weekend if I have your stuff.

I'll try to take a stab at it this weekend.

I've been doing some more testing and while I'm still not 100% sure about this, I think my hunch about distance from the map centre being a factor may have been correct. In parts of the map that are closer to the origin, the texture alignment seems way better. It's still a bit off on some really narrow faces, but in 90% or so of cases it looks pretty spot on.

If I copy the same textured brush to different parts of the map, then import them, it seems like the texture offset indeed gets worse the further away it is from the centre. Again, I can't confirm it with complete certainty, but I'm quite convinced this could be the source of the problem.

Sorry, I haven't really had any time to look into it much yet because of Medical Bullshit, but after some thinking (which is unfortunately all I can do right now) and asking around, you're basically right?

So the way UVs work in the older engines is that they're contiguous, which I sort of keep... but which leads to problems in Unreal, because it Does Not Like That.

The solution is apparently to go into the static meshes that have problems and check "use full precision UVs"?

(which is and absolute pain right now because there's no bulk way of doing this, but if that solves it for you, I can see about making this the default)

No problem - this is very important to me, but it is not very urgent at all. I definitely think it should be fixed, but as far as I'm concerned, there's no big hurry - so by all means, please take all the time you need. I hope your health improves soon.

I've tried the "use full precision UVs" option and yep, it fixes ALL the alignment issues I've described - including the warping, so now you can have faces of just about any shape (I haven't tested n-gons much, but all quads and tris are fine now) and everything aligns nicely between different faces and across separate meshes. As far as I can see, as long as this option is selected, the textures in UE match what you see in Hammer with absolute perfection.

Like you said, it's quite a nuisance to apply this to each mesh separately; in my case, it would be feasible, but I'd just... really rather not do it. I understand that applying this option to every single mesh would presumably have some impact on performance/memory, but I think it's absolutely worth it for me. So if you could indeed make HammUEr do this automatically during import, I'd be immensely thankful for it. Maybe it should be optional, but I'd always leave it on anyway.

Give 2.2+ a shot.

There's now an option in the Project Settings/HammUEr page to switch UVs between Default (aka half, like it usually is) or Full Precision.


Note that I had to build this with VS2022 because my machine decided to nuke itself last week (like I needed more bullshit, right?) and I had to rebuild my entire system and pipeline from scratch... but Microsoft doesn't offer non-paying VS2019 versions any longer, so I figured I'd give it a shot.

Should be fine, and Works On My Machine, but... I guess we'll see.

I've done some quick testing and it looks like everything works the way it should. Checking the new box appears to ensure that nothing is misaligned or warped anywhere. Thanks a lot for adding this and, while I will be sticking to this version, I imagine others may appreciate it if you implemented this in any future releases.

I don't want to have to do extra tedius stuff for big maps. I'm tempted to buy and use this for a upcoming project, but I would really love a few of these QOL issues resolved.
That said I haven't bought it yet, so obviously it's all talk. But I'm just speaking from a interested consumer.