Timmy

Feel free to donate me one and i'll get it working :mrgreen:

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.

That's kind of a bummer, and a huge limitation, funny that this has never been a priority for anyone to tackle and put a fix into the stock T3D engine code.

It's a difficult thing to do because there isn't really a one glove fits all solution, what may work for scenario A could make scenario B worse.

I thought i read somewhere you where using Awesomium? If so that is 32bit only on windows.

With $pref::TS::maxInstancingVerts that will affect all static geometry that uses TSMesh class internally. So all TS based static geometry(not skinned meshes). So what it does is each mesh that has $pref::TS::maxInstancingVerts or less will be rendered using instancing. This in itself can be costly if it's picking up meshes that are not rendered multiple times. So be aware of this part.

Where instancing is a big win is say you have 5000 cubes to draw, without instancing you have to make that draw call 5000 times to the graphics card, with instancing you could make that draw call once. There is more going on than this, with instancing you have to update the instance buffer for each mesh to send the gpu so it's not as simple as i make out above ;) but that is the general idea. So as you can see by this, all that geometry still has to be rendered/processed by the gpu it's just cpu side you are not making 5000 draw calls to do it. So if the actual draw calls themselves are not your bottleneck than instancing may not help you at all. With T3D there is still heaps of other stuff going on with that mesh, like all the collision container stuff, scene graph sorting, . It's possible the bottleneck could be elsewhere but it's certainly worth experimenting with.

Personally i think it would work better if you had to manually mark a mesh for instancing rather than just blindly picking up anything with $pref::TS::maxInstancingVerts or less, i'm sure art departments would most likely hate me for that one because it wouldn't be automatic :lol: :lol: but sometimes fine tuning by hand is simply the best method. Anyways have a play around, there is no magic number to use and it is very specific to your level you are rendering.

*Edit:

When a i say static, it doesn't have to be static in that it can never move, just static as in not a skinned mesh. For example a physics object can be rendered using instancing.

Don't forget with $pref::TS::maxInstancingVerts , it will only enable instancing with meshes that have that many verts or less.

Next version of T3D will support VS 2015 with cmake. As az says above, the only problem is dx9. There is a rough time estimate outlined here

Yeah as rlranft says above, you will need this stuff server side. Even if you where not using it to drive the vehicle and just ran say your sound from it, other clients would need that data too so you will want it server side in any case. Even if you no intention of having multi player support, T3D still uses a client-server architecture regardless.

Won't deferred shading make the engine much slower?

Depending on your scene and hardware configuration, deferred shading can be faster than Prepass Lighting. While it certainly uses more bandwidth it also avoids rendering everything twice.

Oh yeah more testing the better, it's really hard to test every single different scenario. So yeah I definitely encourage everyone to keep testing :mrgreen:

Anyway back on topic i been running and developing with T3D with Win 10 and never had any dramas yet, it's stable as.

@Dwarf King:

Just so you know the dx11 stuff is definitely not ready for production type releases, it's very much still a WIP. I am absolutely snowed under in other work at the moment and most likely won't get much more done with it till some time in February.

Seems that the dynamic shadows when the Torque orc is moving is lagging/ha ha hacking in both DX9 and DX11.

.

Try changing the values of the shadow caching.

Hi, I've found some issue with rivers - there is a missing part at lowLODdistance, also it happens only when You look from the first node side (on screenshot it's duplicated river, one is rotated by 180 degrees). There is no problem when using d3d9.

Thanks for that, issue is now fixed.

I would guess it's most likely D3D11 related, i mean if you can fire up the exact same level with D3D9 or GL and it's all good than it's obvious where the problem is ;)

Yeah whenever you get time if you could reproduce the problem in the stock levels/art work that is a great help and makes it faster to track down the problem.

The easiest way is to supply a level or just reproduce the problem in one of the demo levels so i can take a look. By the way is that with pbr dx11 or just plain dx11 branch?

I will say i am super busy with my Deadly Matter duties currently but i'll try and fit in some more time with dx11 stuff soon.

Go into game/scripts/client/prefs.cs and change $pref::TS::maxInstancingVerts to 0. I haven't added instancing support yet and this will fix the procedural shader problem above.

As for the warnings in your other post, you can ignore those for now. It's because d3d9 is still using the now deprecated d3dx libraries.

[mention]Mud-H[/mention]

I tried the fogband at 1 on the regular d3d11 and it's ok

http://i.imgur.com/6Qkewm3.jpg

Will have a quick chat with az whenever i see him on irc about it.

Any ideas about what is causing the SkyBox with FogBandHeight > 0 issue? I think it's related to the new shader/D3D11 code so maybe it should be discussed here...

http://forums.torque3d.org/viewtopic.php?f=9&t=55&start=140#p4447

It also cause the SkyLine object to not render correctly.

I can't say i have noticed but truth be told i haven't been able to test every scenario. I'll take a look. Do keep reporting any problems you find, it all helps.

samplerNames[0] = "$diffuseMap";
  samplerNames[1] = "$refractMap";
  samplerNames[2] = "$bumpMap";   

TORQUE_UNIFORM_SAMPLER2D(texMap, 0);
TORQUE_UNIFORM_SAMPLER2D(refractMap, 1);
TORQUE_UNIFORM_SAMPLER2D(bumpMap, 2);

Does this works or diffuseMap/texMap should be the same?

It should actually work with D3D11 even though the names don't match(it works because the texture units match) BUT it's good practice to make sure it all matches up as a different API it may not work.

TORQUE_UNIFORM_SAMPLER2D(texMap, 0);
TORQUE_UNIFORM_SAMPLER2D(refractMap, 1);

That refractMap should be using tex unit 1, it's a typo in the shader. Good pickup ;) The shader uniform texture unit should match the samplerNames[N] from ShaderData

*Edit:

I updated my original d3d11 branch with this fix, i'm sure once az notices he will update the pbr branch too.

Oh yeah you do need to restart or even log out and back in.

Thought i would post and let everyone know i haven't forgotten nor given up on the D3D11 code.

Anyway it was brought to my attention a few people where having trouble running the code in debug mode. I placed a fix on my repo for this, so if you had this problem before it should be ok now.

So in short the debug layers is not essential anymore to run in debug mode but if you do want the extra information this provides you need to

Windows 7: Have at least Windows 8.0 SDK installed

Windows 10: Have graphics tools installed. See my OP for details.

I have started work on the instancing which is the last big feature to add. I have put this in a separate branch until it is finished and than i will merge it over to my main D3D11 branch. If you happen to checkout the d3d11_instancing branch just beware it might not be stable or even work at all, best to stick to the main D3D11.

Once instancing is done it's time to fix some of the smaller issues and start cranking out a bit more performance :mrgreen:

I will write the shader tutorial tonight, i totally forgot about it :oops:

Windows 7 and 10 works ok for me 64bit.

* That is running the latest version though not 3.6.3

Hey all good @JeffR there is no hurry with it, i still gotta add the linux side to the original PR i sent as i got all that working too.

What compiler/ide are you using there jeff? Is the environment variable you set definitely pointing to /PhysX-3.3/PhysXSDK ? Perhaps i should have set it up to just point to the root physx folder rather than the PhysXSDK folder within it.

For anyone else reading that folder called PhysX-3.3 could be named anything you like, i just left it at that because if you clone the physx repo that is the default folder name.

Do you happen to have physics plugin enabled?