[Bloodknight]

[/size]Torque 3D MIT Uservoice Wishlist[/size]

This is the complete list of wishes from the garage games uservoice, I intend to relist them in some orderly fashion.

Some are done, some are works in progress, some despite wishful thinking are never likely to happen, especially with the current manpower issues, these along selected items from the other places where features are requested can form the goto list if you want to work on the engine, or users can add their own to the list and start work.

If you are working on one of these and wish to say so, I can put your @link next to them so people who want to help with specific parts

Also I've no idea how this clashes with jeffs new posts, if it does then... I've prepared a list for him :p

• Add full support for Linux Operating Systems to Torque 3D
• Multiple CPU Core Usage (for skinned meshes especially)
• A new scripting language
• Shader Composer / Material Editor
• Open GL 4.x support for Torque3D
• Add full support for Mac OS X to Torque 3D
• AI System - Navgraph, planner, fuzzy state machine
• Physical Based Lighting/Shader (PBR)
• A system like kismet from unreal engine 3
• DX11 Support
• Global Illumination
• Update the Terrain System
• Inverse Kinematics for character animation
• Export to mobile platforms
• weather system
• Create an Open Source Alternative to Torsion
• GUI system Overhaul for Torque 3D
• Terrain Streaming or Paging
• Wind animation and collision support for groundcover objects
• 3d skybox
• Multiple Viewports in World Editor
• Revamp the Shadow system
• Better support for MinGW compilers
• Upgraded sketch tool
• Advanced snapping options
• hitboxes aka locational damage
• KEY FEATURE - Please keep Torque-3D-Linux Generic (Non-Os and Non-Version specific! )
• Animation Blending
• Add Torque3D to Steam Greenlight
• Steps in the FPS Tutorial for how to compile Torque3D for the first time.
• CgFX Shader Language integration
• Use a Plug-in Architecture so all the Add-ons could work together
• Add full support for Linux Operating Systems to Torque 2D
• Convert data serialization over to use TAML
• In game cinematics
• More Full Featured templates/Starter kits
• Forest Editor to support multiple forest objects per mission
• Play through web page, with streaming capabilities
• Support for Intel Graphics Cards
• Displacement map option.
• Core Engine refactor with Core Plus modules
• PhysX vehicle
• C# implemented
• Light animation for the emissive material
• wetness PostFX and wetness custom material
• Torque Smart ptr: Shared, Weak, and Scoped
• Seperate Sever from Client
• XMLVM toolchain for cross compiling to .Net, iOS, Android and Java
• A scripting language like GML (Game Maker Language)
• Realistic Skin Shader
• Rim Lighting Shader
• screenspace lightning
• Elevation mask for terrain-painting and new filling function
• Add placement of physicsForce objects to the World Editor
• Re-add terrain erosion
• More efficient / intuitive handling of the editor
• Add TorqueScript Prefab methods
• Additional options for forest/mesh painting
• Phong Tesselation
• More Simgroups/better managing (forest items, terrain materials...)
• Bigger brushes
• Marble Class
• Vehicle steering return-to-centre
• Better Zip file functionality
• Occlusion Volume
• RayInfo distance with ContainerRayCast
• Database: Simple and Complex
• MVC Design Pattern (Component System?)
• An unreal mesh paint like editor hooked into shadergen
• SetDPIAware()
• Add terrain layer sensitivity to the forest
• Enable looping for GuiTheoraCtrl.
• Zone Update
• Support for exporting game to the Flash platform
• Ai poses and ContactTimer Pack/Unpack update fix (already in resources)
• T2D Style Toybox System
• beefing up the sketch tool
• Jitter in terrain system between terrain and models
• Feature: "externalCommand" for Torque 3D
• GuiHealthHud - a C++ replacement for the scripted numerical health hud
• Improved Color Picker
• Add new GuiBitmapStringCtrl that strings a number of images

Art and level development

