After some testing and hard work I figured out how to generate some decent landscapes, using quite simple methods and maintaing speed. After a tip from Fall_X I decided to use PerlinNoise to generate a GreyScale image that is used for generating the landscape. A dark pixel (black) means the landscape is high, and light (white) means low landscape.
I'm showing the PerlinNoise proces on the left, so you can see what's happening. Once it has processed half of the displayed Bitmap, it moves the Bitmap up and attaches new PerlinNoise to the bottom. Then it Blurs the center, to create a decent transition between the two (not always perfect though). This process happens infinetly, which thus enables infinite scrolling.
ps: I'm still ading a small random value to the value that get's generated from the PerlinNoise Bitmap. Just in case you wonder why it's a bit off sometimes.
Would appreciate some feedback.
Edit:
I've finaly fixed a way to achieve Backface Culling (ok, not realy, but it looks like I'm doing it ) Read the posts below if you're interested. I've added a new file called Backface.zip for your to see.
Not sure if I'm out in left field, but I can't see anything... just a solid black screen
"If I have seen further it is by standing on the shoulders of giants." Isaac Newton
------------------------------------------------------------------------------
For those who can't see it; you will need the newest Flashplayer. If the Adobe site is telling you you already have it, you might want to reinstall the player.
About Backface Culling. I've had a conversation with Tom (Random####) about the engine today, and he aswell suggested Backface Culling. The concept seems very interesting, and it'd be great if I could implement it. However, I'm afraid Flash won't realy be able to handle this. And I can't find any decent artilces regarding Backface Culling or something of the like.
I also tried filling the tiles sepperatly (using beginFill), but this aswell asks too much from Flash. So that'd require me to decrease the mapsize
i take it this thing just draws lines to different points, thats the slowest graphical operation in flash i think. What if you don't draw the points but just fill the graphics in, would that work better?
However, I'm afraid Flash won't realy be able to handle this. And I can't find any decent artilces regarding Backface Culling or something of the like.
It might speed it up a little because some polygons won't have to be drawn.
I think the basic concept is this : if the normal of the polygon is facing is facing away from you (I think this can be done with the dot product of the normal and the view vector), you don't draw the polygon. But since your perspective doesn't change, you could probably calculate this once, when generating the polygon in memory. And if it doesn't face the viewport, just remove the polygon or something. However, I'm not sure about the actual calculations to do all this - I have very very little 3d math skills.
Do you know how much polygons are on the screen? You do not really need backface culling, but your polygons are ordered front-to-back or back-to-front thats not the question.
So just think about which polygons we do not see? The ones that are in the back behind some higher polygons. You can work with a line-of-sight. Just shoot a ray to your new polygon and if it hits any other, it wont be visible cause it is behind some higher polygon or it has to be split up.
this would be very interesting;
i'm thinking you kinna draw each slice frame by frame. maybe you could draw each column using a gradient fill and use the colors/ratios to set a color for each horizontal piece.
this would in effect make flash do all the work for each slice within a column. all you would need to do in as is deal with the columns.
Graphics Attract, Motion Engages, Gameplay Addicts
XP Pro | P4 2.8Ghz | 2Gb | 80Gb,40Gb | 128Mb DDR ATI Radeon 9800 Pro
Malee,
I've not yet tested this. But doing it this way, will require me to use different shades for the tiles. Which will also require quite some calculations to get that done.
Fall_X,
I don't realy think it will speed up. Plus that your method doesn't quite work as you might expect. Because with 3D, things that are rotated away from you and thus aren't visible might become visible when they're closer. Just try it with a book, rotate it away, and bring it closer.
Joa,
That would leave your method, and it seems as the one with the post potential. However, this method will require me to 'draw the line' for EVERY point EVERY frame. For the same reason as above, something that's not visible might become it later on, and vice versa. Let's just say i can figure this out, every frame, with decent speeds by reducing mapsize and increasing tilesize. Once I've figured out that a point is invisible a point next to it could be visible. This point will still need to be drawn towards to the invisible point, but how far? This will, I think, require quite complex calculation that Flash won't like to do every frame.
Blink,
I didn't quite inderstand your method. Could you explain it a little further plz?
Edit,
Ok, I did figure out the most simple way to get this done, but I still find it way to slow to use this for a game or something, and it's proberbly quite a lame method Update soon.
Fall_X,
I don't realy think it will speed up. Plus that your method doesn't quite work as you might expect. Because with 3D, things that are rotated away from you and thus aren't visible might become visible when they're closer. Just try it with a book, rotate it away, and bring it closer.
Okay, you're right (duh) - you wouldn't be able to pre-calculate the dot products, but you could pre-calculate the normals. So all you'd need to do before drawing a polygon is calculate the dot product, and depending on that value, you either draw the polygon or not. I don't think that would make your engine any slower (at least not noticeable).
Still not sure if I'm folowing you here... Could you explain it a little more?
The method I thought of does seem to work properly though. I'm currently just filling tiles over tiles and lines behind it, so that everything that lays higher, will automaticly fill over lower tiles. And to make sure perspective won't screw things up, I'm filling the tiles from the sides towads the center, and from top to bottm (depth to near). Hope that makes sence. The process looks kinda like this (topview): \/
I've uploaded the file in my first post. As you can see, it's realy darned slow. So I'm afraid it's still not useable in games. Oh well, it's still fun to watch
Still not sure if I'm folowing you here... Could you explain it a little more?
What I was describing was a method for backface culling, not hidden-face removal (is that a term? lol). It means you don't render polygons that are not facing the camera. But now that I think about it, it would still make your untextured version show polygons when parts overlap though (as I said, I'm not an adept at 3d programming at all so I confuse these things sometimes).
But texturing the polygons in the right order seems to solve it (if you ever implemented rotation, you'll have to z-sort first though). Have you considered trying to actually texture-map your polygons? You could try porting the DistortImage class (http://sandy.media-box.net/blog/dist...ionscript.html) for this. It would probably mean you'd have to reduce the number of polygons drastically, but the added realism of the textures might just make of for that.
Also, i dont know if it migth help,but some time ago i made my own backface culling
Its based in the first three points, like senocular's one
Its in AS2, and i dont know if its faster them sen's one,i think it can be optimazed, but just in case, here it is:
Nothing, that's basically what I was describing, but backface culling isn't enough. It won't solve the problem when two polygon that both face the right way overlap eachother. Now, if you're texturing it (or filling with a color), then a simple depth sort should solve it. If you're using wireframes (like the first version of this), it won't.
You do not draw a ray and you do not draw points. We are talking about polygons. And I am quiet sure that Flash is able to handle a little bit more not-that-complex math. Especially AS3. You should try it. Or draw from front-to-back with some textures and every pixel that has been set should not be overwritten. So you've got some sort of z-buffer.
Just two engines written in AS3.
Voxel:
Simple voxel engine based on some tutorial but it uses a 3MB *.raw terrain file for the heightmap (could convert this to jpg) and creates a colormap. Also bilinear-interpolation is used for the height data. Still some bug in one of the degrees-of-freedom. But the terrain is 1024x1024 uints large and can be deformed in realtime(!).
Perspective texture mapping:
Engine with correct mapped textures loading *.3ds data. Alpha-blending in textures possible. Poly-to-poly clipping etc. implemented. Also bsp-trees (you may know this from quake, flash can also handle it) and some types of buffer techniques. In fact it is not as fast as Andre wished it because the poly-to-poly clipping can turn into a lot of polygons on complex maps wich results in 2^n blabla iterations.
And why to I write all that stuff? Because you just can say what is possible and what not if you tryed it out. I have to say, I think it could be possible without having to decrease the terrain. But you have a field of view, and a far z-plane etc. Just look at the voxel map. it is 1024x1024 px BitmapData and runs very smooth. Technique and optimization is the key.