Seth Hoke
What we've been up to...
What we've been up to...
Seth Hoke
Continuum Graphics November 2018 Progress Update
Seth Hoke
Stratum Early Access is Live!
Stratum Early Access is Live!
Seth Hoke
It's finally here! Continuum 2.0 is released!
It's finally here! Continuum 2.0 is released!
Seth Hoke
What's been going on...
What's been going on...

Continuum Graphics April 2019 Progress Update

Here we are, another month has passed…what have we been up to?

Those of you that follow us closely likely already know, but for those of you that don’t, or might have missed something…well, we will catch you up here.

Stratum

I’ll start with Stratum, since it’s been the focus of most of our attention lately.

It has had a fair few additions this month, as well as a lot of miscellaneous tweaks and fixes. You might have seen many of the additions on our Social Media already, but I’ll go over them here again for those that haven’t, or for those that would like to see them all in one place.

Tweaked/fixed

  • Iron block improvements

  • Fixed Grass Normals

  • Improved Grass Texture

  • Fixed Leaf Block model issues, in hand, in UI and when dropped

  • Improved Stone tiling

  • Tweaked Grass Side

Added

  • Bedrock

  • Gravel

  • Oak Planks; this texture also applies to:

  • Oak Stairs

  • Oak Slabs

  • Oak Fence

You can view the more detailed commit history here.

Here’s some screenshots of these additions and tweaks, taken in game with Continuum 2.0.2 (click to enlarge)

Continuum 2.1, Legacy, and yes, RT

Between tax season, and some personal troubles, DotModded hasn’t had a whole lot of time to work on the current blockers for the Continuum Base. That said, taxes are almost done, and he is in much better spirits! He should be getting back into the swing of things soon. This means that with any luck, the last 12.5% of performance we want to squeeze out of the Base will be found, and we can begin to build out Continuum 2.1 on top of it. Once we do, we will push the first Alpha release, something I know a lot of you have been looking forward to.

Once the Base is done, work on Legacy, the fully updated and cleaned up version of 1.3, will commence. Robo and Jake are particularly excited to get started on it, and we will share more news about it when we have it, but rest assured, we have not forgotten about it.

And last but not least, RT…Continuum RT will also be built upon the same Base as 2.1 and Legacy, and work on it is scheduled to resume shortly after. Dot is very excited to get to work on this, and we know a lot of you guy are very excited to see it, so we will share more info as soon as we can.

Discord Community

Some interesting things happened in our Discord Community Server this month. We hosted our second Continuum Screenshot Contest to celebrate reaching 2000 members. We got a lot of great submissions, but Karrasko managed to get the most votes and take the 1st place spot, with Jman and ET-Gamer taking 2nd and 3rd respectively. We would like to thank everyone for their participation and we look forward to doing it again!

Here’s a little gallery of the winning submissions, in order from 1st to 3rd:

We also had a Discord exclusive discount code for a few days this month, just to give back to our community there a bit. If you don’t want to miss future contests or potential discount codes, or just want to join our Discord community, you’re more than welcome to join us. Here’s the invite link.

Before we go…

We wanted to mention, and thank Ultimate Immersion for his terrific video showcasing both Continuum and Stratum! You can check it out below and maybe give him a sub :)

With that said, this monthly update is over. we will see you guys again next month.

Thank you for your continued support, we couldn’t do it without you!

What we've been up to...

It’s been quite busy behind the scenes here at Continuum Graphics these past few months. Between the holidays, Server upgrades, PC upgrades, PC troubles, new staff, slowdowns from staff leaving, and work on 2.1 and Stratum, we have been quite busy. But rest assured, we are still here, and still working.

Lets run down what we have been up to these last few months, in a bit more detail.

The Holidays

The holidays were obviously a busy time for many of us, between family, other obligations and just people enjoying some time off, not a lot got done through December and early January. We did however have a fairly long holiday sale that a few of you might have taken advantage of.

PC upgrades (and issues)

Me, and our main texture artist upgraded our PC’s around the holidays. Him, so he could get more RAM and a faster CPU to make his texture work much easier, and me just because my CPU was getting a bit slow for my personal needs. Sadly, we both had some fairly annoying issues for months. Mine were more minor than his and my system was still usable during this time, but his was out of commission for about a month. So very little texture work was done between the Holidays and the first month or so of the year, mostly due to this issues. He eventually got a replacement CPU and his problems were fully sorted.

The GitLab…

As some of you no doubt know, our GitLab had started having some serious issues sending invites and allowing people to download files towards the end of last year, and behind the scenes we were running out of RAM, disk space and overall server resources for our GitLab instance. So to kill two birds with one stone, we went ahead and wiped the GitLab, upgraded our server, and rebuilt the GitLab, this time with better organization as well. This solved our invitation issues for the most part, and gave us breathing room for many, many more members (that’s you guys!), to be added to the GitLab, as well as some cool new projects in the future. This took us a few weeks though, as we had to learn how to do a lot of it ourselves. These are the kinds of things Dethraid used to handle for us, but we managed it in the end.

Stratum Development

Development did not halt completely throughout these last few months, though most of you already know that…that said it was slowed significantly. We did still manage to add a fair few textures, fix a few oopsies, and managed to add a 1.12.2 version of each resolution of Stratum, not just the 2K one. Something many of you have been asking for since we made the switch to 1.13. It can be accessed by clicking the drop-down menu on the download pages that says ‘master’, and selecting 1.12.2, then proceeding with the download as usual. These 1.12.2 branches are not currently automated, like the 1.13 ‘master’ branch is. So it will sometimes be a bit behind the master branch in terms of how up to date it is, at least until we get automation figured out for it. If, and when we do, we will update you all in a future blog.

With Hox’s PC now back up and running, and with more RAM and a faster CPU, updates should come more regularly. Also, once we get Myth, the new texture developer we brought onto the team last November, fully integrated and up to speed, things should really start to pick up.

As for new textures added/tweaked recently, here is a full list and some screenshots;

  • Added New Cobblestone

  • Added New Mossy Cobblestone

  • Added Birch Wood

  • Added New Brick

  • Added Oak & Spruce Leaf Model Variants

  • Added Netherrack

  • Added Ice

  • Added a temporary Snowy Grass Block

  • Tweaked the tinting of Oak Leaves

  • Tweaked Spruce Leaf vibrance and specular brightness

  • Fixed some name issues with concrete textures

  • Various fixes for Wheat textures

  • Various fixes for specular textures

  • Various naming and misc fixes

These additions and changes can all be viewed on the GitLab as well.

Here are some beauty shots of many of these new and improved textures at the full 2048x resolution. They are taken with Continuum 2.0.2, as usual. Click them to see them in fullscreen.

Continuum 2.1

Continuum 2.1 development has continued, albeit slowly, for the reasons we went over earlier. That said, we did manage to squeeze a bit more performance out of the base, getting within 12.5% of our performance target. We are almost where we want to be performance wise. Hopefully we can squeeze that last little bit out of it soon.

Continuum Legacy

Great news for those that love 1.3, but want a more updated, polished experience…work on Legacy has started! It’s still very early, and has only been in development for a little over a week, but it is coming. Hopefully we will have some more to share about it in the coming weeks.

