[JeffR]

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 )

So, first bit to cover is the ever-specter

PBR

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: https://github.com/Azaezel/Torque3D/tre ... beArrayWIP
PR-a-palooza

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: https://github.com/GarageGames/Torque3D/pulls

Verve
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: https://github.com/Areloch/Torque3D/tree/Devhead3dAAK

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:


ASSIMP
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

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.

[Steve_Yorkshire]

Arrays, are there anything they can't do? I love arrays!
Also 1 drawcall sounds rather good.

However I am somewhat concerned by JeffR and his demonic naming conventions for harddrives ...

[JeffR]

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: https://github.com/Torque3D
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:
https://github.com/Torque3D-Resources for resources, content packs like Adam's stuff he recently MIT'd for us because he is an excellent person, etc
and https://github.com/Torque3D-Demos 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.

Documentation
@ Bloodknight got a ReadTheDocs page set up here: https://torque3d.readthedocs.io/en/latest/index.html 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.

Entity/Component/Systems
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' https://docs.google.com/document/d/1z0z ... 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!

Laters!
-JeffR

[Code_Man]

Great work, highly interesting stuff, is all i can say.
Im sure hyped for 4.0
Thanks for keeping us on the loop in such a informative way.

Just two questions:
Is uiask gonna be included by default now?
And is there any expected breakage concerning torquescript?

[Razer]

How is going 4.0 release ?

[Nils]

A lot of work been done. Thank you all who have been contributing to keep good old Torque alive and kicking. Looking forward to see 4.0 sometime in the future. Good luck!

[JeffR]

Will have a new update up tomorrow! Lots to write about as usual, so it takes a while to jot it all down

[HeadClot]

A lot of work been done. Thank you all who have been contributing to keep good old Torque alive and kicking. Looking forward to see 4.0 sometime in the future. Good luck!

Happy to see you back Nils.

Will have a new update up tomorrow! Lots to write about as usual, so it takes a while to jot it all down

Looking forward to seeing the Update

[JeffR]

Hey boys and girls, time again for a workblerg!

Sorry for the delay on posting this. Caught a delightful seasonal bug and was pretty low power for most of the weekend.

Bunch of things to cover, and the thing to mention upfront is even though we missed our original roadmap target of Q1, everything's actually finally bloody coming together now. I'm putting together a not-quite-RC build - a 'preview build' so people can start testing things out with the anticipation that a few things have yet to get fully folded in, but I figure I can cover the big highlights, what to expect, and the todo.

PBR
There's a few bugs to correct, but the core functionality is finally bloody done. We got it working in forward and deferred, and in both D3D11 and OpenGL. So the preview build will have this ready and waiting to try out 100%(the remaining bugs aren't even explicitly PBR related, but some material/shader issues we'd noted along the way that need correcting. PBR's definitely in a solid, usable spot at this point)

There'll be a test level in the preview that will show off various materials in PBR so you can get an idea of it.

For shots, there's a bunch in the dev channel in the discord, but I like this one, which was when we got the forward probes working again:


If it's hard to tell, the right-side wall is actually transparent like glass, it just has a black backdrop so you can actually more easily make the reflection out.

Important to note is that both deferred and forward utilize 99% the same code, but forward is limited to a maximum of 4 local probes + skylight per object and the whole of the PBR system(mostly prudent for deferred rendering) can handle a lot more, though I believe we currently have it clamped to 50. This number can get adjusted around as requirements get calibrated. A big thing to note is that with the arrays implementation, it's overall REALLY efficient to render probes. We effectively do up to all 50 probes in a single render call via a postFX, so 1 probe and 50 probes effectively have the same overhead. It's definitely far more efficient than the older method we were doing before where every probe gets it's own rendered primitive. So the logic is simpler, and it performs better. All around a win-win.
It may have been a massive pain in the butt to get it all working, but it's worth it.

Assets
One bit that came up when bloop was testing stuff out was that there was some annoying behavior with paths on assets if you tried to rename a module. Assets internally hold a reference to the file it's related to(or files). I ended up at first utilizing the relative path at a project level, which included the module name. Some script functionality helped deal with renames when stuff changed, but bloop came across a limitation/imperfection with that approach where if the rename was done manually, you had to manually update the paths in all your asset files.
I did some digging and re-discovered Asset Loose Files, which was always a system in the asset stuffs, but I forgot/missed it originally. Basic concept is it operates under the presumption that the file(s) associated to the asset will be with the asset, which is reasonable. So instead of needing a path, you give it just the file name, like "myImage.png".
Then when the asset is set up, loaded or refreshed, it knows via the AssetLoseFile type to basically build out the file path for you. This means that renames of modules, or moving around of modules/assets is even easier as all paths are put together when the asset is loaded. So that was a neat tidbit that was rediscovered.
I implemented that across all the existing asset types and will be merged in this week(and be part of the preview build).

Not-Quite-RC Preview Build 4.0
So as mentioned, since all the big chunks are pretty much solidified, and we're down to the 'polish things up and merge it all together' end of things. It's not quite a real release candidate yet(as there's definite known bugs that need a-quashin' before then) but it's there enough that it makes a lot of sense to get a build out there for people to really be able to screw around with in earnest and try and spot any bugs or missed bits that can get shored up during May so we can get the RC put together and 4.0 out the door.

Mr_SquarePeg in the discord asked for a bullet point of all the new stuff that's in 4.0, and I'm still working on that, partially because I did this as an attempt at a quick reference:


And, uh...that's a lot of changes, even before my updated assets PR, PBR itself, and the other chunks that'll be in the preview that are about ready for PR'ing/merging.

So....yeah it's a lot to sift through. But here's some bits you can expect in the preview for sure that you should lean your attention on to try and hammer on as much as possible:

• PBR(of course)
• Modules and Assets, including a better asset pipeline
• Entity and Components
• Assimp
• Verve
• Dark Theme
• Updated BaseGame template, mainly the UI side to just be cleaner and more refined while still being minimalist

Obviously with hundreds of commits, there's waaaaay more stuff, and the changelog should be quite monstrous in the end, but those are the big ones to emphasize on for the preview beatup.
Az raised a good point that we could probably consider PBR really done if we can PBR-ify the old Chinatown level and it's assets, so this week I'll be working to PBR-ify the materials, and convert 'em to assets for the preview build.(I'll definitely get an 'old T3D' and 'PBR T3D' comparison spread in Chinatown as well)

I'll also do a few smaller demos/vignettes to show off a few things like Static Shapes, Collisions, Zones, etc.
I figure it'd be a good litmus test for how small we'd like the vignettes/demo scenes to be to show off given features.

Project Manager
So to better facilitate the community and management of your projects, the updated Project Manager was obviously going to be pretty key. Originally we were going to just do an updated version of the old Project Manager, which did a solid job of letting you manage projects, but between wanting to manage an assets library as well as the discussions of keeping the community better integrated and in the loop, I realized that a PM that JUST manages projects kinda wouldn't cut it.

