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.
One task that is pretty common in game development is to transform data according to some sort of hierarchical layout. Today, we want to take a look at probably the most well-known example of such a task: transforming joints according to a skeleton hierarchy.
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.
Even though a task scheduler can help with alleviating the burden of having to distribute small pieces of work to different threads, it cannot help preventing a few issues common in multi-threaded programming, especially in multi-processor environments.
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):
Continuing from where we left off last time, this post explains how parent-child relationships are handled inside the task scheduler, and how streaming tasks can be split automatically by the scheduler.
In this part of the series, we will discuss Molecule’s task model in detail, and have a look at the underlying C++ code and some subleties we need to watch out for, as well as some unique optimization opportunities.
With multicore hardware becoming the norm in both PC/console-based gaming as well as on mobile platforms, it is crucial to take advantage of every processor core and thread being thrown at us developers. Therefore, it is important to build technology alleviating the task of writing correct, multi-threaded code.
In order to achieve that, this series will try to explain how to build a load-balancing, work-stealing task scheduler.
Everybody knows that writing correct multithreaded code is hard, even when using proper synchronization primitives like mutexes, critical sections, and the likes. (Ab)using the volatile keyword for synchronization purposes makes a programmer’s life even harder – read on if you care to know why, and help spreading the word.
A fast content pipeline is crucial for today’s engines, allowing the user to quickly iterate on features, assets, etc. Molecule’s content pipeline enables hot-reloading of every asset the engine understands (textures, models, shaders, …), while retaining blazingly fast loading times.
Whenever you’re baking signals into texture maps, there’s quite some issues to watch out for, regardless of the signal you’re baking. This post will try to explain issues I ran into while implementing a baking framework.
Eventhough gamma-correct rendering is absolutely crucial in order to get good and realistic lighting results, many programmers (sadly) still don’t care about it. Today, I want to show how different the visual results of lighting in gamma-space vs. linear-space actually are, and what you can do about it.
Let’s face it, performance on modern processors (be it PCs, consoles or mobiles) is mostly governed by memory access patterns. Still, data-oriented design is considered something new and novel, and only slowly creeps into programmers’ brains, and this really needs to change. Having co-workers fix your code and improving its performance really is no excuse for writing crappy code (from a performance point-of-view) in the first place.
Molecular Musings 