Continuum RT

We have not given up on Continuum RT, but getting 2.1 to Alpha testers is the current priority of our shader developers at this time. And with work on Legacy also starting, there just isn’t time for RT right now. Work on RT will likely have to wait till after 2.1 hits Alpha, at the very least.

Going forward…

Development is mostly back to normal now and you can expect regular blogs and social media updates from us going forward, barring anymore unforeseen circumstances.

Thank you all for your continued support, we couldn’t do this without you!

Continuum Graphics November 2018 Progress Update

November is now over. Thanksgiving, Black Friday, and Cyber Monday are all behind us. We all hope you guys had a wonderful Holiday, but now that it’s over, I figured I would sit down and give you guys a update on what we’ve been up to this last month or so. Let’s get into it!

Continuum 2.1, RT, and Legacy

As some of you may already know, Sp614x recently implemented the buffer flip feature we needed to further optimize the new base for 2.1, RT, and Legacy. We got our hands on it a few weeks ago and have already began to implement it. Early results are very promising. Dotmodded is very optimistic about how much more optimized 2.1 will be in the end, versus 2.0. This enthusiasm is being funneled into working on 2.1 at the moment, and it is where most of his time is going. A alpha build of 2.1 should be ready soon™. For now though, here is a very early sneak peak of 2.1 we shared on are social media earlier last month…

Work on RT and Legacy should be ramping up in the coming weeks/months as well, due to the base being ready to be built upon, but getting 2.1 to alpha is the current priority. We will share more about RT and Legacy’s progress in future blogs.

Continuum 2.0.2

We recently released another small update to 2.0. This update, version 2.0.2, includes full support for Minecraft 1.13. With a compatible pack like Stratum, POM, Normals, Specular and PBR should all work in Minecraft 1.13. This version also still supports Minecraft 1.12.2 and older, provided the older versions of Minecraft have a fairly recent build of Optifine available for them.

You can download 2.0.2 for free below.

Stratum

At the beginning of the month we added another texture developer to our team! Discord community members may already know him as MythicalPigeon, and he has been working on Stratum alongside Hox for a few weeks now. Having two developers should greatly increase the speed at which we can develop the pack.

Speaking of developing the pack, we added a fair amount of textures this month. If you follow us on social media you might have seen some of them already. They include; podzol, podzol side, oak leaf, spruce leaf, spruce log, a new grass side, and sand. Here’s a gallery of some of the new textures for your viewing pleasure…all taken with Continuum 2.0.2, in Minecraft 1.13.

Server Upgrade

Not super interesting, but I figured I’d share anyway. We were running low on ram on our main server, and had it upgraded earlier this month. We have double the ram now, and are fully prepared for many more future users and a few other exciting possibilities…

Gitlab has been giving us some fits since though, as some of you may know. We are still working on finding and fixing the last of those issues. Bear with us please.

Last, but not least, Nova

If you don’t already know, Dethraid, and by extension, Nova, are leaving Continuum Graphics. He wrote his last Nova blog with us last week, it detailed this months progress, as well as why he is leaving, you can read it here. If you don’t have the time to read it, or just want to know why he and Nova are leaving, the gist of it is this; between his new job, doing his job here at Continuum Graphics, which was managing our Server, Automation, and Gitlab, and working on Nova, he just wasn’t able to put as much time into Nova as he wanted. So something had to give.

What does this mean for Nova? Well, as Dethraid explained in his blog, not much. Nova’s main goals and features are NOT changing, and he will still be working on it, more than before in fact (that is the whole point of the split). Continuum Graphics customers will still be able to use Nova when it becomes available and Dethraid will still be hanging around in our Discord server, as well as his own Nova server.

We are all still good friends and we wish Dethraid the best of luck in continuing to develop Nova.

So there it is…we had a busy month, mostly behind the scenes, but busy nonetheless. We will be back next month with another progress update. Until then, thank you for your continued support, and goodbye!

Nova Update - November 2018

Hello everyone, please join me for the November 2018 update for Nova!

As mentioned in the last blog, I started a new job in late October. Much of my time in November has been taken up by that job, which is just how things go sometimes.

The first work I did in November was getting the DirectX 12 render backend’s shader loading working nicely. Nova converts all shaders to SPIR-V before sending them to any render backends, so I needed to convert from SPIR-V to DirectX 12 HLSL. Doable, but incredibly non-trivial - I spent most of a week on the conversion code, even though I was able to use SPIRV-Cross to handle most of the translation.

I then started working on loading and rendering meshes - the core part of Nova. Nova will use indirect rendering to draw meshes, which means that I needed to put meshes into as few buffers as I could. I spent a couple weeks making a mesh allocator. I actually tried a few different ideas before settling on a block allocator that can compact its allocations if needed - if there’s enough total free space in the buffer for a new allocation, but no blocks are large enough, the allocator will move data towards the front of the buffer until all free space has been filled.

Once mesh memory was allocated, it was time to render meshes. This is the crux of Nova, and I expect it to take a long time to get right. One of the major challenges is how to make rendering things multithreaded. I definitely want Nova to be able to take full advantage of all cores, but how to do that while staying sane is…difficult. At the time of writing this blog post I’m making a command buffer for each VkPipeline and synchronizing them…somehow. There’s a couple of unknowns in there.

Additionally, near the middle of November I decided to leave Continuum Graphics. For a while now I have been responsible for maintaining the server infrastructure, and unfortunately that took far too much time away from Nova, especially with working a full-time job. Nova needs all my free time, and now it can have it. There are no hard feelings between me and the Continuum team, and we are all still friends. This is just a time management thing.

My plans for Nova have not changed in the slightest. I’ll still be working tirelessly to bring everyone the best possible general-purpose renderer, and to integrate it into Minecraft and eventually other games. Leaving Continuum Graphics has given me the time to make that happen.

I won’t be making blog posts about Nova any more. The best way to keep up with development of Nova is to join the Nova Discord server, where I hang out pretty regularly. There’s also a Twitter account, but I mostly use that for big announcements. I’ll still be hanging out in the Continuum Discord as well.

That brings us to the end of the final Nova progress update on the Continuum Graphics blog. Everyone’s support for my project has been incredible, and I only hope that I can deliver something that meets your expectations - Dethraid

Nova Progress Update - June to September 2018

In June I stopped writing about Nova so I could write Nova… but now I’m writing about Nova again. Sorry for the delay, and for the very…dense nature of this blog. If you’re more into pretty pictures and less into a lot of technical talk, you might want to skip this one.

With that said, let’s get into it!

June

In June, I continued fixing any bugs I could find and continued building out more of the renderer. This included setting up the data for UBOs and handling the Minecraft lightmap properly. I also started on a CPU profiler to get a general idea of how well Nova runs.

Janrupf joined at the beginning of June and started working on moving Nova from raw MCP to Forge. Most of this effort was converting Nova's changes to Minecraft from a source code patch to Forge Mixins.

July

Barteks2x joined at the beginning of July and jumped into helping Janrupf convert Nova to Forge. He also updated Nova to run in Minecraft 1.12.2 instead of 1.10. That brought us into a better position to update to 1.13 when it became available.

