garagegames / torque3d Goto Github PK

Was it intentional that the svn history was not imported? Seems like a shame, considering how far back a lot of these files go.

As it stands, the Torque3D download is pretty big. A certain amount of that is unavoidable, but one thing really gets me: there are four templates, two of them near-exact duplicates (Full and Full PhysX), and the other two subsets of the first two (Empty and Empty PhysX). The Full PhysX template is almost 250MB. Surely we can devise a way to share assets between templates?

Aside from download size, this would also have advantages in maintenance. For example, if we want to make template script changes, we wouldn't have to modify the same script four times, or leave three templates unmaintained. The game/core and game/tools directories would particularly benefit from this.

http://www.garagegames.com/community/forums/viewthread/129094

Originally from THREED-3147

I've tried this with several different models, stock torque and otherwise.

In the process of "cleanig up" all my 3d assets and testing them with T3D.

All the custom models I tested load up and "seem" to be fine - no errors, animations work, etc.

However, when loading them in T3D1.2 ShapeEditor ... and try to save the shape as a new dts using saveShape() function ... (even without making any changes) ... most of them caused the editor to start writing the file, then crash.

The custom models were fixed by re-importing using the COLLADA and using SingleDTS "detection".
This created a LOD(2) by default – and NONE of the models had issues with saveShape() after that.

... So I then proceeded to make the required mount points, eye, cam, etc ... and so on.

NEXT -

I then turned to the standard Torque assets ...

"Boombot" has detail levels, but still causes a crash when trying to save in shape editor view
//in console //
ShapeEditor.shape.saveShape("./test.dts");

... Soldier, Alien saved ok

Then I tried some of the models purchased from GG stores ... and had same issues as my custom art.
It loads and works fine – but saveShape() crashed when trying to save to a new file. Even with no changes.
And most all of that content had LODs, etc ... already built into the DTS models.

Could it be an issue with DTS v24 versus v26 ? Or just a coincidence ???

Here are specific steps to reproduce the crash;

Load T3D 1.2 / FPS Example

Hit F11, enter editor mode ... select shape editor
load art/shapes/actors/boombot/boombot.dts

open console window, type:

ShapeEditor.shape.saveShape("newShape.dts");

... crash.

This is the only place I noticed it but found it a bit odd. Not really a bug, but think it should be changed none the less. In Engine\source\platform\types.h

getMin for both float and double (line 221 & 227) use the words float and double rather than the typecast F32 and F64 where as all the others use them.

Simple enough change. Once I start getting pull requests working I can add this if someone else doesn't before me.

Originally from @ex:

I can't find the instructions about how to compile using VisualC++, neither I see a make file. This need to be more easy to find.

Original response from @jamesu:

Project files are generated using the "Torque 3D.exe" toolbox. Alternatively you can copy one of the templates in the "Templates" folder and run the "generateProjects.bat" file which will generate the VC++ project files.

Original response from @DavidWyand-GG:

We should add a Getting Started guide either in the repo, or the Wiki (and point to it from the repo).

http://www.garagegames.com/community/forums/viewthread/129117

Originally from THREED-3128

Build: 1.2 Pro

Platform: Windows 7 64

Target: Game

Issues: Whenever the host of a game exits the level it crashes any clients that are connected.

Steps to Repeat:

1. Host a Full PhysX template game
2. Join the game via a second instance of T3D
3. Exit the Host instance of the game
4. Notice that the client has crashed because the Host left

Move all files from the staging repository into this one.

This issue is worth the $. It helps us port core files.

There are enough regression tests we could include that would quickly exceed our quotas. The solution is RTS, ray-traced scenes, but that discussion, I know, is off-topic here.

The COLLADA profile attribute lets us choose between library arrays, so that file is optional. The intent is obvious, and I am not that kind of minecraft-bitcoin base advocate. I did, however, consider the build-button with bit-coin code-behind on the completion dialogue.

This may mean nothing after any aspect of the OSI event has past, yet in my experience gg may want to wrap string dates with in $ comments. It is good exercise for the semantic recollection process. We can batch string replacement statements. My preference is by schema techniques rather than by semantic reflection. Our code arguments would often collide.

Inventory systems do not collide, and language skills should not be an issue in the presence of $. Every optimization is another technique definition.

$infinite = "Mathematic infinite."

Accept quotes, like spoken speech, or we will never understand each other. I think of an OSI event more like forged steel that takes awhile to cool. At this point, I reconsidered jsLinux as one of your targets for T3D.EXE. It would be ideal for .ts files, and your target may reflect generated profiles.

