Jump to content
• Advertisement

# legends2k

Member

9

1. ## 2D Transforms 101

A presentation/tutorial on 2D transforms for programmers and practitioners favouring intuition over mathematical rigour; animations are used to illustrate the effect of every transform explained. Click Here to view presentation. Firefox, Chrome or Opera recommended as they support animations; see Requirements below for details. Press ? while in the presentation for controls and Esc for an overview and quick navigation. Comments and suggestions are welcome. Overview Transformations are a general mathematical concept that is applicable to anyone working in: Computer Graphics Animation Game Programming (2D and 3D) Image Processing Motion Capture UI Design Computer Vision Robotics Aeronautics Parallel Computing Concepts discussed are dimension-indepedant; it's just easier to explain and visualize things in 2D but they're applicable to higher dimensions without loss of generality. Instead of dealing with only elementary transforms (rotate, scale, translate) on points, which most resources do, it also covers: Basic math behind transforms (without matrices) Matrix introduced past the basics since it's just a tool Composite transforms -- concatenation of multiple transforms Anti-commutativity Transforms about an arbitrary origin Active and passive viewpoints of transforms Transformation of coordinate systems Mapping between multiple coordinate systems Hierarchical Transforms Requirements The presentation was hand-crafted using HTML5, CSS3, JavaScript and SVG; so nothing more than a browser is required to view the presentation. Firefox, Chrome or Opera, even if you've an older version, is highly recommended since support for SVG animations isn't that great in other browsers; with browsers like Safari, Edge or IE you will not be able to see these animations -- caveat lector. You can also view the presentation on a mobile or a tablet; the content, without any loss of fidelity, should get resized and fit to given form factor, thanks to vector graphics and CSS3. Touch (tap and swipe left/right) is supported both for navigation and animation control. Animations Transformations are better understood visually than with just dry theory. Hence every transformation workout is accompanied, along with the math, by an animation. Images with a graph sheet background contain animations. Simply click on such an image to cycle through the animation. Every click changes the image's state, animating it into a new figure. When you see the original figure you started with, it denotes the end of all the animation the image contains. If you're using a keyboard to navigate the presentation, clicking the image steals focus from the presentation and sets in on to the image; simply click anywhere outside the image to give the focus back to the presentation. Now press space / -> to continue with the presentation. Solution The solution to problem of mapping the boy space to street space that is posed at the end of the presentation is in map_boy_to_street.md. SVG The demonstrations/interactive animations embedded within the presentation was done in SVG, the XML-based, open standard file format for vector graphics with support for animation. In English, all it has are just instructions like move to, line to, rect, circle, ellipse, etc. in a very readable, XML format and no unintelligible binary data. So a reader (yes, a human one too) can easily read and understand it; a renderer can render it at any resolution without any loss in fidelity. The presentation's first slide has a 3D-transformed background which too is an SVG -- it should show up as something similar to this; a simple check to see how well your browser supports SVGs and CSS3 transforms. It's highly recommended that you fiddle with the SVGs under images directory. SVG format is very similar to PostScript (which also has commands like move to, line to, etc.) and is an excellent Hello World test bed (Short, Self Contained, Correct, Example) for learning transformations or 2D graphics in general. Oh they also have a tag for groupings which may be used to learn hierarchical transformations. An SVG is only more readable than a PS, PDF or XAML. Just open it in a (modern) browser to view it (no, not Edge, it doesn't do 3D CSS3 transforms in SVGs yet :), open it in your favourite text editor, muck around, save and refresh your browser to see the changes immediately; rinse and repeat. Credits Computer Graphics using OpenGL, Francis Hill and Stephen Kelley 3-D Computer Graphics, Samuel R. Buss Essential Math for Games and Interactive Applications, James Van Verth and Lars Bishop 3D Math Primer, Fletcher Dunn and Ian Parberry reveal.js, the presentation framework, generously shared under the MIT licence by Hakim El Hattab MathJax for rendering beautiful math equations on any browser, American Mathematical Society Elementary affine transforms chart shared under CC 3.0, used as first slide background, CM Lee What is or isn't a linear transform, shared under CC 3.0, Ldo Reveal.js on Github pages, Vasko Zdravevski

3. ## 2D Transforms 101

Do you really understand the difference between a book and a presentation? That too, an interactive one and why it relates well with transforms? If you'd looked carefully, pressing O while in the presentation gives you the option of seeking randomly too.   Constructive comments, as the site recommends, are much better than rants; try giving objective suggestions upon which we can work together to make the article better.
4. ## Moving a shadow for a rotating object at an angle for 2D

The shadow itself should be drawn with a circle and not a square. Not only will it be more realistic, it'll also be easier to code this up. Now for the placement:   The two extremes from which the scene can be viewed are Top view i.e. the path of revolution is a perfect circle Front view i.e. the path of revolution is a horizontal straight line If you get the shadow for these two angles right, then the remaining, intermediate angle views may be obtained by interpolating between these extremes. For the top view, the shadow circle will always be on the "far" side of the planet, quite simple. The front view, however, isn't as simple. The planet will be in the horizontal line's midpoint twice, once the shadow circle should be completely invisible (or rather behind the planet), while the other time it should obscure the planet altogether. When it hits the endpoints of the line, it'll be the same as the top view. This will mean changing the z-order of the rendering based on the planet's to or fro movement. While it's doing the first half of the circle, arc1, shadow should be drawn first and when in arc2, the shadow should be drawn second.   Hope these pointers help.
5. ## best math learning source for game programers in all fields(ai, graphics ..)