Barteks2x also got chunk rendering working. I hadn't quite gotten that feature working, but Barteks2x was able to solve the issues and get the chunks drawing. Unfortunately, this introduced a bug where, on my computer, the GPU would freeze up after a second of rendering a world. Solving that would take me many weeks.

4D Klein Manifold (hereafter referred to as Klein) came in around the middle of July. He began working on getting the main menu panorama working.

We merged the Forge version of Nova into the Vulkan branch - essentially declaring that Nova was completely moved to Forge. During that merge we had to resolve a number of compatibility issues. Barteks2x and Janrupf develop on Linux, while I'm on Windows and Klein switches between the two. Unfortunately they had done a few Linux-specific things that needed to be resolved.

Janrupf then started setting Nova up for Continuous Integration (CI). CI lets us automatically compile Nova whenever the code changes. This ensures that the code changes we make won't horribly break Nova, and removes the need to manually compile Nova. I had wanted to set this up for a while, but it would have been much more difficult before we converted Nova to Forge.

Then came the task of merging the Vulkan branch into the Master branch. This was more tricky than one might expect because back in February, Klein had made some changes that made chunk loading much faster and more like vanilla - but made them when I was having doubts about Vulkan, so we ended up with two branches with different commit histories. Barteks2x took on the task of resolving all those changes, and did so very well.

With CI conquered, Janrupf began working on a standalone shader editor for Nova. Nova is much more complex and more involved than Optifine shaders or Bedrock shaders. Developers coming from those platforms will likely need a lot of help to become proficient with Nova, and a standalone shader editor can go a long way to providing that help. You can see and follow his work at here.

Another developer, Strum, also joined in July. He began working on the shader marketplace. The vision here is that shaderpack developers can upload their shaderpacks to a central location, then the shaderpacks can be browsed and downloaded through Nova, without leaving Minecraft or moving things to different folders. This will provide a lot of discoverability for shaderpacks, especially smaller packs that needs a popularity boost. You can see and follow his work here.

August

To help solve some of the issues that arose when merging Vulkan into Master, Barteks2x created a tool to capture the parameters to native Nova functions, then replay them in a JVM-free environment. The JVM is cool and all, but it does a lot of things that interfere with debugging C++ code. In the first week of its existence, his tool proved to be well worth it, time and time again.

But that prosperity was not to last. While Barteks and Janrupf were making wonderful progress, I did not have any such luck. A crash began rearing its ugly head. On Windows, after Nova was rendering 50+ chunks, it just…died.

I first noticed the problem as a segfault when updating the lightmap. I removed the offending code, and got a crash when updating a different resource. Removed that code, and now the crash happened when reading the GPU time queries for each frame.

The behavior was dumb. Were there multiple crashes? One bad one? I added a new thread that would poll the GPU to find out when each VkFence got signaled. It polled, and… things got weirder. I could see each command buffer be submitted, could see the fence get signaled… then a segfault somewhere inside vkWaitForFences.

This was dumb.

I dug into this for a week. I tried this and that, poked here and there…nothing. The GPU was just like “nah bro I’m out” in the middle of rendering a frame.

Vulkan isn’t the first-party graphics API on Windows 10, DirectX 12 is. On August 14 I made the decision to add in a DirectX 12 rendering backend for Windows 10. This was the first-party API on Windows 10, surely it would work better?

The work began. I would write the DirectX 12 backend for Windows 10, Janrupf would make the Vulkan backend. By this point Barteks was back to focusing on CubicChunks and unfortunately couldn’t give more time to Nova

Janrupf did a lot for the architecture of Nova in the last half of August. He realized that Nova shouldn’t have its own logger or load its own config file, that all should be provided by whatever application Nova was embedded into. Additionally, he pushed for “add a DirectX 12 backend” to become “add a DirectX 12 backend and also rewrite the Nova backend”, which I agreed to. The Vulkan code would have to be mostly replaced anyways; I was trying to get things done quickly and made far too many compromises

 
 

September

During September, I continued working on the DirectX 12 code, and Janrupf continued working on the Vulkan code. At one point I had the bright idea to make a command buffer-based abstraction over both DX12 and Vulkan. That was a horrible idea, because while DX12 and Vulkan are similar, they aren’t similar enough to have a single interface. Bleh.

In mid-September I decided to convert Nova to a job-based threading model built on top of fibers. This meant that Nova could take advantage of all the cores in your CPU, and they it could do so very efficiently. There were a number of growing pains as we adapted to this new style of programming, but ultimately we learned.

We started working on loading shaderpacks in both Vulkan in DirectX 12. We made a good bit of progress, but Janrupf had to go back to school and my girlfriend came to visit for three weeks (one week in October) so not much happened in the second half of September.

October

I added all kinds of validation and debugging information to the shaderpack loading code in October. Shaderpack developers are going to have to re-learn a lot of things to take full advantage of Nova, and the better the error messages I can give them are, the easier the transition will be. I also spent a lot of time fleshing out the shaderpack loading code for both Vulkan and DirectX 12. Janrupf was busy with school, which meant that the Vulkan code fell on me. The work to load shaderpacks and create the API-specific resources that each one needed was straightforward, if a little tedious.

What was not straightforward was transpiling shaders. Nova accepts shaders in GLSL (which is compiled to SPIR-V) or in SPIR-V. DirectX 12 accepts shaders in HLSL (which is compiled to HLSL bytecode), or HLSL bytecode. Additionally, a few concepts that are crucial to Vulkan shaders have no equivalent in DirectX 12 shaders. This meant a pretty significant amount of work on my part to perform the translation.

Additionally, on October 22 I started a new job. This was pretty cool, but meant that I’d have less time for Nova.

Looking Ahead

Rewriting the Vulkan code and adding in DirectX 12 code will take plenty of time, but it’ll be time well spent. Nova will end up with a well-organized code base that can be easily extended as more and more features get added to the code.

Nova won't be updating to 1.13 until Forge does, and Forge won't work with 1.13 for a while - they want to take some time to improve their code quality. This gives us a lot of time to make Nova amazing before we have to handle all the changes that Minecraft made for 1.13. We're excited to be starting to realize the vision of Nova, and we hope that you're excited, too!

 
 

Continuum Graphics October 2018 Progress Update

Well, it’s October, and that means it’s time for a update blog. So let’s have a chat about what we’ve been up too, shall we?

Continuum 2.1, RT, and Legacy

We have good news, and we have not as good news. I’ll start with the good.

One of our main goals with 2.1 is optimization. When rewriting the base shader code, we managed to get back around 20% more performance, and while that is good, we are aiming for about 100%. Problem is, we couldn’t figure out what was bogging the shader down. Even with all effects removed, it was still running slower than shaders like Ebin.

This is what was holding up any release of even Alpha Builds of 2.1. We didn’t want to push out a update that we weren’t happy with, and we didn’t want to have to go back and redo half the shader again either, especially when the issue was right in front of us, just teasing us. So we continued working. About a week ago we finally figured it out, which while being a great relief, brings me right from the good news, into the not as good news.

Basically, the problem is this: we need the ability to fit more data into a single buffer, but Optifine does not currently allow us to change settings related to that. We have opened the appropriate issues on the Optifine Github and contacted him about this, and are currently just waiting for a response. Hopefully that will happen soon, as the shader base for 2.1 is also the base for Continuum RT and Legacy, and without it, in its fully optimized state, we cannot continue work on those projects. We will share updates on this issue in our Official Discord server and future blogs as the situation progresses.