I know, an issue, so I am back in my corner with it to lay this out by license nodes, like another library choice by n-profile and n-technique.

Sorry, this is not blog grade. This is my spin on xs:String transitions. "I'm trying to stay out of your core due to license issues." I like the general rule of thumb that every string entry is an asset, which activates the $ character in library-script context, like some bit flipped for tainted input.

Convex-meshes have that input context. Other than that, it was code-shopping.dae in here. Thanks.

At the moment Torque3D is stuck in 32-bit land. This is somewhat problematic as it introduces overheads on 64bit windows (i.e. WOW64), and perhaps other platforms too.

I've noted there have been a few efforts by people in the past to allow for compilation of 64bit binaries, but it would be nice if we could compile 64bit binaries out-of-the-box.

Problem points I've noticed previously when attempting a 64bit port:

• Some of the hashing functions (e.g. in StringTable & Dictionary) return strange numbers causing the tables to be indexed incorrectly
• The DTS loader assumes pointers are 32bits
• The script compiler inserts pointers to strings in the opcode list, but opcodes are 32bit

Build: 1.2 confirmed, though I've seen it happen for as long as we've had HDR
Platform: Windows 7 64 bit
Target: PostFX
Issue: HDR does not treat the sun as a bright object

Something I've noticed for a while and been meaning to ask about. When you turn HDR on and start at the sun, everything gets really bright, presumably because the HDR shader doesn't register the sun as a 'bright' object. Is there anything we can do about this?

Reproduction: Open up Empty Terrain from the Full template, add HDR via the PostFX manager, look at the sun. Everything becomes brighter when it should become dimmer.

As described here

Open the Torque 3D repo to the public.

Bug and potential solution reported at:
http://www.garagegames.com/community/forums/viewthread/131998

other player's pose not appear on multiplayer game.

missed 'mPose' variable in player::writePacketData() and player::readPacketData() function.

Bug and potential solution reported at:
http://www.garagegames.com/community/forums/viewthread/131919

With Pull Request #19 an empty light type was added to T3D. We should remove this empty light type in a manner that stills allows T3D to compile on Windows and Linux.

Originally from THREED-1678

The tabs in a tab book render on top of the GUI Editor actual interface.

Steps to replicate:
Drop a GuiTabBookCtrl, with at least one GuiTabPage in it, into a gui near the top. Make the Gui Editor window smaller height-wise so that you have to scroll to see the bottom of the gui area. Scroll down and the tabs should render on top of the Gui Editor buttons and drop down boxes. Also can drag the tab page over top the Gui Editor gui and it will render on top of the interface.

cpu : Intel Xeon i7 W3503
memory : 4GB
vidCard : NVIDIA Quadro FX 3700
soundCard : none
hdSpace : 387GB 0f 465GB
connection : Broadcom NetXtreme 57xx GB

On older models of ATI cards that can run torque perfectly fine there are lines around terrain squares. It would be nice to fix this if you want players with older machines to play your game

Example with details
https://dl.dropbox.com/u/25535993/squaresize-texture-problem.jpg

Example without details
https://dl.dropbox.com/u/25535993/squaresize-texture-problem-no-details.jpg

How to reproduce
Create a new terrain, set the gridsize to 4, paint two textures over the terrain, look at the areas where the textures are blending

Currently seen on
At least 2 machines with ATI cards

Other threads about this
http://www.garagegames.com/community/forums/viewthread/124104
http://www.garagegames.com/community/forums/viewthread/126391
http://www.garagegames.com/community/forums/viewthread/90863
http://www.garagegames.com/community/forums/viewthread/112035

Some binary chunks (Torque 3D.exe) are missing source files. '

eg.
[Torque3D] grep "Would you like to generate a project" * -R
Binary file Torque 3D.exe matches

With a fresh clone or ZIP download, clicking on the Torque Toolbox's Play Game button will crash the Toolbox. The work around is to first create a new project based on one of the templates.

The solution is to correct this when the open source version of the Toolbox is released.

First reported: http://www.garagegames.com/community/blogs/view/21886/3#comment-187339

Discussed cause: http://www.garagegames.com/community/blogs/view/21886/3#comment-187351

Bug and potential fix posted at:
http://www.garagegames.com/community/forums/viewthread/131958

After modifying the console variable system I noticed that console variables were being added more than once in Con::init. If for example you put a breakpoint in "EditTSCtrl::consoleInit()", you'll notice its called at least 12 times. For "ShapeBase::consoleInit()", 8 times.

