> We’ve done a lot of talking about what the problems are and not a whole lot of proactive thinking to address them.
…
> We’ve observed the main problems with voxel engines being how our data is laid out and processed, and what happens when it’s not optimal for a given job.
…
> Now it’s time to apply these ideas to voxels. As I previously mentioned, the answer is simply to use whatever format is best for the job.
> But when working with volumes, it’s not that easy. Even with different formats, we can’t ever just store raw data for the entire world because of memory usage.
> Conversely, we can’t always work with compressed data because compression takes place after the raw data has been filled out.
…
> By building systems around formats that can be swapped out at run time or exchanged/changed in the future, your codebase is safe from painful refactors.
…
> The very thing we started out discussing and are going to close on. How do we take a dynamic voxel format with dynamic attributes and expect to throw it at the GPU?
> The solution here will have to wait until the *next post* where I take a deep dive into the rendering setup (I guess I accidentally lied on the last post). I’ll briefly…
I mean, I’ve obviously cherry picked quotes here, but you decide if I’m being unfair.
We enumerated a problem; it’s a well known problem.
Perhaps, there is a novel solution to the problem; there certainly seems to be the suggestion there is; maybe it’s not novel… but the solution is not shown, so who knows?
Does it need to be novel? Dunno, but it’s a bit rubbish to say you have an interesting solution to a problem, and your solution is “generic data processing at runtime” and give no other details.
…
> We’ve observed the main problems with voxel engines being how our data is laid out and processed, and what happens when it’s not optimal for a given job.
…
> Now it’s time to apply these ideas to voxels. As I previously mentioned, the answer is simply to use whatever format is best for the job.
> But when working with volumes, it’s not that easy. Even with different formats, we can’t ever just store raw data for the entire world because of memory usage.
> Conversely, we can’t always work with compressed data because compression takes place after the raw data has been filled out.
…
> By building systems around formats that can be swapped out at run time or exchanged/changed in the future, your codebase is safe from painful refactors.
…
> The very thing we started out discussing and are going to close on. How do we take a dynamic voxel format with dynamic attributes and expect to throw it at the GPU?
> The solution here will have to wait until the *next post* where I take a deep dive into the rendering setup (I guess I accidentally lied on the last post). I’ll briefly…
I mean, I’ve obviously cherry picked quotes here, but you decide if I’m being unfair.
We enumerated a problem; it’s a well known problem.
Perhaps, there is a novel solution to the problem; there certainly seems to be the suggestion there is; maybe it’s not novel… but the solution is not shown, so who knows?
Does it need to be novel? Dunno, but it’s a bit rubbish to say you have an interesting solution to a problem, and your solution is “generic data processing at runtime” and give no other details.
In my opinion.