Continuum 2.0.1

The shader team has not been completely idle while waiting for Optifine’s response, as I am sure some of the Alpha level donators will already know. We have created a incremental update to 2.0 to address some issues that made it past us into 2.0.

Fixes included in Continuum 2.0.1 are as follows:

  • Leaves on trees in distance fading nearly completely out resolved due to TAA applying to them improperly (see screenshots below for a visual comparison of 2.0 and 2.0.1’s leaf TAA)

  • ‘Leave TAA’ toggle removed completely as it is now unnecessary

  • POM issue that was causing lines on the seams of textures fixed

This update is now available to all, and you can download it right now!

Stratum

Work on Stratum has been progressing steadily, with a lot of textures behind the scenes being worked on, and a few making it into the Early Access testers hands already.

Most notably we have a new cobblestone texture, and a new texture for the ends of the oak wood. These are not 100% final however. The cobble may have it’s overall scale tweaked, and the oak wood still needs some polish around the edges of the ends.

Here are a few screenshots of the latest textures, taken in game with Continuum 2.0.1.

Click any image to enlarge and open in gallery view

Nova

Work on Nova has been progressing, albeit at a slower pace than normal. This is because the main developer, Dethraid, has been on Vacation for the last 3 or so weeks. He will be back soon though, and he has a rather large update blog prepared for the last few months of Nova development. We will try to get that out within the next week so we can get you guys up to speed on Nova as well.

That about wraps it up for this monthly update…as usual, thank you for your continued support! We couldn’t do this without you.


PS: there may be a little contest and giveaway on the Discord server soon™…be sure to join if you want to be notified about it. You can join here.

 
 

Stratum Early Access is Live!

Our new resource pack, Stratum, is now available for Early Access purchase. If you would like to be the first to test Stratum, and/or you want to support us and it’s development, you can purchase a Tiered Stratum Package. We have three Tiers available:

  • Tier 1 gives you access to 256x

  • Tier 2 gives you access to 256x and 512x

  • Tier 3 gives you access to 256x, 512x, 1024x and 2048x

They will all be updated regularly as development progresses. Please remember, this is Early Access. Textures may be removed at will, or replaced with other ones as it progresses, for various reasons. There may be occasional bugs as well. But they will be fixed when found as soon as possible. Each Tier also comes with a Donator rank on our Official Discord Server, which you should definitely join to follow Stratums development and even give the developers your ideas and thoughts on it as it develops.

You can purchase a Tier, download the demo, find more in depth info, and look at screenshots of Stratum by clicking the button below.

Thank you for your continued support!

 
 

It's finally here! Continuum 2.0 is released!

We made it!

The day has finally come. After many months, and more than a few delays(sorry!), Continuum 2.0 is officially available to all! It's been a long time coming, and we appreciate all your support along the way... but we aren't done yet. Not by a long shot.

Continuum 2.1

We aren't done with Continuum. Development of 2.1 is already underway, with alpha builds of 2.1 coming to Alpha level donators early next month. 2.1 will be faster, more customizable and even more polished than 2.0. We will likely go over new features, optimizations and general changes coming in 2.1 in a future blog. 

Continuum RT

That's not all that's coming though, we have a few new products in development. The first is something we are currently calling Continuum RT... RT meaning Ray Traced. Yes, you heard that right. It will also be available to Alpha level donators starting next month. It's still in the early stages but we are excited about the possibilities opened up by using Ray Tracing to enhance your Minecraft experience! Here are a few teaser images...

Continuum Legacy

If that wasn't exciting enough, we have more! For those of you that prefer the look and feel of 1.3, but find it to be too buggy, slow or too outdated in general, we hear you. We plan to revisit 1.3 and fix it up a bit; we will be adding a few new effects like TAA and just generally cleaning it up. We will be calling this Continuum Legacy. We will keep you guys updated on it's progress in the coming months!

Stratum

And last, but certainly not least, we are proud to announce our own in house Resource Pack. We call it Stratum. It's being developed to support all of Continuum 2.0's features and will be available in a variety of different resolutions all the way up to 2048x. It is still in a fairly early state, so we don't have a whole lot to share with you right now, but more information will be available soon. In the meantime, here are some in-game screenshots of some of the current 2K textures with Continuum 2.0 for you to enjoy. 

Site updates

We will be making a lot of changes to the site in the upcoming weeks/months. Tutorials will be getting much needed updates, a FAQ will be added, some general system requirements for our different products, and more. We hope these changes will improve your experience using our site. If you have any suggestions for improvements to the site please let us know on one of our social media accounts, our Discord or email us at support@continuum.graphics.

Thank you all for sticking with us. We hope you continue to do so as we go forward with more updates for Continuum and our other projects! - Continuum Graphics Team

 
 

What's been going on...

Hey guys, Seth here... It's been a bit since we have had a proper Continuum update blog, and especially in light of recent events I feel that one is long overdue. 

First thing's first, some answers to a question that is probably on a lot of your minds...

What's going on with Pulchra? 

Long story short, a few months ago, Blockstate, the primary developer of Pulchra, decided to start his own company; Atlas Graphics. The whole team here at Continuum Graphics would like to wish him and his team the best going forward. This does however mean that Pulchra will now be sold exclusively on his site, not ours, and that support will be handled through either his site, or his companies official Discord server. Existing customers will still have access through the Atlas Graphics GitLab. Your Continuum Graphics credentials should work on their GitLab as well, but if they don't, contact Atlas Graphics support via their site or their Discord, and they will help you get logged in. All the links you should need have been included above.

How is Continuum 2.0 doing?

Image credit to karrasko#0548 on Discord

Image credit to karrasko#0548 on Discord

As most of you probably know, we released a Public Preview of Continuum 2.0 back in July; you can read more about that in the accompanying blog here. We did this because we felt it was close but wanted to knock out as many bugs as you guys could find, and dotModded, the lead developer, wasn't quite happy with the overall polish level. Still, release was only supposed to be a few weeks out at most...but we obviously didn't get there. Between recovering from kidney stones, starting a new job, moving, and some license renewals for the business coming up, dotModded just couldn't get it all done at the quality level he wanted. We could have released it, but he just couldn't okay it's release in its state at the time. We are truly sorry for the delays, but we really do hope they will be worth it in the end. 

Image credit to karrasko#0548 on Discord

Image credit to karrasko#0548 on Discord

With that said, with any luck work on 2.0 will finish in the next week, and then work on 2.1 and some other, yet to be announced projects will begin. You'll want to stay tuned for more info on those in the coming weeks. 

Also, our YouTube channel will be getting some more focus. We currently do livestreams and the occasional tutorial but we will be ramping things up starting in September. So if you want to see the content we plan to post there, please subscribe here, and click the bell to be notified about our latest videos as soon as they drop. Since we are talking about the YouTube channel and new content, if you want to see some eye candy, since this blog is a bit lacking in that, here is a shader cinematic of the Continuum 2.0 Public Preview we uploaded there recently...made by yours truly(shameless plug). Be sure to watch in the highest resolution your internet and computer can handle for the best quality.

