Wojtek Sterna

UE5. If you are writing a plugin which you want to work ONLY in non-shipping game/editor builds (think of a helper plugin used only during development) you can configure the uplugin file like in the screenshot below.

t.co/7QUI33zwGY

UE5: So there are these comps for dealing with dynamic geometry:
- ProceduralMeshComponent
- CustomMeshComponent
- DynamicMeshComponent

Apparently starting with UE5 we should be using DynamicMeshComponent. The other two are legacy.

References:
[1] docs.unity3d.com/Packages/com...
[2] en.wikipedia.org/wiki/Rodrigu...

𝟰. Unreal uses an even different algorithm with projecting the point to rotate onto the rotation axis. If you make a material using the image below and in the UE material editor go to 𝗪𝗶𝗻𝗱𝗼𝘄 -> 𝗦𝗵𝗮𝗱𝗲𝗿 𝗖𝗼𝗱𝗲 -> 𝗛𝗟𝗦𝗟 𝗖𝗼𝗱𝗲 you can look up implementation of 𝗥𝗼𝘁𝗮𝘁𝗲𝗔𝗯𝗼𝘂𝘁𝗔𝘅𝗶𝘀 function.

𝟯. Use Rodrigues' rotation formula (minding the pivot point). This is a pretty neat and fairly short formula that can be used if you don't feel like using matrices or quaternions [2].

𝟮. Use a quaternion. Construct a rotation quaternion and transform by it the point we want to rotate (minding the pivot point).

And how can such a rotation be implemented? There are at a least a few ways:
𝟭. Use a 3x3 rotation matrix. Build a rotation matrix and transform by it the point we want to rotate (minding the pivot point). Unity seems to be using that approach [1].

In Unity's shader graph (Unity's counterpart of Unreal's material editor) we set the position of the vertex directly, and that is reflected in its 𝗥𝗼𝘁𝗮𝘁𝗲 𝗔𝗯𝗼𝘂𝘁 𝗔𝘅𝗶𝘀 node, which contrary to Unreal does not return the offset but returns the absolute rotated point position.

So it returns the difference between the rotated point and the input point. This is very much likely due to the fact that in UE5 materials one of the output pins is 𝗪𝗼𝗿𝗹𝗱 𝗣𝗼𝘀𝗶𝘁𝗶𝗼𝗻 𝗢𝗳𝗳𝘀𝗲𝘁, where we put an 𝗼𝗳𝗳𝘀𝗲𝘁 to the vertex position, instead of setting direct value for the vertex position.

It is important to realize what is the output of that node because 𝗶𝘁 𝗶𝘀 𝗻𝗼𝘁 the rotated position/point! It actually returns the value of:
𝗥𝗼𝘁𝗮𝘁𝗲𝗱𝗣𝗼𝘀𝗶𝘁𝗶𝗼𝗻 - 𝗣𝗼𝘀𝗶𝘁𝗶𝗼𝗻

- 𝗣𝗶𝘃𝗼𝘁𝗣𝗼𝗶𝗻𝘁 - That is the center of rotation, a point around which the rotation will occur.
- 𝗣𝗼𝘀𝗶𝘁𝗶𝗼𝗻 - This is the point/vector that we want to rotate.

- 𝗡𝗼𝗿𝗺𝗮𝗹𝗶𝘇𝗲𝗱𝗥𝗼𝘁𝗮𝘁𝗶𝗼𝗻𝗔𝘅𝗶𝘀 - That is our axis of rotation.
- 𝗥𝗼𝘁𝗮𝘁𝗶𝗼𝗻𝗔𝗻𝗴𝗹𝗲 - That is the angle of rotation. It is quite quirky, because this angle is not expressed in radians or degrees, but in normalized units. A value of 1.0, 2.0, 3.0, ... is a full revolution. 0.5 is 180 degrees rotation, etc.

3D engines, like Unreal or Unity, usually expose some functionality that makes such rotations easy. In UE5, in the material editor, as shown in the image below, there is a node called 𝗥𝗼𝘁𝗮𝘁𝗲𝗔𝗯𝗼𝘂𝘁𝗔𝘅𝗶𝘀. It takes four inputs:

Rotation of points and/or vectors is an extremely important geometrical operation. In 2D it's quite simple because there is only one axis of rotation (the axis perpendicular to the XY plane) but in 3D we have an infinite number of axes that we could rotate about.

This is how you can inspect HLSL code of a material authored in UE material editor:

