Would it be possible to program the renderer of the game to render the outside build pieces of an enclosed structure first ? Is there a programming or game engine issue preventing this from being possible? I know this suggestion has came and went many times and have yet seen this issue being corrected.
This is a primarily pvp issue in the game renderer will show sometimes the whole inside of a structure before it finally closes up by rendering the outside last. This literally shows nearly everything a pvper would want to know about what is contained and where it would be in the structure.
Again is it a programming issue that is preventing this correction or is it something else ?
Off the top of my head and from mobileâŠ
It is certainly not a trivial issue to fix. In general you can easily use a technique called raycasting to determine what object is âfirstâ from a given point of view. But youâd need to do a whole bunch of those every frame to determine the entire âouter perimeterâ. For every player observing a building. Baking or batching that information is probably possible, but the extremely dynamic nature of building in CE means those bakes would be out of date very quickly - though thatâs probably the route I would take. It might mean your base would be âout of dateâ while its perimeter was being modified, but that would at least be relatively rare (compared to every frame).
I know that for a guy like me, taking information from this limited time you see the base in, with rendering, itâs nearly impossible.
BUTâŠ
For a really charismatic person, that can read thousands informations with just a glimpse, this is a fortune cookie .
I cannot blame the company for my console (ps4), but if this is happening on new gen consoles, or pc, it would be nice to be fixed.
Yeah, it happens on PC from time to time. Like when there are 5 to 7 large-ish bases that suddenly come into view - like, as you breach a hilltop or something. If there are also more than about 10 or 15 players online, the partial render can last well past the time it takes to inventory or see hidden chambers.
On rendering the outer walls first, sure, itâs very possible. But doing so will slow everything down and overall take longer to completely render. It would need to figure out which pieces constituted âthe outer wallsâ and from that specific playerâs position and view angle. Solving for that is going to eat some major CPU cycles.
Yes. This has been dealt with before. I bugged Funcom about doors rendering late and allowing everybody to walk through before re-rendered. Doors and outerwallsâŠ
I would guess proximity and angle to the player. And for multiple players?
I donât think our thoughts on this matter though - theyâre not likely to do that. If they cared about this issue and I seriously doubt they do, the better way would be to leave the whole thing invisible (rendering it âunseen by player cameraâ) until everything was âloadedâ and then pop it into place in a single render frame. But that would likely present other problems - and maybe worse ones.
It used to be that if you built a medium Wheel, it would render first, and block all the stuff behind it. Something changed in the coding so that everything sort of flops out when it wants to.
Would it be possible to create a new piece, letâs call it a solid fence, where if placed would always be rendered first? If so, what if that attribute were applied to our present Fence Foundations?
Yeah, or how about just giving walls, frames, fence foundations and maybe ceiling times, a higher priority than everything else⊠that would likely solve most if not all the issues. Likely the only thing they might be able to detect then would be the layout - but I think that would be pretty difficult - I mean to judge the layout from just walls on the few times stuff didnât actually render in real-time.
Does anyone know whether this is primarily an issue with rendering or with receiving the data from the server?
On my PC, this generally manifests itself only when Iâm coming into the range of the build in question after Iâve been far enough that it got unloaded, which is why I assumed it wasnât a rendering issue, but now Iâm doubting that assumption.
I donât know for sure but I think itâs all server side. The DB sort is determining the order things are sent (to be rendered) and the packet throughput (or lack thereof) is limiting the speed and/or number of items that the client is tasked with rendering. Again, just guessing.
This is one of those situations where client and server doesnât make sense. Some server parts are there and some are here. Some client parts are here, too. Before it gets too vague, rendering or receiving, we can still imagine the parts that fit in proper order. Receiving data should be easy because there is a lot of support for its standards. Rendering always feels like bleeding edge. Keeping the connection up can be tricky. One is stable and the other is⊠âexperimentalâ
Servers are also dynamically configured which makes it more complicated to imagine in our thought-models. For example given the same data center and maybe or maybe not even the same physical cluster within, resources are constantly allocated and reallocated as they are needed and where they are needed. There are many different models from being low priority hyper-dynamic across a large facility (inexpensive) to a dedicated box (blade) sitting on a shelf (rack) with your name on it (expensive).
So this makes it difficult to assume the server condition or âhorse powerâ given the information we have access to - like time of day, distance, number of players logged on, and etc. For example when there is no one on a specific server maybe itâs resources are completely allocated away from it. When one player joins said specific server like âOfficial #1334â the data center or cluster therein aggregates or allocates the needed resources for letâs say 1-3 players. This can take time depending what those resources were doing (like maybe running SETI@home - LOL). It might have to finish up first before it can then begin to reallocate - usually determined by priority hierarchies - which is usually determined by contract ($). When a 4th player joins more resources are again called in to support the load for that server âOfficial #1334â, and again this might take some time. Itâs also a similar case with networking bandwidth allocation at every major hop - although this switching is usually very fast.
To complicate things even further there are more than a few data centers being used to host FC CE servers and each one will have different software solutions running. This means that maybe an Asian server will almost never cause the conditions whereby we see bases rendering incrementally but the facilities in the EU are constantly causing such conditions.
So are we the 1st or 4th player in the above scenario and seeing the server lagging because of those reasons, some combination of other things as well; like number of hops, our ISPâs load at the time, our own line-speed, our own clientâs environment, and so many other things?
It becomes very complicated to assume the various points of stress but we can often generalize and simplify as I attempted, and not be entirely wrong.
Switching is literally the dumbest network model to run. On a small scale it fools you to think it will automatically scale to larger models. No magic here.
We want the internet instead of switchers. Itâs faster and smarter. Iâve heard of putting a linux kernel on the RJ45s plugged into a switch. Is it dire?
I donât know enough to comment further really. In fact Iâm so ignorant on the topic of networking I donât even know what youâre talking about. I just know that there are thousands of network switches in every data center, hundreds or thousands in every ISP, and at least one in every home. For data to get from one place to another it âswitchesâ from one line or âaddressâ to another. At data centers network bandwidth allocation is dynamic similarly to how other resources are dynamically allocated like I explained in my overly simplistic explanation above.
.