Also, Nova is still a thing

Nova is still being developed, and has been making a good deal of progress, which has been in part due to the new team members that have recently joined to help with development. There will be a Nova Blog soon™ that will go into more details about recent developments, new team members, and everything else that has been going on with Nova over the last 3 months, so look out for that. 

Thank you all for your continued support.

 
 

Nova Update: May 2018

Note: I apparently forgot to publish this blog post until now. It was all written up by the end of May, I promise!

May was a busy month for my person life - I took almost two weeks off in the middle of May to visit my girlfriend, so not as much happened in May as has happened in other months. Some interesting stuff did happen, though!

Swapchain

One of the major differences between OpenGL and Vulkan is that in OpenGL you don't have to worry about the swapchain, but in Vulkan you do.

What's the swapchain? It's a list of images that are presented to the screen. When Nova renders a frame, it renders to one swapchain image. While that is being drawn to the screen, Nova uses the next swapchain image. While that's being drawn, Nova renders to the next swapchain image...

There's a lot of complexities here that OpenGL hides from you, whereas Vulkan lays the swapchain bare and makes you handle it. Figuring out how to deal with that took up a lot of time in April, and it took up about a week in March - but I've finally got it.

Descriptor Sets

Oh descriptor sets... they're a lot of fun. They're roughly equivalent to uniforms in OpenGL, but they're a lot more involved and I was not prepared at all. It's taken most of the time I've worked on Nova in May to figure them out. Because of how Vulkan works it makes the most sense to have each material manage its descriptor sets, which is something that took me far too long to realize. There's a few bugs left in the descriptor set code, but the actual architecture for how I update and bind descriptor sets is in place

Conclusion

As I said in the intro, I didn't have a ton of time for Nova in May - but I had some time, and I made some good progress. Work on Nova continues...

 
 

Continuum 2.0 Public Preview is Released!

2.0 isn't quite ready for prime time, but we have decided to give you guys a little teaser before we go live. A public preview version of Continuum 2.0 is available for download on our GitLab HERE.

If you find any bugs please let us know, as the whole point of this preview is to find as many bugs as possible to squash before we launch 2.0. Please open an issue on GitLab, let us know in the comments, or on our Discord server.

If your screen is black unzip the shader; the folder structure should be as follows: shaderpacks/continuum-shaders-master/shaders

 

Continuum 2.0 Update: It's June 1st...

Hey guys, Seth here. As the title says...it's June 1st...and I'm sorry to have to be the bearer of bad news, but we have decided to push Continuum 2.0's official launch back a bit...by one month to be exact. Our goal is now July 1st. Some stuff came up that slowed work down a bit, and with the amount of things left to finish polishing up, we feel that taking the extra time to do it right is a good idea, and we think it will be well worth the wait!

With that said, I do have some good news. Those of you with Tier 1 (or above) will now be able to download the first RC (Release Candidate) build! These will be updated throughout the month as we close in on the release of 2.0. Those that don't have a package will now be able to purchase RC access by itself if they want a sneak peak of the full release. 

Continuum Tier 1
Continuum Tier 1
7.50
Add To Cart

 

As always, we all appreciate your support. Thank you.

New Purchasing Options and Continuum News

The New Purchasing Options

Continuum Early Access and Pulchra Revisited can now be purchased separately at a discounted price!

You can now choose from Continuum or Pulchra packages for $7.50, $15.00, and $30.00. This is for people that only want one or the other, and would like to save a bit of money while getting only what they want. For those of you that still want both, you can still purchase them together at their original prices; $10.00, $25.00, and $50.00.

We have faith that these added options will provide more value and satisfaction to you guys, but these new options are still a bit of a test. If it goes well, they will stay. If not, we will revert back to the old combined Tiers as the only option, but rest assured, anyone that purchases the new options will still continue to receive support and have access to their purchased files if we do revert back to the old system.

ContinuumPurchasingOptions
PulchraPurchasingOptions

Continuum 2.0 is almost here!

We made it folks! We are entering the Release Candidate stage this week. There will be a few more beta updates and probably many more alpha updates before it's all said and done, but Continuum 2.0 is set to release June 1st, 2018!

We know it's a little late, however we think the project needed a little extra time. Thank you all for putting up with our shenanigans. It has been an absolute treat developing this project for you and we are glad it will finally be released to the masses.

Continuum Settings Documentation

Continuum 2.0 has a lot of settings, some of them quite advanced, but we want to make sure everyone can get Continuum to look how they want on their own. So we have built a docs section to our website going over every feature, with pictures for reference. The more advanced settings like LUT's and some of the custom programming in our UserLib will get video explanations along with the written explanation. These videos are not ready yet however Subscribe to us on YouTube, or follow us on Twitter and/or facebook and we will make posts when they're released.

ContinuumDocs

Continuum 2.1 and the future

With Continuum 2.0 launching soon, we are looking towards the future; Continuum 2.1.

Continuum Spir-V/Vulkan addition will be developed in 2.1 in conjunction with the Optifine version. Continuum 2.1 will focus heavily on immersion, performance, configuration, and playability while still being fully PBR and boasting all of the currently available options and more. Continuum 2.1 should mesh into the background and feel natural for every scene with wind simulation* and heavy emphasis on indoor lighting. Random events will happen constantly from lighting strikes arking through the clouds lighting the volume from within. Our goal isn't just to make it look natural, it's also to make it beautiful. All owners of Continuum 2.0 will receive 2.1 following the official public release of the shader.

We hope you are as excited for 2.0's release, and our future plans as we are!

Nova Update: April 2018

Oops, this one was a little late. We're all going to have to find a way to deal with that.

What happened in April? Fun things! The render graph, which I've been working on for a couple months, is coming together. Get hype!

Materials

As the render graph became more complete, it became obvious that Nova needed a material system of some sort. It needed a way to specify which resources (textures and other data) were bound to each shader.

I ended up going with a simple dictionary-like thing. You use the uniform names from your shader and assign the name of a resource to each uniform. I wrote up a wiki page that gives you an overview of this system.

Putting it all together

With the render graph in place, and the material system in place, Nova should finally run!

Except there were a number of bugs and errors, which is to be expected when one writes a large block of code without running it. A few days of bug-fixing, and we finally have some images, including one very nice image of the GUI!

That tweet was also retweeted by the offical Vulkan Twitter acount, which isn't a huge achievement but it did give us some nice publicity.

Textures

The GUI is pink! Oh no! I hadn't made the code to get textures working yet - so that's what I worked on next. It was kinda painful; since the way that Vulkan handles textures is very different from how OpenGL handles them, but after a couple days I got them sorted. Behold!

That's cool. The render graph is now mostly working!

You'll notice that there's no text on the GUI. Nova is issuing the draw call for the text, but nothing renders because the font is using the GUI texture atlas, not the font texture atlas. This issue will be solved when I get virtual textures in, but for now I have to make a new material for GUI text. I was hoping I wouldn't have to do that, but here we are.

Swapchain Management

In OpenGL, everything relating to the swapchain is handled by the driver. You write to framebuffer 0 from a shader, tell the windowing system to swap the backbuffer with the frontbuffer, and there you go. In Vulkan, however...

