Work Blog - JeffR

  • 1
  • 2
  • 3
  • 4
  • 5
  • 39
388 posts Page 2 of 39
LukasPJ
Site Admin
Posts: 409
Joined: Tue Feb 03, 2015 7:25 pm
 
by LukasPJ » Thu Jun 11, 2015 12:14 am
I want to extend a HUGE thanks to Lukas though, he kicked off the initial TAML implementation, and I just took it, made it a bit cleaner an integration, and rolled the asset/module stuff over to work with it.
Image
JeffR
Steering Committee
Steering Committee
Posts: 929
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Jun 11, 2015 12:38 am
;)
chriscalef
Posts: 381
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Thu Jun 11, 2015 8:13 am
Dude, you are awe inspiring. Can't wait to DL all this and try it out!
JeffR
Steering Committee
Steering Committee
Posts: 929
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Jun 11, 2015 7:58 pm
Alright, so. Dat writeup.

First order of business, is if you're unfamiliar with TAML, Assets, or Modules, here is some pre-emptive reading:

https://github.com/GarageGames/Torque2D/wiki/Taml-Guide
https://github.com/GarageGames/Torque2D ... ager-Guide
https://github.com/GarageGames/Torque2D ... ager-Guide

So what is this actually good for, and what does it mean for T3D going forward?

As mentioned in prior posts, I've already started utilizing it in the Entity/Component stuff with the scripted Game Objects.
However, in a broader sense, this ecosystem would be utilized elsewhere as well.
For example, mission files could be converted to TAML, which would allow us to parse and edit mission files without needing to generate the objects in the mission file first.

Modules specifically would be incredibly useful in moving the templates to a packages system like we're hoping. You'd have a stock barebones template, and then pick several packages in the PM that are installed into that barebones template for you, such as editors, default content, etc.

Modules also would make it easier for people that want to enable mod support, as mods made by players could just be contained into a module and automagically work.

The asset system will allow for a MASSIVE amount of improvement and streamlining of the current content workflow. As it is now, it works, but is pretty finicky, and expects stuff to be organized a certain way. This would allow for the content browser I'd mentioned earlier, for one.

Instead of the current system of having a collada model, it load in torque, gen the cached DTS and hope that the materials and textures are named correctly, etc. The content browser would be a one-stop-shop for the entire content pipeline.

To import a new model, for example, you'd open the content browser, and click to import a model(or drag-n-drop into the browser window!). This would automatically parse it and generate an asset file. From there, you could readily attach tags, or tweak the various settings on it, which would be written into the asset definition itself. Eventually it could probably replace the shape loader system we have now.

Textures/Materials could be loaded the same way and utilize the loose references that the Asset manager enables. So rather than needing the models' textures to be in the same directory, and be named a specific way to match what's in the model file and hope that the cached shape file doesn't flub anything. It would utilize loose references so you could organize your files however you want so long as they have the anticipated name. Files could even be reorganized without it breaking all your art.

And with the mentioned tags stored in the asset def itself, it could work like an expanded version of the tags system in the material browser currently. So you could group assets of various types by certain tags, and then ALSO filter by asset type, to find the content you need, rather than needing to remember where you put it in the game directory.

And this doesn't even touch stuff more down the line, like revamping Shadergen with a visual interface that would probably utilize TAML and Assets, and so on.

So yeah, this opens up a lot of options that'll improve a lot of different parts of the engine experience, which is neat.
buckmaster
Steering Committee
Steering Committee
Posts: 321
Joined: Thu Feb 05, 2015 1:02 am
by buckmaster » Sun Jul 12, 2015 9:53 am
Hey, does the file change detection work on TAML files? How easy would it be to hook into that and reload the level live as you edit a TAML file, like they demoed for T2D before it went MIT?
JeffR
Steering Committee
Steering Committee
Posts: 929
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Wed Nov 11, 2015 7:57 am
Right, so, been a bit since I updated the workblog, so time to do that!

This'll be a quick run-down for now, and I'll do a more in-depth one when I'm not supposed to be going to sleep.

New Template
One of the biggest problems people have had to deal with was the bifuricated template approach. When doing PRs you had to remember to edit both templates' scripts, when testing PRs you had to remember to test both, and there's the fact that the Empty template is simultaneously too empty to be a starting point for a full game without serious work, but also too full to act as a complete barebones template.

So, a new template is needed! Good news is, is I'd actually been slowly working on a new template for a while now for my internal stuff, based on Dan's old barebones template. I'm working to finalize it and be a proper base template.

