I’m wondering what I should cover next in the lessons. The longer-term plan I’m working to right now is to put together something a bit larger than my lessons have been so far; a complete scene demonstrating most of what I’ve covered, but also showing more about program structure. I’ll aim to build it while I write a few more lessons (because there’s more I want to put into it than I’ve tried to explain so far), and then do one large post working through the structure of the big demo.
I’ve started putting something together; it’s called Spacelike (for no reason other than that I felt like writing something called Spacelike) and you can check it out here (a warning — the sky texture is quite large and will take a while to load). The only control right now is that you can orbit the spacecraft by dragging, and zoom in and out with Page Up / Page Down. Here’s a quick video for those without a WebGL-enabled browser:
Working on this has led me to think of a bunch of different things that feel like they would be worth teaching, some of which are already used in the demo and some of which aren’t:
- The way cameras interact with lighting.
- Sky-spheres and -boxes — that is, background imagery that is always behind objects in the scene.
- Picking — the ability to handle the user clicking on an object in a scene.
- Shadows — objects casting shadows on other objects.
- Exporting meshes from Blender (like the spacecraft in the demo).
- Normal-mapping — like specular maps, but with the normals, allowing you to give the impression of much more complex surfaces.
- Reflections — shiny stuff.
- Particles — flames, smoke, explosions, etc, like in this Google demo.
- Heads-up displays.
What do you think? Do any of these sound particularly cool? Is there something else that I should be looking at?
Spacelike crashes both Safari and Firefox on Mac OS for me :(
Shadows would be very cool. I didn’t get the stencil buffer to work yet, so I wonder what technique you’ll be using :)
Picking is another nice topic.
Hi murphy — that’s a pain, I suspect it might be my use of insanely large textures… do you get anything at all displayed or does it just go down straight away?
I’ll put you down with a first-choice vote for shadows (I agree, they might be challenging right now, but still…) and a second choice for picking.
Picking and Shadows are the two most painful, and therefore most worthy. :)
I really like the idea of a bigger topic for the lessons. Showing people what they could do with what they’ve learned has to be a plus.
I’d agree picking and shadows are a challenge and a lesson on them would be really cool.
But, I would really like to see normal maps as personally I found them more challenging as you have to start thinking about tangent space to use them properly which personally I found very difficult to get my head round.
Why not add parallax mapping to the list, I’d love to see a lesson on that. For such a cheep and impressive technique I think it’s way under used. Although I’m a bit biased having just added it to GLGE;-)
The challenge of picking is that the drawn shape can be different from the initial data, so the Javascript side of things just about needs to replicate the pipeline to figure out what happened.
Another approach is to use picking shaders, one with a different colour per object (to find which object) and one with linear UV colouring for where the object was picked.
This will handle vertex transforms, and bump mapping can be handled by linear changes to the colour in the fragment shader.
I’m sure you already know this, I was just concerned that we may see a lesson based on ray intercepts to primitive shapes picking. :)
Been going back an forth with Chris Marrin. In order to promote reuse, we need to start using the XmlHttpWebRequest for downloading vertex/fragment shader code. Otherwise common code used in both vertex/fragment shaders will have to be cut and pasted into both shaders. The “src” attribute in the tag can’t handle shader code.
@steve — thanks for that, it wasn’t something I’d properly appreciated, so very timely! It makes a lot of sense. So, if I understand the process correctly, if we consider just being able to detect which object was picked and not where on the object the pick action was performed, we render the scene twice — once with the normal shaders to produce the image, and once with simplified shaders: no lighting, no textures, and only the pickable objects (which should leave us with a fragment shader that just does a static colour for everything). Each pickable object is a different colour, and we do this second rendering to a texture, so when the user performs a picking action we can just get the location, look up the colour of the pixel in the texture, and find out which object has been hit.
Is that roughly right? If so, perhaps I need to introduce render-to-texture first in a simpler form: perhaps a scene containing a mirror?
@jd — that’s a good point generally, I think for the larger-scale lesson I should look at moving the fragment shaders into separate files just like the meshes. Also, if I understand steve’s comment above correctly, then I guess you’re also saying that separating out the shaders like that will make it easier to do a render with different shaders for picking — is that right?
How about a lesson on collisions? That would be very helpful!
Sorry, I was off topic with my comment. Just wanted to make it clear that keeping all shader code within tags hampers reuse of code that can be leveraged in both vertex and fragment shaders.
Yes, shader code should be in separate files like the meshes. Then what we’re calling and can be ‘linked’ with other shader files (after being fetched with XmlHttpRequest) containing code that is common to both fragment and vertex shaders.
In a nutshell, all shader code should be kept in separated files, downloaded with XmlHttpReqeust, and then linked within the page.
This isn’t a big deal right now with simple shaders. But as shaders get more complex, reuse is going to be a bigger issue.
something filtered out text in my posting …
what were calling id=”shader-fs” and id=”shader-vs” can be “linked” …
@rodolfo — that’s a good idea; once I’ve done picking and shadows, I might be able to re-use the ideas from them for that.
@jd — ah, thanks. Makes sense.
Some News about stencil Buffers? (My tries fails)
Nice idea! I’ll have to learn about them…
Demo seems to fail, but the video looks excellent. I would LOVE to see a further explanation on this demo. Specifically, I am interested in handling camera movement. I have a 3D scatter plot from DB data. Performance is awful because of the amount of data shown. It also has problems with selecting elements for more information. I have come to discover this is because I am rotating the model, instead of the camera around the model so the specific elements are in a different vector when I try to select one.
So I am interested in camera movement, and details about this awesome demo you put together. :)
Picking is another interesting topic. All my efforts have been with O3D, but everything I have learned here applies to that. The picking element is extremely slow though, as it takes 4-5 seconds if you have a significant amount of objects rendered. There has to be a more optimal approach than traversing the entire tree. I would like to see your approach to picking as well.
Love this site!
Hi Nathan — many thanks for the heads up on Spacelike, I’d forgotten to upgrade it to the latest WebGL API! It should work fine now.
Since I did this post, I’ve started on a new lesson to introduce render-to-texture — an interesting topic in itself, but more interesting because it’s the underlying technique beneath doing GPU picking — which enables you to handle picking at the same speed as repainting. It’s been languishing for a while because I’ve been very busy in my day job, but hopefully when it’s done it’ll be of use to you.
They are all extremely useful. Thanks for all the insight you bring.