3 ms·

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.

by djmips 5y ago

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.

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.

by 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.