LOADS less code duplication, and the game mode logic is a whole lot simpler to deal with. I should be able to set up the full template's stuff as a drop-in package instead of needing to be a full template on it's own, which should drastically streamline PR edits and also make it easier to work with on a whole.

New Project Manager
The old project manager worked, but it was only on windows, and QT is kind of a whale, so we'd been mulling on doing a new PM that was a stripped down version of Torque(ensuring that if T3D ran on the platform, the PM would as well).
The barebone guts of this are actually working, the main holdups on this are:

a) the cmake script integration so regular peeps don't need to mess around with cmake directly if they hate it, they just click the major feature/settings like the old PM, and it does all the dirty work in the background and
b) the above mentioned template to simplify down that entire mess.

Entity Component work
This has, of course, been chugging along as well. Spurred by the trouble Az and Timmy were having with DX11, hardware skinning and all the mesh rendering junk, I took the time to start stripping out the specific logic from TSShapeInstance and shove it into the respective component.
So MeshComponent directly deals with all the render logic rather than handing off to a shape instance, and the animation component will do the same.

This, when finished, will allow quite a few things to happen.

A) the compartmentalization can be back-ported to TSShapeInstance, which means
B) deep changes like hardware skinning should be easier to track, as there's less spiderwebbing
C) We can look at overhauling the render logic to be more efficient
and D) re-boxing all the mesh handling stuffs allows for us to go back and re-attempt Assimp, which stonewalled because it was a mess trying to get it to agree with the existing code. With everything being compartmented and less insanely spider-webby, it'll be much more feasible to try and get Assimp's output rolled over, which opens up a lot of formats for everyone to use.

This work also let me fix a few potential bugs with entity interpolation as well, so that's a neat bonus.

I think that's the major things for the moment, though I'm sure I missed some stuff. As said, I'll come back later and do a bit more in-depth breakdown on this stuff, and anything I missed.

Peace out!
JeffR
Steering Committee
Steering Committee
Posts: 929
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Wed Nov 18, 2015 6:30 am
So, update.

The new template is most of the way there now. Basically just chasing down bugs and then gunna document the ever-loving-crap out of it.

I did make a small detour this evening for 20 minutes or so and did a proof-of-concept on a graphical metrics/profiler ui:

Image

It's based off the netgraph ui.

The plan would be to base it off Chelaru's profiler PR as a base, which adds the nice conveinent ui hooks and filtering settings, and have the gui part be in a window. It'll have different tabs for the various info being profiled, such as general, shadows, networking, etc.

The end goal would be to not only have it nicely display the profiler as a history graph so you can see how it's running over time, but allow it to write out the profile info to files that can be loaded up and compared against, so you can see how a change impacts the performance compared to what it was before.

Should provide a LOT better info that can be used to optimize/isolate problem spots.
MilkywayM16
Posts: 38
Joined: Sat Oct 03, 2015 7:26 am
by MilkywayM16 » Wed Nov 18, 2015 5:13 pm
That sounds amazing
chriscalef
Posts: 381
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Wed Nov 18, 2015 6:00 pm
♥♥♥
JeffR
Steering Committee
Steering Committee
Posts: 929
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Sun Nov 22, 2015 7:09 am
So, doing more work on the new template. think I'm nearly done with the bug testing pass, so I decided to start working on the UI a bit more, specifically, the menus:

Main menu:
Image

Options menu is seeing a total overhaul:
Image
Image

And it'll have a real pause menu as well:
Image

The options menu, as you can see, has a lot more options than the old one already.
In actuality, it's just exposing stuff that was already in there, but either hidden, or grouped into the pre-existing categories. In the interests of letting end-users better fine-tune their performance, exposing these settings just made sense.

There are several additional preference/scaling options I've got a mind to get added as well that should further let us dial performance in.

The postFX settings can, as you can see, be enabled/disabled by the user. If it's set to on, it'll use whatever the map's settings are(so if the map doesn't HAVE any HDR settings, it's still disabled), but if the client decides "SSAO is too expensive on my machine, I'll disable it", that works now.

Parallax is another major cost hog on lower-end cards, so being able to specifically disable that should help a great deal.

The UI style in general is designed to have a clean, generic look, without looking bland or not-game-like.

The big issue with the old UI style is it felt like you were using an accounting program with the way you had windowed dialogs, and the aesthetic of the buttons and the like. The new template is more like a game ui, while being generic enough that it can be utilized as much or little as needed, without feeling excessively samey.

Obviously you should customize your UIs, but if you have to leave the options menu as-is, then at least it shouldn't feel as weird and out of place as the old one ;)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 39
388 posts Page 2 of 39

Who is online

Users browsing this forum: No registered users and 4 guests