*Interior/structure designer like Constructor
*Prefab object that combines models and scripts
*Improve forest editor
*Beefing up the sketch tool
*Beef up the material editor
*Fix the Shadow system
*Jitter in terrain system between terrain and models
*Add weather system
*Better snapping system
*Better Zip file functionality
*Re-add terrain erosion
*Add terrain specular, and if needs be, remove parallax from the terrain pass to make way for it, but retain parallax for shapes.
*Add the ability to set a kind of 'alpha mask' for the terrain tools, so you can set the strength & shape of the tools a bit more specifically.
*Add more flexibility in the noise tool again, maybe being able to set a tiled heightmap mask to it so you can again control the behaviour of it better depending on design requirements.
*Water... although I haven't played around with it in recent builds, and it may have been changed since I have used it properly, the settings for water could really be simplified down to make it more user-friendly, a lot of the settings are awkwardly named considering their effects on the water blocks.
*A basic precipitation and particle library
*Add split screen "viewports"
*Better terrain materials manager
*Add a semi "auto-zone" widget kinda thing. for example selecting a building shape, and at the click of a button, create a "zone" item matching its bounds etc.
*Ground Cover needs collision support
*Add terrain layer sensitivity to the forest
*Improve character import
*Add more keyboard shortcuts and show on the menu
*Light bleeding through the seems
*Possibly change the ground cover and forest editor to be 2 more generalized editors
*when standing outside of a zone, particles and lights are visible that are created inside of it. the only way that they should be visible is by looking inside the zone through a portal.
*Occlusion Volume. It should have a switch that allows it to effect the terrain behind it or not. As it stands, it causes the terrain to disappear behind it, which u don't always want.
*More 3D imports
*Artist friendly - add sliders along w numbers input
*SKYBOX and SCATTER SKY should work together somehow
*Better animation blending

everything that says 'improve' or one of its 20 million gazillion alternative ways to say improve need moving to a separate list, since clearly, the feature exists in some form, also to some extent they are the most pointless and irritating *wishes* in list form, they need to be discussed.

if you believe this is an important area of work, take an item and create its own thread, make sensible suggestions and notes about what is missing of needs adding/enhancing.


TODO Note: Rework to new thread with appropriate separation.

[Steve_Yorkshire]

A new scripting language

Bloodknight confirmed for iterally worse thanStarfish Hitler

[rlranft]

• A new scripting language - vague
• C# implemented - available
• A scripting language like GML (Game Maker Language) - why?
  -
• AI System - Navgraph, planner, fuzzy state machine - vague, I'm guessing just some basic tools? Navigation is already present with recast/detour. State machine is already there, how the end user decides to trigger state transitions it is up to the end user.
  -
• GUI system Overhaul for Torque 3D - vague
  -
• 3d skybox - "skybox" is by definition 3D
  -
• Animation Blending - I think you mean "improvements" - animation blending has been a thing for over a decade, it's just not great
  -
• Steps in the FPS Tutorial for how to compile Torque3D for the first time. - this doesn't belong in the FPS Tutorial, It's about making an FPS, not building the engine. A link to this information (which already exists elsewhere) would be more appropriate.
  -
• Use a Plug-in Architecture so all the Add-ons could work together - Which add-ons? ALL the add-ons? Because some are redundant and some are mutually exclusive....
  -
• Convert data serialization over to use TAML - pros and cons
  -
• In game cinametics - I thought GMK was part of the engine now....
  -
• Forest Editor to support multiple forest objects per mission - but it already supports multiple brushes, and brushes can contain multiple meshes. What need does this address?
  -
• Support for Intel Graphics Cards - this is backwards. Intel graphics cards have poor support for the features T3D provides. Or do we want T3D to reduce feature usage to allow running on inferior hardware?
  -
• wetness PostFX and wetness custom material - puppy shader confirmed.
  -
• Torque Smart ptr: Shared, Weak, and Scoped - where? Rewrite the engine using these? or make them available script side (and how)?
  -
• More efficient / intuitive handling of the editor - using whose opinion as the metric?
  -
• More Simgroups/better managing (forest items, terrain materials...) - vague
  -
• Marble Class - What? One can create a sphere with mass using any of the available physics systems - what does a "marble" do that any other sphere does not?
  -
• Database: Simple and Complex - which DBMS?
  -
• Support for exporting game to the Flash platform - Under what license?
  -
  - redundant
• Upgraded sketch tool
• beefing up the sketch tool
  -
• Jitter in terrain system between terrain and models - Need to add jitter? Remove it? What jitter specifically? This sounds odd - how reproducible is this? Never seen it before....
  -
• Feature: "externalCommand" for Torque 3D - Again, in what context? Engine-side you can do this at will. You want a script command that will allow execution of third-party code outside of the game? Ever hear the phrase "recipe for disaster"? "Your game deleted my C:\ drive!" "Your game sent my credit card information to a bank in Tunisia!"
  -
• GuiHealthHud - a C++ replacement for the scripted numerical health hud - Okay, but it's crazy simple to use a GuiBitmapCtrl and resize it to show reduced health....
• Add new GuiBitmapStringCtrl that strings a number of images - guessing we're talking about some sort of animated bitmap control like the old IFL-animation system, but this is also a little vague.

