As a quick side project, I’ve started working on the problem that postal code area information in Openstreetmap is often insufficient. Why? Because it’s a nice show case of how flexible the Core SDK is, allows me to stress test the 2D / orthogonal handling code paths and it is a good opportunity to potentially contribute to this great, crowd sourced project.
The render layout sub-system in Core SDK is one of its central features. It helps compose multiple views or multiple output displays to a single consistent layout and is one of the reason why the SDK is so versatile. But it also helps managing input mapping and other aspects such as stereoscopic VR/AR rendering. Here is how:
After adding FBX support the other week, there was yet another reason to finally add support for normal and specular maps. While it’s still not physically-based-rendering but a simple Phong lighting model, it’s still a nice improvement to the overall image quality and helped developing some further multipurpose code.
FBX has gotten quite a high adaption rate over the years. I had shied away from adding support for it because there is no official spec, only unofficial bits and pieces like the document the Blender foundation published a while ago. There is the official FBX SDK but it is in binary form only. However, it seemed to be the most viable option to be able to handle all the different versions the format had over the years.
For those who haven’t heard of it yet, TRAC is an open source combination of a ticket and a wiki system mixed with version control integration written in Python. It’s great for organising work especially in small to mid-size development teams but due to the large number of plug-ins and its incredible plug-in API, one can even customise it to cover other aspects of a business. I had meant to write a blog post about it for a while, mostly as a cheat sheet for myself or as a reference to point others to. Since I had to move my personal TRAC to a new machine it is the perfect occasion to write it down for once. So here goes …
The second instalment in the dev update videos has just been published. In the last couple of weeks, work has mostly been focused around improving the tessellation quality and algorithm robust with some nice results. ISO-lines are now weighted higher than trim curve tessellation which results in a much nicer topological flow.
There hasn’t been much news lately as we have spent the time on improving tessellation quality and optimizing low-level NURBS functionality. So instead, here is the first in a monthly series of videos that will keep you in touch with what is going on inside our operation. Enjoy!
Shadows add a lot of realism to renderings. After having done a lot of internal refactoring and ground work for future features, I wanted to add something that improves the image quality but doesn’t delay too much from the actual topics I have to work on. Hence the idea of adding a simple, pre-baked ground shadow.
I have been working on a feature that requires reading the depth buffer and storing the data in an image. While this was quickly done in the OpenGL-based renderer, I struggled getting it to work with the Metal-based renderer. Things got weirder and weirder … until the source of all problems presented itself as a single missing line of code! … Read More