Jump to content

Pre-Pull Request: D3D11 Initial testing


Recommended Posts

Hey, great work everyone, wow Dx11 will really change things...

Noticed that the Oculus code in platform/input/oculusVR is still all dx9 - any chance you could take a look at porting that up too?

Am hoping to be able to make a build that uses latest oculus sdk and runtime, and a dk2, to make sure the engine is compatible moving forward with the consumer headsets. As noted in the DK2 thread, they deprecated dx9 after version 5 of the oculus sdk. And they are up to version 8 now. So, it would be awesome if that code was kept up with the other dx11 changes.

Thanks so much for all the hard work!

Link to comment
Share on other sites

  • Replies 59
  • Created
  • Last Reply

Top Posters In This Topic

I don't personally own a dk2 so i won't be able to do much here with porting it over sorry. I think JeffR does though??

Anyway with this dx11 stuff i'll be back on it next week, since the deferred shading stuff is going in first i'm going to help get that finished first and than have to merge all that with the dx11 code. So until that happens i would recommend waiting before testing this current dx11 branch any further.

Link to comment
Share on other sites

  • 4 weeks later...
  • 2 weeks later...
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.



Thanks so much for this effort. This is the expansion to T3D's API I have been waiting for. It feels really good to see this sort of initiative from the community.

Recently I've pulled my head out the sand and decided to dust off my GitHub repository. I'm finding lately that many of the source changes I've been doing could be useful to others sitting in a repository. I've even got a couple super simple pull requests I really should run by the committee. When I see this sort of initiative from my peers, it really gets me motivated to use a little free time to contribute a bit back myself. Thanks for that, Timmy =)

Anyways, I guess I just wanted to express some sort of gratitude for this work and let you know I'll be testing it fairly thoroughly soon(potentially with a few different game builds).

Link to comment
Share on other sites

  • 2 weeks later...

By all means, if you've got code you think would be worth getting into the engine, toss a PR up for it :D

Contributions are ALWAYS appreciated.


Honestly my repos are a mess. I had a couple tiny PR's ready to go, but lost them when I was updating my dev branch :( Luckily they were tiny little fixes, but I'm not entirely keen on updating a dev branch in GitHub without damaging branches I've made from it. Perhaps I could just put those changes in the forum as a resource? The first change is literally a one line change, and it's subtractive at that( comments out an existing line of code ).


I was able to get it to compile using VS2013 on Windows10 without issue. Select DX11 and use it from options menu no problems with GTX 980.

I found 2 problems right away with my main project that prevented further testing with that project:

° CRASH - When opening GuiObjectView the application would crash. I assume it's when loading the shape or animation from the shape.

° BUG - Objects don't appear to support multiple materials. All my models would render with one material and the other materials on the model rendered white.

When I get a bit more free time I have some side projects with project-specific rendering code I will test with this.

Link to comment
Share on other sites

I just took a look into it, and very quickly realized that the source of the issues was from my own merged code! My custom GuiObjectView code extends the class to support cam nodes, blend animations, and hiding/showing sub-meshes. It all works fine pre this D3D11 merge.

But there's a catch, of course : All of this stuff is hooked to new GUI's and supporting scripts for said GUI's. So it's a tad bit of work but I'd be willing to wager I'll find the culprit hiding someplace in the initialization functions for the class - either in script or source(i.e. onAdd() or initMaterials() etc.). Bottom line, though, is I am able to use the provided D3D11 branch without issue prior to merging my updates. Therein lies the quandary - now I just have to buckle down and fix it lol.

I don't believe a log will be necessary but at some point I did want to release the extended GuiObjectView code as a resource to the community. I'd definitely want my changes to be compatible with the D3D11 update =) I'll have all the changes available on a GH branch soon enough(cleaned up a bit), so if the problem persists maybe someone could identify it. Moving forward I plan on blogging and sharing about my experiences with T3D, while providing code resources and so on. It's a geeky need that simply must be fulfilled - but more on that later (soon™).

Anyhow just wanted to be sure I let you know asap about my findings. The last thing I'd want is to have you chasing ghosts :shock:

Link to comment
Share on other sites

I'll keep that in mind, although the project was sync'd with 3.8 development prior to this coming up. There are a lot of moving parts on my end that tie into this, though, so I just have to do the work.

This update is significant enough that I am keeping a build sync'd with its changes. After I pop the hood and iron out my issue I'll let you know about what went wrong for me.