The issue seems to be when you don't override consoleInit in a derived class the ConcreteClassRep helper ends up calling the nearest implementation in a base class. Since ::consoleInit() is only usually used to define global variables, the extra calls are essentially redundant.

e.g.

// Calls MyConsoleObject::consoleInit during console init, great!
class MyConsoleObject : SimObject {
   static void consoleInit();
};

// Calls MyConsoleObject::consoleInit() during console init, ...
class MyDerivedConsoleObject : MyConsoleObject {
};

// Still calls MyConsoleObject::consoleInit() during console init, ...
class MyOtherConsoleObject : MyDerivedConsoleObject {
};

Possible solutions:

1. Create an empty consoleInit function in the next derived class.

2. Use a more flat class hierarchy.

3. Expose consoleInit in some other way which prevents this duplication.

See this thread -> http://www.garagegames.com/community/forums/viewthread/120473/1

I rewrote the color picker recently to be quite a bit better. I submitted it as a resource here: http://www.garagegames.com/community/resources/view/21931

And was going to fork the torque build and make a pull request but github for windows keeps crashing on me.

Along with the improved color picker there are several other code additions that alone could be added to the head build.

I may end up adding an eye dropper tool as well to it later on, but we will see.

Let me know if you see any issues with the changes or anything.

There's a rather large error in the README.md.

Compiling Torque 3D

Navigate to engine\build\Visual Studio 2010
Double-click the Torque 3D.sln file.
When Visual Studio 2010 is fully loaded, press F5 to perform a clean build.

This folder doesn't actually exist in the Engine directory, so as of right now it'd be pretty hard to open T3D in VS without going through the tedious measures required to make the solution from scratch.

If the PhysX SDK is required to create these files, then that's also a problem as the Nvidia Developer Zone is still down as of a few days ago.

As displayed here - would be a great addition to stock torque

http://www.garagegames.com/community/resources/view/19259/1

Originally from THREED-3077

New TSStatics will sometimes get re-positioned when in Camera Orbit mode.

Steps to reproduce object re-positioning issue:

1. In a new empty project start an empty level.
2. Place a shape by going through the meshes tab.
3. Activate camera orbit mode.
4. Rotate the camera about 90 degrees in any direction
5. Place another shape by going through the meshes tab.
6. click in the position text box in Inspector.
7. right click in the main view. The object should now be re-positioned to the location of the first created shape.

Workaround: After creating the second object, click on something else and then select the object again.

I don't remember how I found out about this or how it happened, but in stringFunctions.h shouldn't dAtob use dAtoi(str) instead of dAtof(str)? I see I made the change in my build but I can't remember why, I think it caused some bug.

object rendering transform problem in guiobjectview control.
missed some code when engine update.

http://www.garagegames.com/community/forums/viewthread/127491

Originally from THREED-2488

Build: Torque 3D 1.1 (1.0 is affected too)

Platform: Win32

Target: GFX/Cubemap

Issues:

1. At some angles, while both shapes in view, the cubemap "resets" when you "looking around" (the first 10 seconds of the video).
2. Two TSStatics with same material (with cubemap enabled) are somehow affecting each other (the rest of the video).

Video:

http://www.youtube.com/watch?v=4xlncv4kDCk&feature=player_embedded

Steps to Repeat:
Start empty template, drop meshesart/shapes/rocks/boulder.dts, switch to Material Editor, set Cubemap to something like "NewLevelSkyCubemap" (which I used for screenshots).
Now, copy the TSStatic and fly around.

Suggested Fix:
None yet.

Under Windows 8 the Torque 3D Toolbox crashes upon load. Here is a copy of the problem signature provided by windows.

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name: Torque 3D.exe
  Application Version:  1.0.0.1
  Application Timestamp:    4eb78f5c
  Fault Module Name:    QtCore4.dll
  Fault Module Version: 4.3.4.0
  Fault Module Timestamp:   47bb2a8f
  Exception Code:   c0000005
  Exception Offset: 00001cb6
  OS Version:   6.2.9200.2.0.0.768.101
  Locale ID:    1033
  Additional Information 1: 5861
  Additional Information 2: 5861822e1919d7c014bbb064c64908b2
  Additional Information 3: dac6
  Additional Information 4: dac6c2650fa14dd558bd9f448e23afd1

http://www.garagegames.com/community/forums/viewthread/127435

Originally THREED-3168

Build: 1.1 Final

Platform: Any

Target: TS System

Issues: As title

Steps to Repeat:

1. Launch the game
2. Enter on the World Editor
3. Place a really complex shape with more of 16 bones that influences a single vertex.

Suggested Fix:

