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.
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.
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):
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.
I’ve recently had the need for a simple ray-tracer since I started working on a precomputed radiance transfer (PRT) baking tool. There’s multitudes of sample code, implementations and SDKs available, so I wanted to share my findings after a bit of research.
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.