X4 Pop-in?

[rulerofallcheese]

While playing Rebirth, you can sometimes look out into space and see the highways snaking around everywhere like a galactic racetrack or circuit.

However - in this official X4 clip (link below) the highway "pops-in" and Bernd even comments about it.

https://youtu.be/Hk4pPuC3GjA?t=298

Now I know X4 is in-development and they warned us that graphically the footage isn't complete. But now I'm wondering if this will be typical in X4. I used to have this issue back in X3R, but both AP and Rebirth seemed to have solved it - so I'm a bit puzzled seeing it's return.

Games with this issue have always been irritating because you will be looking really hard for something and sometimes you can't find it because it doesn't render until you get right up close.

[UniTrader]

no idea how you can have Issues with Highways in Reunion (where they didnt exist at all) or Albion Prelude (where their previous Form of Trans-Orbital Accelerators are present, but which are functionally almost the same as a Gate)

Regarding the "Pop-In" of Tubes: its probably currently the same as in Rebirth: unless you are close to a Tube its highly Transparent (not gone entirely)... and when you are close to some part of it the Tube in the whole Sector becomes easily visible even at long Distances. could be better by just highlighting the close parts imo...

Or do you refer to Render Distance in general? usually this is a Graphics Setting, but might be restricted by local stuff like Nebulae... and Render Distance should be pretty good because at least in XR there are about 7 "LoDs" for Cap Ships (4 regular LoDs for the main Hull and about 3 "Layers of Greeble" for closeups then the highest LoD is already in use)



PS these are just my personal Observations/Impressions, nothing official

[pref]

Since its the same engine id expect it to be similar in this regard as xr.
Never had any such issues in that game, i could even increase view distance to such a high level that i saw everything big 2+ zones away.

Normally its more a hardware issue, not enough resources to handle a convenient view distance - like shortage of memory, or slow hdd io.

[rulerofallcheese]

no idea how you can have Issues with Highways in Reunion (where they didnt exist at all) or Albion Prelude (where their previous Form of Trans-Orbital Accelerators are present, but which are functionally almost the same as a Gate)

Regarding the "Pop-In" of Tubes: its probably currently the same as in Rebirth: unless you are close to a Tube its highly Transparent (not gone entirely)... and when you are close to some part of it the Tube in the whole Sector becomes easily visible even at long Distances. could be better by just highlighting the close parts imo...

Or do you refer to Render Distance in general? usually this is a Graphics Setting, but might be restricted by local stuff like Nebulae... and Render Distance should be pretty good because at least in XR there are about 7 "LoDs" for Cap Ships (4 regular LoDs for the main Hull and about 3 "Layers of Greeble" for closeups then the highest LoD is already in use)



PS these are just my personal Observations/Impressions, nothing official

I was referring to render distance in general in X3R. One thing I really liked about X3AP and Rebirth was that big objects like stations, etc. would still be drawn even if you were really far away. That's why I thought it was wierd you could see the highways in Rebirth from super far away. but they popped in during that X4 clip.

I'm just curious as to why that was happening. I'm guessing since it was running on a development machine, there might be development software running in the background competing for resources. Or maybe, this happened when they switched to Vulcan. I don't have the VR edition (on Vulcan) to verify this myself though.

[MegaJohnny]

You're right, it's very glaring. My (tentative) guess is the pop-in just wasn't addressed at the time.

[A5PECT]

In XR pop-in was noticeable if you were riding on a capital ship as it boosted across zones. Now that the player can pilot ships with that kind of speed, I'm worried about pop-in in X4.

[Tamina]

In XRebirth highways were widely* regarded as ugly and them being visible all the time didn't help at all.
Different technices for covering up their uglyness were discussed in another thread extensively, including this solution.
After all they need to be visible in order for the player to interact with them.

I guess in X4F they let them pop-in now, which is better? "Like when you are starving but you are happy that nobody is pointing a gun at you right now on the other hand"-better.
Remember this this video is one year old, maybe they found a better solution in the meantime.

[Vandragorax]

