torque3d.orgTorque3D - Torque3D

Jump to content Existing user? Sign In Sign In Remember me Not recommended on shared computers Sign In Forgot your password? Sign Up Torque3D Docs Code Reference Roadmap Wiki Github More Torque2D Github More Forums Torque3D Forums Torque2D Forums All Activity More Blogs Torque3D Blog Torque2D Blog More Games All Games Add Your Game More Discord More More Everywhere Status Updates Topics Blog Entries Pages Article Images Albums Members All Activity Home Torque3D The pinnacle raw Torque power, Torque3D has been used for everything from driving simulators to MMOs! Check Out Torque3D Torque2D All the power of Torque with less of those pesky dimensions to tie you down! Check Out Torque2D Forums Looking for answers, wanna see some cool projects or talk about new / upcoming features? Read the Forums Work Blog Updates Workblog Nov 2022 By JeffR in Torque 3D 3So, on today’s installment of "random rambles about development things" But for real, it’s a good time to do a new workblog and keep people in the loop for those not in the discord, or those that aren’t spending every day in it So, what’s on the ol’ discussion stuffs today? Well, for the big one, the main Feature target for 4.1: Components. Or, more specifically DOCs. What does DOCs mean? Well... Directors, Objects, Components You may have heard us discuss ’Entity-Components or Entity-Component-Systems(EC and ECS, respectively). For a brief refresher in concept, here’s a simple breakdown: Entity-Components as a paradigm can be described simply as having an Entity object, and then Component objects that contain and implement data. As in, if you have a component to render a shape, the component not only holds the info for what shape to render, but also the logic to render the shape. This is how, most other engines do components. The reason for that is pretty simple. It’s robust, and it’s easy to work with. It’s not the most efficient system, but it’s pretty hard to screw up. You slap a component onto an object, set the properties on the component, and then the component does the thing. When I did the main previous implementation of components, this was also the system I went with. The MAIN problem with this approach is that any given component is kinda...chonky. And you also have a lot of bloat on the Entity object in most cases. And with all the bits that have to cross-communicate to ensure dependencies work(you gotta have collisions for physics to work properly for example) as well as order of events(collisions are calculated then physics) as well as any deeper engine system dependencies. It can spiral quite a lot. Beyond that, it’s also very difficult to thread any of the component’s workloads because everything cross-communicates in order to work. You can’t easily punt a physics component into a thread if other threads need to talk to the same collision component or entity it uses, etc. So, advancements to the theory of components implementations lead to ECS: Entity-Component-Systems. Now, the confusing use of "Systems" aside, the main differentiator to EC is that Components now ONLY contain data. They don’t implement any logic whatsoever. Likewise, ALL the burden of functionality is moved off of Entities. In a ’pure’ ECS implementation, an Entity is nothing more than an ID for Components and Systems to reference. Instead, Systems implement all functionality logic. If you have a physics component, there’s PhysicsSystem that implements the actual logic for it. This is certainly more complex to implement. In fact, very few engines or games use ECS. Unity’s new DOTS approach is based on ECS, and a few games like Overwatch have utilized it. But the innate complexity of the approach and how abstracted the data and implementation means that it’s far less common. So why use it? Because it is MUCH easier to be cache-coherent and thread things. For the non-coders out there, cache-coherency is the idea of wanting to keep all the memory a given chunk of code in the engine uses all bunched together. Think of it like how if you’re studying. Rather than getting a book, reading a paragraph, then walking back to the shelf, putting that book away, and getting a new book and reading the next paragraph, and so on - which would be very, very inefficient - instead you just get all the books you need, and can quickly reference between them. In practice, memory in the computer works similarly. So if you can cram all the data you need to work into the same blob of memory. Performance is improved SIGNIFICANTLY. But it’s not very ’human friendly’. Which is why you get stuff like ECS. All components of a type can be crammed into a dense set of data. So when a System goes to implement logic, you’ve got all the relevent components in a tight blob of memory, and the whole thing can be processed without having to go "get another book" as it were. In addition to this, the data being more detached from implementing logic(and better managed in memory) makes it much easier to implement the logic in multiple threads. This allows the machine to crunch a lot of objects in parallel - which is especially good on modern CPUs that have sometimes dozens of threads. But there’s a good number of downsides to this approach as well. It is, as said, not very human friendly. Implementing new components and their associated systems is not how most code is implemented, so it can be difficult to work with. It also requires much more tracking of when things are added, removed, when things should run. Dependencies are still burdened on the components and systems to keep track of for when to implement things, and scripting it is very, very difficult. All those and a bunch of other smaller inconveniences make it generally a pretty poor paradigm to work with in something as complex as a game engine. There’s a LOT of ECS implementations out on the internet. But they’re more academic than practical because of the inherent limitations of the approach. Cramming it into a game engine while still making it easy to work with from a scripter, designer or artist’s perspective is pretty hard. And both of these have various limitations in how to deal with it from a networking perspective. It’s very difficult to have the server and client safely agree on the data the client has without trafficking a ton of data, which is bad for net performance. So, between what I learned from implementing an EC style deal in the first pass of components, and a lot of tests and research into ECS. I settled on the fact that, both approaches just kinda aren’t ideal. So I did some work and fashioned up a - as far as I can tell - novel components implementation for Torque3D. Directors, Objects, Components, natch. So, what’s the deal then? Well, per the name, there’s 3 main components(heh) to the model, which we’ll cover here: Directors So what’s a director? Well, in practice a Director is a simple class that ‘directs’ when and where updates to components happen, hence the name. The idea is that we want to move the burden of when and why updates happen off the objects and components. At it’s core, a Director is in charge of doing a particular thing, generally updating a specific component or set of components. Like, say, when we want our RenderMesh component to draw. The Director has a specific timing to it(aka, Rendering) that the rest of the engine can invoke to the DirectorManager, which is pretty much just a simple container class. When we want anything with the Rendering timing to kick off, we tell that DirectorManager to run an update on said timing. And in turn, any Director with that timing is told to do it’s work. Simple enough. So in our example of the RenderMesh components, the RenderMeshDirector has the Rendering timing, the engine, when it goes to draw objects, can tell the DirectorManager to run the Rendering timing, and our RenderMeshDirector gets told to update. When this happens, the Director loops over valid RenderMesh components and directs them to do their work. And...