Featured image of post The Animal Shrine - 06 - Lamps

The Animal Shrine - 06 - Lamps

The development process of The Animal Shrine - 06

Lights In

Yesterday, I modelled some hanging lanterns. I really needed to put some object that cast actual interesting light in my scene so I can start thinking about my light scenario. It’s still in the early stages and looks patchy in the sense of having a lot at of light at one place and then none at others, but I’ll be working on it more.

Screenshot of a camera between two buildings, close to them, Unreal 4. One can observer the wooden beams and supports, fully textured now. The roof has a wooden texture as well. There are hanging lantern props that cast some Point Lights too. In the distance, where the landscape ends, there are long, sharp cylinders that are indicating placeholder trees creating a forest.

Today I sculpted a bit more the landscape around the place. I also scattered a lot of placeholders for the trees. It changed the mood of the whole place immediately in a way that I really like. I’ll have to look into how I’m going to make the trees and what to do with my mountains in the distance (they are just placeholder big boulders for now). I’m open to any suggestions and tips when it comes to creating the landscape guys!

But back to the lanterns, they were kind of very fun to do. Their process was interesting to say the least. Right now they are an Actor (Blueprint) attached with a rope and a Physics Constraint. That way I can apply physics to them and use Impulse to add force and nudge them in one direction. Gives them a slight animation and it makes such a big difference!

While making them, I had to explore how the Physics Blueprints work in Unreal as I had never used them before. It produced an interesting result. Just when I thought that none of the Blueprints worked even the slightest, I looked up and saw a few lanterns suspended in the air, rotating around as if in zero G.

(YouTube video embedded above. Shows a hanging lantern that is suspended in open air and floats around as if the place has zero gravity.)

I have them working now, and its something that I believe will add quite a bit to my scene when it comes to the final rendering videos. Also now I know how to do stuff like that for any other object I might want to implement that could be moving. Only thing left now is to actually texture those lanterns.

As in my every post, its time for a GIF now

Gif progression preview. Shows the build up of the wooden structures up to the point of the support beams having a texture. Then the adding of fog, lanterns and placeholder trees in the background.

I had to change the fog once again in order to make the “trees” in the distance appear lighter and thus look even further away. The fog changed how my roofs look though, made them maybe too light for my liking. The Volumetric Fog and Atmosphere actors are things I will have to tweak a lot more before I get to what I imagine, but at least there is progress.

That will be from me tonight guys, have a good one.

Go to next blog entry.


Commentary from 2023 (draw calls tips)

I wanted to quickly drop a few words about some of the things I showcase above.

Knowing what I know now, in 2023, compared to back in 2018, I would not approach making these lanterns with Physics Components at all.

It is fun to experiment with Physics Components in Blueprints. If you have not had the chance to do so before, make sure to try as I think there is plenty to learn. There is something I didn’t know about back then though, and it’s a fundamental part of Tech Art and of creating optimized, real time scenes.

That is draw calls.

For Physics to work, we need to make the lanterns mesh “Movable” as opposed to “Static”. The moment we do that, we separate that piece of geometry in its own draw call.

Lets run a hypothetical situation:

We leave the lantern static - like ordinary geometry.

We scatter 10 copies of it near one another.

Then we make sure the material used on all 10 copies is identical.

On the scaling options of each we leave it to 1;1;1 on the x;y;z scale.

A great thing happens; the moment those 10 lanterns get to render on the screen they batch into a single draw call. This keeps it all more optimized.

If we are in a blank scene and we render 10 lanterns in 1 draw call as opposed to 10 lanterns in 10 draw calls, we might not feel much of a difference, even if we inspect the fps / ms and profile the entire scene both GPU and CPU wise.

Imagine increasing up the numbers and putting 100-200 even 1000 of these lanterns on the screen. Suddenly rendering all in 1 draw call as opposed to 1000 draw calls can be felt. Then add up all kinds of other art assets on the screen, some static, some movable. Add a bunch of fog cards and alpha card effects that are overdrawing the screen. Add lots of AI running on the CPU. Add some particles, doesn’t matter if you pick to scale them onto the CPU or the GPU. Suddenly you get the typical amount of things happening in a usual game world in a big AAA title. Your performance will then be low, if you were to render these lanterns in 1000 draw calls instead of 1 draw call.

The lesson here being that we always need to consider clean practices of putting in art meshes so they end up as optimized and bundle in draw calls as possible.

I can hear you wondering, though, how are we to then make these lanterns move and look interesting? Without dirtying up our draw calls?

Some might suggest doing a bespoke bone animation and then attaching it to the lantern. We animate it in Blender or Maya and import in Unreal. But that will have the same culprit of an issue as above. Animated assets with bones of their own most of the time end up as separate draw calls (there are ways to overcome that and still keep bone animations but that is for another blog).

As such a better way instead would be to ask the following. Is there a way I can bundle all of this movement onto the GPU? When you ask that question the follow up conclusion would be: yes! You can. Through a material shader perhaps? That’s on the GPU, right?

Absolutely. If we create this entire animation of moving the lantern in some direction, as if slightly moved by wind, inside the shader, then it means the geometry when placed in the world can remain Static. When it remains static it means our draw calls are back to being easier to manage.

My suggestion for getting that done would be to 0.0.0 your pivot point of the mesh to where the upper cable of the lantern is. Export like that and put into Unreal. In a special material shader for the lantern then, create a World Position Offset (WPO) that slightly rotates everything in whichever axis you like. If you add a little Sine animation multiplier to that, inside the WPO numbers, you will get exactly a bit of movement as if pushed by the wind. Apply that to all other lanterns now and they will all bundle into draw calls, as long as using the same material and their scale in the world is similar.

If you dislike the lantern movement being similar between all of them, you could introduce a bit of a random number multiplier in the shader to overcome it. Or you could expose a number that controls it, and in a material instance of the original parent put in your own animation offset as a number.

If you do that second option though, consider making just 3-4 material instances and then applying them to your 300-400 lanterns in the scene so they all end up in 3-4 draw calls. If you go out of your way to make a unique instance for each lantern then we are back to square one and we end up with all of them having a unique draw call (kind of bad).

I know I quickly gloss over the last few tips, but I intend to give you the names of the techniques and resources you could look up online and I believe you can accomplish whatever it is you imagine using that. The tricky part is knowing, and being aware of it all in the first place.

That is the part I struggled with the most before I joined the industry professionally. At my university for 3 years course not once were the words “draw calls” mentioned. When people talked about optimization everyone jumped to “oh well, its just too highpoly”. Though even back then I knew that clearly is not the case, it still took me years before I first realized about draw calls.

Quite honestly, being in the industry now, I will tell you that even some professionals go for years unaware about draw calls. They talk and talk about lowpoly and highpoly but never consider their draw calls or implementing LODs to increase performance. But this would be a conversation for another time.

As for now, if you are a student or someone getting into things just now, and in this blog you for the first time came across the concept of draw calls, then I take it this was helpful and the idea of it leaves me happy. Now go on and look up some more engine docs and videos on draw calls and supplement and increase your knowledge even more!

Pete.

Go to next blog entry.

Writing and art by Peter Dimitrov. Website theme by Jimmy, modified heavily and customized by Miroslav Dimitrov.
Built with Hugo
Theme Stack designed by Jimmy