This blog’s been a bit silent the past couple of weeks, but I haven’t been idling at all - quite the opposite. Even with fresh copies of Dead Space, Fable 2 and Fallout 3 laying too near for comfort, most of my free time has been taken up by Wick3d (1 | 2). Recent developments in Papervision3D and Away3D (the choices for commercial-grade Flash 3D) only made me more excited to do some extra studying and experimentation. Just to clear things out now - there won’t be any demos in this post, but I will mention what I’ve been working on, and hope to merge with the Wick3d repository sooner than later

• Lighting/Shaders: The old Wick3d (before I started over, that is) had some basic support already, but shading is going to make an improved reentrance.
• Correct Z-Sorting: a tricky one. Since a stencil (z-)buffer isn’t an option in Flash, the only way I know how to sort triangles correctly is the Newell-Newell-Sancha algorithm (an extension to the simple painter’s algorithm). However, since it’s an O(n²) algorithm it can slow down to a crawl rapidly with enough triangles. Organizing the triangles in a quadtree (similar to PV3D’s latest addition) could improve performance, but still - per quad - there’s the n² issue. I’m sure there’s better ways to solve this problem and I’ll keep up the research. Any tips on this subject would be most welcome, of course
• Working with the BSPRenderPipeline has been reworked and now supports dynamic objects moving about in the BSP tree (this one’s actually done, but not comitted to the trunk yet - check out the dev branch if you’re feeling brave :) ). Create a BSPWorld3D instead of a World3D, passing the static base to the constructor, and add dynamic children with addChildren as usual. A demo with source will follow soon, with some luck.
• Redone Collada support. It’s still very basic, no hierarchy, but parsing is much faster. It will be improved whenever needed. Parsing files is not my preferred pass-time, so I tend to keep it at this point until I personally need more support.
• Restructuring of certain parts of the engine. For example, Rasterizers are now classes on their own, so different types can be used in any render pipeline.
• Various optimizations and trivial updates.
• Thinking about FP10 and how I could harness the power of drawTriangles when dealing with (virtually) a polygon soup. I guess you’d still be drawing every triangle separately without sharing the vertices.

Heh, at least I’m not slacking off! It might take a while before these updates are comitted to the main trunk, so I thought I’d give this rundown of things to come - hopefully! Any brilliant insights? Let me know

When Alternativa3D showed some demos with their parallax mapping, I always thought it’d be interesting to try it myself without having to resort to PixelBender.

Well, I did, and I wasn’t happy how some things turned out. There was no overlap of objects, and sharp edges would come out looking odd or distorted. Then, taking another look at their demo, I noticed they conveniently used slanted or smooth edges all the time without any possible overlap.

Reading up on some stuff, I decided to make the process iteratable, and liked it much better already. There are some downsides… Most importantly, it’s a cpu-killer and still pretty flawed compared to the real thing (which is a pixel shader). Nonetheless, it was fun to figure out and code, and that’s pretty much the reason why I decided to post it

Oh, and I also rewrote the Bump Map from some time ago, since I needed it to make this demo a bit cooler overall. The code back then was a quick experiment; not exactly a beauty nor reusable whatsoever, which has been taken care of to some extent. Additionally, the lightmaps now support colours and you could just as well write your own.

Check out the demo here and the source here. The images used came from here.

After some developments in Papervision3D and Alternativa3D, I decided to try to tackle BSP sorting myself (yeah yeah, months after everyone else did :p). It gets rid of those typical annoying z-sorting anomalies, and allows for intersecting objects to be rendered flawlessly. However, due to the cpu-intensity of building the initial bsp tree, it can only be applied on static scenes. I haven’t yet built in support for movable or animated objects inside the 3D world. The current implementation will probably change a lot, but as this is mainly a self-study project, it’ll do for now

Check out the demo, and check the source. The cubes are generated randomly, so performance may vary from time to time, due to the BSP tree. But note how, even tho intersecting, all triangles are rendered in the correct order. And please, forgive the uglyness of the demo. The Wick3d source can still be found on Google Code.

The past few weeks have also seen some bugfixes (the matrix invert function was warped causing the camera to behave oddly) and some refactors. And more importantly, there now is a DisplayObjectMaterial which is interactive. It’s probably very buggy tho, I haven’t had time to test it thoroughly, and it’s not one of my favourite aspects of a 3D engine (creating it, that is, I love using it ).

Finally, I recently got back from Flash on the Beach ‘08 (thanks to Nascom for sending us). Because Sakri already wrote a pretty accurate article on the time we had there, just check out his post at the Nascom blog. We had a great time, and some good opportunities to chat and have beers with some flash heroes and like-minded people. Needless to say, I came home stoked and full of inspiration!

I’ve been thinking of changing my previous Pixel Bender water filter to an AS3-only version for some time (since FP10 is still in beta), but never got around to it. Until trusty old Nascom told me we might perhaps use it in a project. So here it is, added to the NascomASLib and ready for you to use I added some functionality so the appearance of the ripples can be altered. Overall, I’m quite happy with the performance, especially since it runs smoother with bigger ripples (and usually looks better too ).

So enjoy the demo, and check the source here.

