I have a model made in blender divided into parts.
Each part has its own UV maps.
I want to do it this way because I want to assign a different material and texture to each part.
(One material for the floor, another for the ceiling, another for the wall…)
There’s no problem with the materials because I make them in Unreal and they’re infinite..
But textures need correct UV size.
So when I import the model into unreal it converges meshes.
And creates a single UV map.
I use the “LayOut” function and the UVs stop overlapping.
Now building the lights is error free.
But now the textures don’t have the correct UV coordinates and are not displayed at the correct size.
How do I fix this? What is the appropriate workflow to achieve the desired result?
I want a single mesh, I want textures with the correct size, and I don’t want problems with lighting.
Help is welcome!!
I see. i don’t understand what your problem is. sounds like you have a choice to make.
i personally wouldn’t try to optimize for drawcalls to the level that it creates issues with the workflow.
afaik if you are using different materials then there’s no such thing as “merge draw calls together”. each material is a draw-call. afaik. even on nanite.
in fact in nanite meshes that are different but have the same material have some optimizations and trigger less draw calls.
there’s also instance meshes, hsim, and auto instancing which i think you might be aware of, but good to remind them for other readers.
that does not seem to be an option from my pov. that’s why i meant you have a choice and not a problem. but i don’t know a ton about uv mapping in ue, i’d assume you know more than i do.
i have an idea though.
this is an idea:
if you are authoring those models, you can, when authoring them, position the uvs with a padded size.
so that when merged, they don’t overlap. i’d need to draw it, but i think it’s clear enough.
that probably means that your textures are going to be larger. as they all will be padded.
i don’t think you can build lightmaps with overlapping uvs. i think that’s just a limitation of the technique (not even the implementation).
afaik a lightmap is a texture, so it’s ONE texture per MESH.
since you want to have ONE MESH then your uvs can’t overlap.
ah ok, so you have multiple meshes with the same material, not just one mesh with multiple different materials. i did not get that from your first post.
check out auto instancing.
again, you might be trying to optimize beyond your options.
i’d recommend using a visualization mode to make sure our assumptions about batching and draw-calls are correct. though i would assume you’ve done that already.
are you targeting mobile or vr, so that lightmaps and performance is so important?
the only issue with autoinstancing (which afaik you don’t really need to do much to use it) is that it works for same meshes only.
but the thing is, if you can reduce DC per instance, as opposed per piece, you might still consider that as a benefit. maybe that’s an ok enough boost.
otherwise you could try my idea above, but, merge ONLY the pieces that share a material. that way you need less padding. since different materials will issue a new DC anyway.
no prob, i hope it helps. sorry i can’t give you a better answer.
good luck.
It’s a PC game (Multiplayer game). I’ve been optimizing the game for months.
I’ve learned that the game thread and the rendering thread get bugged very easily by small, seemingly insignificant things. (The sum of very small things makes a very big problem). And every nanosecond you can earn is important.
nice. me too actually, i’m quite obsessed with optimization.
imho there’s always a trade-off, and some optimizations will incur in extra workflow overhead.
also i believe by definition an optimization will create rigidness, and reduce your flexibility, since it usually leverages a specific situation. not a reason to not do it, but something to keep in mind, i think.
agree. that’s something i’ve learnt in my experience that happens in many if not all things.
no prob good luck
if your project is public i’d love to check it out.
It is not public at the moment, I hadn’t even thought about it. But maybe someday I’ll make it public. I’ll remember this post and let you know if I do.
Thank you very much for the plugin. I take a look at it.
