Jump to content

Recommended Posts

Hey everyone!


Figured I'd make a post on the status for 3.9, as we're getting pretty close at this point to RC'ing it and getting a release out there!


Quite a bit of work's gone into 3.9 so far - Linear texture color, proper Deferred lighting and then DirectX 11 support, shorting up lots of parts of OpenGL and work to stabilize Linux, among a lot of other minor improvements and fixes!


The tentative lock-in date to start testing the RC is the end of the month, with a few features to add in yet, such as fixing Linux's lack of file dialogs, and getting my Entity/Component work added into the engine behind a experimental flag(so people who are curious can begin playing with it, while not distrupting any existing work with the standard game classes) as well as a thourough run-through of any other bugs and improvements we can cram into it.


So what's next after 3.9 is out?


Excellent question, Bold-Text-Reader-Stand-in!


From there, we begin to push towards 4.0. Yes, I know, these are version numbers, not decimals, and we could just as easily have 3.10 if we wanted ;). But the numerical roll-over reflects something we've been planning for version 4 for quite a long while now. With 4.0, we're going to be making big changes, and some of them are going to be breaking changes for existing projects if one doesn't update to match.


The break in backwards compatibility in some areas - the art pipeline most specifically - means that it's a sort of line in the sand of 'If you don't really want to deal with porting these big changes, then 3.9 is safe, but after this there may be some large shifts'.


An example of this is the overhaul of the base template I've been working towards to make it less hardcoded and easier to drop in content and packs. Another would be Dropping DirectX9 support. Yep, that's going the way of the dinosaur. It's important, because that frees up a LOT of options that DX11 and modern OpenGL provide, as well as being able to restructure some DX9-oriented parts of GFX to make it less....well, DX9-oriented. This would make it MUCH easier to begin looking towards DX12 and Vulkan, as well.


Another huge one would be switching over to PBR-based rendering. This is another pretty hefty change to the art pipeline, because it impacts materials and rendering in quite a significant way.


So all in all, 4.0 should end up being a pretty huge jump forward for T3D. It'll be bumpy for existing projects if they wanna jump up with it, but I'm fully invested to documenting and making whatever wiki pages or the like needed to make it as smooth a transition as possible.


Just wanted to throw down some info-bits as we move in on the kill for 3.9, and give some light detailings for what to expect for 4.0. If you've got any particular inquiries, feel free to toss them in here :)


Peace out,

-Jeff

Link to post
Share on other sites

What changes are there that would break the art pipeline? Only thing I know so far are the PBR textures, but this can be solved with a slider to adjust roughness and metalness for each texture, it is not as good as a roughness and metalness map, but it should work, right?

Link to post
Share on other sites
What changes are there that would break the art pipeline? Only thing I know so far are the PBR textures, but this can be solved with a slider to adjust roughness and metalness for each texture, it is not as good as a roughness and metalness map, but it should work, right?

 

PBR is the big one,yes. However, we're also looking at stuff like assets as opposed to direct paths to art files and the like, which would impact existing levels and datablocks. Been talking about how to make the import process for assets nice and easy, but it would still require some conversion work with existing projects.

Link to post
Share on other sites

So it is like an auto replace operation? I'm already used to it, since if you use the full path name to the asset, often you will need to update it, if you move assets around, so you have to search the whole object and replace all the path names in the objects used then.

Link to post
Share on other sites
So it is like an auto replace operation? I'm already used to it, since if you use the full path name to the asset, often you will need to update it, if you move assets around, so you have to search the whole object and replace all the path names in the objects used then.

If you move an asset into another module, then it's a chore, yeah. Assets are usually given IDs like so:

%spriteObj.setImage("AssetModule:TheImageAssetName");

So if you move the asset to another module you'll have to do a search/replace of that... yeah.

Link to post
Share on other sites
So it is like an auto replace operation? I'm already used to it, since if you use the full path name to the asset, often you will need to update it, if you move assets around, so you have to search the whole object and replace all the path names in the objects used then.

If you move an asset into another module, then it's a chore, yeah. Assets are usually given IDs like so:

%spriteObj.setImage("AssetModule:TheImageAssetName");

So if you move the asset to another module you'll have to do a search/replace of that... yeah.

 

Yeah, having to manually change assets like that is a pain. I'd already started some R&D into an asset browser/manager to help deal with that kind of stuff without having to touch on it manually.


Simplifying the import and export process, as well as being able to move an asset into a different module and have the editor tool propagate that change will be huge timesavers.

Link to post
Share on other sites

