What would you like to see addressed in Torque 3D?

#101

Quote:
5. Built in minimap

Good feature request. I don't know if it will make the cut for Torque 3D but it will be added to the list for future versions.

Quote:
6. In-game particle editor system,

One of our internal devs is pretty hyped to tackle this but he has to get some other stuff done first.

Quote:
10. Fix bugs for Mac (it is still buggy with the terrain system and other small parts).

Do you have specific bugs that aren't already reported? To the best of my knowledge there aren't any bugs related to the terrain that are *specific* to the Mac.

Quote:
11. Ingame xyz editors and scaling (I don't want to type numbers everytime I want to rotate or scale an object)

Hold down alt or ctrl. These allow you to scale or rotate using the axis gizmo.

#102

Quote:with a *lot* of detail/texel density

@Matt - Are you targetting a high texture density, such as you seen in the detail of this screenshot?



Also, Are you planning on have support for bumpmapping, and specular per material?

#103

Quote:
First fix all outstanding bugs (some of which have a several year history) and fill in missing and broken (stubbed/commented) features and provide that for existing customers. We shouldn't have to pay for this.

If it is a bug that is fixable with a reasonable amount of engineering effort we want to fix it. Please list *specifically* any longstanding (or otherwise) bugs that aren't already fixed.

I agree that no one should have to pay for bug fixes (within reason) and we will be rolling any appropriate bug fixes back into TGEA 1.8.X.

I do say "within reason", however, because *some* of the "bugs" in Torque would take a major engineering effort to fix them properly and that costs us money. At some point the cost of large bug fixes won't be covered by the potential increase in revenue from a more stable product and we will need to charge money for it.

#104 Would love to hear any plans on interiors and DIF's. Are they being removed? If not, perhaps they are being improved? I'm not having any problems though, but (add this to your list!) source for the exporter would rock my world.

#105

Quote:
- Polysoup fixed (I strongly believe that there's a bug with rotated statics - still testing)

Please let us know if you find that bug (or any others). We *definitely* want polysoup collision to be rock solid.

Quote:
- Complete Mac version

What in particular are you missing from the Mac version? *Most* of the differences we left were because of Apple video driver bugs or because the engineering cost was prohibitive by our Mac expert's standards.

Quote:
- AutoLOD generator for objects that don't have lods and polysoup meshes for objects that don't need detailed collision / shadowing - to optimize system resources.

Mesh decimation is *really* tricky to get right. There has been some good R&D for this over in GG Studios but it probably won't make it into Torque 3D.

Quote:
- Make anything that's too game specific be switchable on / off in a modular way

We've slowly been modularizing more and more since we introduced the Project Generator. This will only get better over time. It can take a while to untangle some of these systems =)

Quote:
- Very detailed and versatile camera system

Absolutely! This is high up the list for Torque 3D. Does anyone have any particular requests to help us better focus our efforts here?

Quote:
- A uniform replicator system that uses script callbacks for defining replication rules

We are going a slightly different route than script callbacks but I think you'll find it very usable.

Quote:
- Editor should not assert (ever) when an inverse range is given - just clamp the last value instead - I usually develop in debug mode, and I've lost a tremendous amount of data due to reversed random values and such...

File a bug report so that we can make sure this doesn't slip through the cracks. Anything else you specifically are having trouble with in the Mission Editor?

Quote:
- Tools to optimize game art for speed and bandwidth

This is something we've talked about a lot as a long range goal but it doesn't currently have much by way of actionable items on the Torque 3D list.

Quote:
- Mission editor: Drag/drop, wyswyg texture and model selector / loaders, customizable interface (ie. if I want the tree on the left and the properties on the right - which I really do)
- Datablock editor, yes, though datablock storage and use would probably have to be reworked

I will make sure these get forwarded to the World Editor team.

Quote:
- Add NULL, please, even if it just means ""

Sounds simple enough.

Quote:
- Add %this and %datablock automatically

Little trickier but I will mention it.

Quote:
- A human starter model with correct proportions - Kork has got all artists creating 2.5-3m tall humans

This would probably occur when we do a model with a better starting pose.

Quote:
- Include a very detailed change log and patch with newer versions. There's lots of time to be lost deciphering what those new changes mean. Mention functions, methods, flags, etc...

At a certain point we start to lose too much dev time to staring at a diff tool (like WinMerge) and trying to explain what should be fairly evident to a competent coder with his own diff tool. We do focus on the biggest changes and pitfalls that you will encounter if you are a developer familiar with a previous version (like the TGEA 1.8 "gotchas" doc). We'll strive to continue to improve our changelog but we need to make sure it doesn't impact development time or documentation content generation for other areas.

Quote:
- Weekly patches - however small they would be - in between major versions

Weekly patches can cost us a *lot* of time to prepare and manage. Also, as pointed out in by others in Brett's blog, they can actually add a lot of burden on the developers who are trying to stay up to sync ("wait...that patch broke what?"). In general this kind of thing is really only useful to a very small segment of our community.

One thing I would be interested in exploring when we get some more webdev resources available is adding a public bug tracker (managed) that would allow users to hunt for bugs and apply fixes they find in resolved bugs (probably would include the source files affected and expect the user to do a manual merge). This is further out however.

Quote:
- Pay-for-view resources (instead of content packs), where it's easier for artists to sell their models. It would still be moderated, but would work more like a vendor system where GG acts as a shop and as a moderator while artists and developers would have access to updating their products. This is almost the same as content packs now, still it would trigger a _huge_ number of new resources.

We aren't currently ready to explore push-to-publish.

Quote:
- Host files images and video, so no external providers are required.

That's more of a website request than a Torque request but we feel your pain here.

Quote:
- Let users control who has access to a resource they have submitted.

The problem here is when users allow access to a resource to users who *shouldn't* be allowed access. This is the main reason our resources are moderated: so that we can ensure that only the people who should be able to see it do.

Quote:
And finally, I think it should actually perform better than its predecessors. :)

Agreed. TGEA 1.8 was a *massive* replacement of the biggest system in the engine (GFX). In the short term it traded some performance for better features (stateblock and shader constants) and we simply ran out of time to address all of the performance issues (at some point you *have* to ship the version you are working on so that you will have enough money to keep working on it =P). We will be looking closely at these performance issues and rolling any fixes we can back to TGEA 1.8.

#106

Quote:
At some point, I would like to see GG focus on reducing Torque 3D's footprint. Make it an engine that is far more friendly for lower powered devices.

I think this is a longer term project.

Quote:
I'd also like to see consistency in coding practices throughout the engine.

Slowly but surely this is getting cleaned up. TGEA 1.7 was a *huge* leap forward over TGEA 1.0.3 in terms of code consistency and our internal Torque R&D is getting a lot of love here.

You will always have minor inconsistencies when you are dealing with as many different people as Torque and over the course of as long as it has been around (I code fairly differently now than I did even 2 years ago).

Quote:
GUI updates. Many of the GUI controls have just been thrown into the engine will little regard for efficiency or tidy coding. It would be nice if they had an update.

Sound like I might need to see about getting some of your time off Torque 2D ;)

