PC Alpha 18 Dev Diary!!

Alpha 18 Dev Diary!!

  • A18 Stable is Out!

    Votes: 2 66.7%

  • <img alt=":)" data-src="" src="___base_url___/applications/core/interface/js/spacer.png" />

    Votes: 1 33.3%
  • Total voters
    3
Status
Not open for further replies.
That and constantly transferring all those meshes to clients because they do not know the status of those chunks until they actually get there at which point this is moot.

 
That and constantly transferring all those meshes to clients because they do not know the status of those chunks until they actually get there at which point this is moot.
Click to expand...
You don't need to send the entire mesh as such, just enough data that the client can rebuild it on the other side. That could still be a lot of data but far less than a full mesh.

 
As long as we get more NPC's in the future games! lol
Click to expand...
There are a lot of npcs coming to 7 days, just not ones you can recruit to do your bidding unless we can make it look convincing and afford the performance setback.

 
I have some questions about this performance issue because I have been making a ton of modular underground POIs. I've tried asking in the mods section, but nobody seems to have an answer for me. I would really like to use them all at some point, but I am afraid that it's going to cause problems, as mentioned above and several other times when caves were discussed in this thread. If a dev could chime in and explain the cause of cave performance issues, it would be great.
Firstly, is there any difference between an underground POI and simply a hole in the ground with no roof? If I made a roof over a hole in the hole in the ground, does it suddenly fall into a performance issue? If not, then I am not seeing the difference between a cave and building.

Is there anything I can do to help with performance when building underground POIs?

If I set "ExcludePOICulling" to FALSE, this means it will not render at a distance and it will be culled, right?

If I set "ExcludeDistantPOIMesh" to TRUE, does this mean it will not use the simple mesh and will continue to use the main mesh at a distance, or does this mean nothing will be rendered at all?

What is the best combination of these two settings to optimize underground POIs and avoid these performance issues as much as possible?
Click to expand...
We were using perlin worms and generating cave data at runtime. Some of the caves were extensive and we were rendering huge cave networks MOST players didn't even see. (why is my game slow, I'm staring at a flat open desert?) Then to make them interesting, we had to spawn animals or zombies down there, slowing it further and taking away from potentially obvious zombies on the surface. In short, imagine rendering 1.5 x as much stuff as you need to, and use a costly algorithm when generating it for the first time when a player goes into the area. It was making it challenging to keep up with a minibike movement. If we could pregenerate it and cull it 100% and not spawn guys in there until a player was inside, (all easily doable in a static world game, but challenging in a fully destroyable voxel game) then we could probably add them in.

 
hey madmole and the rest of yoos pimpsspent some time this week playing 17.3

balance of stamina feels much better than before. cant go hard out non stop running mining or wrenching but a bit of a rest and can still keep going without the rage that was there before. to my mind it it close to where it should be.

seem to be more zds in the world. is that just me or has something changed?

often fighting or avoiding the z bears. and dogs. nice to be challenged :-)

big thumbs up bro. this iteration rocks!

died 4 times tonight. the brats crack up at that... now they are doing the dishes.
Click to expand...
Nice and lols.

 
Why does grain alcohol have a lower economic value (48) than Beer (100)? Grain alcohol is stronger and especially given that it is actually useful for first aid kits, it seems like it should be worth a lot more.
Click to expand...
Probably an oversight, but the guy who left had beer as some god tier item with a bunch of beer perks and bs I nuked.

 
For an underground POI you do not need a distant POI mesh at all. You can not see it at a distance.ExcludeDistantPOIMesh=TRUE would be sensible.

"Real" POI do not exist at a distance at all. The chunks are not loaded so no blocks exist there period. That's the whole point of the simplified meshes.
Click to expand...
Thanks for clearing up the underground POI uncertainties I had. For the ones I made, I’ll be sure to not include the distant POI. I suppose I will have to keep them simple with not too many spawns or suffer some slower rendering.

We were using perlin worms and generating cave data at runtime. Some of the caves were extensive and we were rendering huge cave networks MOST players didn't even see. (why is my game slow, I'm staring at a flat open desert?) Then to make them interesting, we had to spawn animals or zombies down there, slowing it further and taking away from potentially obvious zombies on the surface. In short, imagine rendering 1.5 x as much stuff as you need to, and use a costly algorithm when generating it for the first time when a player goes into the area. It was making it challenging to keep up with a minibike movement. If we could pregenerate it and cull it 100% and not spawn guys in there until a player was inside, (all easily doable in a static world game, but challenging in a fully destroyable voxel game) then we could probably add them in.
Click to expand...
I see. So a big part of it was also the generation. Makes sense.