If you want to write directly to the swapchain, you have to create a framebuffer for each swapchain image. A framebuffer needs to be created with a reference to the renderpass that uses it, so I would have had to create (and manage) one framebuffer per swapchain image per renderpass that outputs to the swapchain directly.

That doesn't appeal to me. Instead, I'm adding a step after rendering is completed to copy the data from the texture named "Backbuffer (which is created by the render graph) into the current swapchain image. No more need to deal with a ton of framebuffers! Yay!

Unfortunately, I had originally set up the code to assume that there was only one swapchain image...which is in no way correct. Changing to the way I want to do this has proved less than trivial, as a quick glance at Nova's commit log will tell you. Still, it's happening.

The Future

Where does Nova go from here?

The render graph still needs more testing. I've only seen the GUI rendered with it - will it handle chunks? It better! There's definitely more work to be done with the render graph to ensure that it's robust enough for usage by shader devs at large. I know a few Minecraft shader devs - they will take whatever system I give them and push it far past any reasonable limits. It's my job to make sure pushing it that far doesn't break it.

As part of that, I need to get the scripting system set up. The scripting will tie in with the render graph - you'll be able to write Lua scripts that are executed before, during, and after each render pass. This will let shader devs perform work on the CPU, such as calculating custom uniform values or only running certain passes every few ticks. The scripting system will be what really pushes Nova past other Minecraft shader implementations.

I'm not going to stop there, however. After scripting comes virtual textures, which is essentially a way to load a texture in at runtime in a memory-efficient way. This technology was originally developed by id Software for Rage, then improved for Wolfenstein: The New Order and DOOM 2016. It's also shown up in Far Cry 4, Battlefield 3, and associated sequels. This will vastly change how textures work in Minecraft. Rather than loading all textures into a single atlas texture, they'll be loaded as needed. If you only have one type of block on screen, only one block texture will be loaded. This will vastly decrease memory usage, allowing for larger resource packs than are currently feasible. Combined with texture compression, this may make 2k resource packs usable by consumer graphics cards

This is all great, but Nova will still be running on a single core. Sometime around virtual textures, I'll be implementing a task-based threading system. This will allow Nova to scale with the available CPU - buying a processor with more cores will make Nova faster. It should also vastly reduce frame time, further improving what will already be a very solid renderer.

I haven't forgotten about Forge either. The plan is still that, once Forge for Minecraft: Java Edition 1.13 becomes available, Nova will move from modifying the Minecraft client directly to injecting through Forge. I fully expect that to be absolute hell, given how many changes Forge makes to Minecraft. There's a possibility it won't be worth the effort - although, considering the immense value the Forge provides to Minecraft modding, that's pretty unlikely.

And that's just what's on my plate! In the last couple of weeks Nova has had a couple people start working on setting Nova up for CI/CD (Continuous Integration/Continuous Delivery). There's a number of benefits to CI/CD, including that Nova could be compiled on a server somewhere and not on an end-user's computer like it is now. Licensing with the Minecraft client prevents us from distributing more than the C++ part of Nova in a per-compiled format, but once Nova moves to Forge we should be able to distribute the whole thing as a compiled Forge mod, which Forge will then inject into the Minecraft client. That's where the fun begins.

In closing...

That's where Nova is now, and that's the next few major tasks for Nova. As always everything is subject to how much time I have and how many other developers are working on Nova at any given point in time - you'll notice that I haven't given any estimates for when things might be done - but all those big tasks are probably a few months of work each for a single developer. If you're willing to help, we could deliver features much faster!

Nova Update: March 2018

What happened in March? The better question would be: what didn't happen in March?

Render Graph Initial Revision

In February I announced that Nova would be adopting a data-driven render graph system. This system would give shader developers a lot of flexibility in how they set up their shaders and would make Nova a data-driven renderer with practically nothing hardcoded. Forward, deferred, tiled deferred, hybrid forward+ - all these will be possible by simply changing some data.

On March 9th I got the initial revision of this system working. I could build a rendering pipeline in data and it would Just Work. This was exciting. There were a few bugs, but the basic tech was working. 

However, I realized that the existing material system wouldn't handle all I needed it to handle. Specifically, there's currently no way for objects for one material to have different textures - which has led to text not working very well. Nova currently mixes two concepts - a material and material instance in Unreal Engine 4 terms - that really should be separate. Future work will separate these concepts and lead to something much, much better.

Vacation and GDC

From March 10th - 18th my girlfriend was in town visiting. We had a lot of fun, but naturally, I didn't make any progress on Nova during that time.

GDC was March 19th - 23rd. I attended many sessions, including a number of talks about Vulkan. The result of all those talks was....

I'm Making Nova Vulkan Again

Yes, I'm switching back to Vulkan.

After listening to the talks at GDC, I can't not use Vulkan any longer. It's become overwhelmingly clear that Vulkan is the future and OpenGL will not deliver the performance that Vulkan can. So, it's time to get the Vulkan branch working.

When I last left off, RenderDoc didn't give any useful information - it reported everything as 0. However, there was a new RenderDoc version since I last tried using it, so I ran Nova with the new RenderDoc to see if there was still that problem...and Nova crashed. So I tried running Nova normally, and it didn't crash. It would appear RenderDoc is crashing Nova.

I have filed an issue on the RenderDoc GitHub, but I can't wait for RenderDoc to update. So I have begun digging into the RenderDoc code myself to try and see what is crashing Nova. A few hours of hardcore debugging later and I noticed that I was destroying a buffer, but then trying to use it. This made Vulkan crash, since Vulkan doesn't handle errors so that it can deliver maximum speed. I'm not sure why Nova was crashing in RenderDoc, but not when run normally, but I noticed slightly different behavior when it was running with RenderDoc before.

After that there were a number of smaller bugs. Vulkan requires thinking a little differently than OpenGL, and that takes some time to get used to. Still, I persevered, and got the Vulkan branch to draw things on screen. At that point the rest was details.

Render Graph 2: Hydroelectric Boogaloo

With the render graph code written, and the Vulkan code getting written, it's now time to put the two together. March ended with starting to merge the render graph into the Vulkan code, adapting it where needed and rethinking some of the Vulkan code to better fir the the render graph. Many challenges remain, but Nova is set up to be a very powerful shader development environment.

Nova Update: February 2018

segfault at vkResetFences

That's the error message that's greeted me for the last few weeks. There was a segfault, which is a portmanteau of segmentation fault - a program has tried to access a segment of memory that it shouldn't have. Usually your debugger can take you to the line where the segfault happens and you'll see what you did wrong - Are you accessing an array element that doesn't exist? Did you forget to initialize something? Segfaults are annoying, but usually they can be squashed in development.

Except for now.

The debugger gave me a location where the error was happening - deep within the Vulkan loader. It said that the error happened in the function vkResetFences, but I didn't call that from anywhere within Nova. Something strange was happening.

I tried a lot of things to learn more about this error. I tried compiling the Vulkan loader myself, tried compiling Nova with Visual Studio, tried commenting out large swaths of code until the error went away so isolate the offending line - many hours were spent cursing at my compiler. I learned a few interesting things, such as that the Vulkan loader doesn't support being compiled with MinGW, and that Nova doesn't like being compiled with Visual Studio, and that the error wasn't necessarily happening in the function vkResetFences, but since I had a release build of the Vulkan loader then gdb wasn't reporting the offending stack frame accurately. This was all rather interesting and would probably be useful, but was not useful now.

