By Eric Matyas , November 7, in General. By Jason Campbell , January 9, in Show-off. By Eric Matyas , January 18, in General. By Duion , February 21, in Website Feedback. By artistterrymartin , June 3, in Show-off. Check Out Torque3D. Torque2D All the power of Torque with less of those pesky dimensions to tie you down! Check Out Torque2D.
Read the Forums. WorkBlog - October Mid-October workblog time! Which should've been last month, but chasing down bugs like memleaks and straight up crashes before I wanted to post caused delays, so So, how's it going everyone? Time for fanciful development news. First, lets go over what all work has happened thus far since the last workblog: 76 pull requests merged in, which had over changes which ranged from bugfixes, to improvements to additions.
Notable examples include: Updating SDL to latest Steve passing along a fix to correct render issues for the ribbon particles Preference settings which will get integration into the options menu soon for forcing static object fadeout at a distance, as well as limiting the number of local lights renderiable at a time, and if they fade out over distance as well.
These can potentially help a lot in very object-dense scenes with lots of small clutter stuff that doesn't need to render at a distance Some better default values for local lights, and cleaning unneeded fields Fixing of gamepad inputs Various shadergen cleanups A whole metric butt-ton of fixes, improvements and QoL changes for the asset workflow Ability to better control script queue ordering between modules A crossplat option for 'open in browser', which could see a lot of use in jumping to documentation Improvements to baking of meshes Adds populating of a level's utilized assets into it's dependencies list to ensure everything preloads as expected instead of trying to do it at the last second, which could cause scripts executing during object creation and lead to variable corruption Settings files are now properly sorted A small change, but it keeps the layout of the settings.
This is so you don't have to define a bunch of supporting stuff in a given class over and over. Basically, convenience and code templating thing. Minimal direct use currently, but useful in debug operations, and in the future could drastically simplify doing stuff like picture-in-picture displays or multi view GUIs and the like.
Fixed a pretty gnarly memleak, so we're memory stable again. Lukas got his C project caught up to current BaseGame so we can better test the cinterface changes and soon people can play around with all that too For some of the bigger changes worth going into more detail: First, Mars contributed some very important improvements to window and resolution handling. This adds in Borderless window mode, as well as the ability to set in the options what display if more than one is detected the game window should be on.
Additionally better handling for what screen resolution should be in play based on window mode ie, Borderless is always the desktop resolution as well as ensuring display options apply properly. Easier to find, easier to edit, and the shaders aren't in a completely different module. The loader logic was tweaked slightly as well, so that the levelAsset has a field which indicates what the postFX file is.
This requires less manual logic for 'lemme go dig around for a posteffectpreset file' and should be a bit more reliable. Additionally, the PostFX editor saw some fairly big updates, both in how its accessed, and how it works.
You can now either edit the default postFX preset, or edit the current Scene's preset, as seen here: The editor now better integrates into the PostFXs themselves, as well as auto-applying changes as they happen which is much, much, much better for dialing in how they impact a scene.
Importantly, you'll note that the list of PostFX's displayed in the editor there looks kinda This is because it now only displays active PostFXs rather than the entire registered library, which should help cut down on confusion about what PostFXs are actually active and impacting the scene.
Adding is as simple as pressing the green plus button at the top and then picking which to add from the list that auto-populates with all registered postFXs And then selecting from the list on the left to edit a given postFX: Removal is as easy as selecting the PostFX in question in the list and pressing the red minus button.
You may also note a bit of change in what PostFXs are there. Most are the same as always, but a few tweaks happened to make things a little more consistent and interop-friendly, such as moving the LUT color correction logic out of HDR and into it's own. What's ORM? It stands for Ambient Occlusion, Roughness, Metalness.
It's basically the PBR image maps arranged in a specific channel order. GLTF and a handful of engines assume for it in that order, making it the closest thing to a standard, so to keep it simple, we're doing the reorg. Likewise, we were operating with Smoothness being the front-facing value instead of Roughness.
This is - similar to the PBR channel order - sorta a 'eh whatever works', but Roughness is a bit more standard, so we're going ahead and making that the front-face standard as well. Internally the math assumed roughness anyways, so it isn't a huge change principally. Touching to the above, we'd noted some oddball behavior when adjusting roughness and metalness values, so with Timmy's fantastical eye for that stuff, he was able to spot some problem areas with the logic and our BRDF image.
Huge props there. I had also mentioned some crashes and stuff. There was a bug that snuck in with the probes where baking them could cause crashes. It hit some hardware more consistently than others, and was a right pain to track down.
In the end, though, I put up a PR with a big update to the probe handling. Before, you could have up to 50 active probes, and they would render all in one big go.
It worked, and it guaranteed consistent performance, but a lot of scenes don't utilize anywhere near than many probes in your line of sight. So I shifted the logic to where you have registered probes, and active probes.
You can have up to registered probes in the scene now, which is quite a lot for anything other than a big open world deal and you can always unregister them selectively as needed , and an adjustable amount of active probes.
The default is 8 but it can technically go all the way up the whole though that's not recommended for performance reasons. One of the big advantages outside of the basic performance consideration of not needing to actively render as many probes at once, is we can now lean on culling to ignore probes you can't even see, which just compounds the performance gains, and be smarter about which ones to bother with.
It calculates and picks the best probes based on the camera's position, and I'll be adding an 'influence' value for more artistic control so certain probes can be noted as more important than others.
All of this together means it selects the best probes and renders only those up to the set per-frame limit which again, is adjustable for a given game's needs yielding the same results in terms of blending between probes, but much smarter and targeted selection of which ones to render, yielding improvements in performance. We also fixed it finally so that surfaces that are metallic will correctly render in the baked cubemaps for probes instead of the flat black they were before, which should yield more accurate results in the reflections.
While the above probe reorg and crash chase-down sorta dominated the last 2 weeks crashes are a pretty big deal, so it was important to get out of the way , we can get back on the track of getting the asset integration with the game classes sorted out. I mentioned the utility macros added for image assets, which are most recently utilized by the materials class now. This has streamlined quite a bit of code and makes everything Just Work, and between it and the asset usage in TSStatic, we're feeling pretty confident in finally moving forward and adding asset integration for the remaining classes.
This is probably the last big obstacle for 4. Additionally, a number of primitive objects like a cube, cylinder, etc are in there. However, we also needed a size reference stand-in, and I thought, who better for that than our very own Kork-chan? Definitely won't be as long for the next workblog, and I imagine we'll have a number of modules to try, art to ogle, and a new test build up quite soon, so stay posted! Workblog - Aug Hey everyone! A lot, as said. These range everything from bugfixes, library updates, QOL improvements and all the way up to converting pretty much every class that touches a content file into using the assets system.
Lets cover a few of the specifics and big ones. Pushing tutorials or updating documentation on the site had enough of a hurdle that no one really wanted to bother. So we did a lot of digging and landed on a fully integrated CMS platform.
This allowed the forums to be integrated into the main site and allowed us to easily manage the content that was on the site itself. Other features like broad site search and a few handy additional boons like being able to post micro-communities for games all tie together to make a better centralized point of community engagement. And as noted prior, it drastically lowers the bar for people pitching in to update the documentation if they have at least the Contributor designation, as someone trusted within the community on helping out and know their business.
It's definitely a big deal! Of course, you can still use sliders or individual maps to fill in the PBR properties too. Other things were cleaning up and stabilizing probes and IBL and improving performance with them by adding some nice convenience functionality with controlling active probe counts and the like. All in all, PBR should give stable, quick results that look quite nice. So, assets. Part of that is we made some… liberal use of macros to fill in a lot of duplicated and common code pertaining to these content file types.
Whereas before each class would have to implement the entire file ingest, load and bind logic each time - which as with all duplicate and repeated code, leads to points of possible failure - they now use a common set of macros which have been aggressively and thoroughly tested, making everything a bit leaner and less prone to issues sneaking in.
In this shot, we see an example of defining our asset macro in the class header file: And here's how you use the asset macros to set up the init persist fields to expose them to script: There's even macros for the packing and unpacking of the network data: And finally, an important bit, is that it doesn't just generate function info or anything, but actually configures the internal variables and the like off the parameters you pass in. This allows everything to be VERY consistent and predictable, making usage in the classes once you actually want to utilize the data set much more comprehensible, like so: This means that pretty much every class has a very similar content-file flow, which allows us to standardize object fields more less guessing if it was shapeName, or shapeFile, or shape, etc.
This also standardizes accessor functions. You're welcome - encouraged really - to jump in and get involved. Or, if you like solitude, work alone. We'll be here to help if you need us. There's more, but you get the idea. Torque2D has been around in some form for the last two decades.
Over the years, features have been added to handle every imaginable game. With the Rocket Edition, that legacy of development continues! Torque 2D's powerful rendering is perfectly suited to achieving a great looking artistic style. Torque 2D allows users to share snippets of code easily using behaviors and modules. Simply create a behavior and send the behavior file to a friend. A number of basic behaviors and toys are included with the engine so that developers have a leg up in development!
It supports a large complement of functions including math, object manipulation, fileIO, and more. Torquescript features:.
0コメント