#107

Quote:
More power to scripting, you shouldn't have to do any source modification to make any type of game.

This is definitely one of our areas of focus. I don't think it is possible to push the current generation of Torque technology to the point where you could make any type of game without source modification but I believe we can move the bar here.

#108

Quote:
One thing I would like to see is the the FxRenderobject maintained for all future releases of Torque.

It would help to have an example to look at when you you try and create a new renderable object.
TGEA has gone through some changes here lately that leaves me puzzled as to how TGEA expects an object to be setup in order to render it.

We were *just* talking about this last week and I already have it on the lower priority list.

Quote:
One problem I had with it was it made reference to being able to be setup as a mirror like object but as far as I can tell no one every documented how to achieve this effect.

It is currently only achievable with Interiors and you can see a working example of it over in TGEDemoAdvanced.

Quote:
New Physics for vehicles would be nice.

For Torque 3D we are going to be focusing on refinement of the existing vehicle physics...largely driven by LUMA/BLUR/Racing Genre Kit. We are also going to try to put some limiters to the speed/velocity/etc to help keep people from trying to do stuff outside of the intended ranges of the existing system.

One of the first games being built with Torque R&D is a racing game with an all new vehicle physics system so there are changes coming down the pipe (long ways out right now).

#109

Quote:
The mission editor desperately needs a nudge tool, one that can be toggled on and off by holding down a key. It can be a pain to change the move scale back and forth every time you need finer control. I had one coded at one time and was planning to release it as a resource, I may still do that if I can ever dig it up again, but its definitely something that everyone would get a lot of use out of if it were stock.

