Work Blog - JeffR

353 posts Page 36 of 36
Steering Committee
Steering Committee
Posts: 908
Joined: Tue Feb 03, 2015 9:49 pm
by JeffR » Wed Mar 13, 2019 6:54 am
Hey guys, update time yet again!

With all the discussion about community status, what to do with the sites and all that jazz, didn't really get on a workblog last month, so this one'll end up being extra long. (I'll break this up into 2 parts and put the second part up tomorrow, these take be a good while to write without the bonus-length :P )

So, first bit to cover is the ever-specter


We were struggling with getting the blending/attenuation to play nicely when I last covered this, so we opted to ultimately go ahead and shift to utilizing a array-based system. Instead of each probe being rendered with a given shape(box or sphere) we instead shove everything into arrays - including cubemaps, thanks to our fair Timmy - and punt it all along to a fullscreen quad posteffect. This is actually great for performance, because it's a) consistent, b) 1 drawcall instead of tons of small lightweight ones and c) much more efficient as a baseline.

We've actually talked about shifting lights to a similar deal(this is actually a very common approach nowadays, though usually it's a grid of quads, not a single fullscreen) down the line, but for now just probes is fine.

This came with a number of benefits outside the above, namely in letting us actually process all the probes at once instead of trying to do blend and render state trickery to get them to add all together nicely which was the problem before. Now we just calculate each probe's influence(up to 50 active probes, currently) and blend the total contribution.

To that end, I ended up writing some visualizer modes so we could see the attenuation/unique probe contribution, which looks a little something like this:


As you can see, we're getting some lovely blending between probes, no weird jank and no flickering.

We can also visualize just the cubemap or just the irradiance contribution from the probes(which looks pretty neat:


Timmy's even been working on making sure it renders consistently in the editors(utilizing a skylight) so everything'll look consistent and predictable among other improvements/refinements to the flow of it.

For the base implement, we're pretty much down to an issue with the box mode where the influence area, if a rectangle, doesn't completely rotate right, but otherwise the base of it is done. There's some cleanup to do with it, but it actually works pretty much as intended.

Less 'obligatory for function' and more 'an extra layer of polish to tie everything together nicely' includes dynamic reflections, which for the near term we're going to look into re-activating per-object dynamic cubemaps(so if your car needs 100% dynamic reflections, it can have them, and leave everything else with probes) as well as Screen Space Reflections. If we don't get these slotted in for 4.0 it wouldn't be terrible, but we'll see what happens. If they don't they'll absolutely be a fairly quick follow-along since they just kinda slot in overtop.

If you want to play around with the PBR stuff, you can nab it from here: ... beArrayWIP

Up next, we've got the big ol' dump of PRs I did alongside all the excellent contributions others put in recently we've been working our way through. I highlight my stuff not because of ego, but because it's me stripping out all the changes from my internal WIP build to get rolled into devhead.Ended up getting 14 separate PRs rolled up with a few more I'm polishing up to get put up.
They're currently getting put through the wringer(az already noted a few problems I missed, which is why we test these things boys and girls) but when they go in, it's a bunch of bugfixes, a bunch of logic for the entity/component stuff as well as most of the work thus far on the asset pipeline, plus some new bits, like colorblindness visualizers:

Regular view:

With one of the colorblind modes on:

It's not 100% accurate, but it's pretty close to the example code I found for the different modes, and well more then accurate enough to be able to flip it on and see if there's any glaring issues with your game's color balance/aesthetic in regards to those with vision impairments.

Also a PR for adding gui3dProjectionCtrl which is a delightful gem that lets you attach gui elements to objects or points in the 3d space. Useful for objective markers, 3d interaction prompts and more.

Another one that'll be pretty big once we really start leaning on it in the future is the addition of the Scene object i've talked about prior for more centralized and expandable scene tracking and management. That also got a PR for the initial addition. You can see the list of PR's here:

Another bit I got some time on was to try and get Verve playing nice with the current builds. Multi-window support has issues right now, so in addition to the regular update work needed, I added logic to let you use the verve editor in the same canvas, just it's own window in the editor.

Still bits that need shoring up before that gets rolled in as a PR(as we do need a proper cutscene editor in T3D) but it's pretty close:


Modulification of Old Resources
Because we also need more baseline starting content for people to use, as well as examples of how people can utilize modules and the like, I started updating/porting various resources to modules for drop-in-and-go-ness. I've covered a few here I've tested before like the 3d main menu or AI guards, but I've also been testing out some other more involved examples as well.

One's like the PostEffect Library. Seen here, I combined some lighting settings in the desert map, with the Night Vision, monochrome and pixelate PostFX's from the library to create a FLIR thermal vision mode:

As well as an initial go at the UAISK:
Though I think that needs to updates to the editor UI there. Having to change pages via dropdown is so oldschool ;)