I agree that pop-in like this is pretty bad in a space game. The majority of the sectors should allow you to see far into the distance to spot where objects of interest might be (even if they aren't in your radar range yet). I remember this being the case in X3 but also it had a massive frame rate impact.

Hopefully with this new engine, the distance LOD models can be low poly enough not to impact frames but still be visible and recognisable. I'd like to be able to see dots in the distance in a clear sector if there is something there, and be able to approach it to see it gradually increase in detail. Of course some sectors might be in a nebula, or dust cloud etc. which would obscure vision which is perfectly acceptable.

I'm not really sure of the best approach when it comes to highways as they can look kinda ugly snaking around in the sector, but it's also weird to see them popping in right in front of you when you get close, and that doesn't help when trying to navigate around the sector by looking at 'landmarks' whereas if the whole highway was vaguely visible at distances too, it could be used as a navigation/orientation aid.

[ubuntufreakdragon]

I Think Highways should stay invisible until you either activate the sensor overlay or come very close, they just look ugly on long ranges.
Instead I want to see some solid repeaters which surround the highway each 5-10 km

Lore explaination:
Highways dont emit light, but if a ship enters it's shields interact with the highway producing the light. And you sensors can of couse detect them.

[Sandalpocalypse]

pop in will probably be necessary given the size of the sectors.

There was popin in xr i dont recall it bothering me particularly. The non-popped highways were way more of a problem.

[Vandragorax]

pop in will probably be necessary given the size of the sectors.

There was popin in xr i dont recall it bothering me particularly. The non-popped highways were way more of a problem.

It's never necessary, that's what distance LOD models are for. Providing lower poly renders of the same entities for viewing at a distance so that it doesn't impact frame rate so much. But still you want to be able to see small dots moving in space from a distance, where there are ships fighting or a trade fleet moving etc.

It doesn't make sense that you can see for light-years by viewing distant planets and stars in the background, but you can't even see a ship or station a few hundred KM in front of you. Let alone the highways which are very large and should clearly be visible across the whole sector!

It would certainly be noticeable and distracting to play X4 if it has the sort of pop-in that is shown in the OP's video clip link.

[linolafett]

It's never necessary, that's what distance LOD models are for. Providing lower poly renders of the same entities for viewing at a distance so that it doesn't impact frame rate so much. But still you want to be able to see small dots moving in space from a distance, where there are ships fighting or a trade fleet moving etc.

Stupid artist attempt at an explaination of why things are not that simple:

Reducing the polycount of a simple object (for example a single drawcall object - a ship which only has a single material and no textures) only makes it faster to render. The amount of calculating if its on screen and pushing that information through the CPU stays the same.

The polyount is not our main problem,its the amount of drawcalls - things to render (the ship hull, the landinggear, the cockpit, the positional lights+....... ).
Therefore we also reduce the amount of drawcalls in the LODs down to a simple object (one gemetry - one material) to get rid of all of this small stuff being pushed through the system.

Okay. now we have a relatively lighweight object, which might take up a 5pixel radius on screen, sounds good right? Problem is, a station for example consists out of a dozen of these guys. Having then a few station on screen increases the drawcalls again quickly. Having now a few dozen ships nearby makes the count explode in no time.
Thats why there are no small dots of things in the far distance, because these dots are not super cheap to compute.

You can always modify the renderrules in the .xml files or change the settings in your config file to values higher than the ui exposed"100%) to increase your view distance. This will just drasticially increase the drawcalls and therefore reduce the performance. If you have a beast of a pc, this might be worth a shot. People did this already in XR, though the assets in X4 are now better optimized and we should be able to draw more things for less calls on screen.

[UniTrader]

since lino replied here a two questions regarding the "Levels of greeble" in XR and probably also X4:
first how i understand they work:
its basically additional LoDs in the widest sense, so on a linear scale it basically works like this:
lod3 < lod2 < lod1 < lod0 <
lod0 + detail xl <
lod0 + detail xl + detail l <
lod0 + detail xl + detail l + detail m <
lod0 + detail xl + detail l + detail m + detail s <
lod0 + detail xl + detail l + detail m + detail s + detail xs

and these detail levels are basically all the greeble on an object, which are disabled if the object is too far for them to be noticeable, so basically working like LoDs but with Object Parts / Visualy surface elements instead of Polygons. Very likely directly aimed at reducing Drawcalls by removing not noticeable Objects and Materials.

so now to the Questions regarding this:
=> Is my Interpretation of this written above correct? (please also correct fine details i got wrong )
=> And how should we refer to this "Levels of Greeble" in future Discussions? not sure if this technique was invented by you or if there are other examples of it available and how their terminology is..
My two attempts to group them are these:
A) Object Details are made up of in Levels of Polygons (LoP; previously known as LoDs) and Levels of Greeble (LoG), which together make up the Levels of Detail for an Object
B) The Scaling of Ship Details is made up of the Levels of Detail, which scale the Polygon Count of an Object, and the Levels of Greeble, which scale how many fine Structures on the Surface of an Object are displayed using a seperate, but attached Object. (i am missing an Overarching Descriptive Term for both in this case though..)

[Alan Phipps]

(For those wanting to know what 'Greeble' is.)

[adeine]

Hopefully distant objects can be faded in/out smoothly where necessary instead of popping in and out of existence.

Yes, there's no reason why a far distant object should be invisible and/or fade into view in space as if seen through haze or an atmosphere, but it looks so much more natural than the alternatives.

