We are trying to improve on the demos that come with Codea, and all comments and suggestions are welcome.
I’ve made a new demo about starting in 3D, which you can find here.
So if you are comfortable programming in Codea and with meshes - but haven’t tried 3D yet - I’d like you to try it, and tell me what you think is good, unclear, missing, etc.
Important! - when pasting into Codea, keep pressing on the “Add New Project” button until you get the option to paste into a new project. Then Codea will split the code correctly into tabs.
You keep making this claim about the axes being the wrong way around. Can you provide a simple example demonstrating what you view as the wrong way around? Whenever I program in 3D then I find that the axes are in exactly the orientation that I expect them to be in.
I’m simply saying that it is natural to expect that if you go forwards, z increases, and vice versa. In real life, you don’t walk forward counting -1, -2, -3,…
Ask anyone who has never worked with graphics (or heavy duty math), what they expect. It was certainly a complete surprise for me. Maybe it is different if you were taught a right handed coordinate system, but I certainly wasn’t.
I’m not the only one.
"What I find strange about the OpenGL coordinate system is the orientation of Z. Since the positive Z axis runs towards the camera, it means that every visible object in the scene needs to have a negative z coordinate, which seems a bit un-intuitive. I would find a left-handed coordinate system (where Z extends away from the camera) to be more intuitive. "
“Ohhh so the Z axis goes that way… So everything was working fine, I just got confused!”
I’m not sure how to say it without sounding critical. I applaud the idea and the effort to rework the samples. But, for example, in this project, the code is not easy to read, despite being heavily commented (or because of that, to an extent). If i could make a suggestion, it would be to get rid of comments, except when absolutely necessary. Well-written code will speak by itself to those who actually want to read it and understand.
I agree that code should explain itself where possible, but if you know nothing about 3D, then
perspective()
camera(0,0,100,0,0,0)
is just gibberish. It needs clear explanation.
It would be nice if comments could be hidden behind an icon until they are needed, but we don’t have that option. It may be that an ebook is a better format for this (and I think it probably is, having done both). However, we need some real demos to get people started.
In the end, I suggest that whether my approach is useful will depend on the opinions of people who have never tried 3D.
Fair enough, although i think a healthy dose of gibberish is needed. It is what makes a newbie programmer want to change a value or two to see what happens. However, you are right that 3D has quite a steep learning curve.
Sometimes you want challenge; sometimes you want quick understanding. For myself, reading the documentation and looking at the code quickly gave me an overview of how 3-D works in Codea and the issues I’ll need to consider if I want to use 3-D. In comparison, I will need to spend much more time and energy trying to understand the Basic Physics demos (which I’m very thankful for, nonetheless!)
It is important to identify teaching that results in accurate and efficient learning (which necessarily shouldn’t be boring) by more people, not just those who are particularly motivated. “Don’t Make Me Think” (about extraneous or confusing stuff) is the title of a (thought-provoking) book on web design. It’s much easier for learners to figure out what works or doesn’t work when important bits and pieces are introduced incrementally and when there are fewer opportunities for errors. Of course, simple things may sometimes be seen as negligible, although they fulfill their purpose. Anyway, I think this demo shows some of the important pieces simply and without a lot of extra code.
By the way, the only way to get more than responses based on personal opinions (however well-founded) and anecdotes would be to pilot test it in a more organized way. Not that this is what could be done, necessarily, but just a reminder that how well some teaching material works can be gauged by how well (and easily and quickly) people of different backgrounds learn to use something new. (If we really want more people to be more math/science/programming literate, we need to give them materials that are more accessible, which is what the demos can do.). There are always people asking about how to learn Codea on the forum. Even though this demo is ostensibly about an advanced topic, it seems likely to work well in showing unexperienced people how to use code to move sprites forward and backward in space, etc. even though they still might not understand much more crucial basics like how setup and draw functions work.
@Ignatz The misapprehension that you seem to have is that you think the coordinate system should be set up for you as the viewer. It isn’t. It is set up for the world and the camera is merely a participant in that. This is actually far more useful as the usual order of things is to set up the world and get everything in the right place first, then to put the camera in it and move around.
Now of course, if you have this misconception then OpenGL’s coordinate system will feel “wrong”. But that doesn’t make it wrong, that just means you need to readjust how you think about it. However, given that plenty of people do get it right, when explaining it then I would recommend explaining it positively. By explaining it negatively, you risk confusing those who actually are on the right track. It’s actually not that different to the puzzle about why left-right is reversed in a mirror but up-down isn’t (hint: in fact, neither left-right nor up-down is actually reversed when you look in a mirror) - the misconception occurs because we subconciously try to put ourselves in the position of the person in the mirror but without thinking carefully about what that actually means.
Back to OpenGL. Here’s what I might say:
To understand how the axes work in your scene, imagine first that you are inside your world. Walk around on the x-y plane. Standing at the origin, the x-y plane spreads out before you just like it used to when you were drawing pictures in maths class. So imagine that you are, in fact, standing on one of those pictures in your old maths book. I’d bet that your natural orientation is so that the positive y-axis stretches out before you. Then the positive x-axis lies to your right. That works fine if we just want to move around in two dimensions, but we want to add the third. So add in to your imagined world the ability to move vertically. Maybe you’re in a lift, or maybe you found some kryptonite and can now fly. Or dynamite and can now dig. The “up-down” axis is the z-axis, but we need to choose which is positive and which negative. We’re used to measuring “height above sea level”, so let’s make height positive. That is, as you move upwards the z-coordinate increases.
So we have our coordinate system: standing naturally at the origin in the world, we have positive y in front of us, positive x is to the right, and positive z above.
So far so good. Now let’s put the camera in the scene. A common place to start with a camera is looking down on the scene. So we might have it hovering above our character looking at him/her. What can be a bit strange here is that when our character moves upwards (so their z-coordinate increases) then they are actually moving towards you. But this is because in the world coordinate system, they are moving upwards.
So long as you keep in mind the fact that the coordinate system is that of the world and not the observer, you won’t go wrong.
Okay, that’s a quick version. But hopefully you can see that I’ve addressed your misconception (viewer versus world) but in a positive way, so that if someone already has it right in their head then they won’t get confused by being told that the coordinates are “the other way to what you might think”.
@LoopSpace - OK, so you have explained the direction of the axes from the camera perspective, but there is one thing you didn’t explain. Using your explanation, one would expect z to be up, but y is up, meaning everything in your world is tipped on its side.
I’m sorry, but I find that no more intuitive. The obvious question is why on earth would you do that?
If it’s just because it fits the way it’s done in math or physics, then maybe we just have to accept it, but if you haven’t been taught that approach, it certainly isn’t intuitive, IMHO.
And I don’t accept that I have a misconception yet. I have read a lot of attempts to explain the use of the right hand rule, and none of them are particularly convincing. One says it’s because of the cross product, another quotes magnetic force direction, others say either handedness works fine, and right handed is simply the convention. I haven’t found your explanation anywhere, which doesn’t mean it’s not a good way of explaining things (until you go y-up, at least), but it seems to be retrofitted - I don’t think right handedness was chosen for anything related to camera views.
I’m not trying to be difficult, but I think it’s important to find intuitive explanations wherever possible, to make learning easier. So if you can explain y-up logically, that would help.
I think this a great tutorial and will help people a lot. I especially like the tab illustrating 3 problems with billboarding and the workarounds. It’s rare to see a tutorial that shows things going wrong, I think it’s a great idea.
One criticism I have is that you assume the audience is a complete beginner who is totally new to 3D. I understand why you’ve done this (and its impossible to write anything without assuming an audience), but I think the audience for this might be bigger than you assume. ie some readers might have a bit of experience in other coding languages, or using 3D in modelling software etc, but are still new to Codea, so still want to read the tutorial and will learn a lot from it. With that in mind, and this is maybe just a question of tone more than anything, you might want to think about making some of the language a bit more neutral, eg take out the parts that say such-and-such will be “too difficult for you to understand” or if you do this “you will learn nothing”. Assume that you don’t know who is reading or what their skill-set is. And I also think there’s no need to apologise for not being a “WOW” tutorial. I would avoid saying anything that’s a value judgement in fact. It’s kind of fun in a way to have these moments where you sound slightly strict, it’s like 3D bootcamp And all of us could probably benefit from bootcamp at some point. But on balance I think that a tutorial that ships with Codea (as opposed to one on a personal blog) should be slightly more impersonal in tone, even if that means making the language slightly bland.
One minor quibble, the bit where it says OpenGL doesn’t recognise as alpha as transparent pixels. It does, but it only blends through to whatever’s already been drawn into the draw buffer. That’s why changing the order of draw makes the transparency work as expected (and why transparency works in 2d). If you just say that OpenGL treats transparent pixels as filled, then the solution doesn’t make sense (ie the pixels would still appear filled regardless of the draw order).
Using your explanation, one would expect z to be up, but y is up, meaning everything in your world is tipped on its side.
No, z is up. You are standing on the x-y plane, looking north (ie along the y-axis). So z is up. And if you read carefully, my explanation is not trying to justify the axes, but to make them understandable. Right vs left is pure convention. What I’m trying to do is relate the coordinate system in OpenGL to something one is used to in real life. If you look at a map, you read the coordinates as (latitude,longitude), ie as (x,y), with positive y corresponding to north and positive x corresponding to east. Then if you add in elevation, that’s positive upwards. So the coordinates in OpenGL match “everyday coordinates” exactly.
@LoopSpace - I get that, and if we drew everything with z-up, it would make sense - but we draw all our objects with y-up. So you may have given a logical explanation for the arrangement of axes, but how do I explain why we draw the world on its side, with y up instead of z?
@yojimbo2000 - thanks for the comments, I’ll correct the transparency comment. I also take the point about beginners - in fact, this is squarely aimed at beginners, and the comments you have highlighted are prompted by my experience in dealing with beginners, who need a lot of encouragement. But I’ll tone it down so it has a broader appeal and doesn’t talk down too much.
Blender is z-up. But then, blender’s .obj exporter defaults to y-up. In OpenGL I guess if you omit the up value from the camera command it also defaults to y-up. But that’s very easy to override. In other words, I think of OpenGL’s y-up being a weak convention, rather than anything particularly innate. You can put your camera wherever you like, and point it at whatever you like.
I often end up making the world z-up (longitude and latitude are X and y). Then, if you implement an overhead camera, the camera will be y-up.
It’s nothing to do with being a mathematician. It’s all about perspective - who’s viewpoint are you using.
Always construct your scene thinking about “world coordinates”. Never lose sight of that. Then place your camera inside the world, but don’t make the mistake of shifting to “viewer coordinates”. That way, madness lies. Then no matter how you move around the world, you will be thinking of things in the right way because the world coordinates won’t change.
This isn’t maths, it’s basic orienteering. You don’t give coordinates based on your current position and orientation. You give coordinates based on some global standard. If I want to give you instructions on how to drive from, say, Birmingham to Sheffield then I won’t say “Go 50 miles in the direction I happen to be facing right now”, I’ll say “Go 50 miles north east” (and then turn onto the M1 and slow to a crawl due to all the road works …).
Take the Roller Coaster demo as an example. The coaster itself does not move. It stays still. The person moves and twists and turns. Sometimes the person’s “up” coincides with the world’s “up”, but most of the time it’s all twisted around. But I don’t need to keep track of it because most of the scene doesn’t care where the person is and is drawn in exactly the same place each time, relative to the world.
But I maintain the default OpenGL axis arrangement is STILL not intuitive.
Saying that it is created by adding z-up to 2D, and then turning everything on its side so y is up and z is reversed, doesn’t make much sense to me. Why didn’t they leave z up, in that case? (I know you can do it yourself if you choose, but why isn’t that the default)?
So my question is not how it was done, but why it was done that way.
It is what makes a newbie programmer want to change a value or two to see what happens. However, you are right that 3D has quite a steep learning curve.
