In the last installment of this series, we talked about handles/internal references in the Molecule Engine, and discussed their advantages over raw pointers and plain indices.
In a nutshell, handles are able to detect double-deletes, accesses to freed data, and cannot be accidentally freed – please read the previous blog post for all the details.
Today’s post is only a small gem I accidentally came across while I was looking for something entirely different: a faster method of multiplying a quaternion by a vector. Continue reading
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.
As promised last time, today we will see how pool allocators can help with allocating/freeing allocations of a certain size, in any order, in O(1) time.
Last time, we were looking at a linear allocator, probably the simplest of all memory allocators. This time, we will detail how to implement a non-growing stack-like allocator, along with conventional use-cases.
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.
One benefit of using a true radiosity solution for indirect lighting is that self-emitting surfaces can easily be simulated. In traditional lighting pipelines, emission effects are very local only, and mostly do not contribute to the global illumination at all, if not faked otherwise. I have recently added an emissivity feature to the demo, further showing what the technology is capable of.
At last, I can show what I’ve been working on for 3 months. It’s a real-time radiosity system which dynamically updates lightmaps with bounced, diffuse indirect lighting. Without further ado, here are some screenshots and comparisons with direct lighting approaches to see what a difference indirect lighting makes (click the thumbnails for a higher resolution image, and make sure that your browser displays them correctly, e.g. Firefox is unable to cleanly show the darker .pngs, but they work perfectly in Chrome):
Molecular Musings 