I second that.   If you want a slightly more approachable (funny/intuitive) alternative, I suggest: 3D Math Primer by Fletcher Dunn and Ian Parberry   If you want something reference style, more rigorous (harder) with wider array of topics covered, I suggest: Mathematics for 3D Game Programming and Computer Graphics by Eric Leyngel   I've read all three books. Each one is very good in treating some topic or the other. All are excellent in their own right.
6. ## Disassembly and assembly links

An older Wayback machine snapshot had the images. I rsync'd the complete tutorial (12 parts with text and images); made an offline archive stripping off irrelevant parts.   The last two parts has sample code that could be downloaded but I couldn't recover them. Asked the author, he too didn't have backups, but for all the other parts the code is part of the tutorial/image, no a separate downloads, so it isn't much we're missing.   The download link, with the author's permission.

13. ## When/where does handedness really matter?

scgames, on 11 Jun 2009 - 12:24, said:   This led me to thinking about coordinate system handedness and I see the point that numbers are numbers and the formula for cross or dot product are the same irrespective of the human who perceives it and hence we'd get the same results be it we consider data in any handedness. Then why do we see handedness conversions being talked about? i.e. converting some asset from one handed system to another doesn't seem to make sense; say a triangle data of v0 = (0, 0, 0), v1 = (0, 0, 1), v2 = (1, 0, 1) could be interpreted as a triangle irrespective of the system used and in both cases the base of the triangle would be away from the origin, hence why would this (or any asset/mesh) data be called LHS or RHS.   Also in another post I noticed this   Quote   but what beats me is, even here, I'm unable to differentiate the handedness, since in both systems, i x j = k and there by k.k will always be > 0 (k^2, to be exact), then how does the above hold true?   Handedness is something that is only in the mind of the human who interprets the data; say in a model file, after all the numbers present are just numbers and they don't've any inherent handedness bound to them (or am I wrong here?), then why do we talk about conversion from one system to another? Is it because of the graphics API that we use (which I think shouldn't be the reason since both GL and DX supports both handedness is what I read); so I'm really confused on what circumstance does the handedness really matter. If, I, the developer always interpret/see all data in RHS, then when would I be bitten by it and why?   It'd be great if someone can explain this to me. Thanks!
14. ## When/where does handedness really matter?

Oh good, because this is exactly what I was thinking when I revisited cross product definition; although handedness decides the direction of the resultant of the cross when it boils down to math, the formulas don't change, numbers are still numbers, the resulting numbers would be the same; it's humans who interpret it based on the coordinate system handedness based on our liking. Yeah, in the reference of one system, when a new one is introduced via mirroring then this test would help. Thanks!
15. ## When/where does handedness really matter?

I'm now clear of the part that a model/asset by itself isn't explicitly left or right handed while to see it exactly the way its creator expected it to be seen, we need to interpret in that system. However, I'm reading "Essential Mathematics for Game Programmers", in which there is a statement which goes, "when we've three basis vectors i, j and k, performing scalar triple product like (i x j) . k > 0 then it is right handed while if it's negative it's left handed". What confuses me is, I took 3 vectors say 1i, 3j, 4k and drew them both in a left and right handed system, perform the aforementioned scalar triple product, I always get 12, which is positive, when would this be negative to show that the basis is left handed?
16. ## When/where does handedness really matter?

Agreed. My point is how do you differentiate a LHS model and RHS model, what exactly is different between the two? The reason I'm not able to differentiate is that both models will've just numbers; say in a triangle of vertices v0 (0, 0, 0), v1 (0, 0, 1), v2 (1, 0, 1) where's the handedness encoded/lurking?   Similarly, given three vectors say i (1, 0, 0), j (0, 1, 0), k (0, 0, 1), how do you know if it's left or right handed. In my first post, I'd quoted       But then with the above vectors, considering them as either left or right both pass the test. Then how do I differentiate?
17. ## Can't decide which math/physics basics book to get

Nope, I've this book, in the disc provided with it, you've 4 appendices. Perhaps you didn't look at the TOC properly. Appendix A - Trigonometry Appendix B - Calculus Appendix C - Coordinate Systems Appendix D - Taylor series   My review of the book is that it covers the basics extremely well, the authors seem to be very sincere in what they did, giving so much of attention to detail. I've come up till Chapter 6, and so far so good!
18. ## Handedness

This led me to thinking about coordinate system handedness and I see the point that numbers are numbers and the formula for cross or dot product are the same irrespective of the human who perceives it and hence we'd get the same results be it we consider data in any handedness. Then why do we see handedness conversions being talked about? i.e. converting some asset from one handed system to another doesn't seem to make sense; say a triangle data of v0 = (0, 0, 0), v1 = (0, 0, 1), v2 = (1, 0, 1) could be interpreted as a triangle irrespective of the system used and in both cases the base of the triangle would be away from the origin, hence why would this (or any asset/mesh) data be called LHS or RHS.   Also in another post I noticed this     but what beats me is, even here, I'm unable to differentiate the handedness, since in both systems, i x j = k and there by k.k will always be > 0 (k^2, to be exact), then how does the above hold true?   It'd be great if you can explain this to me. Thanks for you time.
• Advertisement
×

## Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!