
Practical Examples in Data Oriented Design - Tomte
https://docs.google.com/presentation/d/17Bzle0w6jz-1ndabrvC5MXUIQ5jme0M8xBF71oz-0Js/present#slide=id.i0
======
hermanhermitage
I recommend the old bitsquid blog as well - it gives a good snapshot of the
thinking that goes into creating game engines these days.

[http://bitsquid.blogspot.com](http://bitsquid.blogspot.com)

~~~
metaobserver
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].

[1] [https://ourmachinery.com/post/](https://ourmachinery.com/post/) [2]
[https://www.autodesk.com/products/stingray/overview](https://www.autodesk.com/products/stingray/overview)

~~~
hermanhermitage
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.

~~~
metaobserver
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]

[1] [https://blog.molecular-matters.com/](https://blog.molecular-matters.com/)
[2] [https://macton.smugmug.com/Other/2008-07-15-by-Eye-
Fi/n-xmKD...](https://macton.smugmug.com/Other/2008-07-15-by-Eye-
Fi/n-xmKDH#!i=593426709&k=ZX4pZ) [3]
[https://www.youtube.com/watch?v=rX0ItVEVjHc](https://www.youtube.com/watch?v=rX0ItVEVjHc)
[4]
[https://flipcode.com/archives/articles.shtml](https://flipcode.com/archives/articles.shtml)

~~~
hermanhermitage
Excellent, thank you for those references.

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.

------
Mikhail_Edoshin
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.

~~~
mind-blight
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.

------
m12k
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]

[1]
[https://www.youtube.com/watch?v=rX0ItVEVjHc](https://www.youtube.com/watch?v=rX0ItVEVjHc)
[2]
[https://en.wikipedia.org/wiki/Entity_component_system](https://en.wikipedia.org/wiki/Entity_component_system)
[3] [https://medium.com/@savas/nomad-game-engine-part-4-3-aos-
vs-...](https://medium.com/@savas/nomad-game-engine-part-4-3-aos-vs-soa-
storage-5bec879aa38c)

~~~
glun
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.

~~~
madhadron
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.

------
ztjio
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.

~~~
hermanhermitage
Did you try with the speaker notes on? That gives a bit more detail.

------
Peckingjay
Might be just me, but I was expecting the examples to be a bit more fleshed
out than they actually are based on the title. A bit disappointed.

~~~
ztjio
Based on the notes it seems there were better examples just not in the slide
deck.

------
jayd16
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.

------
redcat7
whot?? this is some kind of a new thing? i do everything in this fashion for
years

