Anything you can implement from this video?

[NastyFlytrap]

I know the entire thing is cancer to watch, and im not a programmer so i dont actually know what he's talking about, but the comments are acting like this is a genius thing, and i do like the sound of 'chunk based rendering that lets the height to be effectively infinite' so im suggesting it here. Also, insane performance is always welcome.

 

Obviously, this'd require extreme rewrites of how the game functions, but, based on what i've seen of the dev team, they seem to want the best for the game, and if these things are as good as the comments make them seem, i think it'd worth the huge hassle.

 

 

[Thorfinn]

(Apologies in advance. He uses "chunk" differently than VS does. I've tried to make it obvious in context, but...)

Aggregating can make a lot of sense. In the scene above, for example, almost the entire scene is trivial. Considering how many 8x8 "chunks" of water you see, aggregating just the top of an 8x8 into one entity should see a dramatic improvement. Create it once and tile it. Most of the dirt blocks in the foreground are a similar situation, if not quite as trivial. There is not much variation, (over 1, down 1) so one should expect a pretty good improvement there, too. The same is true in a lot of the vid -- there is a lot of very flat ground, and even where it's not flat, if you squint a little, you can see the perlin function looks to have been optimized to his chunk size. Which he hints he did anyway. Not that it is a bad idea. It just ends up with a different product.

The problem comes where there is a lot of vertical height change in a "chunk", or when you make changes from the seed. Not only does the palette increase in size, it increases in variety. While a wall might be all packed earth, it might also have decorative banding, or alternate mudbrick, or have windows, or some block from a mod, or lord knows what. All of which is loaded from the server instead of generated from the seed. And what really causes issues are the chiseled blocks. Since that can have almost any texture (mix of colors, etc.), most chunks with at least one chiseled block would end up being individually aggregated, and at the limit, every block in the chunk being different, would be slower than an individual block render.

So the steep inclines where you see several different rocks, inclusions and maybe ores? I doubt you will see much if any improvement. The cliff faces where it's all granite, all the time? Those should do much better. Smoothly changing gravel deserts should see improvement, the ones more typical of VS terrain, probably not much.

Most of the visuals he talks about, SSAO, god rays, etc. are already here.

Conceptually, I'm not a huge fan of a completely deterministic seed. It's what makes the various speedruns in Stardew so boring. "Oh, look, I dug in this completely 'random' location and got a clay! Oh, look, I did it again! And again! What are the odds?"  Etc. I like the fact that ore bodies and crops and such will be in different locations even with the same seed in VS. And I'm not a huge fan of offloading mapgen onto the client in multiplayer if only because it introduces security issues for the admin. But I think there is a lot of potential in offloading mapgen onto sbcs. 

Maybe. I'm interested in hearing others' impressions.

Edited September 9 by Thorfinn

[NastyFlytrap]

11 hours ago, Thorfinn said:

(Apologies in advance. He uses "chunk" differently than VS does. I've tried to make it obvious in context, but...)

Aggregating can make a lot of sense. In the scene above, for example, almost the entire scene is trivial. Considering how many 8x8 "chunks" of water you see, aggregating just the top of an 8x8 into one entity should see a dramatic improvement. Create it once and tile it. Most of the dirt blocks in the foreground are a similar situation, if not quite as trivial. There is not much variation, (over 1, down 1) so one should expect a pretty good improvement there, too. The same is true in a lot of the vid -- there is a lot of very flat ground, and even where it's not flat, if you squint a little, you can see the perlin function looks to have been optimized to his chunk size. Which he hints he did anyway. Not that it is a bad idea. It just ends up with a different product.

The problem comes where there is a lot of vertical height change in a "chunk", or when you make changes from the seed. Not only does the palette increase in size, it increases in variety. While a wall might be all packed earth, it might also have decorative banding, or alternate mudbrick, or have windows, or some block from a mod, or lord knows what. All of which is loaded from the server instead of generated from the seed. And what really causes issues are the chiseled blocks. Since that can have almost any texture (mix of colors, etc.), most chunks with at least one chiseled block would end up being individually aggregated, and at the limit, every block in the chunk being different, would be slower than an individual block render.

So the steep inclines where you see several different rocks, inclusions and maybe ores? I doubt you will see much if any improvement. The cliff faces where it's all granite, all the time? Those should do much better. Smoothly changing gravel deserts should see improvement, the ones more typical of VS terrain, probably not much.

Most of the visuals he talks about, SSAO, god rays, etc. are already here.

Conceptually, I'm not a huge fan of a completely deterministic seed. It's what makes the various speedruns in Stardew so boring. "Oh, look, I dug in this completely 'random' location and got a clay! Oh, look, I did it again! And again! What are the odds?"  Etc. I like the fact that ore bodies and crops and such will be in different locations even with the same seed in VS. And I'm not a huge fan of offloading mapgen onto the client in multiplayer if only because it introduces security issues for the admin. But I think there is a lot of potential in offloading mapgen onto sbcs. 

Maybe. I'm interested in hearing others' impressions.

This is kind of why i suggested it because even if only 30% of this is viable to implement in VS, thats still a win! These are great things he's showcasing here and would be a shame to not be 'inspired' by some of them

[Maelstrom]

The big problem with performance in that other block game, is JAVA is totally the wrong program to use.  VS is written in C# and from the get go has performance in mind.  Pretty sure almost everything in that video does not apply to VS.

[Thorfinn]

That's the question. I don't know whether or not it is. My sneaking suspicion is yes (or can be) so long as you are you are exploring virgin territory, but around your base or a moderate-sized ruin, probably not. Is the overhead to have two different systems, and algorithmically deciding when to use which worth it? Particularly when you could do even better by switching out your i3 out for an i5 for less money than you would have to pay a programmer to put in a couple hours and not even have a good start. 

It does drastically affect your ability to use alternate mapgens. If you wanted the performance, you would have to re-tune the base game if you want to use the valleys or rivers or whatever mods. Unless they just happened to generate landforms that are also tilable.

I'd be interested in seeing how he's doing what a different voxel game (no, not that one) calls "decorations" -- things like the various sizes of grass, of berry bushes, crops, sticks, rocks, mushrooms, etc. Notice he hasn't put any of that in the vid. When I was doing some profiling for that other voxel game (no, not that one) those exceptions essentially determined framerate. That may be why mods like Wildcraft started bogging systems down so badly -- the game's rendering was not optimized for that many exceptions, and at some point, it can't be.

The only partial voxels I saw anywhere were the player blobs. Might have missed some, but I did not see any where I thought they would most likely be. Partials are all over the place in VS. Mushrooms, vines, ruins, sap, moss, etc. Walk past a vine, viewing it from different directions. You will get an idea of what you would be giving up converting that to a transformable tile.

Also think about how many things in the game are smaller than 1 voxel. You may not be able to tell at a distance which quarter of the voxel a bowl is resting on, or if it is centered, and far enough away it doesn't much matter, but in order to take advantage of tiling, you need the surfaces facing the player to be on the face of the tile you are building. If they are recessed, rotation of that aggregate is no longer a simple transform. At a distance, it's a non-issue, but the spyglass or zoom mod will show artifacts. Picture 4 bowls in a recess. Viewed from 45 degrees, you should be able to see 1 bowl and half of two other bowls, with the ones in front partially obscuring the ones behind. You could create a texture to replace that. But you couldn't transform that texture in a believable manner, because the occlusion of the bowls in back depends on the angle you are viewing it from. 

Meh. Rambled on long enough, methinks. Still interested in hearing other opinions. Far and away, I think the biggest bang for the buck would be in coming up with a scalable way to use something like a cheaper sbc than a R-Pi to do the grunt work, freeing the server (mp or sp) to be the file server and doing the rendering. 

[NastyFlytrap]

44 minutes ago, Maelstrom said:

The big problem with performance in that other block game, is JAVA is totally the wrong program to use.  VS is written in C# and from the get go has performance in mind.  Pretty sure almost everything in that video does not apply to VS.

That video uses a custom 'game' (more like an extremely impressive tech demo, really), and it runs in unity, and therefore C#, and there's some built-in safety limit disabling using burst, or whatever it was called.

 

I understand that people may not have time to watch or read an entire thing, but this is an egregious example of 'only reading the title'/'only looking at the thumbnail'. The video explicitly addresses this.

[Maelstrom]

I didn't watch the video and responded based off your comment and assuming (yes bad, I know) the video was about TOBG.

[NastyFlytrap]

9 minutes ago, Maelstrom said:

I didn't watch the video and responded based off your comment and assuming (yes bad, I know) the video was about TOBG.

Admittedly it does look like it, the textures are probably ripped and being used as dev textures

[Thorfinn]

6 hours ago, NastyFlytrap said:

... and there's some built-in safety limit disabling using burst, or whatever it was called.

That was the big turnoff for me, @NastyFlytrap Any easily user-moddable game damn well better not disable things like checks for buffer or register overflows, or writing into another process' domain, or it's not going on my machines. I'd vastly prefer just upgrading my hardware to blindly trust riding bareback.

Now if the intent is to create a game which is not moddable, which runs checksums or hashes and the like on startup to make sure nothing malicious has hooked itself in, maybe. But since one of the things I look for in a game is moddable to my tastes...

[EDIT]

That said, it's likely someone will talk some sense into that boy, and he'll realize there's a point to having those built in safeties, but if not, hard pass.

Edited September 10 by Thorfinn

[NastyFlytrap]

15 hours ago, Thorfinn said:

That was the big turnoff for me, @NastyFlytrap Any easily user-moddable game damn well better not disable things like checks for buffer or register overflows, or writing into another process' domain, or it's not going on my machines. I'd vastly prefer just upgrading my hardware to blindly trust riding bareback.

Now if the intent is to create a game which is not moddable, which runs checksums or hashes and the like on startup to make sure nothing malicious has hooked itself in, maybe. But since one of the things I look for in a game is moddable to my tastes...

[EDIT]

That said, it's likely someone will talk some sense into that boy, and he'll realize there's a point to having those built in safeties, but if not, hard pass.

Huh. Right. I did not consider the security implications. In my mind it was just turning off the guard rails, and taking the kiddy wheels off and doing things manually, like memory management, garbage collection, and stuff like that.

 

I didnt know it outright allowed cheat engine-like memory editing of others things, and such.

 

In that case, big yikes.

[Thorfinn]

I'm not concerned about cheat engine. I'm not even sure what cheating is in a single player game intended to be user-modded. I'm more concerned about how easy it might make it for even script kiddies to put garden-variety Trojans into their "mods". The point of many of those checks was to prevent exploits. Just seems like a bad idea to pretend the days of viruses and trojans are over, and hope the virus checker that you probably have set to "Game Mode" catches it.

To be fair, those may not be the checks he's talking about. But I have a sneaking suspicion it is. There isn't much of a point in wasting very many clock cycles on bound checking if exceeding those bounds has no consequences, and compilers usually optimize that anyway. The only ones that make sense to spend much time on are those that could be catastrophic to your system.

Edited September 11 by Thorfinn