It was removed from T2D before it went out the door, but I wrote a TAML "visitor" that would walk TAML scene files and update asset and object names. I might still have some code that could be used as a starting point, or leave it as an exercise for the reader...


T2D's Asset Library interface was pretty nice:

Image assets - if the image was defined as multi-celled, it would have a set of browse arrows to scroll through the cells.

http://www.roostertailgames.com/images/3ssassetlib.png


Animation assets - this would play defined animations right in the library preview.

http://www.roostertailgames.com/images/3ssimagelib.png


GUI images - this excluded the "internal" editor assets, and these assets were used by the underlying template to replace default assets for the game GUI

http://www.roostertailgames.com/images/3ssguilib.png


Sound assets - clicking the sound "preview" plays/stops the sounds.

http://www.roostertailgames.com/images/3sssoundlib.png


So, some ideas. Probably could make (using the GUIObjectView)"Model," "Material," "Decal," etc.

Link to post
Share on other sites

@rlranft


That's pretty much *exactly* what I was looking at doing, yep.


Though the plan was to have a tree view for easier module management as well. The R&D test pass ended out with something like this:


http://ghc-games.com/public/AssetBrowserWIP.png


Obviously not truely functional, but it proved the basic concept well enough. With it having the tree view of the modules and THEN broken down by asset type, it would make it easier to do the 'move an asset to a new module' by simply drag-n-dropping on the module it needs to move to, etc.


It'd also have the search and tag filtration stuff like what you've got there(the eye button would bring a pop-up for filtration of types and tags).

Link to post
Share on other sites
  • 1 month later...

As a complete noob to Torque3D I can see why it is not seen by many in a favourable light. I wanted to do what I thought should be simple... fit a turret to a vehicle. Well I managed to get it to be on the vehicle but not managed to get it to rotate. When the vehicle drives the turret jitters like it is not in sync with vehicle. After hours of searching I found a 2 year old post dealing with this and issue but it still seems to be an issue in the current version.

So it is great to hear about the new stuff in 3.9 but is all of the 'old stuff' working correctly? There seem to be many posts detailing all sorts of code fixes required and many of them going back years, but most of the issues still exist in 3.8.

Is anyone actually ensuring that all these bugs get fixed or is it more important to get new stuff and people who want to use the engine must try and patch it?

Link to post
Share on other sites
There seem to be many posts detailing all sorts of code fixes required and many of them going back years, but most of the issues still exist in 3.8.

Is anyone actually ensuring that all these bugs get fixed or is it more important to get new stuff and people who want to use the engine must try and patch it?

 

Heh! Welcome to my life :? This engine is a nightmare for artists, don't get me wrong I love it, but still a nightmare thought.

Link to post
Share on other sites

I don't think it is a nightmare for artists, I found it one of the easiest engines from the artist standpoint, just build your stuff, drag and drop and done. The nightmare only starts if you want to code new features.

Link to post
Share on other sites

I don't want to start this kind of discursion on this tread but I'll jus say this.


Importing from Blender (the ONLY tool you can use for free if you want to do decent models) equals to at least tree days of research, and still not quite right.

No multiple UV's supported.

Bugged animation tools.

Making LOD's manually is a pain in the ass for today standards.

If you want to lightmap don't even bother on using the editor for making your level since you have to lightmap in external tools.

Sketch tool is completely useless as it stands.

Good luck on making animated materials without coding skills.


And the list goes on and on... So believe me wen I say IT IS A NIGHTMARE.

Link to post
Share on other sites

-Importing from blender is just pressing the button "export as DAE" and with other modeling tools it will not be easier.

-Multiple UV maps are supported, I used them.

-Animations works fine, animate in blender, export and set up the animations in Torque.

-Everyone has to make LOD by hand, there is no known tool that automates it all.

-Yes, lightmaps have to be made in blender, but you don't really need them and if so you can utilize the multiple UV map feature for it.

-Sketch tool is not completely useless, it is just bugged. There is also an updated version from JeffR that improves it a lot, no idea how far he is with it. There was also a guy that did a complete game in a game jam with the sketch tool.

-Animated materials work fine as well, you can just click the different animation methods in the material editor and they work.


So yes there are some problems here and there, but your statements are mostly false.

Link to post
Share on other sites

My skills are mostly in embedded systems using C and IS project management.

Due to the various versions of Torque it is very difficult when searching for help, to know what has been fixed in the current version, what tutorials will work

and what features exist and can be expected to work correctly.

As new user of T3D I would like to make the following comments that might be of some help going forward. Some of this might be 'common' knowledge to the

experienced Torque users, if so please just accept it, as mentioned already I am a T3D noob.


