I also am experiencing this issue. It’s really baffling.
Hi Kurylo,
Here is the link to the public JIRA version (UE-52466); I’m sorry that I forgot to expose that and attach it to my original answer.
Our developers looked into this and made the decision not to allocate resources to fixing the HLOD issues that you are experiencing because we have some changes in the pipeline that will probably fix many, if not all of the issues that you are seeing. However we don’t have any info or a timeline that we can share at this time.
-TJ
[434]LogMeshUtilities: Error: Raw mesh is corrupt for LOD0.
[434]LogStaticMesh: Error: Failed to build static mesh. See previous line(s) for details.
[434]LogStaticMesh: Building static mesh LOD_LODActor_734…
[434]LogMeshUtilities: Error: Raw mesh is corrupt for LOD0.
[434]LogStaticMesh: Error: Failed to build static mesh. See previous line(s) for details.
They dont plan on fixing this from what i heard… may be a possible replacement for HLODs coming in the future but no word on when… At least thats the sort of response I had received…
has any replacement for HLODs now?
The new HLOD system did not fix this issue. Neither with normal merge meshes or with the new “simplify mesh”… still generates 0 poly hlod.
is it the new hlod simplify mesh in 4.19 ? Because that doesnt work either… same problem.
What version are you testing this in?
4.18.2 and the new 14.9 beta
totally forgot i also had this problem in 4.17
There have been some improvements to the HLOD system in 4.19 but the large changes that will likely fix the core issues that you are experiencing will be coming in later builds. We don’t have an exact target fix at this time.
is there even some sort of preferred work around?
Not that I have been able to find in the project you provided. Starting from scratch in a new project, I have been able to avoid any issues altogether. I suspect the reason the issue is so severe in your project is that it’s been converted through different iterations of the engine.
did you need me to send you the link again to the project in PM? Also to reitterate this problem is with actor merging tool as well…
A previous private message i sent u:
"Hey since my problem with the HLOD has to do with actor merging as well… (0 polys on generating the merged mesh…)… I was wondering if i could request a feature in the mean time…
Seems like the actor merge works and gives me the correct merged meshes error free if i put the settings to force LOD 0… rather then auto LOD…
HLOD currently does not have the setting to decide on what LOD to use… Seems like my only work around is to generate hlods with the LOD 0 setting ( which although seems lame is the only thing i can make work.)
Dont know if you have been working on my scene at all, but i kinda need some auto feature to generate all these meshes and apply them to the correct HLOD so i dont have to do it manually with the actor merge tool…"
dont think thats my issue. Triplanaring although i have some that use it… removing those does not fix it.
This was driving me up the wall for over a week and I finally solved what was causing the 0-triangle problem on my side.
CHECK YOUR MATERIALS. If you are using a material that uses triplanar texturing, HLOD generation will give up immediately upon trying to generate the merged material. If you can get one object to consistently break it, swap the material out and see if it fixes it.
I’ve found certain meshes also break the system and return 0-polygon results. If an object doesn’t have lightmap UV’s especially, or if the UVs are overlapping really badly.
Thats not the problem either… ive checked every mesh and originaly i had found 1 that had no lightmap uv, but i removed it. Problem remains. The rest of the meshes and materials are fine. No idea why… it seems like it just randomly picks out meshes in the output log to blame the error on, but when hte mesh works in 1 place and doesnt in another … something else is going on…
Just wanted to post my experience with this and hopefully it helps someone else.
We spent a number of days trying to track this down. We’d made a number of houses out of modular parts and then wanted to test HLOD with it before going too far. What we found was that some of the parts we had used were using LOD0 for HLOD0 and some were using LOD1 (or even LOD2) for HLOD0. This led to the raw mesh is corrupt error because the number of UVs in each channel didn’t always match the number of WedgeIndices. Once we adjusted the LOD screen size of LOD1 to ensure it was above our HLOD0 screen transition size the message went away.
TLDR; Ensure that the models that are in a cluster are using the same LOD level for generation. If the LOD level differs you’ll receive a corrupt mesh error message.
i really dont understand… are you saying i have to make sure lod 1 turns into lod 1 far away? Thats very stupid if its the case… and im hoping one of the developers is reading this so they can make a change already so we dont have to wait for 4.20 or 4.21 for a new hlod system.
HLOD0 should be (if I’m understanding HLOD correctly) LOD1 or greater to generate HLOD otherwise it defeats the purpose of using HLOD. If the LOD’s on your models aren’t setup correctly it will end up attempting to use mismatch levels of LOD which will result in an incorrect number of UV’s.
If you’re using the default values in your HLOD setup provided by Epic then LOD1 on all your models included in a cluster should be at 0.5 screen size in order for HLOD0 to use LOD1 to generate its merged mesh. If you want to use LOD0 to generate the merged mesh then LOD1 needs to be less than 0.315 (the default value for HLOD0) on all of your meshes in a given cluster in order to force it to use LOD0.