Can an actor declared as DT_Sprite be rotated?

[gopostal]

As above.

I have a smoke grenade and it uses sprites to draw the generated cloud. Once it reaches a certain size it becomes visually static because I clamp the growth. I'd like to give each little cloud it's own slow rotation so the overall effect is more of a rolling, billowing one. I don't think I've ever seen a sprite get rotated and I did try to do it in editor with no success. Am I going to need to make a scripted texture to achieve this effect or is there a way via code to do it?

[[]KAOS[]Casey]

Use Panel mesh (or don't, because its an extremely tessellated flat plane for no real good reason) and rotate that

[gopostal]

I saw "extremely tessellated" and thought to myself "How bad can it really be?"

A quick trip to editor and I see you don't throw terms around lightly. WTactualF? And...why do that?

Anyway I tested this and it does work but orientation to the players is a problem. I can stack multiple sprite sheets and get a decent effect but if I switch over to a mesh I'll need to use many more to cover the area from all directions. I think it's just over-complicating something that's ultimately trivial but I wanted to see if it was fixable.

[[]KAOS[]Casey]

I saw "extremely tessellated" and thought to myself "How bad can it really be?"

A quick trip to editor and I see you don't throw terms around lightly. WTactualF? And...why do that?

It is truly a mystery. I dont think Panel is actually used in game to my knowledge.

Anyway I tested this and it does work but orientation to the players is a problem.

DoomPawns does orientation based on player view using a flat mesh similar to Panel. Don't know how it works offhand, but its in there somewhere.

[Feralidragon]

Sprites cannot "roll" in this engine if this is what you meant.
However, sprites in terms of rendering are just squares (2 polys/triangles) being rendered in a way that they are always facing the camera, therefore all you have to do is the same here.

This one is actually pretty simple to do:

1 - Create a 3D mesh sheet, and make sure the orientation is such that the sheet is facing the X axis (imagine the sheet expanded in the Y and Z axis), and import it.
This orientation is important because then you will be able to apply 2 types of rotation simultaneously and independently from one another: the rotation to always face the player (like a sprite) and the "roll" rotation that you want to have in the first place.

2 - Then in the code, in the tick event, and only in the local client, just set its rotation to always face the local player camera, but keeping the Roll component intact, something like:

Code: Select all

SetRotation(rotator(PlayerCameraLocation - Location) + rot(0, 0, Rotation.Roll));

or

Code: Select all

local rotator r;

r = rotator(PlayerCameraLocation - Location);
r.Roll = Rotation.Roll;
SetRotation(r);

(I am not sure if the first example is syntactically correct, it's been a while)

From here on, now you have a sheet acting and rendering exactly like a sprite, and you can freely tweak its Roll to rotate it how you want, including even using the DesiredRotation and stuff like that if you so wish.

[Kajgue]

I expect that the panel mesh is heavily tessellated to provide more points to catch the light.

[gopostal]

I hope this isn't too dumb a question Ferali but what if multiple people can see the mesh at the same time? Do I need to do all of this simulated?

Edit: Never mind, I get it now. This is a neat trick. Thanks for writing this up!

[Feralidragon]

No question is too dumb. 
It is only dumb to not make questions when you have them.

But as you have certainly realized, this code only runs client-side, and client-side there's only one player that matters: the player owner of that client.
Ideally, anything that is purely visual and has no bearing in actual gameplay logic, you should spawn and execute exclusively in the client, without the server to even be remotely aware of their existence.

I expect that the panel mesh is heavily tessellated to provide more points to catch the light.

Indeed.
I forgot to address this in my previous reply, but it all goes down to lighting resolution of a surface.

As you guys may know, BSP and meshes are lit up using completely different algorithms.
In the case of BSP, lightmaps are used, which are generated when you build the lighting of a map, and they provide a per-pixel lighting, by just multiplying each corresponding pixel color of the original texture in the BSP surface by the pixel light color of the lightmap, providing high quality lighting, including shadows, at nearly zero processing cost on runtime.

However, in the case of meshes, they use Gouraud shading.
This shading is one of the fastest and nicest looking lighting algorithms for lighting up a triangle, and it works by applying a single color in each triangle vertex.
Which means that a triangle may only have up to 3 different lighting colors, and then the whole surface is just an interpolation from one color to the other between vertices.

Thus, compared to BSP, the lighting resolution of a surface in a mesh is much much lower, several orders of magnitude lower, and this is one of the reasons why meshes stand out as being "worse looking" than BSP.
However, often meshes do not need such a high lighting resolution to begin with, and standing out is often a good thing even for gameplay, to quickly spot players, ammo, weapons, and so on.

But sometimes it is desired to have a mesh for decorative purposes, such as a panel with a texture, without necessarily creating a BSP sheet for it.
And the thing is, if a single 2-triangle square sheet is used for this, and the sheet is of a considerable size (the size you would see as a "panel"), and you have a few lights and even shadows and other things there, the panel would always stand out given that it would only have 4 vertices to apply a lighting color on, and then all the way across the surface it would be an interpolation between these colors.

So if you have a shadow in the middle of the panel, or a different color, you wouldn't ever see it, and the panel would stand out as this ugly thing in the middle of what could be a great view with a good lighting in the rest of the map.

Therefore, by tessellating the panel so severely, you guarantee a much higher lighting resolution on it, given that now you have far more vertices to apply lighting color on, and less of a surface area to interpolate by in terms of color, approximating it to the lighting quality you already have for BSP surfaces.

Now if you ask: why to use a panel mesh instead of a simply sheet in the first place?
Well, it may come in handy if you don't want to mess with the BSP tree anymore, or to dynamically change the texture or other properties dynamically without having to use more troublesome things such as scripted textures and the like.

I know this ended up being a long winded up explanation, but I hope this clears out why it is so. 

[gopostal]

Well, it took several hours of frustration but I finally got it to where it looks nice. I ended up using a mixture of some of the doompawns code to get the player owner and Ferali's post to apply the roll changes each tick. This method of fake sprite is really very handy now that I have it all worked out. I can use this in other places. Thank you again guys!

Yay community


The plane noises are part of the video. It's an air drop that's a big aspect of the game (that also BTW was because of your guy's help in getting correct)