I'm in the process of replacing all the foliage models. This one looks good, but isn't optimised, 8000 triangles for the LOD0 and 3 materials. It's difficult to mantain the 60 fps.
Each material is a aditional drawcall, so I'm going to try to reduce to 2 materials or one (using alpha masks).

What causes the momentary 'lightning artefact' in the distant foliage at 3:25?
Don't sweat the FPS, by the time you release, everyone will be on 1080...

Comment

This is the LOD transition, using screendoorfade. Another "artifacts" are produced by the translucency in material, with cascade shadows. I like the translucency effect, but there are this problem with the cascades. The solution are to remove the translucency.

You are right, at my dev speed, when finish probably all the people will have a nVidia 8K...

Comment

You are right, at my dev speed, when finish probably all the people will have a nVidia 8K...

What are your thoughts about going down the Kickstarter / IndieGoGo route instead of holding out for royalty?
(See if things speed up). If it went well maybe you could take the game to another level, add multiplayer etc.

Comment

To go to Kickstarter is better that the game will be enough popular. If nobody know it, then nobody reach the page. I'm waiting to have a definitive game name, a oficial website, and then promote a bit.

Royalty are not working as desired, and Epic are only promoting UE4 games. Too many dificulties.

Comment

going for crowdfunding is a very tricky thing. not only do you have to finish the game (obviously), now you have to spend a lot of time and a big chunk of your newly acquired funds in producing goodies (fund tier rewards). it also means you have to spend a lot of time managing other people (the people you're spending your funds on), making briefings, reviewing their work and providing feedback. little or no time is left for actual development, so you become a manager.
as a hobbyist I would argue that the beauty lies in actually doing the development.

another part of the problem is that unless your game becomes a commercial hit (something highly unlikely, rationally and statistically), your business model becomes that of a company in debt. in other words:
- if you make a game as a hobbyist and make some money, you can use it to make a second game, rinse and repeat. if you fail to make the game or if it just fails commercially, no money is lost and you can just start over as a hobbyist.
- if you make a crowdfunding and then make the game, [unless it's a commercial hit] the money is already spent in that game. to make a second game you need to do another crowdfunding. if you fail to make the game you suddenly owe a lot of money to a lot of people.

now I'm not saying crowdfunding is inherently bad, it works for some people. it can work for people with a name already attached to a brand. it can work for teams with people with a 'company' background, good at doing marketing (pre-funding) and management (post-funding). it can work for teams where main person (as a hobbyist, that's you yourself) doesn't mind being purely a manager and not a developer.
as a hobbyist, none of that works for me though.

[MENTION=564]CobaltUDK[/MENTION]: I don't quite get why you're replacing the foliage, as the old one seemed to be better looking in terms of polycount and shading. is it only because of performance?

in your video I see in the stat Unit that the 'Frame' is 16-20ms and the 'Draw' is always lower. are you sure it's not the CPU that's making the bottleneck? I recently made some CPU optimizations in my game (which is GPU-bound because of pure dynamic lighting and shadowing). it was about AI and some Tick stuff of physical actors, which mostly affected the 'Frame' and not the 'Game'. it improved ~9 FPS.
two things to try: first uncap your FPS to have a better notion of highs and lows in your performance. then try the console command "playersonly" (by default F4) which disables a lot of CPU things (most notably physics and AI) leaving you with an almost "pure GPU" version of your game, and see how it compares

Comment

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.

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.

Comment

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 :P

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:

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
the time and place where you enable/disable the tick might have a significant impact.

Comment

Interesting to read your views as you're both broadly on the RPG / Fantasy path...
Funding is pretty much a car crash for the space game genre, examples: 1, 2, 3..
All 3 are decent looking games, and all 3 were badly beaten by Potato Salad?

Comment

If a creator is unable to complete their project and fulfill rewards, they’ve failed to live up to the basic obligations of this agreement. To right this, they must make every reasonable effort to find another way of bringing the project to the best possible conclusion for backers. A creator in this position has only remedied the situation and met their obligations to backers if:

• they post an update that explains what work has been done, how funds were used, and what prevents them from finishing the project as planned;
• they work diligently and in good faith to bring the project to the best possible conclusion in a timeframe that’s communicated to backers;
• they’re able to demonstrate that they’ve used funds appropriately and made every reasonable effort to complete the project as promised;
• they’ve been honest, and have made no material misrepresentations in their communication to backers; and
• they offer to return any remaining funds to backers who have not received their reward (in proportion to the amounts pledged), or else explain how those funds will be used to complete the project in some alternate form.

The creator is solely responsible for fulfilling the promises made in their project. If they’re unable to satisfy the terms of this agreement, they may be subject to legal action by backers.

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

Comment

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 http://unreal.rgr.jp/Mydownloads/WL-Shader/#leaftrunk

Comment

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.

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.

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
the time and place where you enable/disable the tick might have a significant impact.

[/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.

Comment

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 http://unreal.rgr.jp/Mydownloads/WL-Shader/#leaftrunk

Comment

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.

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

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.

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)

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.

Comment

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