I recommend the new "Our Machinery" blog [1], where they write about a new engine development. Bitsquid was sold to Autodesk, rebranded Stingray and as of now seems to be discontinued [2].
Excellent, I'll check that out. As (at the risk of exposing my geriatric age) someone who did 3d engine and driver work back in the mid 90s to early 00s, I found the bitsquid blog really useful to warping my brain to the near era and the tradeoffs that matter today. Great stuff.
If you are into no-nonsense software design, Molecular Musings [1] written by Stefan Reinalter is also a goldmine. As is anything written or said on topic by Mike Acton, whose ramblings de-facto brought DOD into the mainstream [2][3]. Regarding good old days, remember Flipcode? ;) [4]
I also recently picked up "Data-oriented design: software engineering for limited resources and short schedules" by Richard Fabian, which I've not had a chance to read properly but looks like it covers things in detail.
This emerged as a result of writing performance-demanding games, but I think it should be more widespread, because it's much more fundamental, as opposed to object-oriented design.
Definitely. I started writing React/Typescript this way, and it's been a pleasure. Each component is just a function, so composing components is just a data pipeline. If you have few, key data structures that you're working with, it makes reconfiguring that pipeline to fit product needs a while lot easier.
It also means you naturally end up with small, testable, generic components without having to think too hard about it. You've five the heavy lifting in the data structure, and whatever behavior you want flows naturally from that.
For those not familiar with this, here's a bit of background knowledge: A lot of game engines had run into an issue where a sensible and user friendly object oriented design led to a lot of little inefficiencies that added up to relatively poor performance. And fixing this became very tricky, since the problem manifested itself across multiple layers of code, and was a result of the access patterns that came with OO, in addition to poor cache optimization. In most applications this rarely matters (e.g. in a web-app the round-trips to the database will dwarf this), but in game engines you're trying to simulate and render a complex world 60 times per second, so you've got 16 ms for each frame, and you really don't want half of that being wasted on the CPU doing stuff that could have been avoided or not optimizing cache usage.
So an alternative to object-oriented design was proposed: Data oriented design - there's a good video about this from 2014 by Mike Ackton [1]. But in short, the idea is to go 'back to basics' and focus on this: You're pushing around and transforming bits of data so you can eventually give an output. So the goal of your design is to make it explicit how and when you do any of this, so you can avoid unnecessary copying, you can lay out data to fit efficiently in the cache, parallelize as much of this as possible, and do as little else as you possibly can. The result is the difference between opening Word and Sublime Text. In a web-context, Map-Reduce is a similar way of explicitly expression transformations in a way that enables parallelization.
A common pattern that many game engines have adopted as a result of this is Entity-Component-System [2]. Basically, most game engines work with a model where each object in the game world is an object with a list of components that give it varies attributes - e.g. a physics component to define how it handles collisions, a rendering component, a script component with some code to run every frame, etc. Previously that was also how it would be laid out in memory - an object contains the data from its components. With ECS this is inverted/exploded - the object is split up into an entity (basically just an id), each component's data is stored in an array along with all the components for other entities that also have that component (and the entity id is used to look up/associate in that array) and finally a system does transformations on the data in the component arrays. One of the benefits of this is that it lays out e.g. all the physics data continuously in memory, which makes it much easier to use the cache efficiently - for example if you load one components' worth of physics data into the cache, it might already include the next 1-3 chunks that just so happen to be exactly what the physics system will work on next. This blog post comes with some nice illustrations to help understand the difference between these two ways of laying out data [3]
Seems like there's a lot of similarities between DOD and relational modelling (as in modelling for a RDMBS). I imagine DOD is kinda like doing batch/bulk operations in pure SQL vs using an ORM.
It is almost exactly relational modeling. Instead of having an object that maps to an entity, you only have relations that hold information about various aspects of what you are modelling, and iterate over and join as needed.
The scrolljacking + history pollution of this site is basically a crime.
Also, is there anything more useless than a slide deck without the actual presentation? Just have to kinda guess all the blanks eh? I normally wouldn't even comment but I find data oriented design to be the best and love to see other takes/critiques/methods but this is useless as is.
I'm not sure these slides alone will teach anything to anyone who doesn't already know what they're trying to say.
I also find it kind of funny talking about scene graphs and animations when model, mesh and texture data are already examples of data focused designs and they're much more fundamental.
http://bitsquid.blogspot.com