Babylon project (provisional name)

I agree with the crowdfunding thing… not ready yet for that.

I’m replacing the foliage because some of them have poor quality, and other are downloaded meshes that I can’t use in the final product. Also need a lot of optimization. I’m using the runtime foliage script to create the foliage dinamically around the player, so each tree are a staticmesh actor, and these are a lot of drawcalls.

For example actually I’m using about 2000 grass and 1000 flowers. These are 3000 actors, and the flowers are one flower per actor, and with several materials. I want to make different grass with the flowers included, using only one material. This will be a 50% less of meshes and probably a 100% or 150% less drawcalls. It’s something easy to do, but I’m too lazy for this type of things…

For the framerate control, game starts with a 62 fps limit, but I have assigned a key to change the framerate to 32, 62, and uncaped, so with the uncaped I can see the framerate total in each place of the map.

I have functions to destroy all the pawns/weapons/pickups and the foliage, so I can see the impact of each thing. With no bots and foliage, only the player, the game stat are about 2 ms (3 or 4 in the editor). I have some places in the map using bookmarks, I regulary do a test in these places to see if there are some lost of performance. For example I have a place with 100 bots to see the game stat, another place in the top of a mountain to see a big portion of the landscape, to see the performance when I do changes in the landscape material, etc. If the performance are worse than the last, then that night I can’t sleep very well.

For the CPU, the most time consuming are the apex cloth and the rigid bodies. Bots disables the rigid bodies by distance, and it’s configurable by the setup menu. There are a very big improvement with them totally disabled. I’m working now in a soldier model with no rigid bodies (only when enters in ragdoll), one piece, one material… I hope to can use a lot of then at the same time, about 100.

I tried some things to improve the ticking, like this:

TickFrequency = 5
TickFrequencyDecreaseDistanceStart = 100
TickFrequencyDecreaseDistanceEnd = 300
TickFrequencyLastSeenTimeBeforeForcingMaxTickFrequency = 10

but seems to no have any effect, perhaps are not the correct settings.
I use settickisdisabled when are possible, for example to put the bots in a sleeping state. Only the controllers are using ticks then.

Also in UE4 I saw that when setting the physics asset, you can choose the bodies to interact, for example pony tail bones only collides with head and shoulders. I don’t see any simlilar in UDK, seems each rigid body collides with the entire world.

There are a lot of things to optimize, I think.

with the long-ish view distance that you have I’d question the effectiveness of the runtime foliage spawning system. then again I can’t just the distance very well because of the heavy DoF :stuck_out_tongue:

reducing multi-material usage for meshes used in large numbers is probably a very good idea. I suspect the change will be more noticeable on older hardware though so it always depends on what you intend to do with your game (sell it?) and what would be the target PC specs.

seems you have a good grasp of what to do to optimize the CPU part.

as for the “sleeping” bots, I found out that an empty state is not enough. I added this to my disabled state and got quite an improvement:


state Idle
{
	ignores SeePlayer, HearNoise, SeeMonster, EnemyNotVisible, KilledBy, NotifyBump, HitWall, NotifyPhysicsVolumeChange, NotifyHeadVolumeChange, Falling, TakeDamage, ReceiveWarning;

	// rest of stuff
}

this disables quite a few things that Controller does natively, many of which involve traces.

as for the TickFrequency, I thought it was a feature new to UE4 (introduced in 4.5 or later IIRC). a global code search doesn’t give me any results for “TickFrequency” in my UDK code

lastly for setting SetTickIsDisabled on your actors, from where do you call this? a distance-based check on the Tick is ruled out because, well it stops ticking :smiley:
the time and place where you enable/disable the tick might have a significant impact.

well there’s still an “obligation” as described by kickstarter:

this is from the October 2014 revision of the Terms of Use btw. the old TOS were not nearly as descriptive in these matters so it seems this revision of the TOS came from the ‘take the money and run’ cases that happened
the oculus kickstarter is prior to the oct’14 TOS, but also to me it seems a stretch to request a refund if the project’s use of funds didn’t fail per se. sure the project sold its soul, but it still got done and the funds weren’t misused

lots of RPG/fantasy projects have failed their funding too, perhaps its just that there are more medieval/fantasy ones because the genre is more popular. and don’t forget that the biggest kickstarter in history is a space game :stuck_out_tongue:

anyway lets not derail the discussion too much shall we :smiley:

Too bad for the Ghostship as i see the dude tying his best for years with the 3 games and i hope that he succeed soon.
Now that we are on the foliage subject, Cobalt take a look at the LeafTrunk shader (towards the end of the page)for that light transmission effect and maybe you can find something interesting there to brighten the day :wink:
http://unreal.rgr.jp/Mydownloads/WL-Shader/#leaftrunk

I did on the characters models, from 3 materials to 1, using alpha masks to simulate “sub materials” properties. In my test with 100 bots, the gain was about 20% better, with a considerable drawcall reduction. But I need to do some tests with the foliage and buildings to see if the improvement are significant, because it’s hardests to work with a unique material. I have a old PC to test too.

Well, these variables exists in the code, and are documented, but I don’t see any improvement. Perhaps are obsolete in the newest versions.

[/QUOTE]

The pawn controller are the responsible. When the pawn is far, controller goes to a sleeping state, with the ignores that you posted included. In this state, pawn is hidden, pawn tick is disabled, and collisions and other stuf. The controller is ticked, but not the pawn. There are a sleep() variable, and then a vsize to check if the player is near, to awake the pawn, restoring ticking, hidden ,etc.

