Timmy

It creates a 3.2 Core Profile.

Good find :mrgreen: Do take note of what the user raspo says in the comments section (former Crytek guy).

Great work to everyone involved, well done :mrgreen:

Hey impressive work so far, keep it up :) . Bonus points if the editor doesn't default to controlling the player object on launch.

Awesome work az, i find the big problem with awesomium is the lack of 64bit on windows. Pretty restricting really.

Verve and GMK went MIT because their authors are no longer working on them and they where nice enough to release it under MIT so other people can still use them/develop them further.

I do totally agree about the rendering though, it does seem the only hope for further features on the rendering front now lie with OpenGL that was re-introduced in 3.7

Comparing it to other engines the only plus i can come up with is the license (which for some people is massive). It is very much geared towards FPS shooters but can obviously be used for other genres with a bit of effort.

By default no physics plugin is compiled in. The vehicles don't use any physics plugins nor will they interact with any physics objects. You can enable bullet physics (or PhysX) in the project generator (there are other ways but that is the easiest ). If you look here i enabled kinematic bodies with vehicles https://github.com/rextimmy/Torque3D. Not perfect but better than nothing and will work with all physics plugins

I will also say it's a been a long battle getting the joints and the drive parameters right but i finally got it right just yesterday. I just added in support for aggregates into the PhysicsBody class too, hopefully this keeps performance under check in a heavily populated physics scene. I also found upping the joint solver iterations helped stability of the ragdolls too. Hope that helps but looks like from the video you not far away nailing it anyway :mrgreen:

To get the correct pose i solved this by passing in the dead player object id via script to the ragdoll class (obviously server side) and than resolving the ghost and copy the transforms, this saves copying the transforms over the network which would be horrible. Once this is done it's safe to delete the player. Bare in mind i did it this way because i have no need for ragdolls unless they are spawned from a dead player.

I really regret not creating a GUI tool to help create the ragdolls, boy it's a slow, boring and tedious job setting everything up by hand.

Having used Qt with a former project (GUI based OpenGL app), i'm a massive fan of Qt (IMHO it's the best cross platform GUI API bar none). I am not 100% sure using it for T3D windowing/input is a great idea though (a world editor written in Qt would be awesome). Anyways not trying to knock your work, best of luck with it :mrgreen:

At the end of the day T3D will always have something the others don't and that's an MIT license ;)

Option 3

This seems like it could be a good way to go for many types of problem. Taking discrete pieces of an algorithm that involves a lot of computation, and parallelising it within a single discrete time slice in order to make it go faster. Not long-running systems which interact with the main thread over any length of time..

Yeah this seems to be the direction most of the "big boys" seemed to have taken with their engines. Intel has a really great video explaining the concept from GDC a few years back, i'll post the link if i find it.

The downside in d3d9 is that the critical section is global over all api calls

Yes this is the problem.

Exactly why i didn't offer this as an official pull request but added it as a resource instead ;)

Lockable resources (textures with D3DUSAGE_DYNAMIC, vertex buffers and index buffers, for instance) can experience poor performance when shared. Lockable rendertargets will fail to be shared on some hardware.

That part also doesn't sound very nice with resource sharing

Even with multi-threading the asset loading, i think you would still get the dreaded hangs/pauses etc because even though disk i/o and any cpu intensive operations can happen on another thread, things like sending the vert/index buffers, uploading textures,compiling shaders etc etc still has to happen on the main thread causing delays. D3D9Ex does support sharing resources https://msdn.microsoft.com/en-us/library/windows/desktop/bb219800(v=vs.85).aspx#Sharing_Resources though and OpenGL is capable of this too.

You have made awesome progress Az, well done :mrgreen: :mrgreen:.

Sorry my mistake, everyone involved of course ;)

@Timmy started the multithreading discussion at this post.

Sweet no problem.

Yeah Az is definitely right it is a real spider web right now. As it stands the network/sound is the only thing multi-threaded and they both use the thread pool functionality already present in T3D.

The render system is the most obvious place to start, it doesn't need to actually support rendering API calls from multiple threads but breaking down the work the render system does to be distributed amongst the thread pools. Things like traversing the scene graph, culling etc etc

It would be a massive undertaking to do it but very beneficial.

You have made awesome progress Az, well done :mrgreen: :mrgreen:

Slightly off topic but one of the biggest things i have seen that is really holding T3D back, is just how CPU bound it is. Using T3D now on a decent size level it quickly becomes very apparent how under utilized the GPU is. It needs multi threading.

Not sure if this should be in this section or Assets

About

This resource will flip(invert) the green channel of the normal map. It doesn't actually touch the image but will invert the expanded normal map's green channel in the pixel shader. In other words it will flip the direction of the bumps in your normal map. I have not modified the GUI here so it's script only. Only tested on advanced lighting

Material Script Usage

invertNormalMap = true;

Implementation

Source File: Engine/source/materials/materialFeatureTypes.h

After Line: 89

/// This feature flips the green channel of the normal map
DeclareFeatureType( MFT_InvertNormalMap );

Source File: Engine/source/materials/materialFeatureTypes.cpp

After Line: 62

ImplementFeatureType( MFT_InvertNormalMap, U32(-1), -1, true );

Source File: Engine/source/materials/materialDefinition.h

After Line: 282

bool mInvertNormalMap;

Source File: Engine/source/materials/materialDefinition.cpp

After Line: 197

mInvertNormalMap = false;

addField( "invertNormalMap", TypeBool, Offset(mInvertNormalMap, Material),
   "If true this will flip(invert) the normal map/s green channel of this material." );

Source File: Engine/source/materials/processedShaderMaterial.cpp

After Line: 388

if(mMaterial->mInvertNormalMap)
   fd.features.addFeature( MFT_InvertNormalMap );

Source File: Engine/source/renderInstance/renderPrePassMgr.cpp

After Line: 554

type == MFT_InvertNormalMap ||

Source File: Engine/source/shaderGen/HLSL/shaderFeatureHLSL.cpp

After Line: 178

if( fd.features.hasFeature( MFT_InvertNormalMap ))
   meta->addStatement( new GenOp( "   @.y *= -1.0;\r\n", normalVar ) );

Source File: Engine/source/shaderGen/HLSL/shaderGenHLSLInit.cpp

After Line: 48

FEATUREMGR->registerFeature( MFT_InvertNormalMap, new NamedFeatureHLSL( "Invert Normal Map" ) );

Consequences

This will create yet another shader permutation in the ShaderGen system.

Why not just make a forum called Resources below Blogs?

Definitely this

Sorry i missed that, just trying to help.