Start editor go to File then to switch renders. Set it to dx11. That is it. Once you set your maps tessellation to flat that tells game that to run that map it must be in dx11. When i click on my 32 bit exe as normal and it starts a 64 bit dx11 game automatically. For the tessellation to work it must be dx11.
I am assuming beings the map has its tessellation set to flat. It automatically knows it needs dx11 , So it starts it up with 64bit dx11. Also i noticed once changed to dx11 the editor start and compiles in 64 bit dx11.
My localshader_d3d_sm5 file is huge < watch out for that, as you keep editing and adding textures it just keeps getting bigger and bigger. mines at 1.2 gig lol have to throw it out recompile all sm5 shaders 
But once you package the game and install it from fresh, are you saying it packages the Win64 folder instead of the Win32?
I doubt it will, as Win64 was never officially supported in UDK (and was only included to run the editor). I am in the process of preparing my next release to include the 64 bit files, but I’m having to manually move the necessary files via scripts after installing the packaged game.
Edit: I’ve just checked and you can still run DX11 on the 32 bit version: 
Only thing i did was activate dx11 and set tessellation to flat. Wonder why its running everything for me in 64 bit. I did not click on 64 bit exe, i clicked the 32 bit exe to start the game. Here is my shortcuts target.
C:\UDK\UDK-2014-02\Binaries\Win32\FOPB.exe < Win32 folder. I remember yesterday starting the game checking the header in windowed mode and it said 64 bit dx 11. i was shocked, as i knew i clicked the 32 bit exe. Once i get the game to work again, i will check its header in windowed mode. See what version i’m running.
I’m checking this out right now, yesterday it ran fine. Today i’m getting this error when trying to load. lol, my pak got to big. 1.2 gig :). Now i know how big i can take it before it causes me errors. I could just increase my memory on my disk but that is not the proper fix. Plus it is taking 2 to 4 minutes to compile shaders in that pak before anything will start.
[0107.09] Log: Compressing '..\..\UDKGame\Content\LocalShaderCache-
PC-D3D-SM5_save.tmp' to '..\..\UDKGame\Content\LocalShaderCache-
PC-D3D-SM5.upk'
[0107.33] Critical: appError called: Ran out of virtual memory. To prevent
this condition, you must free up more space on your primary hard disk.
[0107.33] Critical: Windows GetLastError: The system cannot find the file
specified. (2)
[0121.44] Log: === Critical error: ===
Ran out of virtual memory. To prevent this condition, you must free up
more space on your primary hard disk.
Guess it is time to figure out how i am going to store these files so my paks stay under 300mb. This is going to be a pain to keep them under 300mb. Will have 1 map, 1 pak for its art, that is about all you can get into a pak with a 300 mb limit. 4k to 8k textures will eat up that much space.
Once i get game to load a map, i will check version in game. In menu it says 32 bit dx11. Yesterday i remember it saying 64 bit, which shocked me as i only have 1 shortcut on my desktop and it is 32 bit dx9.
Look at my pics with blue colored gun thats in game and its header says 32bit dx11. So it is in 32 bit when in game. Must been the other screen shots in the editor that i seen at 64 bit dx 11. You can see that in all the different pics in its header what mode its in.
I can load the editor just not the game, fixing now.
Now that i have the textures in smaller paks under 300mb and deleted local sm5 i can load the game again. You can only get about 6 4k textures in a pak before it is over 300 mb.
The precomputed volume memory stats on my maps. If i go into world settings and re enable the precomputed lighting check box so it uses static lighting that goes to basically 0 then i reenable dynamic and shut of precomputed it tests fine 1st time then after that when restart the map that stat is full on 4gb, i am starting to think this reading is fake. If i were using 4gb of memory that would crash my system and that is not happening. This reading has me baffled as to what is really gong on. One minute it full on next time its nothing. But game runs fine no crashing. Baffled at this setting. Wondering if i should just ignore it?
Edit: Here is a screenshot of that setting in precomputed lighting.
Now i will switch it back to dynamic and post those results.
In editor after i switch to dynamic lighting the stat is full on 4gb
What would you think?
This error has always been an issue for me while cooking my main map (which is 426mb). I’ve previously gotten around it by first doing a “clean and full recook” on my menu map (much smaller), and then cooking my main map. If the problem continue, I delete all my local and global shader caches, then let them recompile and then it works again.
I’ve always worried that at some point, as my map continues to grow, it would fail to cook. However I’ve recently realized that if I cook using the 64 bit executable this issue is not a problem.
I don’t think the package size being over 300mb is the problem btw. I think it is just an arbitrary value made my epic to encourage better practice managing a project with many devs when using version control like Perforce. You can even change the value at which it will warn you about package size in the .ini settings.
yeah it just takes long time to load if over 300mb. I notice when using the 64 bit for editor it wants to constantly recompile my shaders and just adding extra copies same stuff into it, just makes it over sized in no time.
Here is a pic in dynamic and its stats are at 0 did not go back up when i set it back to dynamic?
Not sure what to think pics up 2 posts show when i go back to dynamic the stat goes to 4gb. these pics are back to dynamic but are at 0 on that stat. They all started out as dynamic but with 4gb usage. What would you think?
EDIT: OK i figured it out, that last map did not convert back to dynamic. I had to recompile it in dynamic, when i did it went to full on 4gb usage. So if your maps are in static lighting that setting is nothing. If you go dynamic it just maxs out that setting for some reason. Any one have an answer for this? Seems that this setting is not true in dynamic, if it was, my machine should be going to the blue screen of death and crash. It plays fine never crashes.
Got rid of all landscape slices. will post the height_tessellation_func fix in a bit.
This will not let the landscape slice up.
Finally fixed all landscape slices. If you experience any slicing please post so it can be addressed and fixed.
That looks amazing, . I honestly had no idea UDK landscapes could do that.
Do you think you’re losing out on much market share by requiring DX11 instead of DX9? Is there a big performance difference between a tessellated DX11 landscape with WorldDisplacement and a DX9 landscape without WorldDisplacement (and maybe just a little parallax mapping or something instead)?
And I hope you can take a little criticism too… That beautiful landscape is hidden under some really ugly grass. Are you going to be changing the grass meshes soon?
Thanks, Everyone is on win10 by now and should be using a dx11 cards. It should not hurt it.
Yeah i could replace the grass. Not sure if i will have the time. I will do some test a bit later today on the differences in how each tests and post those results. Just to cover a few things i’ve seen already.
Some texture memory stats double. It is in an above post and fps only went down a bit. Now that i have better settings to mess with and not having to push the slices out of view. I can bring the tessellation in as close as i want to save fps and texture memory. Just need to find the right settings and i am pretty sure fps wont be a factor, just the texture memory usage will double if using 4k textures. Will post results this afternoon. Take me a bit to test everything,
EDIT: Just tested the height_func without the second clamp. The second clamp can be removed and deleted from the height function. Will post a pic next post a bit later, but thought i would share with those who want to just fix it now.
FINISHED HEIGHT FUNCTION FIXES LANDSCAPE SLICING
Here are some performance results from 1 map in the same spot.
No Tessellation, FPS 28.33
With tessellation at 800 distance, FPS 28.82
With tessellation at 200 distance FPS 27.43
There are 3 pics, 1 with no tess, then 2 with tess at different distances. No real difference in FPS.
1 Like
This is probably my last test, as i have to keep recompiling all my shaders for my local sm5 file. 2 pics with 4k textures and 2 with out 4k textures. the 2 without 4k are 512x512 and 1024x1024 in size.
4k_textures with tessellation on, 1st pics fps=21.69 2nd pic fps=21.10 distance set at 200
No 4k textures with tessellation on, 1st pics fps=30.80 2nd pic fps=31.96 distance set at 800
No 4k textures with tessellation on, 1st pics fps=29.45 2nd pic fps=35.07 distance set at 200
No 4k textures with tessellation off, 1st pics fps=36.48 2nd pic fps=40.80 distance set at 200
4k with tessellation to No 4k with No tessellation looks to be around 20 fps increase.
No 4k with tess on to No 4k with tess off. difference seems to be around 5 to 6 fps increase.
About a 10 to 20 fps difference. If your card is decent you should see better results then what i am showing. I am just running a geforce gtx 1050 Ti card.
Enjoy all. Have fun editing your tessellation
Here are tests from two more maps and they are coming out about the same as the last map i tested.
Tessellation is on and no 4k textures Pic 1 FPS=24.71, Pic2 fps= 26.31, Pic3 fps=27.92 distance = 800
Tessellation is off and no 4k textures Pic 1 FPS=30.01, pic2 fps= 27.68 pic3 fps=25.88
Tessellation is on and no 4k textures Pic 1 FPS=24.41, distance = 800
Tessellation is off and no 4k textures Pic 1 FPS=26.74
Figured i would post more test results from other maps before i redid my sm5 file for the last time.
Not to bad of a hit on performance if you stay with your 512x512 or 1024x1024 textures with tessellation on. But if you go 4k get ready for huge texture paks and 20 fps loss with tessellation on. Also pretty sure if you use 4k textures your sm5 file will grow over sized very fast, so you will probably have to up its limit in the engine.ini file. Enjoy and have fun tessellating.
Bit off-topic, but you should use the transmission mask on the material for your foliage. This essentially allows for light color to pass through shadowed regions and prevents the overly dark areas on the meshes.
Will look into that, thanks.
A cheap trick that I use sometimes for small vertical meshes (like grass) that I want to keep the material complexity to a minimum is giving them a normal map that treats the mesh as though it’s pointing up. I would have to dig into my files for an example, but I think you can just give your mesh’s material a normal of R=0.5, G=1.0, B=0.
Here is a few screenshots of some finished areas tessellated.