This is the perfect type of suggestion to make for Torque 3D. Right size/scope and generally useful to all Torque developers but easy to overlook when we get caught up in bigger "features". Keep 'em coming!

#110

Quote:
* implement mission & datablock caching.

Probably not going to happen with Torque 3D but we agree and already have it on the radar.

Quote:
* integrate gecko or another HTML rendering engine, replacing GuiMLTextCtrl.
(this may requite a more robust HTTP object, see below)
* integrate some SWF engine to effectively replace the GuiControl system.

Good suggestions but I suspect they are a *little* too big for this pass.

Quote:
* replace HTTPObject with a libCurl implementation.

We will look into it.

Quote:
* scrape the resources for bugfixes and improvements to various components. there are *tons* of improvements just waiting to be integrated into trunk.

This is what we want to do however there are hundreds of thousands of resources and we need your help to find the best ones. Please link them in as you find them!

Quote:
* provide a system for changing clothes & appearances of characters.
there are numerous resources for this; GG should take the lead and "bless" an approach.
personally i recommend using mesh-hiding and the advanced texture replacement code in combination with a "sku" system which defines clothing items. ie, don't ghost down the names of the meshes and the names of the textures to use, just ghost a list of SKUs.

I agree that GG needs to take the lead on this and "bless" an approach but we've never quite had the right convergence of time and interested developer to make it happen. I suspect this will get visited by us officially when we get to an RPG Genre Kit.

Quote:
* support for alpha in all guiControls, and inherit alpha from parent.
** eg so you can set the alpha of an entire dialog, not just one control at a time.

Good one. I'll get that added.

Quote:
* improve player-vs-player and player-vs-environment collision.

Quite difficult in our pair-wise networked physics world.

Quote:
* provide a default doors system.

I agree that this is a *huge* gap that Torque has had for a very long time. It needs to be fixed but it is a little lower priority than some of the other stuff planned for Torque 3D so we'll have to wait and see.

Quote:
* improve the out-of-the-box compilation story.
the last time i went to compile TGE on VS, i was shocked at how much time & effort it took me to get a vanilla engine to compile.

I'd be curious want version of TGE and Visual Studio you were using. To the best of my knowledge TGE 1.5.2 should compile cleanly on Visual Studio 2003 and 2005. TGEA 1.7.1 should compile cleanly on Visual Studio 2003, 2005, and 2008. TGEA 1.8 should compile cleanly on Visual Studio 2005 and 2008. Of course you need to install the proper DirectX SDK and Windows SDK where it is appropriate (covered in the Getting Started docs).

#111

Quote:
21. Generic plugin/DLL loading system, that can register itself with the engine to provide functionality in the DLL to the scripting system. This would be especially good if you end up with a non-source version, so people could still get addons.

For example:

A Database system, self contained in a DLL. Exposes the connection methods to script, as well as methods to load & save data and run stored procedures.

We've done some light R&D here and run into some interesting blockers with shared memory space and all that. It isn't going to be a focus for Torque 3D and probably won't make it in but we are very interested in it further down the line.

#112 Hey Matt, thanks for replying.
Can i just say that you're responses in this thread have been absolutely fantastic.
diligent, fast, and to-the-point !

i have some brief responses to your responses.

>> replace HTTPObject with a libCurl implementation.
> We will look into it.

