Teaser Fridays and Roadmap talks

Sneak peek on a feature we’re shipping in the next release: Local and World vertex space.

We’ve added a new property to materials that dictates how the meshes that the material is associated with should be rendered and more specifically where vertices are transformed. There’s two options - vertex-space-local and vertex-space-world. World is the classic way of transforming and batching, just like it works in previous releases. Local space however doesn’t transform vertices on the CPU or put them into a large vertex buffer. Instead this is performed on the GPU which is much faster for models that have huge amounts of vertices.

This will break batching since we can’t share world transforms anymore, which means that the draw calls will increase, but as you see in this video the rendering is much faster for 3D rendering with detailed geometry. There’s a bunch of things that isn’t supported yet, but this is a decent first step towards better overall 3D support which I hope people will utilize more in the future!

19 Likes

Another exploration day today :slight_smile:

Today I continued working on the results from a previous exploration day: Supporting ProGuard for Android. It’s a tool used to remove redundant Java classes, and also to optimise byte code, and obfuscate functions.

Today I mostly worked on the actual pipeline of this feature. My goal was go get a MVP working.
In the future, this feature will be improved upon along the way, when we start supporting AAR files as well (Android archive (Zip) files containin libraries, jar files, manifest stubs and also ProGuard files).
All in all, this first MVP feels ok, it just needs some cleanup (and some discussions) and I hope this can be released in a sprint or two.

A new game.project setting:

The final size compared to the same (empty) project without using ProGuard:

Here’s a glimpse of how a .pro file looks like:

19 Likes

Another exploration day!

A lot of cool stuff happened in the office today :wink:

Here’s one thing I implemented: Synchronous Raycasts!

In this example, the (kinematic) hero uses 3 raycasts, directly in the update function, to resolve it’s collisions.

Calling the function 3000 times from Lua takes ~5ms (if you get a hit), or ~2ms (if it misses).
This is an actual pull request, and if it passes the design review, it should land in one of our next releases.

22 Likes

That’s actually super useful. I have a Button class that works with game object sprites and I do the picking manually. Maybe it can be done with this instead.

2 Likes

On this exploration Friday I decided to add extra polish to printing of values evaluated from editor. It will try to print as close to Lua data literals as possible. In places where it’s not possible, for example, in cases of circular references, function values and custom types, it will hint on impossibility to print that by using <angle brackets>

18 Likes

This is very good news. For static environment this is enough. But if we want to move raycast target and cast rays again…

Can your raycast implementation do what I quoted above?

This is just the raycast function.
There is currently no way to update the physics engine manually, to update the broad/narrowphase info.

My exploration day was dedicated to this library for simpler message sending from JS -> Lua: https://github.com/AGulev/jstodef

On Lua side:

local function example_2_listener(self, message_id, message)
	if message_id == "ObjectEvent" then
             --do something
        end
end

function init(self)
	if jstodef then
		jstodef.add_listener(example_2_listener)
	end
end

function final(self)
	if jstodef then
		jstodef.remove_listener(example_2_listener)
	end
end

On JS side:

-- Any your async method
		setInterval(function(){
			JsToDef.send("ObjectEvent", {foo:"bar", num:16});
			JsToDef.send("FloatEvent", 19.2);
			JsToDef.send("IntEvent", 18);
			JsToDef.send("StrintEvent", "str");
			JsToDef.send("EmptyEvent");
			JsToDef.send("BooleanEvent", true);
			JsToDef.send("BooleanEvent", false);
		}, 3000)
14 Likes

Hi all, I just wanted to showcase a little bit of progress on our Vulkan renderer that I’ve been tinkering with on and off for a while now. As you all might know we need to have support for a Metal rendering backend for iOS and MacOS due to the upcoming deprecation of OpenGL. Right now we are exploring the use of Vulkan with MoltenVK as a translation layer so that we could potentially have the same API for all platforms. Furthermore, this could give us (or you guys actually) a bunch of new tools to do some really stuff in the 3D space later on :slight_smile:

The left window is a Defold ‘game’ using OpenGL and the right window is the same Defold ‘game’ but with a Vulkan renderer (actually it’s translated into Metal in reality, but written with the Vulkan API).

Disclaimer: As you can see, it doesn’t look exactly same right now, I haven’t really looked into draw state management so alpha blending is turned off for now.

25 Likes

All these experiments are so cool! Great work guys!

4 Likes

:vulcan_salute:

4 Likes

I am wondering if the MoltenVK render and the future new editor extensions will also bring to the table node based shader creation? Just wondering… :smiley:

3 Likes

Vulkan/MoltenVK wont really do much for such a feature I’m afraid, I’m building it on top of the same render API so it Will have the same capabilities as the current renderer. But it does opens up a bunch of other potentielly cool features down the line that I’m excited about :slight_smile:

7 Likes

One (boring) thing I’m particularily excited about is that we get more than 4k textures on iOS. On iOS, OpenGL is restricted to 4k textures, even if the hardware supports more. Yay! More space for huge keyframe animations!

6 Likes

Before you release the new raycast API I would suggest making rays hit “trigger” collision objects too. This will not hurt anything, but make the new ray casts more flexible.

3 Likes

I haven’t tried it specifically, but I just assume it works since it’s the same raycast code being invoked.

1 Like

This flew a bit under the radar but actually shipped in 1.2.149 under the issue DEF-3618 - Preloader path cache.

In case anyone was waiting for this. :slight_smile:

11 Likes

This Friday was an Exploration day and I decided to implement gamepads for html5.
It’s not done yet, but I have the first results:

23 Likes

wooooow :heart_eyes: glad to hear!

1 Like

Got back to doing a bit of vulkan work this sprint, so thought I should share the progress so far. I’m currently looking into dealing with the render pipeline state management for things like culling and depth testing.

21 Likes