[DaMuncha]

(For those wanting to know what 'Greeble' is.)

So all that crap on the side of a BORG cube

[Fedora01]

(For those wanting to know what 'Greeble' is.)

So all that crap on the side of a BORG cube

Or 50% of most Star Wars ships

[JSDD]

It's never necessary, that's what distance LOD models are for. Providing lower poly renders of the same entities for viewing at a distance so that it doesn't impact frame rate so much. But still you want to be able to see small dots moving in space from a distance, where there are ships fighting or a trade fleet moving etc.

Stupid artist attempt at an explaination of why things are not that simple:

Reducing the polycount of a simple object (for example a single drawcall object - a ship which only has a single material and no textures) only makes it faster to render. The amount of calculating if its on screen and pushing that information through the CPU stays the same.

The polyount is not our main problem,its the amount of drawcalls - things to render (the ship hull, the landinggear, the cockpit, the positional lights+....... ).
Therefore we also reduce the amount of drawcalls in the LODs down to a simple object (one gemetry - one material) to get rid of all of this small stuff being pushed through the system.

as far as i know, you can reduce the number of drawcalls to 1 per renderstate. i`m only a bit familiar with opengl, never did anything with vulkan, but the restrictions on what is possible are less in vulkan (but it comes with more work).

the usual 1 drawcall per mesh (that uses 1 material)
glDrawElementsBaseVertex(...)
--> uses vertex + index buffer in which all the meshes are layed down

then there is instanced rendering, all the meshes of the same type (for example: ship hull LOD 0, again with the same material)
glDrawElementsInstancedBaseVertex(...)
--> uses vertex + index + instance buffer

now you can render as much as you want, drawcall count can be reduced to "materialcount" x "meshcount" ... just fill a buffer with all the "data per instance" (for example: mat4x4 transformation) for ALL instances of a certain mesh, apply its material to the shader, issue drawcall

a recent feature, "indirect" rendering (GL version 4.2) can give you another advantage: buffering drawcalls themself (!) into the indirect buffer. now you`ve got 4 buffers, vertex + index buffer for mesh data, instance buffer for all instances of ALL mesh types together, and an indirect buffer filled with drawcall infos. with that you can reduce the number of drawcalls to "materialcount" (i think)
glMultiDrawElementsIndirect(...);

The parameters addressed by indirect are packed into a structure that takes the form (in C):

Code: Select all

typedef  struct {
        uint  count;
        uint  primCount;
        uint  firstIndex;
        uint  baseVertex;
        uint  baseInstance;
    } DrawElementsIndirectCommand;

If a buffer is bound to the GL_DRAW_INDIRECT_BUFFER binding at the time of a call to glDrawElementsIndirect, indirect is interpreted as an offset, in basic machine units, into that buffer and the parameter data is read from the buffer rather than from client memory.

Code: Select all

first fill buffers ...
for each (material)
{
    apply material;
    glMultiDrawElementsIndirect(XYZ);
}

in XYZ, there is the information:
--> mode = GL_TRIANGLES for triangularized meshes
--> type = GL_UNSIGNED_SHORT for up to 32K vertices per mesh
--> indirect = byte offset to the next "internal" drawcall
--> drawcount = number of drawcalls in the indirect buffer
--> stride = sizeof(DrawElementsIndirectCommand)

the each buffered drawcall in the indirect buffer does the following: (see "struct DrawElementsIndirectCommand" above)
--> count = index count in the index buffer for mesh J
--> instancecount = 1 or 0 (draw it or skipp it)
--> firstindex = offset into index buffer for mesh J
--> basevertex = offset into vertex buffer for mesh J
--> baseinstance = offset into instance buffer for instance K of mesh J

tip of the iceberg, most graphics cards support "bindless textures" feature, with means you dont have to change the "renderstate" per material. just create a fifth buffer, but ALL the materials that you have in there, and put an additional "per-instance-data" called "uint materinlindex" in it. now, you can access the material from a materialarray in your fragment shader.

what about textures?
--> create all textures that you want to have
--> make them "residend", get a handle (which means they are on the GPU memory)
--> create an uint array, put all textures in there, bind it as "uniform buffer"
--> for each material that needs textures, get the index in that texture in the array, and set it as "per-material data"
--> all those materials without texture just access an Xtra 1x1 white texture
--> diffuse = diffusecolor x diffusetexture, so that you dont need to distinguish between "hastexture" and "hasnotexture"

Code: Select all

struct material {
vec4 diffusecolor;
vec4 specularcolor;
float shininess;
uint diffusetexture;
//...etc
};

another advantage is that you can do instance culling on the gpu, and directly use the buffer as "instance + indirect buffer".


RESULT:
1 drawcall per renderstate