Timmy

It's definitely possible, in physx i create kinematic actors from the bones exactly the same as you would for a ragdoll, that runs from the animations and when you do need a ragdoll just change the actors to dynamic. Would work perfectly with bullet too. Just make sure the projectile class is using physics for raycasting AND filter out the actual character controller for that raycast.

Yeah I'll chuck something up in the new year for people to play around with.

Personally i don't think a store will stop people contributing MIT code, it won't stop me contributing anyway. The only time i would consider selling a code add-on, is if it was highly specialized towards a certain genre/solving a very specific problem. It's code like this that would never make into the public repository anyway.

I got it on my private repo at the moment but i will clean it up and chuck it over on my public repo. I'll try and at-least show an example of texturing and hopefully destroying some blocks.

There are a few different directions you could take the Polyvox intergration, i guess that can be a discussion for another day. Will post the link soon anyway

This PolyVox stuff is fun :mrgreen:

Here is the "example" sphere in T3D, this took a few hours to create including a cmake module for PolyVox. This is using the cubic surface extractor but could have easily been done using the marching cubes extractor. I just wanted to test it and see what the PolyVox api is like.

http://i.imgur.com/Y9pJhBx.jpg

http://i.imgur.com/uhX8K3l.jpg

Yeah i think a store is a great idea both for art assets and code.

I'm sure it could be done (the networking). Anyways i do agree it would be a pretty cool feature to have in T3D. I think both block and smooth cubes would be pretty awesome to have, while you don't personally have any need/use for the block cubes i'm sure someone, somewhere would.

Unless you want to dynamically modify those cliffs and caves in game, there is no great point going to the trouble of integrating it.

Aah you want something like the feature set in Cubiquity. Funny enough they are dumping support for the smooth terrain part from Cubiquity and focusing only on block style. Something about the work involved supporting both and creating different editing features for both is just too time consuming.

Well it has to be rendered like something doesn't it, polyvox supports only the two i mentioned ;)

To quote the official documentation on surface extraction

Generates a triangle mesh from the input volume data which can then be used for rendering.

* Supports Minecraft style terrain where each voxel is represented by a cube.

* Supports smooth terrain via the Marching Cubes algorithm.

What where you guys after, the smooth terrain (like what bill vee did) or the minecraft block style?

Merry xmas :mrgreen: . Coming along well az, nice work.

I'm with jeff, it does look like something is wrong with the seams or the neighbour storage is wrong, something along these lines. It is hard to tell from just a vid though.

That raises an interesting question though: datablocks and the like that exist JUST for the editors, namely, the forest brush info: should those be in with the tools themselves? That seems the most logical way to go about it to me..

Good point, also other areas like this but reversed. For example this stuff is bundled in with the world editor https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/tools/worldEditor/gui/objectBuilderGui.ed.gui#L991-L993, if you happen to not ship the world editor obviously problems happen.

Have you considered making a PR?

Between DeadlyMatter, D3D11 branch and physx3 cmake stuff i just haven't found the time ;) . I will PR it all some day lol

No i didn't use that pr but yeah that was one of the problems [mention]JeffR[/mention]

This branch is a little old now but it shows how to enable basic physics interaction with vehicles https://github.com/rextimmy/Torque3D/tree/physx3_advanced works with bullet and physx. It will work the latest t3d physics (they are unchanged since i created that branch)

Do try out the new CMake module i created above [mention]chriscalef[/mention] (if get a chance of course ).

Got linux working too now, i will upload these changes to the CMake module soon.

Talking of linux [mention]JeffR[/mention] , the latest development branch doesn't compile, there are a few minor problems with the taml stuff that was added. Will do a seperate PR for that.

http://i.imgur.com/KwBqPVZ.jpg

*Reserved for linux guide

Well it has been a very long time since I touched the standard PhysX 3 in T3D so thought i better write a guide how to use it now as a few things have changed from the PhysX side.

NVidia no longer supply up to date binaries of PhysX 3 but they will give access to the complete source code instead on github(don't mistake this as PhysX is now Open Source because it's not). I won't run through how to clone a repository as there are so many great guides on the net but firstly you will want to go here and follow the instructions about how to access the source code https://developer.nvidia.com/physx-source-github . Once you have an account the source code is here https://github.com/NVIDIAGameWorks/PhysX-3.3

Once you have cloned the repository you should have a directory structure like so

