More sneak preview, for the people not following the twitter account (why not?)
Before:
After:
The new 1.2 alpha build that has gone up on the store fronts (for 4.10 only at the moment, since that seems to be the major usage target) now contains the automatic smoothing group generation and normal calculation for all brush meshes teased above, with user tweakable smoothing angle (defaulting to 60) - which can be turned off to still use the old flatter, faster normal calculation.
This is also the first try at a OSX version of the plugin, so feedback on that is appreciated.
Before:
After: (with lower lightmap res and preview lighting build)
Looking sick.
What an amazing tool, you guys.
Nice!
Btw, how do you minimize draw calls? With so many meshes and materials I would imagine drawcalls count is high.
Any updates for Doom 3?
I requested that GSC patchs because are in ID Tech, Source and IW Engines too and are pretty useful to create detailed terrain and walls, I requested too GSC brush with visible faces. But looks like Epic Games don’t have plans to make nothing (Requested near to 2 years ago)
Same deal as any UE4 map built out of static meshes really - you save calls by consolidating meshes or culling strategically. Of course, with HammUEr it’s trivial to make any number of brushes import as a single mesh, at which point the tradeoff is between draw calls and accuracy of occlusion.
What do you mean by “consolidating meshes” ? Merge actors? If so, does it merge materials from merged actors into one material?
If you merge brushes on import, doesn’t it create a multi-material mesh? (I tried importing single FBX mesh with several materials on it and UE4 didn’t like that, because it would have to redraw mesh as many times as many materials are on it)
Right, merge meshes or just design in a way that you don’t use that many in the first place. But no, merging actors doesn’t usually merge materials (there is an option for that in UE4’s actor merging thing but I’m not sure how well it works), and yeah, HammUEr will create a multi-material mesh when importing a brush group/entity with multiple materials on it, so that’ll be as many draw calls as materials + 1 for the mesh. This isn’t a HammUEr-specific issue though 
This tool is an absolute blast to work with!
It allows some of the ease of use from Hammer’s brushes, and the power and flexibility of Unreal Engine!
Thanks to this tool we’ve been able to work on Portal Stories: VR. A brand new Portal Stories experience, designed for the HTC Vive!
Here some screenshots:
Niiice! How are you doing your portals?
We’re not actually using Portals, we’re using another mechanism that’s a bit more VR-friendly!
Ah, cool. I have a Vive, happy to test it out for you 
Sure, we got a bit more work to do, but I’ll PM you a key as soon as it’s ready for testing 
Patches are bloody annoying things.
That’s why I suggested to use .proc instead of .map - .proc is a collection of UV-mapped meshes. No brushes, no patches. Just triangles. Doom 3 loads .proc for geometry and loads .map for entities (actors/pawns/lights).
Better yet, all map models ( func_static in .map) can be flagged as “inlined” and map can be recompiled in Doom 3, which will embed all .ASE and .LWO models into .proc file. So not only you’d import map’s geometry, but you also import all decorative meshes (static meshes in UE4 terms) into UE4.
proc loading has been done for ages, before you even suggested it (not in live builds tho).
They’re limited and miss a lot of things that are only in the map file - quite a few entities for example, so I can’t “just” use them.
Also, you know, I need to get patches working anyway if I want to load q3 maps.
Like I said (I guess I edited my previous post after you already posted this one), .proc contains processed geometry. Brushes, patches, inlined static models, decals, on surface GUIs are all converted into UV mapped meshes and saved into .proc. I am not sure why you need entities from Doom 3 in UE4 - there is no code supporting them, so none of the entities are of use, except maybe lights and sounds, maybe trigger volumes. The rest is useless.
If you have questions about Doom 3 mapping, please ask away
The whole concept is to make a map in NetRadiant (or use original Doom 3 maps), compile it in Doom 3, then load up all geometry from .proc to UE4, pull lights (and maybe sounds) from .map and do the rest in UE4. I don’t see how it’s even possible or useful to get entities from .map to UE4. I don’t even think lights should be pulled because Doom 3 lights are soooo vastly different from any other game’s lights (they are projected textures with Z falloff texture). So even if you place standard point light in UE4 into the same origin as Doom 3’s light, you won’t get lighting even close to Doom 3.
For the official campaign maps at least, there is a lot of “entity” brushwork (and almost all models) that is missing from the proc files, so…
Anyway, new 4.10 test build up that merges vertices on smooth for the classic importers, and I’ve also toggled the proc loader to be compiled into the public build, so you can test it out if you want.
Note that it’s not hooked up to the material replacer code and just does a straight one-click run, so if there’s referenced materials it can’t find, you get this baked into your meshes.
(this is what’s cooked into the start map, for example. Notice how much there’s missing.)
Aha, looking good!
I inlined as many static meshes as I could for d3dm1: https://drive.google.com/open?id=0BwE6dxM0O2PsU20xdTZYSHF5bU0 Please give it a try.
I was also thinking maybe it makes sense to load .cm as collision mesh and give it per polygon collisions in UE4 or if it makes more sense to load brushes from .map and turn them into collision primitives. What do you think ? (or have an option to do either of them - for PC collision hull should be fine, but for mobile collision primitives would be better maybe?)
Btw, why are some textures mission on the second pic? (that curves patch on the floor most likely was used as a decal)
It crashed the loader because your area31 has 0 surfaces, something which I didn’t account for because who would do such a thing? 
Better, but it’s still got holes, all the white stuff is missing, and on the left you can see part of the world through it.
(ignore the worldgrid textured stuff, I haven’t reimported the materials yet)
To show what would happen if materials couldn’t be found, I deleted a couple of dirs in the content browser.