i'd be happy to provide some example code which results in a thus-far robust object implementing post, get, file upload, file DL, etc. it uses STL StringMaps tho.


> there are hundreds of thousands of resources and we need your help to find the best ones. Please link them in as you find them!

will do!


>> improve player-vs-player and player-vs-environment collision.
> Quite difficult in our pair-wise networked physics world.

a simple improvement which doesn't change the network model is to simulate player bounds as cylinders instead of boxes.
for p-v-p this is fairly straight-forward, but i haven't looked into it for p-v-e.


>> improve the out-of-the-box compilation story.
> I'd be curious what version of TGE and Visual Studio you were using. To the best of my knowledge TGE 1.5.2 should compile cleanly on Visual Studio 2003 and 2005. TGEA 1.7.1 should compile cleanly on Visual Studio 2003, 2005, and 2008. TGEA 1.8 should compile cleanly on Visual Studio 2005 and 2008. Of course you need to install the proper DirectX SDK and Windows SDK where it is appropriate (covered in the Getting Started docs).

TGE 1.4, Visual Studio 2005 SP 1.
I recall having to edit system include headers, but don't think i had to install DX or Platform SDK.
I haven't tried TGE 1.5.

#113

Quote:
I know it's early days and all, but is BSP/DIF going to continue in T3D?

I like BSP, regardless of how old it is.

What specifically do you like about BSP? The dirty little secret of Torque is that Interiors don't actually use BSP for most of their collision! They only use it for determining which zone you are in and for ray cast/line of sight type collisions. They use a "bins" or grid-based system for the actual polylist type collisions (like Player or Vehicles). I know! I thought it was pretty funny when I realized that TSMesh collision was actually stricter about convexity than Interior's =P

I do think that editing in "BSP" (aka convex brushes) can be a lot more approachable for the average coder or coder/artist since the tools are generally simpler and the modeling is more like playing with blocks or legos (and the projective textures is *simple* unless you are trying to do something fancy).

As I mentioned above, we've found that the rendering "optimizations" that the Interior class is doing (like zoning) is actually costing us a lot of performance on most video cards these days.

For Torque 3D we are going to be exploring loading DIF models directly into TSShape (like we currently low DTS) and making use of the better rendering functionality there. We will also be moving over some of the nicer features from Interiors (like planar reflections) and will have a solution for lighting and lightmapping. This will allow us to focus on a single "mesh" rendering pipeline rather than having to split our efforts on the aging Interior rendering technology. We are going to try some clever things to get *some* of the wins of visibility occlusion (treat "zones" as sub-meshes combined with the sub-mesh frustrum culling).

We'll be doing a lot of testing on this to make sure that it is a good solution for you guys but I think it will be a good intermediate step away from "BSP" to polysoup levels.

#114

Quote:
@Matt - Are you targetting a high texture density, such as you seen in the detail of this screenshot?

Also, Are you planning on have support for bumpmapping, and specular per material?

I *ahem* can't get into that yet =P

#115

Quote:
I would like the ability to have in-game sounds fire events to objects in their audible vicinity. That way we can have AI that *actually* can hear things instead of the hacks we have been using.

I'll add it to the list but I suspect we won't have time to get to it for Torque 3D.

#116

Quote:
- right click contest menu (like in the collaborative design tool)

I believe we've already made the decision to not include a right-click context menu in this version of Torque 3D (what do you guys think of the name "Torque 3D 2009" btw?) because it would require more reworking of the editor than we'd like. We *do* want it to be in a future version.

Quote:
- menu structure reworked (more logical and more intuitive)

Please provide what you think would be a more logical and intuitive menu structure =)

