As promised in the last blog post, today we are going to take a look at how Molecule handles internal references to data owned by some other system in the engine.
One thing I have noticed during the development of the Molecule Engine, is that defining clear ownership over data can tremendously help with following a data-oriented design approach, and vice versa.
I’m proud to announce that the first evaluation SDK for our input technology is now available! A new version of the core technology has also been released, with some minor additions and improvements.
Check out www.molecular-matters.com for more information on the input library. Further SDKs will follow during the next few months.
Continuing from where we left of last time, I would like to discuss how we can build growing allocators using a virtual memory system. This post describes how to build a stack-like allocator that can automatically grow up to a given maximum size.
After lots of work I’m proud to finally announce that the first evaluation SDK for our core technology is now available!
Check out www.molecular-matters.com for more information on the core library. Further SDKs will follow during the next few months.
Before we can delve into the inner workings of growing allocators, I would like to explain the concept of virtual memory and discuss what it is, why it is needed, and what we can use it for.
During the next few weeks, I’d like to detail how the memory allocators inside Molecule work, starting with a simple, non-growing linear allocator today in order to cover some base first.
Today, I want to show what a difference normal mapping for indirect lighting can make. By using orthonormal basis functions defined on the sphere, incident lighting can be evaluated for different directions depending on the surface’s normal.