I cast a wide net online, reaching out for any help I could get. Some people suggested I was smashing my stack, but that didn't seem likely - stack smashing seems to be super rare and difficult to actually do. I looked into debugging a Vulkan application, and realized that I had never gotten a Vulkan debug callback working.

I'm using vulkan.hpp, a C++ wrapper around Vulkan. It's a thin wrapper around the Vulkan API - sometimes too thin. Vulkan debug callbacks, in which you give Vulkan a callback to call when it has something to say about how badly you're misusing the API, is a Vulkan extension, and it isn't loaded very well by vulkan.hpp. Google gave some example code to load the debug callback extension, I gave Vulkan a callback to print errors, and... the callback printed out many errors. Whoops.

In OpenGL, I never had to clean up objects when my program shut down - that was all handled by the API. In Vulkan, however, you do have to clean up after yourself. This information had slipped by me. I went through all my code and added the statements to destroy things I wasn't using, and Nova stopped crashing. When you use the API correctly, your program won't break. Who knew?

...but now it's time for OpenGL

I spent four months working on converting Nova to Vulkan. I got probably 2/3 of the way there, but I kept running into more and more problems. The tale above is just one of them: turns out learning a new graphics API all at once is pretty challenging. I took a step back and decided that I couldn't justify spending another four months getting Vulkan Nova working, not with Bedrock shaders right around the corner and not with all the features Optifine keeps adding. If I had any hope of being competitive, I needed to get a working renderer together as soon as possible... and I already had a working renderer, one that used OpenGL.

The first task was bringing in all the improvements made in the conversion to Vulkan. I made a number of tweaks to the build scripts and wrote a loader for Bedrock materials, and those changes had to be brought in.

Data-Driven Render Passes

During the time I spent working on Vulkan, I came across an article titled Render Graphs and Vulkan: A Deep Dive. The article talked about a data-driven renderer that gives a great deal of flexibility with regards to how a renderer processes a scene, and I realized that it was exactly what I wanted. The author of that article had solved a number of problems I was struggling with, so why not use their solutions?

I decided to upgrade Bedrock's material system to use render passes while bringing in the Bedrock material file loader. The render passes would form the backbone of Nova's data processing algorithms, so I definitely wanted to have that system in place as early as possible.

Bugfixes and Improvements

We haven't only been developing new tech, however. Coler706 has been working on bugfixes and improvements to the existing tech. He discovered that the place I had initially hooked into Minecraft for chunk updates wasn't very good, and found a better place so that Nova was able to handle the removal of block and loaded chunks from the player outward, like in vanilla. He's also been expanding the set of GUI screens that Nova can handle, paying special attention to the in-game GUI. The work he's doing has fixed many issues that I would have taken much longer to get to, so I very much appreciate his help.

Thi brings us to today. We have a strong modern OpenGL base to work off of. We're moving ahead strong with implementing the render pass system, constantly improving the data format to be more expressive and easier to use. We're fixing bugs and making improvements that are highly visible to the end user. Nova development in 2018 is moving along very well!

February Blog: Show me the Updates!

Continuum

The Alpha branch of the Continuum Shader has been relatively inactive as of late, but we have big things happening in the background. A lot of work has been put into the brand new "Rebase" branch, a new branch meant to restructure the base of the code which will hopefully allow for easier editing, as well as much better handling of data. Once we have all of that out of the way, we will begin to migrate and optimize functions from the Alpha branch with our ultimate goal being, do everything that the Alpha branch does now, but at a much better frame rate. Because of this new milestone, we will soon be pushing Beta 3 out to all Tier 2 supporters so that everyone remains as up to date as possible while we continue working on the rebase in the background. As Continuum gets closer and closer to the Release Candidate testing stage, We will continue to work hard and implement several new PBR techniques and features, as well as optimize to surpass the performance of Continuum 1.3  

Continuum 2.0 Alpha  

Continuum 2.0 Alpha

 

Continuum 2.0 Rebase: Not much to see, we have some basic shading done, POM implemented, and our sky function implemented  

Continuum 2.0 Rebase:

Not much to see, we have some basic shading done, POM implemented, and our sky function implemented

 

Hey, where'd the section on Pulchra and Nova go?

This section is going to replace the Pulchra and Nova section as Nova is going to be dedicated to its own blog, and Pulchra is currently undergoing developments not directly related to the resource pack. The Nova blog is a quick recap of all that has happened over the past year of development, as well as a rough roadmap as to where David wants to go next with Nova. This includes the inclusion of Bedrock shading support, Forge mod injection, light-map rework, and many more plans for the future as the renderer begins to take shape. For more details on what's happening, please visit this link to view the latest Nova blog. As for Pulchra, our texture artist is creating a new module to add specular support and conform to the PBR standards of SEUS: Renewed, but this is currently a task that is being put on the backburner as he is working with developers to integrate Pulchra download's into our dedicated GitLab server. This will enable us to take another step in making your purchasing experience easier, eliminating the need to manually send invites to buyers and eliminating the extra steps of switching between file hosting services to download both products. Until this has finished, there have been about 1 or 2 textures added, which should give a general idea as to what's next for the next major Pulchra update.

Rain texture, pretty self explanatory change.

Rain texture, pretty self explanatory change.

Just a test to see how light disperses across a material, may be used for ores.

Just a test to see how light disperses across a material, may be used for ores.

 

Conclusion

Some of you may have noticed that recently, Continuum has been very quiet even a month after the holiday season. We've slowly been migrating back into working on our mainstream projects with our primary focus as of now being quality of life tweaks to make everything faster such as our new GitLab automation system specified above. We hope to have these fixes out soon, so we can begin to dedicate all of our time to prepare for consumer release.

Until then, that's all we have for next month, thanks for stopping by and we hope to have much more to share with you all in the near future.

-James

 

Nova Update: January 2018

Wow. It’s been a full year since the last Nova development blog post. That’s... a long time. I want to get these out more often than that. We’ll see what happens.

A lot has happened with Nova in the last year.

When the year began we were hard at work implementing GUI rendering for the main menu. We finished the framework for that, and added all the pages that were needed to load into a world. There’s still a lot of GUI pages that we haven’t explicitly touched, and probably a few crashes hiding in there, but we have enough to load into the game.

The people who had joined to make the GUI got busy with real life, so I also developed the chunk rendering code. Nova is able to render chunks like Minecraft with Smooth Lighting turned off (getting smooth lighting working would have been hard). There was actually a lot of difficulty here. Minecraft groups the faces in a model by the face of a cube that they would be up against, and it provides an enum for each face of the cube. This would be fine, except that it uses the value `null` (which is never a member of an enum) for all the faces that are not directly against the side of a cube. That is, if you iterate over all the enum values and get each of their faces, you still have to ask for the faces with `null` instead of an actual enum value. This is incredibly silly and caused me a lot of grief

E3 2017 happened. During it, Microsoft announced the Super Duper Graphics Pack for Minecraft. Minecraft: Windows 10, Pocket Edition, Switch, and XBox were moving to a new engine, Bedrock, and Minecraft 1.3 would add support for user-defined shaders - and the Super Duper Graphics Pack would be built using that support.

This changed many things. One of Nova’s main goals was compatibility with existing shaderpacks. At the time I started Nova this meant compatibility with shadersmod shaders, which soon become Optifine shaders when Karyonix gave the shadersmod code to sp614x. While watching E3, I decided to support Bedrock shaders as well. Users will be able to use many existing shaderpacks from all versions of Minecraft with Nova.

Support for Bedrock Shaderpacks was added to the backlog, but there was more work to be done for chunk rendering. Adding the code to support Bedrock Shaderpacks would have to wait.

In September, another revelation dropped - The Windows 10 (and probably XBox) versions of Minecraft were moving to DirectX 12. This would allow Minecraft greater performance on many systems, but it had an affect on Nova. Using Vulkan for Nova had been the original plan, and it’s something I had put on the backburner while I was learning how to work with Minecraft: Java Edition’s code. This new revelation was a challenge: surely I could make Minecraft: Java Edition render as well as Windows 10.

Conversion to Vulkan began mid-October. I first had to learn Vulkan, or at least get a grasp of the basics. I decided that, since I had been spurned to convert Nova to Vulkan by Bedrock, I should add in support for Bedrock Shaderpacks while I was converting to Vulkan. That decision has caused me a lot of pain, since supporting Bedrock shaderpacks, Optifine shaderpacks, and Nova’s extensions to both added a lot of complexity to what Nova had to do. I moved across the USA, started a new job, and travelled a lot for the winter holidays - all things that have taken away from Nova.

That brings us to today. Nova continues to plod steadily on. Nova can load Bedrock material files, and is reasonably good at initializing its Vulkan context. Nova can load textures and shaders without too much difficulty.

The immediate roadmap sees rendering commands added to Nova. This will allow Nova to render the GUI and chunks, like the OpenGL version of Nova.

Once that feature parity is achieved, I’ll take a step back and look at the progress of Minecraft: Java Edition. MC:JE is making significant changes to its renderer for 1.13, and I want to move Nova to Forge instead of raw MCP. Adapting to 1.13 and to Forge are both significant changes, and I want to do them at the same time. If Forge for 1.13 releases before Vulkan Nova has feature parity with OpenGL Nova, we’ll be able to jump right in to the Forge conversion without any delay.

However, if I have to wait for Forge, there’s numerous other tasks I can do. These will all be focused on optimizing Nova so we can render the maximum number of pixels per second. Some items on this list are:

  • Multithreaded command buffer generation and submission

  • Indirect chunk rendering

Once the Forge conversion is complete, I’ll likely spend a bit of time working through making GUI and chunk rendering really nice. We’ll dive into Minecraft’s GUI, making sure each page renders properly through Nova. I’ll work on making chunk rendering respond to the rendering options in the options GUI, such as the setting for fancy leaves or the render distance. When I'm satisfied with that, we’ll begin conquering entities. They’ll have a good bit of complexity with tracking their position, rotation, and animation state, but it’s nothing we can’t handle.

The future of Nova is bright. This project has taken a long time already, and I expect there’s still a lot of time before it’s anywhere close to done, but I promise all this work will be worth it.

January Blog: A few updates, and reflection.

Happy new year!

Happy new year! Hope you guys had a great holiday season. It's actually been relatively quiet development wise here at Continuum, but we still have a bit of news to share with you guys today.

Continuum

Visually, there hasn't been many changes to Continuum since the beginning of December, but most of the time has been spent micro-optimizing and organizing internally. This period of reorganization has allowed for a new Ambient Occlusion system, less present shadow acne, re-done sky shading, etc. All of these features will contribute to the upcoming water update which will introduce projected caustics, better volumetrics, better parralax, etc.

Write here...
2017-12-31_15.21.46.png

Nova

As you all know, we are currently putting all of our time and focus into the conversion of Nova from OpenGL 4.6 to Vulkan, and into making Nova use the Bedrock material format which is used by versions of Minecraft that run on the Bedrock engine (Windows 10, XBox One, Switch, and Mobile). We've completed replacing all the OpenGL code with Vulkan code, and now comes the process of testing the new Vulkan code and removing any bugs that will hinder development.

One major recent bug was loading Bedrock materials. Because Nova is a highly data-driven renderer, we didn't want to predefine materials that you have to use. This meant that Nova had to scan the materials directory in a shaderpack to see what materials the shaderpack developer wanted to use. We used the new standard filesystem library to scan the directory for materials, but unfortunately the standard filesystem library has a number of warts which made the library difficult to integrate. Performing that integration took a few weeks (since we're also busy with the holidays), but the integration is now complete.

The next step is continued testing of loading Bedrock materials and the exiting rendering code, finding bugs and places where our understanding of Vulkan is lacking, and fixing those issues as they occur. The material loading code is very complex, mostly because that code contains the shader loading code which has to handle a file format that's evolved organically over the last few years. We expect that the majority of the bugs will be related to material loading.

Once the Vulkan conversion is complete, we'll be converting Nova from a pure MCP mod to a Forge mod, which will enable a much more user-friendly approach of injection. As you may know, we've tried a number of things to make Nova easier to compile for non-developers, with each approach being too unreliable for satisfactory results. By converting Nova to a Forge mod we'll be able to distribute the precompiled code, eliminating any compilation issues. Converting to a Forge mod is something that needs to happen anyways, to ensure greater mod compatibility.

Pulchra

The Continuum support add-on for the latest Pulchra update is now complete! This add-on should add proper specular map support for the new SEUS Renewed and Continuum 2.0, and you can find a comparison below showcasing what specular maps can do in your average Minecraft house

You can see on the bottom, specular adds a whole new depth to textures both lighting and reflection wise (looking at the floor and walls).

I am also pleased to announce that we will soon be migrating away from Google drive towards our own download servers, which will enable for direct access to Pulchra and Continuum immediately after purchase. This should help with future purchases as it will no longer require a g-mail account, and it should prevent any mishaps about not recieving invites for either product.

In Conclusion...

Let's take a step back for a moment, to the very beginning of the development of Continuum 2.0.

Initial Commit: July 31st

Initial Commit: July 31st

Optimization of Ambient Occlusion: December 28th

Optimization of Ambient Occlusion: December 28th

We've made great progress over these last few months, and with a lot more happening behind the scenes, we hope to improve our shaders, resource pack, and renderer even further with more consistent updates as we march towards release. We here at Continuum Graphics look forward to an exciting 2018, and would like to thank all of you for supporting us through out all of 2017.

Here's to another year,

-James

 

Winter Sale is Live!

Hey guys, Luca here (You might know me as Hox from the Discord server).

The winter sale is now live,all tiers are 50% off!
The sale is live until the 31st of December.

Not much has happened since the last blog post but here's a small update.
Pulchra's 2.0 modules are now being worked on,Robin(aka Robobo) has made a new shadow bias function which greatly improves how shadows look at a distance and Joey (aka Dotmodded) is still cleaning up and organizing the code.
More on this in the next blog coming early 2018™
We wish you a merry Christmas and happy new year.