In no particular order...

 

  • A line should be drawn at some version, for example 3.8. Then the wiki, resources and forum should have that as a separate starting point where only stuff that applies will be found.

  • A list of known issues ie. things that dont work correctly should be made and put on a page where it can be checked. (maybe not every small bug). This will stop multiple bug reports and also help noobs to figure out if something should work or not.

  • There should be some common base class that all objects / shapes use which has stuff like mounting in it. It should allow anything to mount to anything and all in the same way.

    Many FPS games have tanks / robots / vehicles with working gun turrets... Surely this should be one of the standard operations that a new user can achiever fairly simply?

    These are games not the real world. We want people mounted on rocks mounted on robots each with a gun turret.... lol ... anything to anything. (I can suggest how to do it but I am sure the C++ guys here already know)

  • There should be a place where simple examples can be found. Templates are okay but they will always be very specific.

  • If editors / script functions dont work 100% then perhaps they can have some sort of pop up comment in them that alerts users

 

Okay this is my 2 cents worth at the moment ... hey I am new .. only tried making a tank so far. Feel free to add to this list.


I am willing to assist with getting some of this stuff sorted out

Link to post
Share on other sites

@flysouth

There is only a small number of people working on the engine and they do it voluntarily, so there are not really people working full time on documenting things etc so maybe you could offer your help.

Yes, other engines often have examples like a tank with a turret, but if you just drag and drop an already build model with already build code into your project, did you really achieve anything? And it is not that common to have working examples of anything in the engine, often you need to buy it as an addon or from asset stores. I know for example of cry engine having an example tank with turret in the game, you can just drag and drop it, very simple, but if you want to reconstruct how it has been build it will take you a while as well.

Link to post
Share on other sites

I have not looked at the way Cryengine works. I also understand that the people doing the coding are volunteers and I appreciate their effort.

I don't expect to drag and drop a tank, but I would expect that I should be able to put a working turret and tracks on a vehicle without having to change the engine code.

All my point is that adding new features is great but perhaps some of the more basic requirements should be fixed. Using the turret as an example... yes you can mount it,

okay at this moment I am not sure if it will rotate and change pitch.. I am still trying to get that figured out. But once it is mounted I would expect it to move in sync with the vehicle.

Unfortunately this does not appear to be the case and has not worked for at least 2 years. So surely it would make sense to fix it especially when people have already worked out what needs to be changed in the engine?

I dont expect the documents to give a working example of how to make a tank. But it would be nice if it showed how to mount a working turret to a vehicle.

Link to post
Share on other sites

Importing from Blender (the ONLY tool you can use for free if you want to do decent models) equals to at least tree days of research, and still not quite right.

please elaborate on points of confusion. either here, or in a focused thread.

No multiple UV's supported.

As Duion said, at time of writing, lightmapping references a given modeles secondary UV channel. please elaborate on what all else you'd want to use them for.

Bugged animation tools.

like?

Sketch tool is completely useless as it stands.

what additional or altered functionality would you like to see.

Good luck on making animated materials without coding skills.

http://i.imgur.com/zcuNWrO.jpg

Not sure what you mean there...

 

Due to the various versions of Torque it is very difficult when searching for help, to know what has been fixed in the current version, what tutorials will work

and what features exist and can be expected to work correctly.

In no particular order...

  • A line should be drawn at some version, for example 3.8. Then the wiki, resources and forum should have that as a separate starting point where only stuff that applies will be found.

Yeah, when these forums were initially being cooked up, the initial plan was for it to be 4.0/rework focused before Stuff Happened. As is, the bound is generally around 3.7ish.

 

  • A list of known issues ie. things that dont work correctly should be made and put on a page where it can be checked. (maybe not every small bug). This will stop multiple bug reports and also help noobs to figure out if something should work or not.

If it's just to jot down bug notes there's https://github.com/GarageGames/Torque3D/issues hashing out particulars to fix complex issues would be where the forums/irc/skype comes in.

  • There should be some common base class that all objects / shapes use which has stuff like mounting in it. It should allow anything to mount to anything and all in the same way.

    Many FPS games have tanks / robots / vehicles with working gun turrets... Surely this should be one of the standard operations that a new user can achiever fairly simply?

    These are games not the real world. We want people mounted on rocks mounted on robots each with a gun turret.... lol ... anything to anything. (I can suggest how to do it but I am sure the C++ guys here already know)

main root at time of writing for most assets (and the root being used for the entity/component work) will be Gamebase Class