Likewise, at request, I went ahead and did an attempt and getting the Ubiq's old 3D Action Adventure Kit running with devhead. It's got a few rough spots, but a few people in the discord were already eyeballing at pulling some parts like the camera out to be more piecemeal and easier to integrate into general projects.
You can play around with that build here:

It's hardly a complete list but I did an initial outline of a spread of examples of said content that I'd like to have moduleified in the near future for people to easily drop in and start playing with here:

When I last messed with assimp, the basic geometry loading was working(mostly) but it was having issues with the bone transforms being handled right. I got some time last week to load it back up and fiddle with it, and while it still has some issues, I believe at this point it's mainly an issue of the transforms being correctly applied to the root so it cascades up correctly.

Otherwise we end out with a situation like this:

But as you can see, the actual geometry and UVs and all that are good. So if I can get the transform processing locked in, the basic implementation of assimp should be good to get a roll-in. This opens up a LOT of options, most notably FBX and GLTF2, both formats that are very widely utilized and supported in art packs and content tools alike. Having straight support of those should drastically simplify the art pipeline for everyone, so I'm pretty excited on that end.

[A quick detour back to PBR(but like, for art this time around)
One thing that's come up a lot recently is going back and doing an update pass to PBR-ify the old content packs, which is an excellent idea. Me, Blood, Az and a few others spitballed some ideas for a simple flow for that(including figuring out Substance's Automation pipeline tools) as well as using Gigapixel to upscale older, lower resolution images.
All fine ideas, but one shot I had fun with was loading up our venerable Cheetah into Substance Painter and just painting on PBR materials over the normal/diffuse maps. And with fairly minimal work, we definitely get quite a bit of visual 'oomph' out of it:


So doing this kinda stuff on the older content could make it look really good with the new lighting without needing to completely remake it all from scratch for no reason. So that's also pretty sweet.

Here's also a few shots of Gigapixel being used on older, lower-res images to make 'em sweet again:

Definitely lots of sweet tech to simplify making everyone's art as sexy as possible with the least amount of work possible. Always a good thing :D

Anywho, This is about the halfway point of updates. so I'll put a breakpoint on this bad boy(it's pretty long as it is) and get the rest of the updates done tomorrow, including updates to the roadmap and all that delightful jazz.
Posts: 311
Joined: Tue Feb 03, 2015 10:30 pm
by Steve_Yorkshire » Wed Mar 13, 2019 7:00 pm
Arrays, are there anything they can't do? I love arrays! 8-)
Also 1 drawcall sounds rather good.

However I am somewhat concerned by JeffR and his demonic naming conventions for harddrives ... :?
Steering Committee
Steering Committee
Posts: 908
Joined: Tue Feb 03, 2015 9:49 pm
by JeffR » Thu Mar 14, 2019 7:21 am
Part twu!

Mentioned prior was how there was a lot of discussion about how to improve, tighten and streamline the site and community experience. So we've had a jolly old discuss-aroo in the discord and have started putting together a game plan to help everyone be far more efficient and effective when working on their games or the engine.

The Repository(ies)
So, as everyone knows, the current primary repo is via the GarageGames organization. However, we don't have full administrative control and need to go trough GG to get high level stuff done like enabling add ons, adjusting permissions, etc.
Given their slow response time on such issues, it's obviously been a pain point for a while. So we've been plotting to move to a separate repo for 4.0, so I've been talking with Blood and Jon(since they jumpstarted other repos for consolidating documentation, content, resources, etc) to formulate a game plan, and here's what we've got scoped thus far:

Primary Engine Repository will go here:
It'll have the main engine repo, as well as documentation and directly related stuff

From there, we'll have other companion organizations/repos, such as: for resources, content packs like Adam's stuff he recently MIT'd for us because he is an excellent person, etc
and for demos, test packages, etc.

The reason for this structure is that it lets us directly lead to the main engine org and repo via the obvious name, but the Torque3D-* naming schema lets us keep things separate, but organized via a common naming convention so it doesn't get weird.

@ Bloodknight and @ Johxz have both accrued a huge stable of resources, documentation, demos and content packs, so we'll be shuffling this stuff around and begin consolidating all this delicious content into a more consistently structured and centralized place.

This is also convenient because it opens up possible options like the PM scanning the repos for content packs and the like to download.

@ Bloodknight got a ReadTheDocs page set up here: which parses the github repository to generate the pages(in addition to being downloadable as PDF and the like).
It also, nicely, lets us establish versioned documentation, so as things change, we can keep documentation topical to the current versions without losing out prior version info for people that are utilizing older builds.

On top of that @ Johxz already had jumpstarted updating various parts of the documentation, and as we get closer to 4.0's release(and afterwards as well) I plan to jump in and start typing(as anyone reading these blogs knows i like to do) up docs as well.

A slick bit of RtD is it lets us embed content directly, including linking to youtube videos, so we'll be getting a centralized channel set up and can get more complex-to-explain bits also covered in short video tutorials(in addition to longer form tuts) to really round out the documentation.

The wiki, meanwhile, will shift from the primary hub of documentation for everything, to more emphasizing community resources, snippets, tricks and other knowledgebase-y things, while leaving the core code and engine usage documentation to the RtD(as it's a more traditional form factor for docs and I feel people will be more comfortable navigating that than the wiki when you just want to figure out how to do something in the editor ;) )

I've been hashing out the breakdown for how we can better organize the docs and you can get an idea of where I'm looking at pushing the layout like so:


Community/Site Stuffs
The main landing site we have is good, but has largely just been coasting. Some info needs updating, we have a smorgasboard of new images and stuff to add to it, and some elements have begun having problems like the 'recent news' stuff. Similarly, ensuring lots of linkage between it, the wiki, the RtD, discord and all that means we gotta bring it in and set it up on the main Torque3D repo going forward.
This'll make it easier to maintain since it's centralized and opened up to maintainers, but also lets us ensure we can always draw all attention back to the main repos and keep an ecosystem going.

Typing to that, per Duion's suggestion, ensuring we then get analytics set up on the forums and landing page can let us track where people are coming from and to a degree their linking behavior. The more people feel they don't need to leave the site/discord ecosystem to get their information(as resources and documentation being scattered is one of the main issues the engine currently has) the more effective they'll be and it won't be frustrating to work with.

I've also been hashing out what parts to update on the ModDB page(as there's a lot) and what new images to upload since the old ones are not so great these days. Getting that updated and ensuring it links back into the site/discord ecosystem will go a good ways as well.

Asset Stuffs
So, I covered that I've got a big blast of PRs that mostly bring what all I've been working on out and ready to be rolled into the engine. Part of that is a good chunk of asset work and the pipeline relating to it.
I've obviously talked about it a good deal in these workblogs until now, but as a pipeline it's finally pretty bloody close for the prime time. I've got a few more refinements to PR, but then the core flow of being able to drop content into the window, run the importer and just have assets that are ready and rar'in to go will be ready for use and to get beat on properly by people.
From there, I plan to update various things that reference content directly, such as Material names or Image paths, and have them alternately support loading assets to make everything not competely shatter existing projects, but still fully integrate in utilizing assets rather than raw paths.

This'll then make it much easier to work with those modules I talked about in part 1 allowing people to better jumpstart their projects and quickly utilize and tie what those modules offer in.

Tying to that, I started some initial work on the Legacy Content Importer I mentioned prior. Fact is, hand-porting this stuff is a drag and isn't HARD, but is a lot of busywork.
So, I'm drafting the LCI tool to let you select content from old projects, packs, resources, etc by type(Shape, Material, Image, Scripts, etc) and then handle importing them into a Module for you so it can be dropped in and roll. This'll make it easier to get that ocean of content and resources T3D's got brought up and usable for modern projects with minimal work which is great news for everyone.