I know, I'm being obnoxious. Consider this my wish list:

"Be careful what you wish for" and for Pete's sake be specific and detailed. And filter for redundant wishes - I'm sure many of these are already on the roadmap. Much of what is in that list is either available, available with a little thought, or project-specific and therefore inappropriate for inclusion in the engine (I suppose examples would be nice, sure, but don't put your AI solution in there because I'll just have to remove it).

I like all of the "improvement" items, except where vague. Some items are too open to interpretation or too subjective - how do we make the editor "more intuitive?" The only really "counter-intuitive" thing off the top of my head is GUI placement and resizing constants - they're poorly named and when you look at it it's hard to think of "better" names, so they stay poorly named (I mean, once you see what they do they describe it correctly, but until you see what they do they make no sense).

Stuff like "Intel graphics cards" gets me. "This looks like crap on my Intel graphics card." "Yeah? Well at least it runs on it...." is where we're headed with that one. Unless we're still just bailing because it's Intel. This used to be an issue because the Intel cards reported no support for power management features that the engine needs to prevent screen saver activation and monitor shutoff. Do we want to remove this? Should we just allow the game to run and then listen to the users cry because their monitor goes to sleep in the middle of a game? Sounds to me like that's a developer decision - if I want that headache over the "This won't run on my Intel card" headache then that's my choice.

So, tldr, some are vague, some are redundant, many are subjective.

[Azaezel]

[*]In game cinametics - I thought GMK was part of the engine now....

Nope. Last word on that (still) was the things fatal in spots.

[*]Forest Editor to support multiple forest objects per mission - but it already supports multiple brushes, and brushes can contain multiple meshes. What need does this address?
[*]More Simgroups/better managing (forest items, terrain materials...) - vague

