Atom plugins for C++ development

I work a lot on Ubuntu, and Linux is one of the targets of Minko. As soon as Github’s Atom was released, I wanted to test it as an actual development environment for such C++ applications.

Here are two plugins I think are major additions to Atom for C++ development.

autocomplete-clang

Autocomplete is a major feature for any IDE. In the case of C++, it’s even more important because of the complexity of the language. The autocomplete-clang plugin uses clang static analysis to parse headers. It then extends Atom’s autocomplete feature to properly autocomplete C++.

autocomplete-clang

The plugin works great. It’s less tightly integrated than VisualStudio’s Intellisense. So it’s not as fast. Still, the lack of speed is not a big issue compared to the ease the plugin brings. Using pre-compiled headers should speed things up, but I haven’t tried them yet: I guess it says a lot about how not much of a problem this lack of performance might be…

linter-clang

Compiling your code to check its syntax is not a very efficient process. You keep Alt-Tabing between your editor and the terminal where you run compilation. It’s a given clang’s output is a lot more readable than GCC’s. Still, it’s not as integrated as VisualStudio real-time analysis.

linter-clang

The linter-clang plugin fixes that. Once again, it uses clang’s static analysis to check your code and properly report errors in real-time. No need to try to compile your code: linter-clang will check for errors as you type and will report them visually directly in the editor, just like Eclipse or VisualStudio do it.

Using those plugins with Minko

Both those plugins will need to call clang with the proper flags. And those flags depend on your very project. In the case of autocomplete-clang, those flags can be setup in a .clang_complete files at the root of your project (this method is actually inspired from Vim’s popular clang autocomplete plugin). But linter-clang does not support .clang_complete files, so I made a patch available here (that patch will hopefully be merged soon as you can read here).

To generate such .clang_complete files, Minko’s build system has been updated with a “clang-complete” action. This action will automatically create the .clang_complete files for each Minko project (the core framework, the plugins, the tutorials…) or your own project with a single command line :

Instead of solution/project files, this premake action will generate .clang_complete files with each project’s specific flags.

Flyweight design pattern with C++11

To optimize the memory consumtion of the Minko engine, we started by profiling the memory allocations using tools such as the integrated Visual Studio 2013 memory profiler or Massif.

One of the heaviest source of memory allocations was for  std::string  objects. It’s not really a surprising considering one of Minko’s biggest feature is dynamic data binding between the engine data – on the CPU – and the shader data – on the GPU. And “dynamic” means we have to create those bindings according to some naming conventions and explicit declarations made in “effect” files using JSON. Read: we use lots of strings.

We use strings for material property names, but also for the camera properties or the geometry vertex attribute names. It makes the engine very flexible and extensible while keeping some important aspects of strict typing using templates. But it uses a lot of memory because each property names is stored multiple times.

Materials for example are highly likely to share most (if not all) of their property names. If you have 10 of those materials, the property name strings will use 10 times too much memory.

To solve this, I’ve implemented the flyweight design pattern.

Continue reading “Flyweight design pattern with C++11”

Emscripten doesn’t like CloudFlare

In order to make our websites faster and safer, we’re now using CloudFlare on pretty much any of them. It’s fast, reliable and very easy to setup!

Among other things, CloudFlare will cache but also try optimize the content it serves. Mainly JavaScript, CSS and HTML content of course. As you can imagine, Emscripten generated code is not too happy about this, but the problem is not where you would think (ie not in the “optimized” JavaScript files)!

It turns out our server (possibly because of WordPress but I’m not sure) will serve Emscripten’s *.mem files as text/html. Emscripten *.mem files are the program memory init files. You can read more about them in the “Memory Initialization” Emscripten documentation. *.mem files are now generated by default for -O2 and above. Anyway, CloudFlare will try to “optimize” the *.mem files as if they were HTML and break them.

A simple workaround is to disable the HTML optimizations in the “Performance Settings” of the CloudFlare settings for your domain. A more suitable fix would be to configure your web server to serve *.mem files with the application/octet-stream mime-type.

Exponential Cascaded Shadow Mapping with WebGL

Update: my implementation worked well on “native” OpenGL configuration but suffered from a GLSL-to-HLSL bug in the ANGLE shader cross-compiler used by Firefox and Chrome on Windows. It should now be fixed.

Update 2: you can toggle each cascade frustum using “L” and the camera frustum using “C”.

TL;DR

shadowmappingWebGL Cascaded Shadow Mapping demo powered by Minko

  • arrow keys: rotate around the scene or zoom in/out
  • C: toggle the debug display of the camera frustum
  • L: toggle the debug display of each cascade frustum
  • A: toggle shadow mapping for the 1st light
  • Z: toggle shadow mapping for the 2nd light

Motivations

Lighting is a very important part of rendering real-time convincing 3D scenes. Minko already provides a quite comprehensive set of components (DirectionalLight, SpotLight, AmbientLight, PointLight) and shaders to implement the Phong reflection model. Yet, without projected shadows, the human eye can hardly grasp the actual layout and depth of the scene.

My goal was to work on directional light projected shadows as part of a broader work to handle sun-light and a dynamic outdoor environment rendering setup (sun flares, sky, weather…).

Full code after the break…

Stage3D Online Conference Slides

It was really awesome to be invited to talk about Minko today during the Stage3D online conference organized by Sergey Gonchar. He has done an excellent job in organizing this and I hope people enjoyed attending it as much as I enjoyed being a part of it.

minko_file_formats_comparison minko_editor_workflow minko_editor_triggers minko_darksider

You can watch the entire conference here.

As I promised, here are the slides to this presentation. They are pretty heavy because they embed some videos. Here is the outline of the content of the presentation:

  • Community SDK
    • Scripting
    • Shaders and GPU programming
    • Scene editor
  • Professional SDK
    • Physics
    • Optimizations for the web and mobile devices

At the end of the presentation, I also demonstrated how Minko can load and display Crytek’s Sponza smoothly on the iPad and the Nexus 7 in just a few minutes of work thanks to the editor and the optimizations granted by the MK format. You will soon here more about this very demonstration wiht a clean video demonstrating the app. but also the publishing process. This is incredibly cool since Sponza is quite a big scene with more than 50 textures including normal maps, alpha maps and specular maps for a total of 200+MB (only 70MB when published to MK).

Don’t forget to have a look at all the online resources for Minko:

As stated in the presentation, Minko’s editor public beta should start next week. So stay tuned!

New video: normal mapping and specular maps

Normal mapping has been available for a long time inside Minko. At first as part of the minko-lighting plugin and now in the core framework (in the dev branch only for now). The support for specular maps was added recently. Combining normal mapping and specular maps really gives good results. To show how far you can get, here is a little video demonstrating both techniques in the Minko editor: