3 ms·

I have a lot of respect for Johns work, but this post is mostly fluff. > So as you can see, conversion operators aren’t just for rearranging data; they’re more

I have a lot of respect for Johns work, but this post is mostly fluff. > So as you can see, conversion operators aren’t just for rearranging data; they’re more like black boxes. Input data of a specific format and let the engine figure out and execute the link to the desired output format. It’s such a simple concept that’s more general than volume conversion, and yet it’s managed to solve our problems. Well, fair, but this has nothing to do with rendering voxels, or managing the n^3 problem of memory required for voxels. All we get is the suggestion that spare trees aren’t ideal runtime structures, and a whole lot of talk about how it’s not ideal to structure your code around one specific implementation because it makes refactoring and trying new things hard. Cool, I get it, good point… but I don’t think it’s particularly novel to have the idea of an engine built on a black box of data transformers. …unless you’re prepared to go into the detail of what you’re transforming the data into that’s useful, which we got about 4 sentences of.

djmips 5y ago
It's valuable to bring those concepts to the fore. Easy to say it's not novel but what is? But anyway this was 5 minutes of your time.
- wokwokwok 5y ago
  > 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. In my opinion.
codeflo 5y ago
About half-way in, the author even admits that the article is a bit long-winded and not really getting to the point. Unfortunately, it then still doesn’t get to any point. But I have sympathies for the author here. It’s sometimes really hard to verbalize conceptual ideas. You “feel” them, but any explanation sounds trivial. It’s likely there’s a bit more to it than your summary suggests. Not sure what the author could have done better, I struggle with this myself.

djmips 5y ago

It's valuable to bring those concepts to the fore. Easy to say it's not novel but what is? But anyway this was 5 minutes of your time.

wokwokwok 5y ago
> 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. In my opinion.

codeflo 5y ago

About half-way in, the author even admits that the article is a bit long-winded and not really getting to the point. Unfortunately, it then still doesn’t get to any point. But I have sympathies for the author here. It’s sometimes really hard to verbalize conceptual ideas. You “feel” them, but any explanation sounds trivial. It’s likely there’s a bit more to it than your summary suggests. Not sure what the author could have done better, I struggle with this myself.