I put together a series of maths helppatches.
This time instead of making my own videos there are already much better videos from experts out there, which are linked in the patches.
To install
In gamma editor press top left menu>manage nugets>commandline
type
Nuget Install VL.ExtendedTutorials
And then the tutorials should be in your help browser
Small update to 1.1.2 -
Now includes a third person camera example and some bugfixes.
hey toby - really awesome work!
a comment on the Billboard node in patch 19:
The way the node is set up right now it does… well … nothing. it takes the incoming Matrix and multiplies it with the Identity - so the output is the same as the input.
in preparing my upcoming workshop i stumbled over this as well and interpreted in a way that this node should just be an “alias” (or even remind beta-users of the node we had there). devvvs might want to shed a light on why it is there.
you actually don’t have to use it, it makes the patch just more complicated:
just performing the multiplication results in the same thing (and spares you the additional node, which, to add some confusion, even has to be typed)
one more thing i noticed:
in patch 14 you are using LookAt instead of LookAt (RightHanded) nodes, which has the effect of an object flipping and also inverting rotation direction (positive angles rotating clockwise instead of CCW). sinces stride uses a right-handed coordinate system it would be natural to also use the right-handed nodes here (like you did in the camera patch).
Thanks for the feedback, appreciate you having a close look at these.
I have updated those patches, now version 1.1.3.
One question, with the right handed LookAt nodes the negative Z axis faces towards the target point. Do you know why this is the convention? Positive axis would make more sense to me.
Is it also because the LookAt function is intended for cameras?
how you describe coordinates in the world is just a convention - how right, forward, up, … are mapped to coordinates (X,Y,Z) is totally arbitrary. there is no right or wrong how you name those directions and that’s the reason why for some applications it is natural to do it one way, for others another way.
example:
coming from paper contruction drawing it feels natural to think of a sheet of paper lying on a table. there right would map to positive X, forward would map to positive Y and elevation (moving out of the papersheet) would be positive Z. that’s what most construction-based software do (autodesk, blender, …) → you get a right-handed system
coming from screen based media and considering the top-left corner of the screen as origin (or thinking about enumerating pixels in an image), going right would be positive X, going down would be positive Y and for positive Z you need to chose to go in or out of the screen. OpenCV for example chooses to go inwards (–> right-handed system):
if you’d consider to have a positive Y-axis going upwards, and Z going into the screen, you end up with a left-handed system.
here is an overview by Freya for different software packages:
i guess what feels natural is just what you are more used to.
it becomes even more convolved, when you have to mix data from different sources and conventions.
here’s what Eric Haines has to say about it:
in the end - for the LookAt nodes i’d stick to the convention that your world coordinate system uses, as the results will be more consistent.
here is also some info to add to the confusion:
Ok thanks again for the info
Now V1.1.4 with an extra helppatch on converting from world space to screen space. Handy for making custom interactions where you need to test if 3D world things and 2D screen things are colliding or similar.
Thanks @Motzi for support with this one.
These are amazing! Thank you so much!
