Include more helper methods.

[dfkeenan]

trafficstars

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

[Kryptos-FR]

Some extensions already exist. For example: https://github.com/stride3d/stride/blob/master/sources/engine/Stride.Engine/Engine/EntityTransformExtensions.cs

[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 :eyes:

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).

[Aggror]

@xen2 Can we discuss how and if we can incorporate some of this functionality into the core of Stride? I am running into the exact same things as the devs above. I think it can really help out beginners as well as more advanced developers.

[xen2]

Sure, some of them would be quite helpful!

[Aggror]

What are your thoughts on the location of a delta time shortcut? That is the tutorial I want to record tomorrow. Would be a shame if it changes only a couple days later. https://dfkeenan.github.io/StrideToolkit/api/StrideToolkit.Engine/GameExtensions/5C148F80

[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)

[Aggror]

@xen2 Good argument. I am all for keeping things in a logical place and not having a gazillion shortcuts everywhere. I was more concerned with the length. But if this requires quite some work, I will just leave it to what is right now for the tutorial. Did you also read my comment on the this.GetSimulation? I feel like this could look better/cleaner, so that we don't need to use the 'this'. This might be really personal though.

[xen2]

@Aggror Where is that this.GetSimulation() comment?

[Aggror]

Ah sorry, forgot to paste it.

During the making of the C# intermediate tutorials I am explaining Raycasts. The way you currently get the current simulation this.GetSimulation() feels really weird in between all components and some static classes. The this reminds me of javascript, but this might be really personal.

You can find it in discord #developers https://discord.com/channels/500285081265635328/500290856532574209/713763457958412321

[xen2]

Thanks.

The this in this.GetSimulation() is necessary because it's an extension method and they are not resolved implicitly on the current type. It's definitely not ideal. Unfortunately that's how C# works for extension methods.

I will need to think a little bit if I could come up with a better way/workaround to deal with that.

[VaclavElias]

I will review https://github.com/dfkeenan/StrideToolkit and close this once all is included in the Stride Community Toolkit