Really cool work. While on the topic a couple of thoughts.
∙ preview selected camera - display camera view in a rectangle box in editor scene
∙ set view to selected camera - set editor scene view to selected camera.
Will this camera mesh be default? Would we be able to opt in for a minimal display like a simple box at origin and the frustum?
The first of your two points requires quite a bit of work unfortunately, but it’s our idea to support this at some point in the future.
The second point is easier to implement, and I’ve thought about it too.
Regarding the mesh, right now it’s the default one and not exchangeable but if it’s an issue we can perhaps think about it 
Here’s another sneak-peak of a feature I’m currently working on - custom vertex formats:
It basically enables you do pack any type of data into vertex attributes, such as colors, normals or local positions. Typically that’s data that usually ends up in uniforms/constants which can break batching.
Another benefit of this system is that you can reduce runtime sizes as well - if you only need two components for a position you can omit the z component of a position, and if the shader doesn’t include texture coordinates that stream will not be produced.
Another teaser, because why not! We are also working on adding support for per-node materials in the GUI in the same way you can set individual textures:
Note that the preview doesn’t use the per-node material (yet), but it’s how it is supposed to work later at some point.
Currently working on adding support for the custom vertex formats to particles and this is the result so far! (yes it looks weird and broken, but everything is working as it should, it’s just ugly test content)
One of the more voted issues on our github (Issues · defold/defold · GitHub) is the ability to dynamically change collision shapes in runtime. Here’s a bit of a POC on how that could be done in scripts:
And this is the code for this example, showing how a possible API could be implemented:
(keeping this old thread somewhat alive…)
Here is a (not very good looking) screenshot from the “sprite multi texture” feature that’s nearing its completion. The task is almost done, it only needs some fixes with the editor, but the bulk of it is done I’d say.
With this feature, you’ll be able to have multiple textures on your sprites, allowing for effects like normal maps, and emissive lights for your sprites (or other things you may want to do).
My example is very barebones, only combining two images in the shader.
I hope we can get a nicer normal mapped example soon (perhaps the community can help with this?)
ETA: I’d guess within a release or two.
(Left screenshot, a diffuse+normal map combined together. Right, two trimmed images in combination, one arrow in each image))
Can’t wait! I will replace my workarounds with offsetting textures 
Awesome!!! This will open many creative doors!
I’ve been working for a bit on integrating the new RIVE (https://rive.app/) renderer into our extension, and have been asked to share some progress. So here we go!
How are draw calls?
Mostly just a few (1-4-ish?) calls unless you zoom in really close, then the renderer does a lot more work. It’s basically GPU driven, but I don’t really know all the details on how it works under the hood.
Looks great! I see that Rive has a method for modifying text at runtime - do you plan to expose that? Would be useful - possibly essential - for GUI.
Yes, we’d like to expose a general purpose api for drawing vectors / shapes, as well as dynamic texts (somehow). It’s early stages still but we are discussing an api
Is it possible to render more than one rive scene at a time? For instance, using one Rive scene for much of the GUI, but also for a number of other Rive scenes for game objects as well?
Yes it should be possible (but I haven’t tested)
What are the supported platforms?
Currently only Mac with vulkan/metal, but eventually all platforms.
Wow! Very cool! When it’s added to the Defold?
Not sure. We’re currently really busy with the Rive integration and improved atlas packer. But it is high on our list and will hopefully be finished as one of the next tasks.
