Jump to content

Model visibly reloading on fast camera movement


Phodex Games
 Share

Go to solution Solved by Josh,

Recommended Posts

47 minutes ago, Josh said:

Any game that uses this method will display the same behavior.

Hmm ok so I guess this means I cannot disable it right? Because in my actually scene (a dungeon) I personally noticed this behavior when playing. Any techniques to hide this from the user as good as possible? Maybe a normal user does not even notice, but I did as it sometimes appears even if I just turn around relatively slow...

 

Link to comment
Share on other sites

53 minutes ago, Josh said:

Scene occlusion culling is on. You are seeing the result. It is working correctly. Any game that uses this method will display the same behavior.

Why would that be considered correct? Is the culling performed asynchronously to the rendering or only every other frame? Otherwise this behavior makes no sense to me...

Link to comment
Share on other sites

0.o That's kind of ugly, culling isn't very expensive of a process... maybe it'd be worth considering doing this on the CPU, of course on the main thread, in the future. Having to disable culling all together to prevent situations like this ultimately defeats any performance gains the odd user will see , because most will have to disable it.

You will only see slightly less performance gains from the culling done synchronously... I'd bet the CPU culling on a decent sized scene would be negligible, almost immeasurable (I guess depending on the algorithm though). You could also eliminate things by distance, etc, make sure you eliminate them from this if they're hidden... try to "eliminate" the entity from having to go through culling in the first place and you'll probably not notice a difference overall.

If it's simply view frustum culling using a matrix, this operation would be crazy fast no matter where you do it.

I don't know how complex your culling algorithm is, are you just doing view frustum culling? either way the process should be fairly cheap... why not do it before the renderer draws each entity?

Link to comment
Share on other sites

Culling is performed per-pixel on the GPU so it is free and fast. GPU culling is the method all high-performance games use today, for these reasons.

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

That sounds very expensive, unless the culling shader doesn't have to create new wavefronts because the compiler can accomplish branch prediction and act on many pixels simultaneously, all you're guaranteeing is that it happens in linear time (again, unless branch-prediction happened.)... either way, even if it is faster, most people are going to have to disable culling because of this ugly situation, so in practice is it really "faster" if most people can't use it because it doesn't suite their needs?

Even if you don't change this, it'd be nice to also have view frustum culling so you could quickly cancel out candidates that don't fit within your view frustum... then if they aren't in your view frustum you don't have to worry about going further with them because you already know that they aren't visible.

Link to comment
Share on other sites

Just now, Crazycarpet said:

That sounds very expensive, unless the culling shader doesn't have to create new wavefronts because the compiler can accomplish branch prediction and act on many pixels simultaneously, all you're guaranteeing is that it happens in linear time... either way, even if it is faster, most people are going to have to disable culling because of this ugly situation, so in practice is it really "faster" if most people can't use it because it doesn't suite their needs?

Most developers just live with it and accept the tradeoff. I see this in big AAA games so I think you should not worry.

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

I mean, it's not in Unity, UE4, or CryEngine. it seems like a big worry. I personally am not because I don't plan on making titles I want to sell with LE, but I feel it would dissuade many people from purchasing the engine... it's kind of a big issue. There are other ways to accomplish culling, and do it very quickly.. I don't think many AAA titles would do this (Aside from Wolfenstein II which was a mess, but they somehow combated this issue likely with portals), if any for this reason. Culling is an important optimization so simply "disabling" it isn't a great option, unless you have something like view frustum culling to fall-back on, at the minimum.

Unity uses a complex algorithm, idk how it works they don't really say... but it's not asynchronous.

UE4 simply uses the scene depth and the bounds of an object. (so more or less, view frustum culling.) (also synchronous)

CryEngine simply uses frustum culling.

I'm not trying to say you should model LE after those engines, LE is unique and great in it's own right. But theres a reason no AAA engines use this method, it's because it's ugly and it doesn't work! You can't call that behavior "working".

b16846514f96315a2db0501afb434fb5662b9267

