snõwkit dev log #7 (embers)

sign up sign in

Words on the new and the old renderer for luxe.

previous editions
- #1 “assets”
- #2 “history”
- #3 “modularity”
- #4 “data flow”
- #5 “phoenix”
- #6 “community”
- #7 “embers”


In dev log #5 I was talking about the renderer in luxe, which was named phoenix. Today we're going to have a look at the new renderer, how we're going to transition to it, and what that all means for the alpha and the current focus sheet.

phoenix to ashes to ...

Here's an amusing anecdote on the name. From Wikipedia,

a phoenix or phenix is a long-lived bird that is cyclically regenerated or reborn.

and

a phoenix obtains new life by arising from the ashes of its predecessor.

As I mentioned in the phoenix dev log, phoenix has been around for quite some time. It's also been recreated multiple times, which aptly fits the descriptions and symbolism of the mythological creature.

That's about as far as the analogy/mythology goes however, it's just an amusing overlap.

embers

This is what the new renderer is named!

The nature of embers (the renderer) is lower level at heart - It will be a starting point for various higher level forms to take shape.

Names and meaning aside,
embers is the evolution of concepts from phoenix but decomposed further. Like everything in luxe, it will be bottom up, starting with the lowest levels and tiered in convenient ways to form a set of tools and facilitation for the user to use.

Here's what we're going for with embers:

low level

Don't worry, this doesn't mean that you will have to play with raw bytes just to draw a rectangle. It just means that if you want to or need to play with raw bytes - you can.

minimal

Solving only the required problem statement is an important part of getting anything done, and embers is especially affected by this, given how complex rendering can get.

The renderer will be explicit, to the point, and aside from facilitation (the core design philosophy of luxe overall) it won't solve everything for you, and won't do things based on guessing.

future focused

embers is designed around future API's first.

There are some exciting and important new rendering API's heading into consumer space, some of them are already here. Vulkan, DirectX12, Metal, ES 3.x and WebGL 2.0 are all interesting for a variety of reasons.

The most exciting part for me is that the majority will arrive to existing consumer hardware. Metal has been out since 2014, has high user base on iOS and will be available with OS X El Capitan very soon for Mac. Vulkan will launch with a number of consumer devices -already available- in the wild. WebGL 2.0 will run in all browsers like before.

Still, these will take time to become wide spread, they will sometimes require recent hardware (on mobile mainly). That means the existing rendering (OpenGL and OpenGL ES based) will be around for some time to come - they aren't going anywhere.

In other words - embers will still be as compatible as phoenix was with the same minimum requirements, it will just be designed for where we're going, not anchored in the past. When running on a platform with a modern API and the hardware to support it, the newer API's will be used instead.

There's a lot to go into specifically like which backends will be supported and when but suffice to say the initial focus is OpenGL, OpenGL ES and WebGL as before, as it has the widest reach.

There's a lot to solve still, and a few API's aren't available yet but I'm confident in the direction and excited for the future in this regard.

portable

Since the API itself is minimal, the backends handle the implementation details. This means that adding a new rendering API isn't particularly difficult, provided that the rendering API gives you access to submitting geometry, setting shaders, textures and other obvious stuff.

The goal is to make the connection between the rendering API and embers simpler, so that porting is easier. Rendering is normally abstracted, rather than relying on the rendering API directly, so this is nothing new or interesting, just worth noting.

flexible

As with luxe and snow and linc and everything else, a key component will be access. While the rendering will be abstract and portable you'll still have access to the raw GL (or other) API's, and will still be able to get below the renderer as needed.

And as it should be, the renderer will let you define when to batch things and how, as well as what format you want to put your geometry in and all that fun stuff.

Transitions

So, now we know where we are headed, what about "how", "when" and "what happened to luxe alpha-3.0"!

how

I touched on this in dev log 5, embers will be developed alongside phoenix for now. It is being developed in a separate repo at the moment, tested directly against snow (so there is no accidental coupling).

I'll get into that in the next dev log, though, as it's quite an in depth topic.

when

I've actually been working on embers for some time now! Mostly time spent answering unknowns, design questions (things like "what does geometry look like now?" and "how do we handle access to hardware specific API's?").

Still, it's already possible to draw things directly with embers (using the GL backend) so it's coming along nicely. There are a few lower level snõwkit community devs helping out in various ways as well.

embers 0 init

The goal is to tie off loose ends in the fundamentals, making sure that when I put the code up there isn't confusion or discussion getting caught in the wrong details and distracting us from the task at hand.

That said, the aim is to have the code up ASAP, definitely during the course of alpha-3.0 if it makes sense. This makes "when" semi unclear, but there's plenty to be done in preparation which leads to...

luxe alpha-3.0

Although embers itself needs a lot of careful thinking, planning and designing - and while rendering is complex, literally rabbit holes in every direction, there are things that will help with the transition with regards to phoenix getting out of the way.

If you were paying attention to the commit logs (and the Ludumdare post), there was already quite a bit of clean up and fixing going on in phoenix. These benefit everyone immediate term because of the performance benefits but that's not the focus at the moment.

What I am doing is reducing the amount of conceptual and behavioural differences in the phoenix API, to allow simpler transition to embers. That way, all the user facing code has plenty of time to transition before we even introduce a whole new rendering backend.

Concrete example
The group id mentioned here, these aren't something we're keeping. The groups are meant to be a lot more literal, i.e how the batchers work, when creating a second group of geometry. This means that instead of the render callbacks happening on a weird granular level, they happen at the batch/group level, and the group id integer falls away.

The change would mean change batcher.add_group(id, callback, callback) might become batcher.prerender = callback and batcher.postrender = callback, and depending on what you were using the callbacks for, you also move the geometry to a separate group to get the same outcome.

This transition is a good example of something that is a usage pattern that embers will use that phoenix can align with now. Changes like these will be applied over the course of the alpha-3.0 milestone - allowing adequate time to update and clear change notes.

When embers arrives your code is already structured the right way, and the changes will largely be syntactic which is trivial to update.

Charging ahead

Immediate term, phoenix is getting better and faster and cleaner and simpler as a bonus, but the focus is on getting ready for embers.

With a clear path ahead for the alpha-3.0 milestone - We'll have the alpha-3.0 tasks set up today, and I'll post the focus sheet with a sample as always soon as well. More dev logs will roll out in the next week or two, where we'll dive into more details regarding the changes and the renderer.

Till then!

Tags
snowkitdevsnowkitdevlog