Foliage Lag

Foliage Lag

I have foliage working again. I have disabled deletion of foliage for the moment but I have a plan on how to efficiently manage rebuilding foliage indexing if it is needed. The basic framework is in place for it.

My bigger concern is trying to determine the most effective use of foliage.

I made all my props foliage and noticed that large foliage objects (walls) create lag where non-foliage actors do not. This means foliage works best for smaller objects. It may be that foliage comes into play for an actor when it is further away from the player. That would be painful to implement so I'm just going to stick with foliage for small objects like grass for now.

Foliage for grass did improve performance so it is working as expected.

Today's task is fading the camera in and out for teleportation when I know it require significant adjustments to the scene. Knowing unreal, this will be a herculean task. It looks simple but I'm sure it is going to suck for some unforeseen reason.

------------- UPDATE -------------

I got the teleport fade out implemented in about an hour. It works very well. I only need to do it when I know a lot of processing is about to occur.

After some experimentation, I have decided foliage is bad for performance. Frame rate starts out great and you think foliage is helping. But... I started getting low frame rates after teleporting around a while. I removed the foliage and voila, frame rate never went low again.

This is really unfortunate. I probably spent several weeks carefully incorporating foliage into my framework. Oh well.

Distributing Processing Over Time

Distributing Processing Over Time

Since the game now adjusts its quality automatically, I can try out different strategies and see which ones improve game quality.

My first change was to distribute load over time. I changed my world generation logic to queue changes instead of processing them all at once. About 10% of the queue is then processed every frame/tick.

This had an amazing improvement in performance. It improved quality by a factor of 4!

This evening I will changing my foliage logic and see how that changes the quality.

Automatic Quality Adjustment

Automatic Quality Adjustment

Everything in my game is dynamically added as the player moves around the world. I've been thinking about how to automatically improve FPS (Frames Per Second) by adding logic to the game mode tick.

I did that today and it works amazingly well. The game now monitors FPS and if it dips below 80, it slowly reduces game quality settings until it is at least 80 FPS. I also have it automatically improve quality if FPS goes above 85.

I teleported around the world for several minutes and there was no stutter. It was interesting to see what settings the game settled on versus what I thought was acceptable. It was much lower but my FPS stabilized at 85. I know 85 is below the recommended 90, but 85 looks fine to me.

This means the game will automatically adjust itself based on the player's graphics card without them having to adjust any settings.

Next I will rewrite my foliage logic and see what quality settings the games adjusts itself to. I expect it to get better.

Foliage Gotcha

Foliage Gotcha

Foliage is a copy of a mesh that renders very fast. All foliage based on a mesh render the same way except they have a different location, rotation and scale. This allows you to put a lot more items on the screen.

When you add foliage, you get an index. That index matches an entry in an array on the parent mesh the foliage is based on. Problem is, if you delete any foliage, the arrays shrinks invalidating the indexes you were previously given. I did find a way around this issue but in the end, the performance downside of managing foliage indexing outweighs the performance gain from using foliage.

More work is needed in this area, but for now, I am disabling foliage on all my meshes.

Exactly what was unreal thinking when they designed this? The only handle you have to the foliage is an index they give you. That index can be invalidated by deleting any other foliage. wtf?

I have spent a LOT of time incorporating foliage into my framework. I think I may have to stop using it unless I stop deleting foliage unless it is absolutely necessary.

Missing UPROPERTY woes

Missing UPROPERTY woes

Over the last few days I have rewritten my world coordinate system. This was no small task affecting everything in a profound way.

I was testing it and Unreal blew up with a memory allocation issue. I had no idea what was going on but running out of memory this early in development is very frightening. I tried it again and eventually it blew up again in a different location with a memory allocation issues.

I did 2 memory dumps, one when it started and one after moving around a while and saw nothing unusual.

Then I decided to review all my code for missing UPROPERTY. UPROPERTY is a pre-compilation macro that tells Unreal that it needs to manage the variable in memory versus destroying it on a whim.

I found 2 missing UPROPERTY variables.

Once I fixed those everything was fine again.

That is very scary. I need to have a strategy of isolating all member variables for a class at the top of the header file and review them occasionally to ensure every one of them is a UPROPERTY.

Vive Controller Jitters

Vive Controller Jitters

Well, I discovered something new last night. I didn't know exactly what it was until I did some experimentation.

If you move your character past coordinate 100,000 or so in any direction, the controller starts to shake. It continues to get worse as you go past that. Lets just say at 9,000,000, it is very painful.

I suppose unreal never noticed this since most people build VR games within a tiny play space.

This means I will need to keep re-positioning  the player within 100,000 Unreal coordinate space. I can build the world beyond that but the player needs to stay within there. This is doable based on the way I construct the world, but I've got to rewrite some code I thought was finished...

Teleport Arc Rumble

Teleport Arc Rumble

What I thought was going to be a 1 hour task turned into a deep dark black hole of hell.

I did not find a single example of someone successfully rumbling the Vive controller from C++.

I have code that should work but it does not and I am tired of fighting with it right now.

So... I went the opposite route and worked on calling a blueprint method (which I know works) from C++. That was an extreme pain as well.

If you construct a blueprint object via Spawn it will not call blue print methods.

I had to resort to dropping a blueprint actor (that subclassed a C++ class I created) into the scene and then find it once the game started. That gave me the ability to call blue print custom events.

Unreal fights me every inch of the way...