In Unreal Engine, in the material editor there is this node called RotateAboutAxis for rotating points/vectors about a given axis and angle. Here's how it is implemented:

Advanced Graphics Programming in Unreal, part 1 This is a seven-part article series.

If you do custom rendering in UE5, here's a pretty good series of articles

medium.com/@manning.w27...

Here's C# implementation:

For axis-angle rotation in 3D we usually use either a matrix or a quaternion. But if for some reason you do not want to involve either of these "math objects" you can use this neat formula directly: en.wikipedia.org/wiki/Rodrigu...

YouTube video by GOTO Conferences What Every Programmer Should Know about How CPUs Work • Matt Godbolt • GOTO 2024

Pretty cool presentation

www.youtube.com/watch?v=-HNp...

The bolded part is crucial. Nanite, for each pixel has to evaluate 3 vertex positions (of the triangle the pixel belongs to). For that evaluation WPO for each vertex is needed, hence WPO is calculated 3x per pixel.

• 𝘜𝘴𝘦𝘴 𝘵𝘩𝘰𝘴𝘦 𝘵𝘰 𝘥𝘦𝘳𝘪𝘷𝘦 𝘵𝘩𝘦 𝘣𝘢𝘳𝘺𝘤𝘦𝘯𝘵𝘳𝘪𝘤 𝘤𝘰𝘰𝘳𝘥𝘪𝘯𝘢𝘵𝘦𝘴 𝘧𝘰𝘳 𝘵𝘩𝘪𝘴 𝘱𝘪𝘹𝘦𝘭
• 𝘈𝘯𝘥 𝘸𝘪𝘵𝘩 𝘵𝘩𝘰𝘴𝘦, 𝘭𝘰𝘢𝘥𝘴 𝘢𝘯𝘥 𝘪𝘯𝘵𝘦𝘳𝘱𝘰𝘭𝘢𝘵𝘦𝘴 𝘵𝘩𝘦 𝘷𝘦𝘳𝘵𝘦𝘹 𝘢𝘵𝘵𝘳𝘪𝘣𝘶𝘵𝘦𝘴."

Reference [2] is a link to a presentation from Epic on Nanite, where on slide 23 it says:
"𝘛𝘩𝘦𝘯 𝘢 𝘮𝘢𝘵𝘦𝘳𝘪𝘢𝘭 𝘴𝘩𝘢𝘥𝘦𝘳 𝘱𝘦𝘳 𝘱𝘪𝘹𝘦𝘭:
• 𝘓𝘰𝘢𝘥𝘴 𝘵𝘩𝘦 𝘷𝘪𝘴 𝘣𝘶𝘧𝘧𝘦𝘳
• 𝘓𝘰𝘢𝘥𝘴 𝘵𝘩𝘦 𝘵𝘳𝘪𝘢𝘯𝘨𝘭𝘦 𝘥𝘢𝘵𝘢
• 𝙏𝙧𝙖𝙣𝙨𝙛𝙤𝙧𝙢𝙨 𝙩𝙝𝙚 3 𝙫𝙚𝙧𝙩𝙚𝙭 𝙥𝙤𝙨𝙞𝙩𝙞𝙤𝙣𝙨 𝙩𝙤 𝙩𝙝𝙚 𝙨𝙘𝙧𝙚𝙚𝙣

In the 𝗡𝗮𝗻𝗶𝘁𝗲 scenario the cost of WPO is dependent on the number of pixels that the mesh occupies on the screen. For that particular mesh here, covering ~120 000 pixels, WPO would be calculated ~360 000 times (!). That is WPO is calculated 3x per pixel.

In 𝘀𝘁𝗮𝗻𝗱𝗮𝗿𝗱 (𝗻𝗼𝗻-𝗡𝗮𝗻𝗶𝘁𝗲) scenario, when rendering that mesh, WPO in the material would have to be calculated 54 times, as that is the number of vertices of the cube. But with Nanite it's different.

But why is WPO expensive with Nanite in the first place? Have a look at the image attached. It depicts a simple cube that is made of just 54 vertices (it is an Unreal's built-in mesh). This cube occupies roughly 120 000 pixels on the screen.

Long story short: they pre-computed the animation offline and pass it to WPO instead of calculating it all in the material every frame.

Epic even wrote an article where they explain how they dealt with that problem when they ported Fortnite to UE5/Nanite - section "Wind animation" in reference [1] (links are in the comments).