Skip to content

Commit

Permalink
Reduce chunk updates.
Browse files Browse the repository at this point in the history
  • Loading branch information
MDFL64 committed May 15, 2017
1 parent a6ac4ce commit b2c0a81
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion lua/voxelate/entities/voxelworld.lua
Original file line number Diff line number Diff line change
Expand Up @@ -95,7 +95,9 @@ end
function ENT:Think()
local index = self:GetInternalIndex()

gm_voxelate.module.voxUpdate(index,CLIENT and 100 or 25,self)
-- 100 updates per frame is -SERIOUSLY- excessive
-- the entire point of queueing updates is so we dont lag balls
gm_voxelate.module.voxUpdate(index,20,self)

This comment has been minimized.

Copy link
@SwadicalRag

SwadicalRag May 16, 2017

Member

Only bumped it to a hundred clientside since the client just has to update its own loaded chunks, and doesn't have to bother with the entire world: also I didn't experience that much lag with 100/tick

How about a compromise of 35 updates clientside?

This comment has been minimized.

Copy link
@MDFL64

MDFL64 May 16, 2017

Author Member

What's so special about 35? 20 is twice what it was before, and both 20 and 10 handled incredibly large bulk updates well. A high update rate is even less important now since map init should be done in a good order.

I can tell you I was lagging badly on world init and on bulk updates, and my computer is probably better than most. I'd like to err on the side of not dropping frames.

Ideally this will be configurable, but chunk updates are only going to get more expensive in the future with greedy meshing, different block types, transparency, and possibly needing to generate a physical mesh on the client for huge worlds...

This comment has been minimized.

Copy link
@SwadicalRag

SwadicalRag May 16, 2017

Member

Understandable, have a good day


if CLIENT then
if not self.correct_maxs then
Expand Down

0 comments on commit b2c0a81

Please sign in to comment.