Timmy

With physx 3.4 don't worry about that for now, it was more just a casual comment, physx 3.4 is still in closed beta, you gotta ask their licensing department for a copy for testing. So we will stick with 3.3 which is publicly released. Step 1) clone this repository https://github.com/NVIDIAGameWorks/PhysX-3.3 - if you don't have access see https://developer.nvidia.com/physx-source-github Step 2) compile the above physx using whatever version of VS you will use in T3D (don't forget both debug and release if you plan on using both in t3d). Currently the cmake file only supports VS 2013/15 32 or 64bit. Go into /where_you_cloned_physx_above/PhysXSDK/source/compiler for the visual studio solution files. Step 3) make an environment variable called TORQUE_PHYSX3_PATH that points to /where_you_cloned_physx_above/PhysXSDK/ You may need to reboot for this to take affect depending on how you do it. Step 4) place the physx 3.3 cmake file into T3DFolder/Tools/Cmake/Modules and run cmake and obviously select physx. Step 5) Open cmake generated solution file and happy days, no more to do but compile and run. It will copy the required dll files etc automagically for ya and also place the physx stuff in the project. When physx 3.4 is finally publicly released i have made changes to the cmake file that makes this a bit easier, till than you gotta follow the above steps. PVD is the visual debugger for physx. Also nvidia told me they will never again release physx in compiled form, from here on out it is github source code only. Unfortunately for licensing reasons we can't ship T3D with the physx source, hence why you gotta manually grab it and compile yourself. In case you are wondering, the physx sdk source code contains PhysX sdk, APEX sdk and PVD source code.

Yeah in short the requirement for the old june 2010 dx sdk was kept because the d3d9 gfx device is using a lot of d3dx functions that microsoft have removed when they released the windows sdk and merged the dx sdk into, since d3d9 is going to be removed in the next version, it was a waste of time changing the d3d9 gfx device to not use the d3dx functions.

All good, this will be changing in the next version and using the Windows SDK.

No it's for both d3d9 and d3d11.

you need d3dcompiler_43.dll which is from the old june 2010 dx sdk. You can double check it with this http://www.dependencywalker.com/

You gotta save this file https://raw.githubusercontent.com/rextimmy/Torque3D/1770ed01ce45affc76e6ae48278153d93fda58bc/Tools/CMake/modules/module_physx3.cmake and place it in T3DFolder/Tools/Cmake/Modules . There is no official physx cmake file. Than just follow the steps in this post To use it just grab the physx source and compile it yourself and than make sure TORQUE_PHYSX3_PATH points to /somepath/PhysX-3.3/PhysXSDK and away you go.

@chriscalef Are you running the bog standard physx3 plugin or ya got some of your own stuff in there? Last time i tested it worked out of the box with vs2015. The StringTable is hidden away in the physx namespace, so just double check in any of ya own code if you are doing the whole using physx thing. Let us know how ya go. Oh yeah on another note, i have a new branch with support for physx 3.4 (still in beta testing) https://github.com/rextimmy/Torque3D/tree/physx_34, i got cmake file in there for it to, works on windows/mac and linux.

In T3D 3.9 it went from deferred lighting to deferred shading, i won't explain the details of this again because there is a lot of information on the topic floating about. In short, you will find a lot of smaller, simpler levels will indeed be faster using the older deferred lighting technique even though it is drawing a lot of scene geometry twice.The results will vary a lot however from system to system depending on cpu/gpu combo. The current gbuffer used in deferred shading is very large actually and far from ideal, it will be further optimised in future releases. For example on my system: Outpost: Deferred Lighting quicker Empty Terrain: Deferred Lighting quicker Pacific: Deferred Shading quicker

Still requires the old dx sdk unfortunately.

Hi Guys, I wanted a way to be able to reliably benchmark a scene and record raw raw frame rates etc. So i wrote a few scripts to help with this. It can all be found here https://github.com/rextimmy/Torque3D/tree/benchmarking . No c++ changes, all script. It uses a Path Camera and basically goes along the path and records frame stats. It can produce two different reports 1)CSV raw dump showing fps,mspf,draw calls, polycount and camera position for each frame. Useful to import into a spreadsheet and or database. 2) A summary text file that shows average/min/max fps,mspf,draw calls and some basic details about the scene. To use it you must: [*] Create a SimGroup called Benchmark under your MissionGroup [*] Create a Path called BenchmarkPathN (where N is 1 through to however many different paths you want). [*] Add markers to the path, these can be named whatever you like, just make sure the sequence is correctly number 1-N. Just a word of warning, the field msToNext on the marker, with a path camera this actually means Meters per second to the next marker not Milliseconds to the next marker as the documentation for it says. A sensible starting value is something around 10 not the default 1000. Needs adjusting depending on distance between each marker though. To launch the benchmark there is a function called function Benchmark(%id,%numRuns,%writeSummary,%writeReport) so id is the N from BenchmarkPathN above. numRuns is the number of runs you want to do. writeSummary & writeReport (true/false variables) are both explained above. If you pass no arguments to this function it will default to using id=1 | numRuns = 1 | writeSummary = true | writeReport = true When benchmarking, i highly recommending doing multiple runs and completely discarding the first runs results, i'm sure everyone reading has suffered from the dreaded Torque3D loading hiccups as you run around a level, by discarding the first run you allow everything to get loaded in the first run and all subsequent runs after that should be nice and smooth. Now some user configurable stuff is here . They are already commented in the code so i will leave it at that. Anyway if you find any bugs or have any suggestions than fire away. Originally i was going to create a gui dialog to actually launch the benchmark and thus relax the BenchmarkPathN naming convention but kinda got busy with other stuff ;) Few pics of the setup: http://i.imgur.com/GYErGk4.png http://i.imgur.com/9JGr7qc.png

Still going over cleanups and pure additions, like the Mac support you'll find in the development fork. So this new version has full mac support out of the box no tweaking needed? Yes

Yes only Visual Studio 2013/15 are supported now. Just head over and grad the free community edition here and latest cmake(3.7) here. Talking of CMake, i have nearly finished fixing up the old project manager to handle the cmake build system so should make it easier for everyone as you don't have to deal directly with cmake.

Could you run dxdiag.exe and show us a screenshot of the display tab.

Atom is pretty decent and has torque script syntax as add-on https://atom.io/ https://atom.io/packages/language-torquescript

Ok excellent good to know. Just so anyone else reading knows, the SDL side of things is still getting worked on, so in it's current state it only works properly on windows when compiling without SDL. When the SDL side is done i'll get it chucked into the proper development branch.

Sorry for the delay, been busy this week. Check that branch from above, hopefully should be fixed now.

Ok no worries, will check that out and fix it.

If you want to try this out and we can fix any further problems i may have missed before sending in a proper PR. https://github.com/rextimmy/Torque3D/tree/dx11_multi_guicanvas

Yes DX11 is not creating a different swap chain for each window target. Will through up a fix for it this weekend, i'll post the PR here so you can test it.

It's disabled here @chriscalef https://github.com/GarageGames/Torque3D/blob/development/Templates/Full/game/tools/physicsTools/main.cs#L102-L110

Can you post the console.log, it has been tested against amd gpu but not that exact model though.

Are you copying the binary directory to local drive when running it? I.e not running it from within the mounted image

What version of macOS , XCode and CMake are you using? Does the binary download run?

Yes you are still required too The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Copyright (c) 2012 GarageGames, LLC Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. MIT license