The gain are considerable. I have tested to untick controllers too, but the improvement are insignificant (and needs to restore the tick in another function). Seems that the big stuff are inside the pawn code.

But still takes 1 ms for each 100 bots. As the map is big, can exist 300, or 1000 bots and this is too much ms. Now I have about 200 bots on the map, most of them for test, and this are 2 extra ms.

So I’m thinking in a way to stores pawns properties in an array and destroy them. Then check this array to see if pawns needs to be respawn, a very few array items in each tick, compensated with deltatime. Perhaps doing 20 vsizes each tick will be faster than have 300 bots sleeping. Another solution to reduce vsizes are separate the map in sectors, and only checks pawns in the player sector or adjacent.

Thanks, I will take a look :slight_smile:

yeah you just have a lot of bots. destroying them and re-creating them seems to be what you need for such large numbers.
but if it’s really just the Pawns and not the Controllers, you could try also putting the Pawns into a Sleep state with function ignores as well (I should try this myself!)

actually I thought you were doing tick disables and distance checks for other actor types. I do this for rigidbody objects like KActors (disable the rigidbody state, collision and other things) because I have a ton of them on my scenes.

about the TickFrequency, I found this: TickFrequency and config HACK_UseTickFrequency?? - Epic Games Forums
seems you can use it after all :slight_smile:
and I’ll probably try to use it too

btw VSizes are not expensive, it’s the amount of them which depend on the amount of actors you iterate.
a powerful trick to reduce actor iterator times is to defer the iteration over multiple frames. so in fact you only check one actor per frame (or a few), which means that yes, your iterator will take quite a longer time to finish processing all actors before starting over (but for distance checks this is perfectly fine)

O_and_N: that seems to be just using the standard Transmission output of materials :smiley:

Yes, that is what I do actually, togheter with the tick disabled, and is a 1 ms each 100 bots… too much. So to store them in a array and destroy seems the only solution.

Yes, I saw time ago, but no result. Seems that are skeletalmesh component properties, no actor properties. Also I tried with “AnimationLODFrameRate”, and the same result. Perhaps I’m using incorrect values.

Yes, you can divide the array length into 1 or more seconds, then use deltatime to determine how many items process in each tick. I’m using that system to destroy the foliage when is going far. Instead destroy 300 instances at the same time, wich can produce hitches, the script destroy some of them each tick, depending of deltatime and the player velocity. I need to do the same for the spawn, which are producing hitches when the number of instances are high.

ah the Tick Frequency is an actor property in UE4 (not just skeletalmeshcomponent as UE3)

AnimationLODFrameRate works fine for me, you’re probably just using incorrect values. but the results are not great either, not much gained and bad visuals. what I do about animations for the pawns is to disable them completely, and also helps.
this 1ms per bot pawn, what does the GameplayProfiler tell you about it? is the tick anims, the compose skel pos, or perhaps something not related to animations?

and also what about KActors and similar rigidbody actors? do you have a lot in your scene? what does the profiler tell you? I think Stat Rigidbody will tell you the ms time of processing rigidbodies

Yes, I forgot to use AnimationLODDistanceFactor too. But game stat are worse, perhaps because the enginee does more work when updates the animation, instead do it every tick.

The 1 ms each 100 sleeping bots is the game stat when I destroy the bots… so if I have 200, after destroy them the game stat is 2 ms faster. I think that is nothing about animations or skeleton updates, because the mesh is hidden, tick disabled, animations stoped, no collision, no movement, etc. There are something in Pawn.uc eating a bit of resources. Perhaps only Epic know it :slight_smile:

well even then, the Pawn has a lot of functions you could try to ignore on your Pawn’s disabled state. just go through the Pawn class file and check any native functions/events that could seem relevant to ignore. maybe even on the Actor class too

either way, what does the GameplayProfiler tell you about it?

Profiler shows times of 0.0 in the most of pawns sleeping, but in some shows 0.1, in the tick function (and all of them has the tick disabled, in theory…).

I will try to ignore more things to see what happens. Anyway with a prevision of about 1000 bots sleeping, I think that store/destroy will be the best solution. In the best situation, 1000 bots sleeping can take 4 or 5 ms and it’s too much if you want to be under 16 ms.

that’s 0.0 or 0.1 per pawn, but what about the aggregate function calls? (i.e. the total for all pawns)

even if you destroy all bots, further optimizations to the living bots wouldn’t harm :slight_smile:

I don’t see any anormal in that, the most consuming function are calccamera, getplayerviewpoint, etc. My question is why some of the 176 bots that has “settickisdisabled(true)” are still processing the tick.

Edit: found the problem in the sleep state, now are 0.2 ms for every 100 bots sleeping. 2 ms for 1000 sleeping bots are still too much, if I cant reduce to almost 1 ms, I will try the store/destroy method.

yep, a lot of functions aren’t called by the Tick and are still happening very frequently or even every frame :slight_smile:

It’s the only way I know to make a open world game with UDK, using stream levels, dynamic foliage, untick, destroy instead hide actors, etc.

Here a test using a cloak:

[hears voices in Spanish]

caught me off guard! :smiley:

(I’m Spanish/Mexican and live in barcelona)

Spanglish in Babylon, yes.

Another apex test:

Cobalt, still need voices?