Quote:
- fields like position, rotation scale etc having now a unique field to be splitted in X, Y, Z fileds every with is own spin +/-)
- world inspector & similar windows semitransparent (better if you can select the amount of transp.)
- world inspector and world creator windows unified with collapsible sections for each
- in inspector windows a sections giving hints about the field you're editing
- in inspector a way to edit a simfolder(simgroup) position, rotation, scale and have all obects inside it moving/scaling the same amount???
- for fields image related (as detail texture and so on) a select window with a preview of the image files so you can visually choose it
- for many fields where you have constraints in editing (ie I can choose only power of 2 values) a spin to choose it or a select box with valid values
- for fileds where you choose shapes (like in replicators) a select window with preview of it
- for shapes listed in world creator the possibility to rightclick>preview to see a window with a preview of that shape...

All good stuff that has a chance to make it in.

Quote:
Ok, I was meaning something like VMPlayer, giving the ablity to easily play, pause, stop, fade tracks, load and play Playlists, react to event call (for example the player entering a trigger area or the player die and the tracks currently playing fade into another track...) something like that :D

We might be able to address some of that but our sound guy (Tom Spilman) is *swamped* with Torque 3D so we'll have to wait and see.

Quote:
BTW: ok some plan possibly to integrate showtool if I understand correctly... also some plan to integrate constructor and to bring to it shaders?

ShowTool will likely remain a stand-alone tool for now with the ability to load DTS with the newer format and Collada files. It would take a *lot* of rework to add shader support to either ShowTool or Constructor (3-6 months each minimum). Before that happens we are going to be looking at pulling some of the ShowTool functionality into the World Editor (perhaps as part of a mesh previewer).

#117

Quote:
I'm not having any problems though, but (add this to your list!) source for the exporter would rock my world.

Yeah...we just haven't quite back around to adding the map2dif source for TGEA to the SDK (it got removed internally when GG Studios stopped using Interiors early last year). I'll add it to the lower priority list.

#118

Quote:
>> replace HTTPObject with a libCurl implementation.
> We will look into it.

i'd be happy to provide some example code which results in a thus-far robust object implementing post, get, file upload, file DL, etc. it uses STL StringMaps tho.

Send it my way!

Quote:
>> improve player-vs-player and player-vs-environment collision.
> Quite difficult in our pair-wise networked physics world.

a simple improvement which doesn't change the network model is to simulate player bounds as cylinders instead of boxes.
for p-v-p this is fairly straight-forward, but i haven't looked into it for p-v-e.

I have wanted to spend time on that enhancement for a *long* time now (I still have notes from when I was working on TGE 1.5) but it's never quite happened. If you have any code you can share, I'd be more than happy to look at getting it into the engine!

Quote:
TGE 1.4, Visual Studio 2005 SP 1.
I recall having to edit system include headers, but don't think i had to install DX or Platform SDK.
I haven't tried TGE 1.5.

I *vaguely* recall TGE 1.4.2 compiling out of the box on Visual Studio 2005 Express (pre-SP1) if you had the Platform SDK installed but to be honest the last time anyone touched that was mid-2006 so it has been a while. No biggy though...we do try to keep our new releases in sync with the new releases of Visual Studio and to make sure that the out-of-the-box compile is clean*.

Little known fact: I got my start with GG and Torque (then V12) by porting the commandline-only compilation process that Dynamix used for Tribes 2 over to Visual C++ 6. I had previously dealt with some pretty horrible compilation experiences in the open source community and was determined that Torque would launch with a clean, one button compile and I succeeded (except for the whole .cc/registry file issue).

#119

Quote:What specifically do you like about BSP? The dirty little secret of Torque is that Interiors don't actually use BSP for most of their collision!

*Gasp!*

I was thinking about the lighting and lightmaps, but I see you've mentioned that. Zoning I'm not too bothered about.

I made a 9762 surface DIF which runs with lovely performance (and it's all exterior so no zoning). Originally it was a DTS with polysoup but the performance wasn't good, so I exported it from Blender as a Q3map and got it out of Constructor with map2dif_plus_TGEA.

It'd be nice to keep making square mile interiors. :)

edit: markup typo

#120 Quick question since I haven't been on the forums for 6 to 7 months. Is TGEA 1.8 is for OSX (Mac) or is for windows too? I have Windows XP Pro and the last update I installed was TGEA 1.7.1.