Will note there's an opengl bug with multiple meshes per forest brush casing corruption. Different brushes per forest is a thing that does work iirc. would need to tripplecheck.
Of more concern (or at least more often mentioned is the fact it writes the brush definitions all to one file.

[*]wetness PostFX and wetness custom material - puppy shader confirmed.

James Stanley actually threw us a partial I've been keeping a copy of https://github.com/Azaezel/Torque3D/tre ... teness_bbq though as you'll see https://www.youtube.com/watch?v=-y6s73A8TqY the math still needs work and I haven't had time to follow up. Someone wants to swtich from asking to doing, by all means.

[*]Torque Smart ptr: Shared, Weak, and Scoped - where? Rewrite the engine using these? or make them available script side (and how)?

Engine actually already has weak and strong pointer divides, so theres 1/3rd of that request already.

[*]Upgraded sketch tool
[*]beefing up the sketch tool

Being worked on by JeffR

[*]Jitter in terrain system between terrain and models - Need to add jitter? Remove it? What jitter specifically? This sounds odd - how reproducible is this? Never seen it before....

https://github.com/GarageGames/Torque3D/issues/914

Re-add terrain erosion

https://www.youtube.com/watch?v=IFmp9sX8xRM done a little research there. needs proper action classes and some math reworking vs the quickie-hax, but the baseline noise class still seems to work.

Add full support for Linux Operating Systems to Torque 3D
KEY FEATURE - Please keep Torque-3D-Linux Generic (Non-Os and Non-Version specific! )

Last thing* needs doing that's been reported is file save dialogues. either native gui via sdl plugin, or go the torque gui route.
* (barring glew replacement down the road for some non'standard' linux distros)

Shader Composer / Material Editor

This would be the part where I start binge-drinking, right?

Add full support for Mac OS X to Torque 3D
Export to mobile platforms
Play through web page, with streaming capabilities

Oh, wait, no, this is.

Multiple CPU Core Usage (for skinned meshes especially)

Better to fix the remaining flaws in the hardware skinning fork from James.

CgFX Shader Language integration

Do we reeeeely need a third language to maintain?

Add placement of physicsForce objects to the World Editor

That anything like the physicszones that are already A Thing?

Bigger brushes

Is literally a oneliner. That shouldn't be a request. That should be a PR. C'mon now...

Open GL 4.x support for Torque3D -check it off.
RayInfo distance with ContainerRayCast - The capability of getting this has been a thing for more than a decade...
DX11 Support - viewtopic.php?f=40&t=473 -check it out.
Better Zip file functionality - https://github.com/GarageGames/Torque3D/pull/1466 -check it out.
Improved Color Picker - https://github.com/GarageGames/Torque3D/pull/1334 -check it out.
Create an Open Source Alternative to Torsion - http://wiki.torque3d.org/introduction:scripting-ides - should clarify what further integration is needed.

hitboxes aka locational damage - part of E/C

[rlranft]

[*]In game cinametics - I thought GMK was part of the engine now....

Nope. Last word on that (still) was the things fatal in spots.

Darn.

[*]Forest Editor to support multiple forest objects per mission - but it already supports multiple brushes, and brushes can contain multiple meshes. What need does this address?
[*]More Simgroups/better managing (forest items, terrain materials...) - vague

Will note there's an opengl bug with multiple meshes per forest brush casing corruption. Different brushes per forest is a thing that does work iirc. would need to tripplecheck.
Of more concern (or at least more often mentioned is the fact it writes the brush definitions all to one file.

Hmm. I have yet to have an actual problem with this. Does it still munge up the forest saves occasionally?

[*]Torque Smart ptr: Shared, Weak, and Scoped - where? Rewrite the engine using these? or make them available script side (and how)?

Engine actually already has weak and strong pointer divides, so theres 1/3rd of that request already.

Yeah, but the rest of this is just odd anyway - while VS2015 acts up when using T3D's current template stuff, VS2013 is fine with it and you can use the STL smart/strong/weak/scoped pointers at need when adding new stuff. Do we really need to go and rework thousands of lines of code for this? Or create a custom set of templates for them? This entire request just seems odd because these are language extension features in C++ (if we're talking engine-side, of course) and not really engine features (because T3D's weak and strong pointer implementations predate solid STL implementations).

[*]Upgraded sketch tool
[*]beefing up the sketch tool

Being worked on by JeffR

Was just pointing out the redundant requests and subjective nature thereof.

[*]Jitter in terrain system between terrain and models - Need to add jitter? Remove it? What jitter specifically? This sounds odd - how reproducible is this? Never seen it before....

https://github.com/GarageGames/Torque3D/issues/914

Huh. Nope, never had that problem either.... Nasty, though.

[chriscalef]

bigger brushes

I don't know the one line fixes all solution, but here's an example one liner for forest brushes...

Code: Select all

void ForestBrushTool::setSize( F32 val )
{
   mSize = mClampF( val, 0.0f, 15000.0f );//instead of 150.0f...
   Con::executef( this, "syncBrushToolbar" );
}

Re: some of the other items, I know it's not production ready but I'm definitely working on the terrain paging thing, and have PhysX vehicles on my roadmap although I can't commit to a date for them yet. Also interested in several of the other items. But unless it means moving over to C#, which is already pretty well established, good luck with pushing another scripting language.

[JeffR]

• 3d skybox - "skybox" is by definition 3D

Most of the other stuff has been pretty well covered, but I thought I'd comment on this:

This is referring to what the UT99 engine or GoldSrc/Source did for skyboxes, where you basically have the skybox read from a dynamic cubemap probe in a little sub-area in the map. That way, you could model your terrain and add other details/models, and it would act as a dynamic skybox rather than a static image. This is useful for dynamic situations, such as, say, a huge distant forest fire and having the smoke from that animated, while very much perceptually being in the distance.

It would also come with the advantage of playing very uniformly with dynamic lighting from the sun/sky.

So yeah, pretty legit request, actually. It'd definitely have it's uses.

[chriscalef]

Well that does sound quite interesting!

Say, while we're on the subject, can anyone tell me anything about what might be involved in order to implement a skydome instead of a skybox? I searched around on this site and garagegames, and didn't find much, but apparently this guy has done it.

Not sure off the top of my head how to create a hemispherical image, but it's obviously a problem that's been thoroughly solved by now. Beyond that wouldn't it just mean drawing a spherical object in place of the box, and inserting it at the same place in the render?

[JeffR]

This may act as a decent starting point:

https://msdn.microsoft.com/en-us/library/bb464016.aspx

And yeah, could probably just copy the skybox object, rename it to skysphere, have it render in the same order the skybox does now and just have it use the skysphere shader.

[Azaezel]

By and large once you peel off the proceedural colorization and account for the foreshortening, that's scattersky in a nutshell. https://github.com/GarageGames/Torque3D ... y.cpp#L755 for instance would be one to manipulate if working off of that as a base to turn into a full sphere*.

*Disclaimer, Oversimplification. just doing so to that will lead to (admittedly hilarious but) useless results due to the aforementioned shader-side procedural colorization.