First Person 3D Engine
October 3rd, 2007
Wow, it’s been an amazing last couple of days with the announcement of Astro and all the hype around the new 3D API and the pixel shader language Hydra as well as some of the sneak peaks shown at Max. The community is in a rampant frenzy as speculation and confusion runs wild. Hardware acceleration, C++ getting translated into ActionScript, and Flash running Quake! It’s no wonder people are freaking out.
At any rate I figure now is a perfect time to make a little announcement of my own. Actually I confess, I already decided a few days ago was the perfect time when I posted this to the Papervision3D mailing list and John Grden is probably showing this right about now at Max. Never the less I decided this was worth a blog post.
I’ve been working on a Papervision3D based first person 3D engine. Below are a couple of screen captures from two different examples of the engine.
Before you get too excited and run off to see the demos there are a few disclaimers that need to be expressed. First, you need a fast computer. I’m sorry, that’s just the way it is. Second, I haven’t implemented proper pre-loading so you’ll need to be patient and wait for all the imagery to load. Last, these demos are still a little rough around the edges.
Now for the controls…
Mouse click and move – look around
e – walk forward
d – backward
s – strafe left
f – strafe right
And the moment you’ve all been waiting for…
Thoughts are welcome and appreciated.
Updated Fire Sphere with Source
July 6th, 2007
There have been a few requests for the the source to the Fire Sphere demo I posted forever ago. I’ve finally gotten around to cleaning up the code and getting it to work with the latest rev of PV3D.
The material applied to the sphere is created using a static PNG with a DisplacementMapFilter applied to it. The DisplacementMapFilter uses a BitmapData object that has had perlin noise applied to it to give the flame effect. A lot of other effects can be created this way as well. Things like rippling water or clouds. It’s just a matter of changing the original image and tweaking the settings of the filter and the noise.
You can get the source here. It’s really quite simple. The whole thing is under 200 lines of code.
A* 3D – No, really, it’s 3D
July 3rd, 2007
There seemed to be a little disappointment that my A* demo wasn’t actually searching in 3D. Maybe I should have called it A* visualized in 3D. At any rate I’ve revamped things and now have a demo that does search in 3D.
It wasn’t much of a stretch to get things working in the third dimension. The only thing I found particularly tricky was making sure that the path didn’t cut through a solid corner — move diagonally adjacent to a non-walkable node. Besides that everything was pretty straight forward. I also took the time to make sure the code was clean and at least somewhat documented. I haven’t bothered to try to do any optimization and I certainly haven’t put much time into splitting the functionality into proper objects. Nonetheless, here’s the source.
Note that you’ll need to add to your class path Away3D as well as Zeh Fernando’s Tweener w/ Bezier support which powers the animation in 3D.
July 2nd, 2007
Path finding is hardly a new topic for the Flash community. For me however, it’s an area unexplored. While I’ve always found the topic interesting and enjoyed the demonstrations out there in the wild my direction has just simply never really taken me there. Instead I was probably reading about some agile development process or something nice ‘n’ dry like that. Anyway, as I’m now delving deeper into 3D and game development topics I’ve started experimenting with path finding. It’s quite fun and not really all that complicated. At least at the elementary stage that I’m at.
I’ve been working with the A* algorithm which uses heuristics to find the most optimal path from a start node to a destination node within a node graph. The algorithm has many uses, especially in game programming.
In my exploration I’ve combined the A* algorithm with Away3D to illustrate how an object could travel through a 3D environment based on a found path.
It doesn’t always find the best path. Probably something simple I overlooked. I actually find that this could be used as an advantage however. For instance, if this was a character in a game the less optimal path can represent a poor choice by the character giving it a bit of added realism. A thought anyway.