Timmy

Awesome work mango!

You can pass raw pixels to GBitmap https://github.com/GarageGames/Torque3D/blob/development/Engine/source/gfx/bitmap/gBitmap.h#L125

Than pass that to the GFXTextureManager https://github.com/GarageGames/Torque3D/blob/development/Engine/source/gfx/gfxTextureManager.h#L96

Unfortunately your average user won't look there.

Hello.

Where I can find release notes for v3.8?

I think that got kinda overlooked ;) http://wiki.torque3d.org/release:three-eight

Impressive az & hutch, nice work :mrgreen:

With the DX11 stuff i'll start a new thread soonish and explain the whole situation and what's going on with it.

This should get us a baseline implementation of DX11 - it may not see tons of performance gains at first, but we can steadily improve it as we go. Having it in at all is the big first step.

 

rgr that one. I'm gonna reckon there will be some performance, considering drawcall overhead is def. reduced between DX9 and DX11 if your drawcall bound. Won't be as good as DX12/Vulkan/Metal but still should bring up to part with more-like GL drawcall perf.

What i have seen so far with performance is exactly what you said ;) . With less complex scenes DX11 outperforms DX9 (anywhere up to 20% range) but with huge complex scenes it's on par because other parts of T3D become the bottleneck and not the gfx calls. It's early days with dx11 so perhaps some more performance will be found, i have already fixed a few performance issues already.

Out of curiosity has anyone tried threading the CPU skinning in T3D before? I know there is GPU skinning but in T3D's current setup, i often wonder if CPU skinning wouldn't be a great place to start.

No probs, thought that would fix it

The card is a shader model 5 card too, it a HD 5650

haha indeed!

@Azaezel

I couldn't get rid of that warning message until i lowered the number down to 8 for the uv's :| i tried 32,24,16 and finally 8 worked.

Does it work using a memcpy instead of the strncpy? I think the T3D wrapper version is called dMemcpy (don't quote me on that lol).

I'll give it a shot tomorrow, my first guess was that imposter uv size too. There is just nothing else obvious apart from that.

@Azaezel

_V : http://pastebin.com/upqpeKDW

_P: http://pastebin.com/eYuB35hv

Sorry i couldn't remember which one that was i posted originally haha. Same error happens on multiple shaders, i think the imposter is the common connection, i think

Here you go @Azaezel http://pastebin.com/jjen0DJJ noticed that warning on my laptop the other week (amd gpu). Didn't look into it though.

Even after he modified it add GLSL support, I'm not entirely convinced it works

Gotta say i agree ;)

Visually debugging the 3 passes is very simple, just comment out the pass below what you want to debug, than make sure the target in the postfx is set to $backbuffer

Hi Guys,

Here is an implementation of SMAA from here: http://www.iryoku.com/smaa/

Source Code: https://github.com/rextimmy/Torque3D/tree/SMAA

If someone wants to take this further and produce an official pull request, please go ahead but do note........

There are a few problems:

1) There is a problem with OpenGL. It works perfectly on Direct3D 9 and even our own experimental Direct3D 11. With OpenGL something goes wrong in the second pass(blend weights). I'm not sure if it doesn't like the texture format or it's something else? i'm just not sure. We don't use OpenGL so i didn't bother tracking it down any further.

2) This really needs to be implemented with some sort of options menu that handles the different quality levels or even the different AA options (i.e FXAA). In DM we have done this but that code won't be compatible with T3D, so i have trimmed this implementation down to suit. I tried to comment where i could in the source files about this.

Any questions just ask and i'll try and point you in the right direction.

Results

Sorry i only had time to do one round of screenshots here. Biggest difference you will notice between SMAA/FXAA is the vegetation in these screenshots.

No AA:

http://i.imgur.com/HPZctVL.png

FXAA:

http://i.imgur.com/9nVDmAJ.png

SMAA:

http://i.imgur.com/AdBIWi2.png

Performance:

SMAA is definitely more expensive than FXAA. What i have found though (from testing on a few different GPU/CPU combos), the difference can be negligible if you have a recent rig. T3D is so CPU bound for any mid->high GPU/CPU combo, that the GPU spends more time idling than it does actually working I.E this extra work SMAA makes it do, makes no difference to frame rate for those set-ups.

I will get around sometime to creating a physics_now_redux branch :mrgreen: Containing some of the things we discussed awhile ago jeff and also fixing the big flaw there is now, networking.

I always found the biggest pain was not having a visual editor to aid with the ragdoll creation. I personally went the datablock route and it can take awhile to get the sizes etc perfect, i still haven't lol. You can debug the ragdoll physics bodies via enabling physics debug in the world editor but a nice sexy gui tool would be great.

Hi Guys,

I meant to post this some time ago and totally forgot about it.

Here is the source code to compile OpenCOLLADA with 3ds Max to enable Visibility Animation. This can be used for the weapon muzzle flash http://docs.garagegames.com/torque-3d/official/content/documentation/Scripting/Advanced/ShapeBaseImageData.html#Weapon_Muzzle_Flash

Source Code: https://github.com/rextimmy/OpenCOLLADA

I have had troubles getting this to work on Max 2014 but works fine on Max 2015. Any other version is untested.

*Please don't give me credit for the code as i didn't write it, I found it on the web. I am trying to find the original post on-line that contained the small source code change so i can credit the author for his work.

Is it possible to leave the division function as it is now, but add an assert in debug mode for division by zero?

Doing that won't affect performance of release builds at all, but will highlight potential problems when run in debug mode.

x2

Nice work :mrgreen: