So to be perfectly blunt this is a collaborative endeavor. Not a sweatshop for folks to expliot one anothers time for free with. If you can't handle that, then this simply isn't the engine for you.
That being said, lets get into the brass tacks of what made the list and why.
A few months back, the LiF folks were kind enough to offer us a revamped threadpool system. There's some contention that it's needed, hence the test.
If it's found that it's needed, a stumbling block would be the incorporation of several portions of the boost library that folks asked roundly rejected.
contains partial conversions first to the STL, then when that ground out to SDL2. Either way would presumably work, just need a hand there to dial that on in one way or the other.
to clarify the
"Complete probe projection via zone clustering/filtering
[**] If it works, no leaks or major flaws visible, do next major bulletpoint subtask
[**] If it fails to work, due to leaking or undesirable clipping, shift to embedding the distance to the captured pixel in the alpha channel of the specular cubemap, compare there for projection cutoffs
Finalize probe-to-probe (and skylight) blending to ensure no overbrightening from overlaps"
bits, the math for single probe and skylight application is pretty much knocked out to folks satisfaction so far as I'm aware, which leaves the probe end. PBR isn't just slaping in new textures and new math, it requires an underlying system to pick up and project context.
"refix editors after removal of global cubemap"
as a temp-measure, for a while there to get cubemap application going on in the editing suite, we leveraged the older 'assign a cubemap directly to this material' code. that'll be going away due to the shift of effectively using the equivalent of light cookies to project onto the scene rather than wrap arround each individul object.
"complete terrain composite map blending via the same methods as other materials"
could use some cleanup prior to roll-in, as well as opengl conversion, and composite to composite blend should follow the same end blending methodology.
folks will find the latest fork on that subject https://github.com/Azaezel/Torque3D/tree/PBR_math_wip
"Review networking to ensure entities created on a server properly ghost all network-tagged components and component-states to connected clients"
Theres currently a bug with the implementation where you're not seeing meshcomponents when you connect, nor hearing soundcomponents play when connecting from a non-host. That'll need fixing prior to anything else.
"Review rendering of editing-related elements (SoundComponent emission radius sphere when hitting preview, for example)"
That busted a while back with a retool to meshcomponent rendering for speed. need to revisit that end for better(tm) built-in tool support. After all, if we're going to make current users rewrite thier code, it better be a step up.
should be self-evident, though somethin that should probably be knocked out after the other two above.
"Create ParticleEmissionComponent based on the SoundComponent as a template (ie, replicates the ParticleEmitterNode values), 'play' bool for simple start/stop handling, preview button to make it fire off in-editor for previewing/testing"
** not listed, should probably also go ahead and toss in the capacity to set any component to use a given object-node instead of object-origin.
"Create finite state machine system(a StateMachine component already exists, but we may want to utilize the above suggested play/preview aspects)"
this ones 'simply' expanding that end with more options.
"Convert core gameplay classes(Player, vehicle, etc) to internally use Components(or make variants and flag the existing classes as deprecated)"
this makse the list for two reasons. The first is simply that forcing ourselves to use that as a pass/fail measure ensures that E/C does in fact have everything folks will really be needing at a basic level. The second is that it gives existing users a well documented set of conversions for thier own customised codebases.
"Physical Material vs Rendered Material separation(break out the non-visual aspects like sound, footprints, particles, etc into their own class which can be looked up, as opposed to being integrated into a single massive class)
[**] If it works, (prototyped within at least 2 weeks from start. anything more is likely to reflect too large a shift for folks to deal with when converting): proceed with split features
[**] If it doesn't, (not done within a reasonable ammount of time): deal with it as-is, and expand any additional features in the singular class"
There is at present two paradigms for nonvisual material aspects. the former, used throughout the lions share of classes, uses a singular material definition that includes sound effects to be played when walking or jumping on things with that mat, and wether those take footstep decals when walked uppon, while the latter in terrain breaks that on up into two classes.
A fairly simple example of expanding on the former system would be https://github.com/Azaezel/Torque3D/commits/FX
where we tack on a tracking ID for explosions (they have sounds, particle effects, and decals built in, so seemed worth an eyeball form a simplification standpoint)
Other uses would be the physics end, like adding friction and restitution entries for more physics-based games.
It was expressed that the terrain model of material creation was preferable in terms of aspect-sorting, so figured float that out there as a notion, though obviouly from the listed time-frame for prototyping, not wedded to it.
Since alot of 4.0 is about retooling the frontend experience for folks, best we lock that in ne way or the other, instead of breaking things more in a 4.X.
"Use the visual-only portion as a hook-in base for the node-based shader system"
frankly, this one deserves it's own thread.
"Further vulkan/moltenVK future feasability research"
While one of our contributors is pretty confident that they could just toss in a GFX plugin, it'd be nice if we could go beyond that end and see how much we could leverage for gains.
General Ongoing Tasks:
https://gist.github.com/Azaezel/f34201c ... 601a45c88d
should be one anybody can jump into. Pick a warn number, and have at it. Makes for a simultaneous code-review, and just generally means less to wade through to see if folks introduce new problems accidentally.
"Further incorporation of SDL as the core platform layer, further deprecation of per-platform code"
we're now up to platform, platformMac, platformPOSIX, platformSDL, platformWin32, platformX86UNIX. that's alot of potential redundancy, and sdl2 handles those and more platforms. probably best to leverage that further and kill off extra crap to wade though. this made the list, just like warnings, because it serves as a component that isn't necessarily reliant on any of the more.. shall we say, arcane... ways the engine handles things.
Again, if there's anything on the list you'd want to help with, pick one or two. If there's anything not on the list you would want to contribute, there's at least a few folks willing to work ***with*** you to see that happen as well. And if there's a particular point you find contentious, by all means, explain why you that specific item should be put off for a 4.X, not a 4.0 release.