http://i.imgur.com/R0nOot1.jpg

If you go into PathToPhysxSource\PhysXSDK\Source\compiler you should find you IDE choice. With Visual Studio just open up and compile a debug and a release build. Should be fairly straight forward no other mods etc needed here.

Now when that is complete we need to create an environment variable called TORQUE_PHYSX3_PATH and point it to the PhysXSDK within your PathToPhysxSource directory like so

http://i.imgur.com/4MLp8mx.jpg

Due to the changes in how PhysX is now distributed it's almost impossible to make the default project manager work with all the different IDE versions and folder names, so i have created a CMake module to handle this. The PR for that is here https://github.com/GarageGames/Torque3D/pull/1488 and will most likely be in the main T3D development branch sometime in the near future.

Anyway back to CMake, it's pretty easy just select PhysX 3 and if all of the above is ok it should be happy days

http://i.imgur.com/u75sxP7.jpg

Just don't forget to build the INSTALL project in Visual Studio to actually install the DLL files into your project. I will try and find time to get this working in Linux too as the current CMake module only supports windows for now.

*Tested with PhysX 3.3.4

Is VS 2010 definitely finding/using that windows kit directory? You can remove this line if you like https://github.com/rextimmy/Torque3D/blob/d3d11/Engine/source/gfx/D3D11/gfxD3D11Device.cpp#L271 it will work than (should do anyway)

If you are not seeing heaps of these type of warning messages than it's not using the windows kit

warning C4005: 'D3D11_ERROR_DEFERRED_CONTEXT_MAP_WITHOUT_INITIAL_DISCARD' : macro redefinition (C:\Devel\Torque3D-rex-d3d11\Engine\source\gfx\D3D11\gfxD3D11VertexBuffer.cpp)

I gotta admit i haven't tried it with VS 2010. Was that in debug or release mode? If you get that in debug mode you have to install the Windows Software Development Kit for Win8

*Reserved for shader tutorial.

Hey Everyone,

As Jeff mentioned in the 3.8 release thread, i have been working on getting the awesome work anis started here https://github.com/Lopuska/Torque3D/tree/D3D9_D3D11_R%26D up and running. I have fixed a lot of problems, fixed a few performance problems and converted all shaders in the common shader folder to use a new helper macro system to enable Direct3D9 and 11 shaders to place nice together (see post below).

It's coming along well and while i wanted to fix a few more things before starting this thread, time has forced my hand. So don't expect it to be full production quality and ready yet, it's not. It's all a work in progress.

Source Code:

https://github.com/rextimmy/Torque3D/tree/d3d11

Problems i know about:

• Glow blur problem
  
• No instancing support yet
  
• Windowed mode and editor toggle. See here
  
• Feature levels not properly implemented yet

Due to the sheer amount of shaders that need switching over to the helper macro system (this does not include shadergen shaders however), without a shadow of doubt i have missed something somewhere. One thing you will notice compared to D3D9 is the dramatic drop in memory usage and a faster loading of levels.

There is one performance problem i am aware of involving the constant buffers, long story short i can fix this using 11.1 feature level but unfortunately this is only for Window 8 or above. This is one area i need to really fix up and i will when i get the time. So for now i'm not concerned about performance but rather getting it all working and than i will go and start profiling it in detail and fixing up any performance issues.

Compiling

If you are using Windows 10 and want to run in debug mode you must have the graphics tools installed. The easy way to do this via an admin command prompt

Dism /online /add-capability /capabilityname:Tools.Graphics.DirectX~~~~0.0.1.0

Unfortunately the old D3D9 is still using the deprecated Microsoft DirectX SDK. This will cause a lot of warnings when you compile and it will fail to compile with VS 2015 due to the use of dxerr . I will fix this up in time but for now i wanted to keep the fully working and 100% tested D3D9 device in place until D3D11 is 100% working.

If you use CMake the D3D11 code will be automatically included and if you use the project manager you will have to select "Direct3D 11 Rendering". I have also included VS 2013 to the project generator.

It would be great if people could start testing this out and reporting problems, there will be more than what i listed above. Please only use the full template, the empty template has not been updated.

There is a second thread over here too about this. Use either thread, doesn't matter.

If you are ever getting super excited about dynamic textures there is also this https://github.com/GarageGames/Torque3D/blob/development/Engine/source/gfx/gfxTextureHandle.h#L76-L84 .