Include more helper methods.

Hi,

I always felt that the Xenko engine was a bit lacking when it came some general helper methods. So I started the XenkoToolkit project but I really feel a bunch of these things should be included in-the-box. For example:

• Find components in entity hierarchies.
• Transforms using the Entity’s Transform.
• Transforming things between world and screen space.
• Calculating rays for doing picking using physics ray cast.
• Transforming Prefabs when being instantiated.

I am creating this issue more as discussion. I am not super confident in the quality of my code as they have not been thoroughly tested and my math skills are not great. There are probably also a few questionable design decisions. For example, not sure about all the overloads I did either, may have gone a bit overboard. There are quite a few shortcomings as well, i.e. a bunch of the transform extensions throw exceptions if TransformComponent.UseTRS is false (I couldn’t get the math right).

There are a number of things I would do differently if they were included in the engine, i.e. put the Quaterion look at function in the Quaternion struct.

There are somethings I would almost certainly leave out like the material stuff I did. A better option would be to change the ModelComponent and related systems to handle being able to set material properties per ModelComponent.

cheers, dfkeenan

[profan]

Just echoing this, Xenko is missing a lot of stuff that you end up doing all the time (like screen -> world, world -> screen transformations), and writing it all over again for every game or making the engine unnecessarily hard to use for users who aren’t including a certain toolkit 👀

Currently the common advice is just “just get this package of extensions because you’ll need them either way”. So it would be quite nice to have them in core, it would also mean a far easier time for teaching anyone the engine (so smootehr for people like Aggror when making tuts).

[xen2]

Just my opinion, but I am not a fan of including this specific one in Stride core:

• It is simply doing game.UpdateTime.Elapsed.TotalSeconds under the hood.
• I think game.UpdateTime.Elapsed.TotalSeconds is much more explicit (from GetDeltaTime() we don’t know it’s in seconds or milliseconds, is it delta update time or delta draw time, etc.)
• Usually it’s better to avoid two different API in different locations for the same thing (people will start to get confused when they see a sample with the one they’re not used to, wondering if it’s same thing or not as the other approach). Especially more if it’s just for simple accessors like this.
• If people really want to use it, they can still use this kind of extension as a nuget package or create their own (that fit exactly their more specific needs) in their project.

However, if the problem is that game.UpdateTime.Elapsed.TotalSeconds is too long/complex (which I can understand), I think that’s the part of the API that we should redesign.

Overall, I was more interested to possibly integrate the functions/extensions doing more complex operations (that can’t be done as oneliners, or need to connect several unrelated API) and that adds real value. Example: https://github.com/dfkeenan/StrideToolkit/blob/master/Source/Toolkit/StrideToolkit/Engine/CameraExtensions.cs (for this one, it might be difficult for users to properly use math libraries on camera properties, so having helpers to do that is useful)