Thanks again for all your efforts, and to all contributors!

Link to comment
Share on other sites


I have ported over probably 3/4 of the project now, and hope to finish by tonight or tomorrow. :geek:

Along the way, I have been pleasantly surprised to find many things working great. I know some of this isn't directly related to the D3D11 PR, but figured I'd list it all here for completeness. Here's a recap, I did find one tiny issue so far:

Tested OK with D3D11 :

  • All imported models work flawlessly. This includes multiple materials, animations, blends, you name it...D3D11 OK
  • All imported custom GUI's work flawlessly(20-ish + GUIs). This includes fading GUI's and so on that use custom rendering code...D3D11 OK (more on GuiObjectView below)
  • Entire rework of scripts dealing with customizing, connecting, and launching a new mission all work flawlessly...D3D11 OK
  • All custom terrainGen source and scripts generating flawlessly...D3D11 OK (still hooking in terrain materials this evening but the terrainGen is good)
  • Custom .mis files including many of T3D's existing classes work flawlessly...D3D11 OK


Still to Test with D3D11:

  • Full implementation of extended GuiObjectView class...PENDING
  • Finish hooking in materials for terrain, groundcover, etc...DONE
  • DragControls in drag/drop interface...DONE


One Small Issue with D3D11 found so far:

  • Added a guiProgressCtrl to a GUI and when I set the value up so the progress bar would show some progress - the progress rectangle wasn't rendered perfectly within the border of the control's extents. Not sure if anything dealing with calls to drawRect() or similar were altered but I figured I'd bring that up.


About extending GuiObjectView class:

Basically prior to D3D11 I had 4 features added to the GuiObjectView class so I am currently just plugging them all back in one by one. The good news is my GUI's using GuiObjectView all still work, albeit with far less features. I did get the sub-mesh support plugged in and working again today, so one can hide/show sub-meshes on the model in view using script. Just 3 more features to go... :D

Edited by TorqueFan
Link to comment
Share on other sites

Quick Update( The good so far ) :

  • Terrain materials all work great. Diffuse, Normal, Specular tested. Even works when the terrain is generated and layers applied during runtime...D3D11OK
  • Dynamically building a player object with sub-meshes works great...D3D11OK
  • Passing tab-delimited strings for multiple materials on an object( or terrain )works great...D3D11OK
  • Custom materials on CloudLayer works great...D3D11OK
  • GroundCover with shapes ONLY works...D3D11 partially OK


( The bad so far ) :

  • Same offset rectangle bug appeared when I used the 'metrics(fps)' console command. The rendered white rectangle in the fps display is offset and not contained within its border properly.
  • ***CRASH *** GroundCover crashes the application for me when I try to load or add groundcover textures. I'm not extremely savvy with shaders, but it should be easy enough to track down. Here's the log:


failed to compile shader: C:\dev\DX11\Torque3D-development\My Projects\Test\game\shaders\procedural\5d52451f_V.hlsl(64,4): error X3017: 'foliageProcessVert': cannot implicitly convert from 'float2' to 'float4'


Still porting... :arrow:


  • DragControls across separate GUI's works great...D3D11OK
  • Player mounting weapons works great, even with dynamic lights or particles attached...D3D11OK


Update 2:

  • GuiObjectView custom skinning complete...D3D11OK


That's all for tonight! 2 of the 4 features are re-enabled now for the GuiObjectView, so before I run into the actual culprit problem I'm going to get some rest!

Link to comment
Share on other sites

Okay, pretty much the whole project is ported now.

GuiObjectView Fixed

I Fixed the GuiObjectView problem and found the culprit in a couple checks I added. I'm not entirely sure what changed behind the scenes to break it in the first place, but here are the details:

