Well, i suspect empty areas could form when map compiler removes degenerated triangles. I’ll check those white “curls” - could be missing models, could be special materials.
Alright, I investigated these curlies and those are missing faces of the second material:
Basically a lot of static models in Doom 3 have 2 materials (each applied to their own faces) and vertex color, which determines what material is to show through (so let’s say white color is material 1 and black is material 2, and anything grayscale between those edge cases will result with smooth blending between material 1 and 2).
I’ve been thinking about it and I wonder if Doom 3 map compiler strips those triangles… Gotta try loading map without that mesh to see how that works in Doom 3.
Alternatively (as an import option), maybe it would be easy to make HammUEr import FBX models? (for example if entity has “model” key with either ASE or LWO model, it would try loading FBX model instead; it would be up to designer to convert LWO and ASE to FBX) I guess it’s just more mess. I hope I can figure out if those faces are missing in .proc in original Doom 3.
Probably.
I’m just reading what’s in there and showing it.
If it was a missing texture issue, it’d show up as a worldgrid material.
Speaking of which, I checked to see which ones were missing, and kinda like I expected, it’s mostly stuff that doesn’t use a set texture (entitygui, flare, etc), so I’m switching the code to just drop unknown materials and output a warning to the output log.
That’s planned yes, just like is already happening with the Source importer.
Also on the todo list are LWO/ASE/MD5 loaders.
Ah, well, if you plan on importing LWO/ASE and MD5, then it’s awesome! 
I probably wouldn’t worry about MD5 too much right now, since if someone makes a map for UE4 in Radiant, (s)he won’t use MD5 and would most likely simply export animated model into FBX instead (there is only one working MD5 exporter, and at one point it will be obsolete).
For source engine mapping, Will you be adding support for func_instance?
Like say you brush out a window and make it a func_instance then paste it around your map; couldn’t you make the instance into one mesh then handle it like a prop on import?
Does this still require you to manually extract all vtfs and .mdl files?
@: I am going to try and build Doom 3 map with my Doom3BFG engine fork. We had some fixes for map compiler and embedding done, so I am sure there was no missing faces/vertices in .proc file. I will upload .proc if I manage to compile stock Doom 3 maps.
From the .vpks or .gcfs? Yeah.
I guess being able to tell it to just pull everything it can out of a vpk would be good… but then you hit the problem of Valve having extremely haphazardly divided all the content into a bunch of different vpks in different folders now.
VTFs and VMTs in different VPKs. World gone mad.
Does HammUer take into consideration .vmts? Also, when it comes to .vpk there is the main .vpk that handles the structure for the rest.
Yeah, even accounting for that, though - VTFs and VMTs are in two different vpk sets.
And yes, HammUEr can read VMTs and import only the textures referenced therein, and create instanced materials with all the textures in the correct basecolor, normal and spec slots (which you specify).
It also sets blend mode based on whether the vmt was $translucent or not, or was a decal. So for instance, in the HL2 Ep2 map port below, I didn’t have to do anything to get the tree leaves masked like that; it just worked!
@: please give this .proc a spin https://drive.google.com/open?id=0BwE6dxM0O2PsVVFUTG1ENm9scTQ
Yes, and it’ll probably stay that way.
After all texture format types are read, materials are built for every VMT (and MTR) that was found during import, after which you’ll be given an option to build materials per texture (which is the default if there’s no VMTs in the import and which you can probably safely ignore most of the time).
It’s worse, actually. (compare first image with the previous post, notice the new gap)
Are all those floating white cubes baked in lights or something?
Ha, I have no idea 
I guess best way is to just import actual static models
It’s your .proc creator 
There is no proc creator. It’s a dmap, map compiler. So whether it’s original or modified original, it loses geometry (from multumaterial meshes primarily). Apparently the modified one does even more weird things.
Technically, people who will be using Radiant won’t even have .proc file. All they will have is .map, and static models most likely.
Which is why I’ve got the in progress .map importer too (cursed patches), which will also import models and the like.
You thought it might be easier with the .proc files, so I figured what the hell, but it’s not that easy after all.
New build up, with a few bugfixes, extra MDL TF2 types and a new “round accepted points to integer” option that’s less aggressive than the one that’s already there and should help take care of the little “gaps” that can appear between mesh and polys under certain conditions in UE.
Btw, one thing I wanted to ask but kept forgetting - when one builds geometry in UE4 (Build button), does engine remove faces that won’t be visible to player? (backfaces)
Faces are only removed if they use a material marked nodraw, since there’s no way for the plugin to know what will and won’t be visible.
read that wrong.
Don’t think so.
I meant when level is being compiled by UE4, does the engine (map compiler?) remove those?
The easiest way to check is to run cmd that draws triangles in the view, if UE4 has one.