Increase the default number of the bones that can influence one vertex in the tsSkin

Around the line 392 of the ts/tsMesh.h:
view plainprint?
class TSSkinMesh : public TSMesh
{
public:
struct BatchData
{
enum Constants

{ // Increase the BonesPerVert value for complex skinned mesh -> //maxBonePerVert = 16, // Abitrarily chosen maxBonePerVert = 128, // <- THE NEW VALUE // <- Increase the BonesPerVert number for complex skinned mesh }
;
...

With the move to the open source version, FMOD support had to be removed. Rewrite FMOD support to follow how PhysX works with Torque 3D.

Originally THREED-1706

When using the River Editor, if you try to adjust any of the points by just clicking and dragging (without using the positioning gizmo), they river will "snap" and get distorted

Steps to reproduce:

1. Open the River Editor and build a basic river
2. Switch to the "Move Point" tool
3. Click on a vertex on the river and while still holding down the mouse button, drag the mouse in any direction
4. The river will snap and get distorted

From the GG forum (http://www.garagegames.com/community/forums/viewthread/131946)

With the latest build of the Toolbox (1.1 Master branch), the Package Project button is no longer working to trigger the packaging code.

I dont know if this change was intentional, but the template/buildFile folders do not include .sln files in the VC20** projects, and therefore, generated projects do not include them.

Originally from THREED-1709

When creating a decal, if you scale the decal with the "Scale Decal" editor, one the decal reaches a certain size, it will disappear and other decals around it might blink (only had the blinking happen a once or twice)

Steps to reproduce:

1. Create a flat terrain (easier to see this way)
2. Open the decal editor and choose a decal (I was using the "ScorchRXDecal")
3. Paint a few decals, have some overlap others
4. Click on the Scale Decal and click on a decal
5. Using the scale gizmo, click on the bottom box to allow you to scale in both the X and Z directions
6. Keep scaling and the decal will disappear, and if this was a decal overlapping others, the decals around it might blink

I don't mean compile and make a working copy of the engine (I doubt there's enough UNIX code to do that), but as in get to the compile stage.

There's quite a few of them, and I can't help but wonder if they are really needed, because to those of us not on windows the binaries are just useless garbage. It would be better to put them somewhere outside the repository.

Going forward, would it be useful to solidify style guidelines for the Torque codebase, so that submissions maintain consistency?

Originally from THREED-2543

Crash when DAE shape that player is standing on updates because of change.
See a video of the problem here: http://screencast.com/t/eHWiEytcii

I can't find the instructions about how to compile using VisualC++, neither I see a make file. This need to be more easy to find.

I think this is definetly a much needed feature. It's quite tedious to restart the engine everytime you change a variable or a callback.
Dan Keller wrote a resource for it here:
http://www.garagegames.com/community/blogs/view/21262
And i can from experience say it works flawlessly!

While the AIPlayer is following a path they will slow down as they approach each node. It would be better for the AIPlayer to only slow down as they approach the last node. If the path is a loop, then the AIPlayer should never slow down.

http://www.garagegames.com/community/forums/viewthread/125435

Originally from THREED-1668

Build:
T3D 1.1 Preview (not sure about previous Betas)

Platform:
Any

Target:
decal editor.

Issue:
When rotating a decal and then reverting with CTRL+Z (or undo from the "edit" menu)
■The decal doesn't revert to the previous orientation [EDIT:] but to an arbitrary orientation becoming messy /EDIT
■Sometimes also all the 3 axis representations get skewed or ends laying on the same plane
■Sometimes the decal is also nomore taking in account the alpha opacity it previously had

Click to enlarge :

Click to enlarge :

Repeat:
Open Deathball Desert level. Select a decal and rotate it. Then try undo the operation.

Follow the steps you can reproduce this problem:
Create a player datablock, and set renderFirstPerson to false, and don't assign shape to it. And spawn the player. It will crash.
If I must set a skeleton model to it, and this model must contain the animation, I think it's no problem. If I don't want to do that, it will crash. I investigated the problem. I found actionCount is never initialized to zero, because the initialization will be ignored in PlayerData::preload if the shape is null. And in Player::setActionThread, we should check this variable to avoid the crash.

Sorry :D

Compared to other embeddable scripting languages, TorqueScript on average is quite slow. Anyone who has used TorqueScript heavily in an iTorque project has probably realized this. Mobile devices are of course slow, but it seems to me even doing simple things in TorqueScript is costly.

After actually benchmarking a rather simple function call ( https://gist.github.com/3737516 ), I was shocked after seeing just how bad it can get.

I'm not quite sure what the best way of tackling this is, so I'll provide as much information as I can in this Issue.

My tests seem to indicate that function calls in TorqueScript appear to be quite expensive, whereas in other embeddable scripting languages this is far from the case. Variable lookups also appear to be costly though this is true of any scripting language.

For reference, I tested 6 methods of adding two numbers together:

• scriptTest1 returns p1 + p2
• scriptTest2 sets global variable $_R to $_0 + $_1
• scriptTest3 is the same as scriptTest2 except it copies the global to local variables (similar performance to test 1)
• scriptTest4 is the same as scriptTest1, except the addition is done in C (ends up being faster)
• scriptTest5 is the same as scriptTest2, except the addition is done in C (and is actually slower)
• scriptTest6 adds two literals with no function calls, and is the fastest

I've placed the specific code I used for benchmarking TorqueScript, Ruby and Lua in a gist: https://gist.github.com/3760645 . All results are in milliseconds, the last number being the average time taken.

Torquescript results (Macbook Pro 2010 2.4ghz):

Torque3D RELEASE
scriptTest1,2220,2196,2224,2248,2632,2304
scriptTest2,692,688,696,692,692,692
scriptTest3,2224,2208,2236,2220,2208,2219.2
scriptTest4,448,436,436,432,432,436.8
scriptTest5,964,956,960,960,976,963.2
scriptTest6,280,288,284,280,288,284

The worst case here is 2.3s in the pure script function call. It seems making a local variable is costly as test 3 is the second worst case. Test 5 is oddly slower than test 2, and would be even slower if I used the actual Con:: getIntVariable function which does an int->string->int conversion.

The best case is 0.29s, which beats mruby but not lua.

mruby results for tests 1,2,3,6 (latest version, Macbook Pro 2010 2.4ghz):

TEST,1,2,3,4,5,AVG
scriptTest1,642.965,616.527,607.443,604.453,607.673,615.8122
scriptTest2,717.744,717.211,716.863,726.13,714.424,718.4744
scriptTest3,729.728,726.318,722.327,728.388,722.21,725.7942
scriptTest6,490.863,481.995,495.214,484.136,481.721,486.7858

Note that the worst case here is 0.73s.

Lua results for tests 1,2,3,6 (v5.2.1, Macbook Pro 2010 2.4ghz):

TEST,1,2,3,4,5,AVG
scriptTest1,177.313000,173.866000,173.777000,173.635000,172.777000,174.273600
scriptTest2,365.673000,366.093000,366.950000,367.679000,373.810000,368.041000
scriptTest3,495.440000,493.399000,490.451000,492.778000,491.064000,492.626400
scriptTest6,151.421000,150.907000,150.767000,149.743000,151.732000,150.914000

Note that the worst case here is 0.49s.

I use VS2008 projects. When I try to build newly generated project in it, I get errors like that:

  Error 22  fatal error C1083: Cannot open include file: 'dinput.h': No such file or directory  c:\users\denis\documents\workspace\torque3d\engine\source\platformwin32\windinputdevice.h   37  test DLL

To correct these errors I add additional headers and libraries directories for DX SDK to "test DLL" project. But it is pretty inconvenient, because I want to regenerate IDE projects easily for example when I add files to source directory inside my Torque project.

I am unaware of the complete technical transformations that would have to happen for the current version of Torque to find its way onto consoles, but if this engine is going to be a contend with Unity we should probably work toward doing just that.

What major problems would we face in attempting to port the current version of Torque3D?

My understanding is that currently the Toolbox is written for an older version of QT that is not MIT compatible and that it's going to be updated for the latest versions of QT.

While I'm not normally for rewriting code bases from scratch, is there any particular arguments against rewriting it in Python with wxWidgets?

Reasons for:

• I can write it in an evening or a weekend (And I would volunteer to write it).
• You'll gain immediate cross platform compatibility without needing to recompile for every platform, or having three separate binaries for the three OS's.
• Changes and iterations can be fairly rapid.
• OS X comes by default with both Python and wxWidgets installed and ready for use.
• Linux usually comes with Python installed and wxWidgets is either already installed, or trivially installed.
• Faster iteration allows for things like proposed changes in Issue #15 to be added quickly and easily.

Reasons against:

• This would add both the Python and wxWidgets dependencies to the project or we'd have to require users to have downloaded it. This is pretty common practice, but I can certainly understand the objection. We do have the option of using something like Py2Exe, but that would be creating a special binary for windows.
• It would be a full rewrite. But again, it's simple enough that I could write it in a day or two.

Thoughts?