I use an enum to initialize a name index, like this:


	  enum blendAnimations{
	  eyeScale0 = 0,
	  eyeScale1 = 1,
	  eyeScale2 = 2,
	  eyeScale3 = 3,
	  eyeScale4 = 4,
	  totalBlendAnimations = 5

  String mBlendSeqName[totalBlendAnimations];


The problem was I was calling...

	if (!mBlendSeqName[mChosenEyeScale].isEmpty())

...where mChosenEyeScale is just the index value chosen through the GUI's. Oddly enough, these checks worked fine prior to the D3D11 merge. I Removed the checks, which to be completely honest seemed a tad redundant anyhow, and wham all is well. Using the example above, adjusting eye scale with a GUI slider is possible via blends!

/shrug - But hey, who cares?! I managed to fix my own problem, port the entire project over to D3D11, give a chunk of feedback, and spot a couple (potential) bugs.

I extended the GuiObjectView with 4 new features, so look forward to that being up on GH soonish.

When I get the time again to revisit this I will try to port over some custom sky rendering classes I've pieced together along the way to see how they go. Hey, thanks again for all the work on this!!

Link to comment
Share on other sites

( The bad so far ) :

  • Same offset rectangle bug appeared when I used the 'metrics(fps)' console command. The rendered white rectangle in the fps display is offset and not contained within its border properly.
  • ***CRASH *** GroundCover crashes the application for me when I try to load or add groundcover textures. I'm not extremely savvy with shaders, but it should be easy enough to track down. Here's the log:


failed to compile shader: C:\dev\DX11\Torque3D-development\My Projects\Test\game\shaders\procedural\5d52451f_V.hlsl(64,4): error X3017: 'foliageProcessVert': cannot implicitly convert from 'float2' to 'float4'



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.

Link to comment
Share on other sites

Awesome, yep, drawRect() offset fix works great thanks!


Okay, here's what I found about GroundCover object. The problem I ran into deals with the material definition. In my case, I was adding a detailMap layer to the material. This was giving me a little more creative freedoms on how the material would ultimately look - BUT that was pre-D3D11. I've already noticed that some of my other materials that use detailMap layers look different than before this merge...but in a good way. So I need to update my art across the board a tad to fit D3D11( that's a good thing ).

Here's the problem:


singleton Material(Mat_Grass)
  mapTo = "Grass_cover";
  detailScale[0] = "1 1";
  detailMap[0] = "art/environment/cover/Grass/Grass_d.png";

If I comment out the detailMap and detailScale here, there is no problem at all. If I don't comment that out, I get an error popup about 'can't compile shader'( same error as in the log I posted before ).

Now, I dug a little bit deeper around material definitions because D3D11 in Torque is too much win! I created a new GroundCover object( D3D11 build, Empty Terrain mission ) and then for the material I set it to the Lurker rifle's muzzle flash. Boom, same error as above. Now obviously the muzzle flash sequence was never meant to be a ground cover material, but a user could potentially want some other sort of animated ground cover material. I followed this procedure for several materials - some would work and others would not.

Ultimately I found that these variables did work fine in material definitions in any case :

mapTo =
diffuseMap[0] =
diffuseColor[0] =
doubleSided =
translucentBlendOp =
alphaTest =
alphaRef =
materialTag0 =
normalMap[0] = 
specular[0] =
specularPower[0] =
glow[0] = 
emissive[0] =
useAnisotropic[0] =
castShadows =
castDynamicShadows =


These caused the crash :

animFlags[0] = 
scrollDir[0] = 
rotSpeed[0] = 
rotPivotOffset[0] = 
waveFreq[0] = 
waveAmp[0] = 


I'm not sure which of the animation variables caused the problem, I just included all that were used in the muzzle flash sequence I tested.


Cheers for the feedback.


Link to comment
Share on other sites

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.


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.

Link to comment
Share on other sites

Oh nice, thanks for looking into that. If not later this evening than on tomorrow I should be able to confirm.


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.

@Timmy, could you help me to understand the 'normal' workflow used when importing detail textures now? Like prior to this, I'd either use a high pass filter or something very similar when creating a detail map for T3D. What do you describe as "appropriate" textures and how do I import my texture properly?


Confirmed the updates, thanks a lot. :D If not detail maps, surely something would have come up. All material definitions working great now!

Link to comment
Share on other sites

@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


Brighter detail map (art/terrain/example/sand_d.png)


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


Lets see how these look in game now

Rocks1_d: Horrible but not surprising when you see how dark it is above


Turn the detail strength down and better


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.

Link to comment
Share on other sites

@Timmy ...research complete! Thank you so much, I do enjoy a good read! You, sir, are a gentleman and a scholar.

That all makes sense, and I'll be adjusting some of my detail maps accordingly to suit. ;)

By the way I did run into one other small issue with the GuiObjectView port, where the background isn't transparent. I believe @Azaezel has a better understanding of the source of the issue.

In this post, he gives mention to some changes to the class that may be necessary to make a 'complete' conversion of GuiObjectView from the old to the new. Some may not be necessary, per say, but as the goal is always to innovate and improve I believe all of his proposed updates could benefit the class.

Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...