Rendering in things that aren't there anymore

[Sjustus548]

We took over one of the junk yards and demolished the scrap fence that was surrounding the place and took out those containers in the yard. However when we get far enough away from the base the game starts rendering all that stuff back in. When we get closer it vanishes again. Is there any way to get this to stop happening or is the engine just remember those things were there?

[ZombieSurvivor]

its just the way the game is. its been like that ever since distant POIs were introduced sadly.

[Crater Creator]

You're seeing the actual geometry swap out for the low detail 'distant POI', which is static: it doesn't update to reflect runtime changes. This is also why if you make a base from scratch, you won't see it from far away.

[AtomicUs5000]

Madmole commented on this last week I believe.

They are looking into something to improve it. Something like periodic scanning of POIs, searching for flags raised on update(blocks added or removed), and then updating the POI's distant simple model.

 

If you are familiar with the POI editor, you will know that a function already exists to create the simple model at any time... which means, it could be triggered at runtime programmatically. The problem is not only optimizing that algorithm, but also running that function at the right moments during gameplay such that it doesn't cause any noticeable hiccups.

I think we will see this happen though at some point.

[Crater Creator]

Part of the challenge will be the ever elusive question: what defines a base? It will be difficult to algorithmically accommodate all the wacky things players build. For example, if someone puts down a wooden block or three for their starter quest, does that deserve allocating the full resources for a distant POI? If someone builds the Great Wall of China, does that count as one massive distant POI, and if not, how is it broken up? It's not insurmountable, and as a first pass I'd do algorithmic distant POIs on a per-chunk basis, but it will require some thought to carry out efficiently.

[AtomicUs5000]

Part of the challenge will be the ever elusive question: what defines a base? It will be difficult to algorithmically accommodate all the wacky things players build. For example, if someone puts down a wooden block or three for their starter quest, does that deserve allocating the full resources for a distant POI? If someone builds the Great Wall of China, does that count as one massive distant POI, and if not, how is it broken up? It's not insurmountable, and as a first pass I'd do algorithmic distant POIs on a per-chunk basis, but it will require some thought to carry out efficiently.

 

Ah yeah, applying it to strictly player-built structures is a problem of its own. I agree, chunk-based is probably the way I would go too.

[Guest]

I'd tie it to land claims or sleeping bags/beds. While it would be cool to see every little block update you make somewhere in the world to show up in distant terrain, it's only really noticeable with bases.

 

If I'm not mistaken, there are already instances where your base's chunk will remain loaded for a while after you leave drawing distance (and thus be visible as "distant POI"), but I'm not sure what triggers it.

[ZombieSurvivor]

I'd tie it to land claims or sleeping bags/beds. While it would be cool to see every little block update you make somewhere in the world to show up in distant terrain, it's only really noticeable with bases.

 

If I'm not mistaken, there are already instances where your base's chunk will remain loaded for a while after you leave drawing distance (and thus be visible as "distant POI"), but I'm not sure what triggers it.

 

problem with that is what happens when you remove you bed? what about the millions of beds places everywhere? What about the pro players that do not use landclaims (landclaims are for noobs btw, on pvp servers).

[Khulkhuum]

I think this would need to be triggered after every X blocks added or removed. Afterwards a flag updates that the POI needs to be "remapped", but the counter still updates. When the player leaves for a considerable distance so that "distant POI rendering" kicks in for that POI, it first gets updated, resetting the numbers.

 

It could also be ehnanced for having a timer after which the POI would be "remapped" (considering the X blocks were added or removed). The player going in the vicinity and inside the POI would reset the timer. This would allow saving resources and not "remapping" all POIs at the same time (when a player scrapped 50% of buildings in a small town and after 5 days decided to move loot back to a far away base). Additionally, it could detect if a player was not in battle for a longer time period, if there are any nearby Zs, etc. and "remap" when not much is happening (combat wise).

[Damocles]

Updating the distant POIs (imposters) would theoretically work dynamically if its limited to the POIs volume.

(eg, only things inside the POIs area).

 

Not sure how fast the calculation of the low poly imposter is though. But it could probably be crammed into some idle time (entering a menu maybe)

 

Updating everything, also player build structures, probably needs a whole new aproach on how to generate structures on distant terrain.