Timmy

Are you using cmake or the project generator to create the build files?

Yep that sounds right, i would uninstall the old 2009 DirectX SDK though just in case. Older T3D versions will work fine with the 2010 DIrectX SDK too.

Yeah unfortunately for now D3D9 uses the old deprecated D3Dx stuff that MS got rid off so we need to link to the old (again deprecated) DirectX SDK. You need the last version of that which was the June 2010 one. You can find that here https://www.microsoft.com/en-au/download/details.aspx?id=6812 . I have a new branch i am working on that corrects all this (actually removes D3D9 to be exact) but this will be introduced with T3D 4.0. For now unfortunately you have to put up with a lot of annoying compiler warnings. There is little documentation on all of this because 3.9 hasn't been officially released yet and we will be adding further docs when it is.

The better look you are seeing with the textures is the proper gamma correction introduced with 3.9. Anyways onto your dx11 linker errors, what version of the DirectX SDK are you using there paul?

welcome to the forums spam bot

Yeah when james was coding it all up, oculus guys decided to change the api again. Whoever is in charge of the dev sdk should be sacked. Anyway he has since turned his attention to OpenVR, will have to wait for him to comment and see if he has any plans to keep up with the oculus sdk.

The hard part with the dx11 roll in is that it happened at the same time as deferred shading roll in, so there are changes completely unrelated to dx11 going on. This will all be addressed properly(documentation) once 3.9 goes "live". Unfortunately at this stage the old dx sdk is required. I do have another branch that i'm working on now that has dx9 removed and is where i'll be putting other gfx related improvements in, stuff like dx11 speed improvements, new shadow filter, new texture formats and other things along those lines. I'll post a link when it's a bit more stable and ready, most of it will be found it 4.0 though.

The PBR change over is more than just adjusting roughness and metalness. There is also the need to change all your diffuse textures if you want to get good results.

Thanks a lot! I shall play around with it. :mrgreen: Not much has been done on that branch yet, still designing all the new constant buffer stuff which is going to take a little bit, until that goes in dx11 will lag behind dx9 on pure speed. Hopefully i finish in time for 3.9 release but if not it won't be too far behind. Having said that, dx11 is definitely in a working state though.

@TorqueFan ok sweet glad it's working, i sent an official PR for those fixes. Ok now to the detail maps, go grab a coffee or something because i have to blabber a bit to explain this one. This is not just aimed at you torquefan, it's more a general post about it because this topic will come up once 3.9 is officially released for sure, The detail maps are greyscale(luminance) images that have values from 0-255 (0.0f -1.0f if using that scale). In the shader these textures are brought from 0.0f -> 1.0f range into -1.0f -> 1.0f range. This has always happened in T3D, so nothing new here. The reason it is brought into that -1.0 -> 1.0 range is so you get a chance as an artist to either have that detail map darken or brighten the diffuse texture. So a pixel value of 128(approx) will now be mapped to 0 (it won't brighten or darken anything). Previously this was hidden a lot because the blending etc was done in the wrong space and you could get away with really dark detail maps and it would look ok, not anymore. I won't get into the new linear workflow,i'll keep this about the detail maps but this is a good read on the subject http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html. Back to detail maps and few examples to show what i mean: Dark map (art/terrains/example/rocks1_d.png). Take note of the mean, it's fairly dark and look at those black parts http://i.imgur.com/Nkjz4Rs.jpg Brighter detail map (art/terrain/example/sand_d.png) http://i.imgur.com/rFp8gS9.jpg Now if we change that sand detail map to greyscale, note the average is now 126. Pretty close to 0 once it's mapped so it won't brighten nor darken anything http://i.imgur.com/N9Q3cIO.jpg Lets see how these look in game now Rocks1_d: Horrible but not surprising when you see how dark it is above http://i.imgur.com/j2gFzvV.jpg Turn the detail strength down and better http://i.imgur.com/VU0mddq.jpg Don't mind the detail color checkbox, was just playing around to make it more friendly for people who insist on using color in their detail maps.

Check here, i will PR it once it is confirmed. https://github.com/rextimmy/Torque3D/tree/shadergenHLSL_foliage_fixes I gotta say a lot of the detail map stuff with the grass is mostly pointless because it will kill the blending but it won't crash now. *Edit: my bad it doesn't kill the blending ;) anyway should work as expected now. Also with the difference you are seeing with your detail maps, this is because the textures are now linearized by default(appropriate ones anyway), this was brought in with deferred shading.

If you see any problems with DX11, just pile them up in this thread and i'll fix as they come in ;) http://forums.torque3d.org/viewtopic.php?f=40&t=473

I have a fix for that pixel offset problem, will get that online asap. Yeah just let me know about that GroundCover @TorqueFan *Edit https://github.com/GarageGames/Torque3D/pull/1577

Cheers for the feedback. Ok first offset problem, i can reproduce this one. It is the pixel offset that DX9 uses compared to both DX11/OpenGL. Will track it down. The second problem i can't reproduce, could you perhaps try and reproduce this in stock T3D and if you can, would you mind posting the GroundCover code you used.

Yeah no worries, just remember there are other large changes sitting in devhead at the moment compared to release 3.7. The other big change is deferred shading.

I'll never say never with this sort of thing, there are so many different material combos it's difficult to test every last scenario ;). Just report anything you find, log is handy too.

Can you post a log? Both of the problems listed above work ok this end. Also is it dx11 only or does it happen with dx9/gl too?

For anyone interested the phase 2 of all this work will be here https://github.com/rextimmy/Torque3D/tree/dx11_phase2. Just be warned though, i can't guarantee it will always be stable, so treat it as experimental. No problem @TorqueFan , it was a lot of hard work but quite a few people not just myself.

PR is here https://github.com/GarageGames/Torque3D/pull/1559 I will get started on phase 2 very soon which is all about cranking up the performance, phase 1 was nothing more than just a baseline port to get things running.

https://github.com/GarageGames/Torque3D/tree/development/Engine/source/platform/threads. Just remember the renderer is not threaded so all texture/vertex/index buffer uploads to the GPU will have to happen in the main thread and same with shader compilation.

Nice work chris, an XML version would be great :mrgreen:

Just another update for this, I was telling big fat porkies above, the new beta driver doesn't fix the problem and the problem has only ever been reported on GTX 760 GPU's so far. It is actually crashing when using dxdiag to look up information in WMIVideoInfo. So i have enabled DGXI 1.1 in WMIVideoInfo, so this will cause all Windows 7 or above to use DXGI instead of dxdiag for information, those with Windows vista or less it will fall-back to using dxdiag or WMI (in that order). Fix will be included with DX11 in a few days, if you want it now the commit is here (only touches WMIVideoInfo.h/cpp) https://github.com/rextimmy/Torque3D/commit/4a15179cce1b4d19ba7d07d4778e8e69b021b20f

Just to keep this thread updated, should be an official PR for dx11 by next week. Instancing is all done, heaps of problems fixed and the port is now about 98% complete.

Just an update on this, while the above fix from anis does work perfectly (for Window 7 and later), the actual problem is an NVidia driver bug. It is fixed in the latest beta driver 364.51 so i assume that will be rolled out soon enough.

Change that line to this const S32 length = dVsprintf(buffer, sizeof(buffer), format, args);