After a couple months of work, Nascom’s latest big project for Sony Vaio was able to go live, celebrating Vaio’s 10th anniversary. To read all the grubby details about it, you can check the full blog post at Nascom.

It was a blast working on this project, mainly because it gave me a chance to solve some interesting math-related problems, which tapped right into my main interests as a programmer. Especially custom collision detection paired wall sliding in a game-like manner, and optimising paths generated by an A* algorithm. As A* is tile-based, I needed to remove superfluous nodes by checking intersections between extreme nodes with the map and iterate backwards from there to create a shorter and more natural path. Good times!

Cheers to all people involved at Nascom, as well as to Ralph, who helped us a lot with some invaluable input on do’s and don’ts of papervision, performance tweaks, …, to be able to get most out of it. So cheers, man

To close up, just take a peek and a poke here: http://club.vaio.sony.co.uk/clubvaio/gb/en/vaio10/ . Enjoy!

Time for another simple oldschool demo effect as an excuse to mess around with Pixel Bender So just like before, you need Player 10 if you’re interested in seeing the result. I only provided the swf this time, so if you don’t have it yet, grab the standalone player here and check the preview. Holding on to good habits, I also provided the source for the Pixel Bender kernel.

I swear, one of these days I’ll come up with something more meaningful!

Well, I suppose it couldn’t wait much longer… I just had to get my hands on Pixel Bender and do some tryouts. Initially, I set out to make a simple Mandelbrot set, which was pretty darn speedy in the Toolkit. However, once I turned on the Flash error checks, a few disappointments smacked me in the face. When used with Flash, it doesn’t support loops! Furthermore, it seems you can’t make images from scratch without involving a source sample as your output pixel (I’m not too sure about this, tho, I still have some research to do). So far for the Mandelbrot, coz I’d need both.

But, I quickly accepted those limitations, and started doing an old demo-effect instead; water ripples! It’s a fairly simple algorithm using a displacement map. The map image (the actual ripples) is rendered by Pixel Bender, based on the previous two iterations of the ripple algorithm. I was very excited to see how fast the result was. I can’t wait to be able to use PB for ‘real world’ projects once Flash Player 10 is released and settled in. Anyway, if you have Flash Player 10 installed as a browser plug-in, check out the demo here (you know, right-click views source, including the pixel bender src). If you don’t, but have a stand-alone player, get the demo here, and the source view here.

Bump mapping in AS3 has been done a couple of times before already, but I thought it would be cool to try out the effect with a seperate bump map for diffuse and specular lighting (with only slightly different logic for each ‘layer’, and that is how the light maps are calculated). It’s great to create wet surfaces or waterdrop effects.

Well, there’s not much more to say about it, it’s a rather old topic anyway Enjoy the demo, and the source can be viewed by right-clicking, or here.

EDIT: I adapted the code a bit to fix the white pixels appearing

The past week, I’ve mainly spent trying to figure out how to do (fake) Phong shading and environment mapping. In the case of phong, the result can be seen here. A few alternatives that I tried didn’t work out, but after some quick hints from Ralph and lots of calculations, I found a solution that more or less works (at least for me ). Weirdly enough, most of my time went into figuring out how not to show the lighting on the opposite side of the lit object (it’s a normal effect since this shading technique borrows from environment mapping). As you might notice, it’s still not quite right…

In the demo, you can see more or less the same cube and sphere from the Gouraud post. The uv-mapping is still off on the seem where the two horizontal ends of the texture (should) connect, but at least now I know why The texture “wraps back” because the U-coordinates are on opposite sides of the texture. I’ll have to figure out how to fix it… If it looks like a familiar problem, any suggestions are welcome

Next task: heavy duty optimization and refactoring! Good times

Since some time, I’ve been working (off and on, and more off than on) on a rudimentary 3D engine in ActionScript 3, code name Wick3d (hah, I know, rediculous!). Not to become the next Papervision, since there are plenty of engines doing a much better job (just check Papervision, Away3D, Sandy or Alternativa3D and keep a tissue close in case of droolage). Anyway, I’m just interested in 3D algebra and whenever I see something cool, I want to know how it works, and if it results in stuff like this, I’m having tons of fun as well

It’s surprisingly easy to get messy code while adding functionalities, so I had to start from scratch a couple of times. I also had to throw out some work such as coloured light sources, which were killing cpu when used with textures, and to be honest, no one really wants to use untextured objects so I might as well streamline it to be the same for all types of surfaces. This weekend, I reworked the lighting calculations according to Lambert’s cosine law for diffuse lighting and added support for specular highlights. Finally, I also added a Gouraud shader (I have to admit I had a grin on my face when it finally worked). Basically, it’s using a linear gradient image map and defining uv-coordinates on it based on the lighting per vertex normal. After that, it’s drawn the same as any affine texture map.

The code is not public (yet), coz it really needs a lot of cleaning up, and well… It can’t do much right now (apart from creating cubes and spheres). Of course, if there’s people who want to look at it out of interest, I can always clean up the mess I made in there and put it online.

Check the demo if you want, as you can see the frame rate isn’t all that high And apart from that, something is wrong with my UV-mapping. I’m not sure if it’s an error in the texture mapping or the calculations for the spherical coordinates (I suspect the latter…).