[JeffR]

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

[deathbravo]

may i post reply in this thread?

how mad a squad of developers you are!!!!
the logo of torque should be changed to 3 rockets.
and thanks for the hard working

[Duion]

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?

[JeffR]

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.

[Duion]

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.

[rlranft]

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.

[Timmy]

The PBR change over is more than just adjusting roughness and metalness. There is also the need to change all your diffuse textures if you want to get good results.

[JeffR]

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.

[rlranft]

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.


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


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


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


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

[MilkywayM16]

@

rlranft Why was that removed from T2D? It looks incredibly useful.