So I did some research on how to let the PM manage asset libraries, how it could do the build actions for you(which was always slated, but hadn't gotten much digging at it done) and what could be useful information for the PM to convey.
If anyone's used any modern art tools or other project managers, you'll know that they tend to have a page for community/news splash stuff in addition to managing your stuff.
So I did a quick mockup layout and I think it implies the right direction:


Obviously almost offensively WIP, but I think you'll get the gist.

The notion is that firing it up, the first page'll be the community/news tab. It'll let us pull feeds about updates(like workblog posts) as well as a common set of links to the various sites that make up the community, the forums, the wiki, the docs, the ModDB, the Patreon, and so on.

This way, we can further lean into that inter-connectivity, and also lets people stay more in the loop, even if they don't specifically visit the sites themselves regularly. This could be utilizes to potentially huge effect down the line by letting the PM inform people of PRs that could use testing(and if accepted, could spool up a build of that PR automagically for you to quickly test without needing to think about it) as well as job postings, new assets, etc.

On the assets management side, the long-term goal's more or less always been to get a store set up, but there's a huge logistical, legal and financial overhead to establish something like that without being a garbage use experience or super easy to crack and steal people's info.
But ease of acquiring assets and resources is paramount.

So, a compromise: We'll have a curated list of assets that points to a given git repository that hosts said assets. This lets people make up assets easily and in a consistent way, handles the versioning of assets automagically, and lets git deal with all the security/backend stuff. From the end-users's side, it'll pull down from that curated list creators, assets and the various metadatas to said assets.

From there, grabbing an asset for your local library would be as easy as picking it from the list, let git download it, and the it's available to use in your projects. The PM would then also let you install/uninstall assets to a project easily as well.

It should be a really clean and efficient process for the end user, and minimal extra work for the content creators. Updating/expanding the library isn't automagic, but it's low effort overhead and any of the main repo maintainers could update it upon request. Linking back to issue pages for the asset's repo as well as directing to the creator's websites, social media and patreons where applicable also can help focus attention to the creators themselves.

This way, easy to use on both ends, and we can quickly and painlessly begin converting the treasure trove of T3D resources to work with this setup, allowing for a crazy backlog of content people can begin leaning into really fast.

TODOs
While the preview shows everything's lego'ing together and we're finally on the finishing sprint, there's obviously some stuff to shore up yet which will happen during may.
The big bits would be:

Assimp
Thanks to @ OTHGMars, the assimp work has gotten a gigantic leap forward and shored up a vast majority of the problems. I got the rapidjson version updated as well, so that opened up gltf2 support which was part of assimp that wasn't working either.
Mars mentioned a few outstanding issues, like skeleton scaling screwing with stuff, so there's a few bits yet the crack and I'm sure as people throw a lot more models of different formats at it, we'll uncover other issues.

Components
I've been working at a cleaner overall structure for the components backend I'll have put together this month. The frontend use of components won't change at all, but it'll be more efficient on the backend so we should see better performance with components. There's also a number of small bugs and a few larger bugs to iron out with the current components, and a number of components that still yet need to be made so we can finish fleshing out the:

GameObjects
I've already got a jumpstart on GameObject-ifying the various existing gameplay classes, like static meshes, Players and the like, but between the above known issues with components and still needing various components created, a number of GameObjects haven't yet been fleshed out. As the components are made, though, the GO's will be quick to assemble.

Static Mesh Optimizations
I've talked before about baking static mesh geometry to massively help performance on complex, but unchanging scenes. There's still some additional bits to that that need wrapping up(like smarter separation of busy cells). I also have a WIP implementation of utilizing Static Lists to retain renderInst data between frames for meshes instead of thrashing the list each frame. This means that each frame takes less time to process/assemble the mesh bits we want to render(as if it hasn't changed, the prior frame's renderInst is still valid, so we can just throw that along without needing to process anything else), which would be especially nice when combined with the static geometry baking.
T3D's render behavior is actually fairly efficient as is, but also a little eccentric, so it's not super easy to drop it in for stuff like the Shapebase derived classes, so we'll see if this makes it in for 4.0, or if it'll wait for 4.0.1. But it'll at minimum help make the framerate more stable by reducing how much unneeded extra work is done frame-to-frame.

Sites and Roadmap
I'll be updating the roadmap tomorrow. Obviously it's good to have a target, but life, lemons, and tripping on life's lemons often causes delays. That said, I need to be better about ensuring it's kept up to date as stuff finishes or things change. I've been putting a dedicated effort to better organize all my junk, between various sites bits, lists for what needs doing and what needs updating, and trying to lean towards a more consistent schedule on stuff.

For the sites, I've been putting together a list of what needs changing, updating and doing. I've got a fairly good canvas of the todo on it now. And during this month, you can expect to see a lot of this get slowly brought up to speed and updated where appropos. I'll be making posts if anything big happens with it, but don't be surprised if you see information update, get rearranged, new images and the like happen

If you have any images, gameplay footage clips or the like, send 'em to me and I'll make sure they get a home on the sites
Especially you @ Steve_Yorkshire

I think that's the big stuff. I'll have more soon for sure(still on the swing-back after my coughy-sneezy weekend of grossness) but 4.0's imminent, and I'm finally beginning to feel like the spring can begin to uncoil a little. It's going to be an exciting year and I look forward to seeing where it goes with all of you

-Jeff out

[NekoDemon117]

When this makes 4.0 release, I am going to attempt to make a forest scene based off a mix of Kokiri Forest, the different versions of the Lost Woods, and the forest areas in the intro of Majora's Mask. Though it won't officially have anything to do with Legend of Zelda. (don't want to lose any work I do to a C&D letter)

by the way, "Assimp" makes me think of smutty fanart of Midna from Twilight Princess. LOL