Why is view frustum culling not favored? I guarantee you it's faster than iterating over ever pixel, bounding boxes and the view frustum already exist... not like you're allocating memory. And sure? what if an objects behind the wall? well... luckily the vertex shader will discard it after the depth test and it will never reach the rasterizer and therefore it'll never be an issue, performance wise. Sure beats the current method in the engine.

Link to comment
Share on other sites

52 minutes ago, Crazycarpet said:

I mean, it's not in Unity, UE4, or CryEngine. it seems like a big worry. I personally am not because I don't plan on making titles I want to sell with LE, but I feel it would dissuade many people from purchasing the engine... it's kind of a big issue. There are other ways to accomplish culling, and do it very quickly.. I don't think many AAA titles would do this (Aside from Wolfenstein II which was a mess, but they somehow combated this issue likely with portals), if any for this reason. Culling is an important optimization so simply "disabling" it isn't a great option, unless you have something like view frustum culling to fall-back on, at the minimum.

Unity uses a complex algorithm, idk how it works they don't really say... but it's not asynchronous.

UE4 simply uses the scene depth and the bounds of an object. (so more or less, view frustum culling.) (also synchronous)

CryEngine simply uses frustum culling.

I'm not trying to say you should model LE after those engines, LE is unique and great in it's own right. But theres a reason no AAA engines use this method, it's because it's ugly and it doesn't work! You can't call that behavior "working".

b16846514f96315a2db0501afb434fb5662b9267

Why is view frustum culling not favored? I guarantee you it's faster than iterating over ever pixel, bounding boxes and the view frustum already exist... not like you're allocating memory. And sure? what if an objects behind the wall? well... luckily the vertex shader will discard it after the depth test and it will never reach the rasterizer and therefore it'll never be an issue, performance wise. Sure beats the current method in the engine.

This is the exact same method Unreal Engine uses:
https://answers.unrealengine.com/questions/387513/how-can-i-stop-my-meshes-from-flickeringpopping-in.html

Same as Talos Principle (not sure what engine):
https://steamcommunity.com/app/257510/discussions/0/458605613391672391/

Quote

CryEngine simply uses frustum culling.

I guess we are more advanced than CryEngine, in addition to having more users. And since you can disable occlusion culling on a per-camera basis, you can do this too.

Quote

Why is view frustum culling not favored? I guarantee you it's faster than iterating over ever pixel, bounding boxes and the view frustum already exist... not like you're allocating memory. And sure? what if an objects behind the wall? well... luckily the vertex shader will discard it after the depth test and it will never reach the rasterizer and therefore it'll never be an issue, performance wise. Sure beats the current method in the engine.

Frustum culling is used first, then occlusion culling on the scene octree, then occlusion culling on individual objects that have it enabled on a per-object basis. It's quite advanced, and if you prefer you can completely disable the occlusion part.

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

8 minutes ago, Josh said:

I guess we are more advanced than CryEngine, in addition to having more users. And since you can disable occlusion culling on a per-camera basis, you can do this too.

Lol, CryEngine just has the right idea that if you're only going to offer one of the two, view frustum culling makes more sense. Perfect world? offer both it'd like 20 lines of code to add it.

Quote

This is the exact same method Unreal Engine uses:

The difference is Unreal Engine provides view frustum culling so you get most the performance gains even with culling disabled. It is an option, not the only solution.

 

I really hope LE users are planning to make a ghost game, or this isn't going to work for them. :o

Link to comment
Share on other sites

5 minutes ago, Crazycarpet said:

The difference is Unreal Engine provides view frustum culling so you get most the performance gains even with culling disabled. It is an option, not the only solution.

View frustum culling is always enabled in Leadwerks. The entire visible area is built by determining what objects intersect the view frustum. I don't know any game engine that doesn't use this. And if you want you can disable occlusion culling and rely only on this.

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

15 minutes ago, gamecreator said:

Several questions then:

1.  Does this mean that models that are not visible on the camera shouldn't affect the FPS?

2.  If so, does that include vegetation?

3.  Do shaders affect this at all?

Yes, yes, no.

 

  • Like 1

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

  • 3 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...