It's almost like there needs to be some quick and reliable algorithm to determine the average ground level of some chunk so that chunks could be loaded in vertical sub-chunks in order to do the same kind of culling... but this couldn't possibly be a solution because the overhead of maintaining the data would likely negate the benefits. Here's counting on Moore's law.

 
Last edited by a moderator:
Have you thought about putting more unique rewards in the quests to make them more desirable? The Dukes and XP are nice, but I was thinking more along the lines of schematics, mods, books...etc that can only be obtained through high tier quests and no were else. I think this would make the questing system feel a lot less repetitive.

 
Thanks for clearing up the underground POI uncertainties I had. For the ones I made, I’ll be sure to not include the distant POI. I suppose I will have to keep them simple with not too many spawns or suffer some slower rendering.


I see. So a big part of it was also the generation. Makes sense.

It's almost like there needs to be some quick and reliable algorithm to determine the average ground level of some chunk so that chunks could be loaded in vertical sub-chunks in order to do the same kind of culling... but this couldn't possibly be a solution because the overhead of maintaining the data would likely negate the benefits. Here's counting on Moore's law.
Click to expand...
Its not that hard to cull, as long as the cave is not altered too much (digging though the roof)

Caves have the habit to be under ground, so they dont need to be rendered when a player is not inside it, or near its entrance.

At the distance, the entrance can be rendered blocked off, and the underground parts does not need to be rendered at all.

-&gt; once the game knows a client player is near the entrance (voxel volume marked around it) or inside (volume voxel created at generation time)

then the cave gets rendered, and activates ai spawning inside. All those volumes are known at the start, since the game generates those anyhow.

Once the cave gets altered to a certain degree by players / zombies (especially digging though the roof) the whole cave gets marked as "dirty" and is permanently rendered like all other voxels.

 
Its not that hard to cull, as long as the cave is not altered too much (digging though the roof)
Caves have the habit to be under ground, so they dont need to be rendered when a player is not inside it, or near its entrance.

At the distance, the entrance can be rendered blocked off, and the underground parts does not need to be rendered at all.

-&gt; once the game knows a client player is near the entrance (voxel volume marked around it) or inside (volume voxel created at generation time)

then the cave gets rendered, and activates ai spawning inside. All those volumes are known at the start, since the game generates those anyhow.

Once the cave gets altered to a certain degree by players / zombies (especially digging though the roof) the whole cave gets marked as "dirty" and is permanently rendered like all other voxels.
Click to expand...
All valid, but a lot of work for something that would only be effective temporarily until the world actually gets played in.

I'm thinking that if the Raytracing tech in GPUs continues to improve, the same data used for lighting can be recycled for others systems some day, such as culling in a dynamic world.

 
We were using perlin worms and generating cave data at runtime. Some of the caves were extensive and we were rendering huge cave networks MOST players didn't even see. (why is my game slow, I'm staring at a flat open desert?) Then to make them interesting, we had to spawn animals or zombies down there, slowing it further and taking away from potentially obvious zombies on the surface. In short, imagine rendering 1.5 x as much stuff as you need to, and use a costly algorithm when generating it for the first time when a player goes into the area. It was making it challenging to keep up with a minibike movement. If we could pregenerate it and cull it 100% and not spawn guys in there until a player was inside, (all easily doable in a static world game, but challenging in a fully destroyable voxel game) then we could probably add them in.
Click to expand...
Well, it is clear that this may take time to generate on the fly.

But i can't understand - why the pre-generation, which is now available, has not solved this problem?

In the end, can generate caves as POI and then place them in the world...

 
He'll probably get some custom AI and properties so he bull dozes traps and explodes at the right time.
Click to expand...
This will allow me to make a mod with stupid zombies instead of those "smart" who are now?

Sounds like a solution to the problem for us...

 
You don't need to send the entire mesh as such, just enough data that the client can rebuild it on the other side. That could still be a lot of data but far less than a full mesh.
Click to expand...
And for that you have to load enough chunks to cover the area that the POI could potentially cover.

Not doing that is the principle behind all that distant-anything. ;)

 
Is there any chance of a 17.4 soon? I wanna start a new game but I'm scared of it becoming obsolete immediately.
Click to expand...
17.4 if released will probably just be bug fixes and misc changes. Currently it should not break your 17.3 game.

So far 17.4 has:

Fixed SDTD-10072 It is very difficult to harvest pigs.

Added automove console command.

Changed gfx command default permission, so all clients can use.

Fixed SDTD-10122 Virtual memory leak causing client game crashes.

Changed TraderArea command now displays the status of all trader areas.

I played a new RWG game on 17.4 for about 3 hours last night. It ran well and memory use seemed stable.

There might be a few more graphics settings tweaks. I also have a bug with zombies sometimes not able to hit clients that I hope to have fixed on Monday.

 
Status
Not open for further replies.
Back
Top