note it's bipartite: someClassData for data shared across all object-instances, and someClass for the object-instance end. The Shapebase Class is a bit higher-order which in conjunction with shapebaseimage comprises the lions share of interactable content root. (player, vehicle, item, camera et-al being a subclass of shapebase at present, with, again plans to replace those based on Jeffs work https://github.com/GarageGames/Torque3D/pull/1615

  • There should be a place where simple examples can be found. Templates are okay but they will always be very specific.

that one's kindasorta what http://forums.torque3d.org/viewtopic.php?f=40&t=484 is about. or at least smaller chunks to digest.

 

  • If editors / script functions dont work 100% then perhaps they can have some sort of pop up comment in them that alerts users

elaborate?

Link to post
Share on other sites

flysouth wrote:

If editors / script functions dont work 100% then perhaps they can have some sort of pop up comment in them that alerts users

Azaezel wrote:

elaborate?

It was really based on what Janders said about the sketch tool. I have not used it so cannot comment on it.

I was just suggesting that if a tool is released in a version but it has some known issues then perhaps when opening the tool a message could be shown indicating that it is not a 100% working tool and problems can be expected.


Clearly it looks as if some of the stuff will be addressed in release 4 which will be great. For me I would just like to be able to use an engine that does not require the user to change the c++ code. Yes if you are doing some 'non standard' stuf it might be required but for the more common stuff I would expect it to be done in scripts

Link to post
Share on other sites
My skills are mostly in embedded systems using C and IS project management.

Due to the various versions of Torque it is very difficult when searching for help, to know what has been fixed in the current version, what tutorials will work

and what features exist and can be expected to work correctly.

As new user of T3D I would like to make the following comments that might be of some help going forward. Some of this might be 'common' knowledge to the

experienced Torque users, if so please just accept it, as mentioned already I am a T3D noob.


In no particular order...

 

  • A line should be drawn at some version, for example 3.8. Then the wiki, resources and forum should have that as a separate starting point where only stuff that applies will be found.

  • A list of known issues ie. things that dont work correctly should be made and put on a page where it can be checked. (maybe not every small bug). This will stop multiple bug reports and also help noobs to figure out if something should work or not.

  • There should be some common base class that all objects / shapes use which has stuff like mounting in it. It should allow anything to mount to anything and all in the same way.

    Many FPS games have tanks / robots / vehicles with working gun turrets... Surely this should be one of the standard operations that a new user can achiever fairly simply?

    These are games not the real world. We want people mounted on rocks mounted on robots each with a gun turret.... lol ... anything to anything. (I can suggest how to do it but I am sure the C++ guys here already know)

  • There should be a place where simple examples can be found. Templates are okay but they will always be very specific.

  • If editors / script functions dont work 100% then perhaps they can have some sort of pop up comment in them that alerts users

 

Okay this is my 2 cents worth at the moment ... hey I am new .. only tried making a tank so far. Feel free to add to this list.


I am willing to assist with getting some of this stuff sorted out

 

In general, everything on the wiki should be up-to-date. If you find that this isn't the case, the everyone can update it or if you do not feel qualified to do so, feel free to tell me or somebody else that it needs updating :)


You should be able to find all issues using the GitHub issue-tracker (you can find it here: https://github.com/GarageGames/Torque3D/issues)


In general, examples has been written into the code-documentation in the past, you can find a bunch of them in there. Personally I think they should be on the Wiki, there has already been some work on adding examples to the Wiki (look at: http://wiki.torque3d.org/wiki:_scripter-start). I think that when the examples are on the wiki, it makes it more accessible for people to edit, what do you think?


In regards to the common base-classes, I think, and hope, that the component-system will help alleviate this, at it makes it easy to create and share component which could be a "mountedTower" component or "vehicle" component ;)

Link to post
Share on other sites

that I should be able to put a working turret and tracks on a vehicle without having to change the engine code.

 

You don't really know how game development works, do you? Are you sure you're not looking for something like GameGuru or Axis Game Factory? Seems to be more well suited for your expectations and skill set.


T3D is not a nightmare, by a longshot. It was, however, completely abandoned for a long time. With the source release, it's slowly getting traction and being improved by the community. If you want to make a game with a few clicks, this is not the place. Never was, not even when it was a product.

Link to post
Share on other sites

A lot of people like to keep complaining "This is bugged", "This does not work", "It is a nightmare" etc... but most do not even bother to look into the code or try things out, since then they would realize it is not that bad at all.

This phenomena is called "confirmation bias", people want to see it a certain way and so they only seek for things that confirm their world views.


Fact is still, that Torque3D is the best open source engine for 3D FPS games around, so you cannot really complain.

Link to post
Share on other sites
×
×
  • Create New...