as an artist, for an extremely cheap animated escalator, i would treat it like tank treads, using a panning material on a single static mesh, which would use just 1 draw call, and would work for mobile games. i would paint them on a flat surface, like zelda 64 stairs. as long as the AO in the diffuse and normal maps are doing their job, it can look pretty 3D.
another option would be to create the whole escalator as a single static mesh, with each step modeled, and create a morph target that you blend into using a saw wave inside a timeline. this would also only cost 1 draw call, but i’m not sure if mobile supports morph targets, so i would use this for consoles and PC.
but in my game, for which I’m making heavy use of for, I need the Avi’s/Characters, whatever you wish to call them, that when they step on the escalator, they are moved.and this does it, and I don’t use timelines, or anything else, other than my blueprint library. When I create a airtube, and the Avi’s step into it, I need then to move. or if I wish to have a flying carpet, that follows a predefined route. Especially good for like overviews of the game level.
And while one may be concerned with Draw Calls, it’s not the be all end all of performance. It’s the easiest thing for people to see, so it gets a lot of attention paid to it. But bringing up timelines, morph targets, etc all have a cost. The Stat that UE4 displays, that seems to be the greatest concern to me, is something called “present time” which I have not had the time to chase down as to what they actually mean by that, and what values from the engine go into that calculation. Because every time I see “Present time” go ballistic, “Stat Unit” goes into the basement.
yeah, i was just thinking on the fly, morph targets are actually a terrible solution for an escalator. i need to learn more about reading performance stats and optimizing in ue4. i also need to stop prematurely optimizing things before i even start making them.
i like your spline tool, it seems like a decent tool for quickly prototyping some very organic environments. i made a similar thing a while back, for making linear arrays of instance static meshes. it could just make straight lines or circular curves, but not splines. but i gave up on it when i couldn’t figure out how to combine all the instances into a single mesh automatically.
now, if i need 25 arches in a row, i just model a set of static meshes of different lengths, where one would be 8 arches, another would be 3 arches, 2 arches, and 1 arch. then in the editor, i can combine these to create any length, but also be efficient on draw calls.
I always follow the KISS method, and in my case, the “stupid” part really applies! lol
For building roads, or race tracks, well it’s a god send, it keeps me from having to model each curve, etc. I have yet to finish the “mine field”. I.e. lay down say 250 control points, and then tell it, that you wish to fire, only 50 particle systems (depending on how “heavy” the particle system is of course), at any one time, but either pick the control points randomly, or “chase” someone through the mine field. There is a lot of things to do with particle systems that I have not got implemented yet.
A spline mesh component cannot be instanced, so that can hurt on roads, a lot of the other stuff, that it does, can all be instanced, hence even if it’s 500 trees, it boils down to one draw call for them. And I still have the luxury of individual placement once it has randomly built the forest
What I found that was really killer, and I found this when doing the stairs. Is that shadowing, is a performance killer. make a stair system of 200 stairs, and turn on shadowing, and watch performance drop through the floor. Turn off shadowing, and it rebounds right back. I wrote up a blog post on it, because it was so dramatic. So when I’m talking to folks, and they are grumping about performance, i’m always like, “and how much shadowing are you doing?”