Static Level Geometry Baking
One bit that'd come up while I've been working with Az and the other guys working on Cogflicts was that the levels(which use a tile-based system for meshes) end up having a LOT of meshes, which means a lot of individual objects, which means lots of drawcalls.
For obvious reasons, this can seriously hammer lower end machines which is just as obviously not a good thing.

So, it'd come up a few times(I've even yapped about baking stuff in previous workblog entries) but I did a quick-and-dirty pass to do a baking system of the entire level's static geometry into large chunks(50x50x50 voxel cells).

It took a while to bake, unsurprisingly, but ultimately shaved off a LOT of drawcalls which obviously boosted performance appreciably. I lost track of the screens I made, so I'll recapture the compare shots and edit 'em back in here.

So that'll get further refinement as well as some additional features like being able to pause/resume(as a full bake takes a good while, depending on total tricount), being able to pick between voxel cells or zones, and being able to only rebake on areas that have seen changes.

So, obviously the E/C stuff has been getting worked on and has been getting refined over time as use cases and testing of it all comes up.
One aspect that's always bothered me is that the generally acknowledged ideal approach is what's called "Entity-Component-Systems". I'm pretty sure I've talked about it before, but as a brief refresher, you have Entities which are groups of Components, Components which hold data, and Systems which actually do the implementing.
This is efficient because it lets you very efficiently look up and process large amounts of entities and components via the implementing systems without needing to cache-thrash or other nasty things that hurt performance.

The problem has always been tackling this in an actually practical way though. Academic implementations are fine, but when you actually need to DO stuff with these things, it tends to turn into a quagmire quickly. But I haven't stopped pondering on it, and I've actually, indirectly, been doing a trail run as we implemented the array stuffs in PBR without anyone really knowing about it (tee hee).

In the PBR work, we have 3 objects, things, whatever.

ProbeRenderInst - a container class that just holds data about our probes.
ReflectionProbe - a scene object you place into the level that has a reference to a probeRenderInst for it's data, and whatever settings or editing you do are ultimately just contained inside that inst data
RenderProbeMgr - the render manager that iterates over our compact list of ProbeRenderInsts very, very quickly to process the data needed to render.

Does that sound familiar? That's because at a base level, it's reminiscent of the E/C/S structure. And it works rather well without losing out on being able to have objects save their data in levels or prefabs or whatnot, but still be very lean and efficient on the engine side of things which is great for performance in general.

So, while I've still gotta hash out some bits, I'm looking at updating the general structure of the Components somewhat to work through this setup. For existing components, it won't actually be a lot of work to update it, mostly just shifting functions that utilize/implement the component data into a system, but it should overall let us better handle common implementation stuffs(like different physics components that ultimately have similar data, just different needs can share a System without needing to do tons of needless duplication) to keep things cleaner and more legible.

It'll also be more efficient as the back-end stuff can sidestep the console system overhead, only touching that when scripts or save/loading happens, so we can keep the main game simulation loop as efficient as physically possible.

It may sound like a pretty huge change(especially for anyone that's already begun fiddling with Components and the like) but I can promise that it shouldn't take long at all to get the system, and the performance and code coherence gains should more than make up for it.

I'll get some concrete examples of this approach in the near future as well :)

Oh, and here's a link to that 'Big File of Ideas and Suggestions' ... sp=sharing
I figure to help keep a running list of...well, ideas and suggestions, consolidating it into one place will help ensure we don't completely lose track of stuff. It's mostly intended as a sort of corkboard rather than a concrete issues/ideas/tasks list.

So I think that's the bulk of everything that's been happening in the last bit. I'm sure I forgot some things and if so I'll be sure to do posts about it. I'll do an update to the roadmap tomorrow(today?) as it's already well into the AM here and it kind of snuck up on me. But we're quickly approaching getting everything rolled into a nice package we can start establishing endgame testing and Release Candidates on. Exciting times!

353 posts Page 36 of 36

Who is online

Users browsing this forum: No registered users and 2 guests