Sign in to follow this  
Sylon

Unity 2d images given precise 3d behavior?

Recommended Posts

Okay I'm back and this time with a new question about what someone suggested for me. Summary: I want to make a 2d *isometric* RPG with SNES-style art, but with the sprites and objects able to have pixel-precise collisions in 3D (not tile-based). So they can jump and walk over rounded hills and stuff. And pixel-precise shadows that bend around objects just like in 3d. (I'm no programmer, which is why I'm asking if it is possible to code this kind of game). Here is the previous topic. I also want my game to be rotatable every 90 degrees (not 360 like real 3d games). But this means we can see all around the objects (of course I must design all 4 sides to every object). Here's an example pic of a shadow bending on a 2d object: Using the above image as well, an example of a 3d pixel-precise collision in 2d would mean that, say there was a 2x2x2 cubic object, and a 40x40x40 cubic object. The big object would not be able to crawl under the short stubby branch that protrudes from the trunk, but the little object will. And when it does, the shadow of that stubby branch will pass overhead! Someone told me a voxel engine would be too taxing on computers. Then a friend told me about height maps. He said I could make grayscale maps for every object/tile in my game that told the comp how high the object is. Since I want my game to be just like 3d (and we can rotate to see behind objects), I figured just height might not do it because a 2d image can only show the front of an object, not the back. So I'm thinking RGB values to signify to the computer x, y, and z, width, depth, and height values. Here is a pic of my idea: The blue values signify height (z), the red signifies x, and the green signifies y. I gave their values in increments of 15 (15,30--225). The first multi-colored diamond (upper left) is a tile of the flattest height (so blue value=15 for everything), and at the very left is red=15, green=225. At the very right is red=225, green=15. At the bottom is red=225, green=225 and the top is red=15, green=15. Then in the upper right we introduce an object with height. A simple cube-like box. Now, the blue values are being changed, so we can see the height of the object. At the top of the cube, all blue values are 120. This way the comp knows at what x,y,z position each pixel is at. Now the hard part is if I wanted a crevice in the cube. Because if that crevice were facing the other way so we couldn't see it, and an object were to crawl into that crevice from behind, but we only gave RGB values for the *front* of the cube, the computer must somehow be told there is a crevice that the small object can crawl into. So I drew a cube with a little crevice. To tell the computer there is a hole inside that cube, I figure the only way to do it is to (in the bottom right of the image) make slices of that object, and then the computer must compile the slices together, to form the complete 3d object. So if I make my 2d art and apply these kinds of RGB gradient masks for each slice of every object, for every frame of every animation, etc, do any of you think that would be able to allow the 2d art to mimic 3d behavior? In other words would there be any way that code could take these images and compile the slices, mask the REAL artwork images with it all, and make 3d collisions/shadows work? (Not 360 degree rotations or zooming in and out though). And if yes, would this be just as taxing as voxel usage? I'm expecting to take decades here, if this works. I want to steer clear of using polygons for my game hehe! [Edited by - Sylon on November 6, 2006 2:45:56 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
sounds like you're trying for "Voxels"(look that up)

but if the camera is limited to fixed ortho positions... you can probably save a lot of work
maybe have a separate Voxel representation for collision detection from the actual sprite graphics?

Also, Voxel (or as you call it pixel-prices collisions in 3d) is kinda... overkill
you sure you can't just get away with having bounding box collisions, just make the boxes smaller than the tiles for added detail?

Share this post


Link to post
Share on other sites
Hi guys!

Ultimape--

Does that mean you think the method will can work, only that it would take a lot of work to complete? And do you mean it would take the programmers a lot of work, or the artists, or both? Because if it's just the artist, I'm more than willing to do all that work LOL!

Anon--

Yes the camera in my game would be in a fixed ortho position and I was considering making a voxel mask to represent the collisions of each 2d image but someone told me, like you, that they're "overkill," anyway. So do you think this RGB method is "just as overkill" as using voxels anyway? Because if I could use voxels to make the masks I would be happier!

I read somewhere that voxels are better than polygons for a few reasons, but that polygons are majorly supported by 3d graphics cards and whatnot, while voxels aren't, which is why voxels tax the computers.

Anon, I was also thinking of using bounding box collisions, smaller than tiles, and cylindrical/spherical bounding "boxes" (though I heard they are harder to code), but then this would mean to toss out any irregular shapes...If it's a last resort I could consider it--but I want to learn my options.

My goal here is to figure out primarily, if my theory is valid. 1. Can a game be made like this? And if so, 2. Would it require too much computer power? And 3. Would the programmers have to do too much extra work? Or just the artist?

Also, I've thought about using voxel models themselves as the artwork, and I think that idea is also out (it would be too complicated to explain why unless someone wanted to know, but it has to do with aesthetics).

[Edited by - Sylon on November 6, 2006 7:06:31 PM]

Share this post


Link to post
Share on other sites
I think you need to ask yourself if its really necessary to have these features, because in the way you want them, it's near impossible to build.

A: pixel perfect collision detection.
In itself this is possible.
However, as soon as you add an isometric world, especially with the impression of height, pixel perfect collision detection becomes very, very difficult.

Example: Imagine two characters, one on top of a hill, the other at the bottom. For the moment I'm going to dismiss the problem how you would translate these characters as that is a whole problem itself, but they each start walking to each other. At one point there is a collision as they meet (head collides with feet). Obviously there is no collision, but in a 2d game you can't calculate that, unless you change the pixelperfect collision to only one or two points of collision (In this example they both would be at their feet), its never going to work.

Example two A: Imagine a tree. Character A is standing a bit above it, and is going to walk towards it. At some point the top of the tree is colliding with the character. In reality there actually is no collision. Again collision should only be detected at the base of the tree and at the characters feet.

Example two B: Imagine that same tree now with a branch hanging over a road. Character A is small enough to walk under the branch, but Character B isn't. Again at some point both characters collide with the branch. Your point of collision now has to be based near the head area. (Explaining that you can't rely on one point either.)

B: Shadows.
Shadows in 2d games works fairly well up to a point. There are several ways, but I found that adding the shadows to the images themselves gives you the best result.
Here's an example image I used in a different question earlier on another forum (best seen in FF as IE kills the transparency effect)


If other characters walk over the shadow or if this character walks near other objects, they'll automatically receive that shadow too.
Of course this methode doesn't mimic real shadows as they don't really react to the environment, but in most cases it probably comes as close to it as you want it to be.
Mind you that its a very time consuming process. Creating an entire animation for this character (not talking about actually creating the animation in Lightwave, but rendering it and processing the renders in PhotoShop, took about an hour per animation cycle)

Anyway, I hope this helps a bit.

Share this post


Link to post
Share on other sites
Hi Traveler! Thanks for joining in.

About the pixel-precise collisions. Yes, I've thought about this through and through for an isometric 2d game. Once again I don't know code or coding languages but I have a vague idea of game mechanics. I assumed the kind of trouble you're pointing out here was already tackled but I'm just a little too hasty. I realized how tough it must be to code.

There is a game called "Head over Heels", a remake of a classic, made by a team called retrospec http://retrospec.sgn.net and if you download that game you'll see that the single programmer was able to calculate 2d isometric collisions in 3d space. The characters can jump all around each other and objects. If there was a tree (there isn't though), the character would collide with the trunk of the tree, not as his sprite touched the tree sprite (leaves or branches or whatever). The thing with HOH is that the objects all have cubic bounding boxes--the boxes were pixel-precise but...how I'd say, I guess...the boxes weren't true to the form of the 2d image. So yes as you've said, it's possible, and you're right I bet it's difficult but I've seen pixel-precise collisions work with cubic bounding boxes so I'm spoiled. I'm wondering if there's a way to take it to the next level--pixel-precise bounding "boxes" that conform to the 2d image how we'd like it to, instead of just cubic or simple cylindrical bounding boxes.

About the translations of the sprite, wouldn't it just be a sprite offset function? I know in HOH height was apparent. The problem was that nothing was sloped, just all cubic blocks the characters would stand on/jump on. I'm gunning for slopes in my objects.

About the shadows. In HOH as well, there were precise shadows coded. The problem was that they bent only around the cubic collision boxes of objects, but they fell and rose in height accordingly in 3d space. The shadows were transparent images that followed the character and were offset in position when they hovered over an object with a different height.

So I was thinking that say, if a single pixel of a shadow image collides with a pixel with RGB values assigned to it, that pixel of the shadow would be offset, just like in HOH. So blue values signify height. If a shade pixel was on a pixel with a blue value of 15, then the object moved over a pixel with a blue value of 120, the shade pixel under that object would be "told" to offset by however many pixels upwards. This way it would "jump" from a low height to a higher height instantly.

Besides the fact that this all is difficult to code, is any of it impossible to code (because I don't know)?

Share this post


Link to post
Share on other sites
Let's look further about collisions in the RGB model.



Remember I arbitrarily chose increments of 15 for the RGB value differences between each pixel.

In the bottom left, there is an arrow symbolizing a sprite moving towards the cube. As soon as the sprite's own bounding box collides with the pixels that have a blue value of 30, it should stop moving. In other words he is traveling on pixels with blue value=15. So anytime he comes into contact with a pixel of a greater blue value than the one he is currently on, he *should* stop.

Another example. On the top of the cube the blue values are 120. Let's say the sprite follows the arrow direction towards the cliff edge (along the x [red] dimension). All of its green values will be the same as it follows the arrow, but as it moves, its red values will change. At the cliff edge, the red value is 180. As the sprite continues moving past that, the NEXT red value in sequence is 195, which is down below. Those pixels with red values of 195 have a blue value of 15. The sprite moving along that x dimension would collide with pixels that have a change in their blue value (from 120 to 105), and since the next pixel in red's sequence (195) is down below with a blue value of 15, that is where the sprite should fall. Calculating gravity would be another issue I suppose.

Seriously to me this sounds like it means much less work for coders and more for artists, as long as it works. I hope.

I've been looking for someone to verify to me that this is a valid theory but, I guess, maybe I should look for someone who'd like to test it? Maybe all it needs is some testing?

[Edited by - Sylon on November 7, 2006 11:53:54 AM]

Share this post


Link to post
Share on other sites
To be honest I dont think computations on such a scale are really feasible. Usually a (multi)dimentional array is used to calculate where your character may or may not go. This array represents the playarea.


In the picture I've an array where some parts (tiles) are filled already. Each position can hold a number of values. In this case, I have an ID to a texture as well as collision information. (The red area marks collision information.)
I've used rather large tiles here, but it is possible to decrease the size of course, to match smaller objects better.

The cool thing about this is that you can very easily change this information. You can build an editor around it and have a leveldesigner do his thing. I'm not really sure how you would edit maps using your method.

Share this post


Link to post
Share on other sites
Honestly it doesn't look impossible, just fairly difficult (especially for someone who doesn't know any programming languages).


The colored blocks you're posting images of are voxels. If you want to do slopes (not just different heights) then it's either voxels or 3D texture mapping. If you're ruling out voxels, then you'll probably just do linear texture mapping. At that point, it'd probably be easier to just switch to 3D and maybe constrain the camera angle.

Collisions will be a programmatic pain in the ass. First of all, I'd be very careful in your map design. The example given about the tree can be avoided if you make sure there are no hills as tall as trees directly beside trees. Your example about the crevice is very difficult. 3D programmers have long sought after an easy way to do overhangs with collision detection, and you're wanting to do it isometrically. I would personally make the crevice tile a special case tile that actually has three tiles: one for the top of the tile, one for the roof of the crevice, and one for the floor of the crevice.

This post has gotten me thinking about a very special (and very computationally expensive) kind of isometric engine; a voxel isometric engine. Basically it would be layer upon layer of tile. You could effectively dig down through the ground that way, unearthing new tile layers. Might be sweet!

Anyway, what I'd like to know is: is someone going to code this for you? Because that person should be intricately involved in the design of the game. Artists sometimes don't realize the complexities of programming things like this

Share this post


Link to post
Share on other sites
Traveler--

Yeah I've played iso games with that kind of design. Well, I guess, if I was to edit maps with "my method", it would simply be that there would be a bottom layer in each room, of just flat tiles. Above them would be cubic dirt or rock objects which you stack on top of each other to make hills and mountains, and at the top of those stacks are objects shaped like lumps (for hills), or stones, grassy tiles, etc.. And within each stackable object will be these invisible RGB masks that tell the computer what their xyz dimensions are.

The computer will draw the objects from back to front, and apply the offsets.

That's my idea anyway, I guess!

Funky--

You mean the individual pixels in the multicolored dioramas are exactly how voxels are made? Voxels use RGB representations for space?

I guess the bottom line would be that, with the crevice example and all, it would be as if every single pixel in the game was its own "tile", that gets drawn from back to front within the larger tile that it's in (say a 32x32 tile). The 32x32 tile would be the one that the level designers place in the game. I can't seem to get around thinking the RGB values should be enough to tell the sprites what is happening and where they should jump to (offset in height) or stop. Maybe I just need to learn to code.

What would be the most efficient way of learning what I need to for me to study this theory? Should I learn an ENTIRE programming language or just parts of it?

Funky I was planning on doing all the art first for a few decades and then finding some programmers to help me.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Sylon
You mean the individual pixels in the multicolored dioramas are exactly how voxels are made? Voxels use RGB representations for space?


No.
Voxels are a Concept, there are as many different ways of Implementing them as there are different programmers.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
No.
Voxels are a Concept, there are as many different ways of Implementing them as there are different programmers.


Oh okay cool!

Share this post


Link to post
Share on other sites
Sylon,

I responded to your PM. These are my thoughts (assuming I have your goal correct):

First, and foremost, any solution we can come up with will most likely be too slow to be of any good. While 3D pixel-perfect collision is very nice to have, it's just that... a nice-to-have.

However, for the sake of learning and problem-solving, let's assume that processor speed and memory is not an issue.

What you want is for every object you have, associate a 3-dimensional array of bits which will represent what the object looks like in a 3D world. A 3D mask if you will. Every frame the object can be in that changes the space it occupies means also that you will need to have a new array for that. Some will have more than others. A rock will most likely have 1 while a living will have many arrays.

Now since all you are concerned with is collision of 2 objects that are within the same space, checking for collision is very easy. You take the 3D array of the one object and then overlap the other object, of course offsetting it correctly. If any 3D points (also known as voxels) intersect, then you have collision. It's very simple to theorize since this is how the real world works.

Implementing such a scheme efficiently is a different story. A simple 32 x 32 x 32 object will require a total of 32 thousand bits (or 4k of memory) to have it truly represented as a 3D mask. That is not realistic.

So let's try an cut that number down to something more manageable. The most efficient we could get is if we decided to only map the outer surface of our object which would (in the 32x32x32 object) still take up 512 bytes (1024 bits per side, 4 sides, 8 bits per byte). This is a simple cube. A more complex object would require more data to map the surface.

This is why people have opted to use boundary cubes for collision detection or going true 3D because given our current level of technology, having hundreds of objects using that much memory (for a single frame mind you) is just not realistic. Let say your standard character is 64 pixels tall, 24 pixels wide, and 24 pixels deep. A 3D mask of a single frame of this character would require 65,536bits (or 8k bytes). If that character has 15 frames for 1 single position or motion, then that would require 120k bytes. If that character has 20 different positions and then that 1 character would require 2.4M bytes to represent it fully in 3D space. That is actually not that much memory, but that is for 1 semi-complex character.

Now, you can do some things to take advantage of the defined 3D mask. All instances of that character can (and should) use the same 3D masks so it's only 2.4M for an infinite number of character instances. Also, while some monsters may look different, they could all share a common 3D mask.

However, even if you optimize is as much as you think is possible, you will still end up using a lot more memory than you would hope for. While PCs are coming with 1GB and 2GB of memory today, most people playing your game will have around 512kB of memory (+/- 215kB). Also, I only pointed out the memory limitations of trying to do pixel perfect 3D collision. There is then the actual collision algorithm that must be written. It could be written in such a way that it only does collision checks on the voxels that could possibly have intersected, but is still a whole lot of looping, ANDing, and memory jumping. Of the two limiting factors, though, this would be the lesser of the two evils.

I would look into have a close representation 3D model of your 2D object that you can use to do all of your collision detections on. This close representation model can be rendered on a hidden surface with 0 frills and used for collision detection only. You can use the detailed 2D sprite for display, but use the 3D model for most of the grunt work.

Share this post


Link to post
Share on other sites
What a thoroughly awesome reply by Dino! I've NEVER.

For me it was like, more educational than that stuff I read from my Commodore 64 manual, and my DarkBasic manual(s). LOL! Pssh DarkBasic...

Quote:
Original post by Dino
I would look into have a close representation 3D model of your 2D object that you can use to do all of your collision detections on. This close representation model can be rendered on a hidden surface with 0 frills and used for collision detection only. You can use the detailed 2D sprite for display, but use the 3D model for most of the grunt work.


Now THIS intrigues me! Because SHAME on a tad few other gamedev coders from my past 2 or 3 topics--I asked if this was possible to all of them and they said "Why not go all the way with 3d anyway," but I was like NAH, can't we make invisible polygon collision masks for my pixel art displays?!! They suggested billboarded sprites but I was hoping for something like this instead! Now I know it can be done! Thank the Lord. I have one solution down at last! Dino lit the fire. I didn't ask about this point in this topic here because I thought I would be beating a dead horse, I asked it like 4 times already. I must be smarter than I thought!

So this can be for any object, a tree, a rock, a monster, whatever? Because actually for the characters and monsters I was thinking that 3d rectangular bounding boxes would be fine in my game--but it will be a hack'n'slash, another nightmare to code I suppose, with all the weapon swinging/shooting. Would having polygonal collision boundaries save a mass more CPU power than voxel collisions, or just a small amount more?

The other thing is, the reason I really wanted pixel-perfect collisions is because I want objects to "roll" over rounded surfaces, instead of just cubic blocky heights or triangular ramp heights...I want organic hills. If there is a non-voxel collision method to get that, then awesome. Polygonal collision boundaries look like a good way to go. Someone at GarageGames told me that he's making an Isometric engine which will allow some kind of sub-cell collision checking within tiles I think...and they might be given height values too! I COULD probably ask him more about that.



Okay, now back to shadows baby!

So I was talking to guys at devmaster. One of them told me this:

-----"i think its possible, if you have absolute world coordinates for each pixel, which you could get from the base position of the sprite, then using the heightmap/coordinate map to create the exact world position of the pixel, you could use it to detect if its in shadow or not.

you could use geometry shadow volumes to do it.

you make the volume out of the outlines of the sprites (as long as you find its supposed exact 3d position) and extrude away from the light and then its
just a containment test per pixel to find out if its in shadow or not. (including ground tiles)"-----

I don't get the extrude part. BUT! I illustrated what I understand he meant by the world coordinates. So basically (correct me if I'm wrong) the world has absolute x and y values for each pixel right? Then, for objects' base pixels, x and y values are coded (absolute within the object, but relative to the world pixels?) and for any pixels in an object that supposedly have height, instead of coding their x and y values normally, we'd code say all pixels "above" x1y1, to be x1y1 as well! Then when a transparent shadow sprite crosses a world pixel, and an object's x1y1 pixel is sitting on that world pixel, THOSE pixels in the object which were coded as x1y1 will become shaded! Because the shadow will offset to those pixels! If that's confusing I drew my understanding here:

Shadow Offsetting

Shadow Offsetting

The first pink arrow shows an object pixel offsetting the cast shadow pixel.

The pink bracket in the 3rd diagram shows a row of pixels on that cubic object, which are all coded with the same x/y coordinates as the pixel at th base of the object, so they all get shaded by the cast shadow because it's as if it "moved" to all of them.

The last diagram has an unrealistic effect but for code purposes it has to be that way (if my understanding is right).

What we can get is that ramp-shading effect, where rounded and ramp objects can BEND cast shadows, as long as someone codes the heightmaps right?

So, how does this look for making pixel-precise cast shadows? I don't want a lighting system, just shadow sprites that follow objects and get cast over other objects, that's what I want. Does this take the same processing power as voxel collisions??

And, if I choose the polygonal collision checking method, would this kind of thing still be available?

Dino you rule!

Share this post


Link to post
Share on other sites
The method you describe isn't the one suggested to you, but the suggested one was far more complex then you need. If all you need are simple vertically projected shadows your method would work well and feasibly fast. In response to your collisions, if you used a simple heightmap for the terrain and then only used polygonal collision meshes for special objects like characters and trees it might be feasible in terms of memory and performance. I definitely recommend a hybrid approach, with simple collisions/shadows for places where the complex systems aren't needed such as terrain and then a more complex system for 'special' situations. Hope this helps.

Share this post


Link to post
Share on other sites
I LOVE THE UNIVERSE! Holy excellence!

Twincam--

Hi! Perth huh? S'where the coder that suggested the world coordinate thing was from! Are you HIM? LOL.

So "simple heightmaps for terrain" would mean I could make rounded, near-domelike hill tiles? And further can I make them any shape I want or by "simple" do I have to make them inorganic (not lumpy)? Like, if I made a tile with 80% flat heightmap and in one corner of it I made a rock with a small raised height, would the mobile objects collide with it, using their simple polygon mesh? This and the rounded hills terrain is the whole reason I thought voxels were necessary. Would the SAME heightmap that offsets the shadow pixels be the one that dictates collisions (would make it easier)?

And as long as my character sprites "roll" organically over the hills as they run, or bump into these random small objects within tiles, I wouldn't mind if their bounding box was a blocky rectangle or a cylinder.

-------------------------------------------

I think...I'm running out of questions. Somebody slap me. Miracle!

My fantasy is unfolding before my eyes! I don't believe it. Finally! After asking 23,000 questions I'm finally here!

But I apologize to all the programmers who I confused with my uneducated theoretical questions.

SO! My shadows will work, and fast too. What a relief. I will go NUTS defining heightmaps for my artwork! Sweet.

You guys rock, all of you. If I had some, I would give you money just for telling me this.

[Edited by - Sylon on November 10, 2006 8:52:04 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Sylon
You guys rock, all of you. If I had some, I would give you money just for telling me this.


That's way GD.Net has implemented the rating system :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Sylon
Now THIS intrigues me! Because SHAME on a tad few other gamedev coders from my past 2 or 3 topics--I asked if this was possible to all of them and they said "Why not go all the way with 3d anyway," but I was like NAH, can't we make invisible polygon collision masks for my pixel art displays?!! They suggested billboarded sprites but I was hoping for something like this instead! Now I know it can be done! Thank the Lord. I have one solution down at last! Dino lit the fire. I didn't ask about this point in this topic here because I thought I would be beating a dead horse, I asked it like 4 times already. I must be smarter than I thought!

The reason several coders would recommend going all 3D is because they don't deem the added 2D sprite detail worth the extra work it would entail to do a 2D/3D hybrid. However, you think it is worth it and that is all that matters.

Quote:
Original post by Sylon
So this can be for any object, a tree, a rock, a monster, whatever? Because actually for the characters and monsters I was thinking that 3d rectangular bounding boxes would be fine in my game--but it will be a hack'n'slash, another nightmare to code I suppose, with all the weapon swinging/shooting. Would having polygonal collision boundaries save a mass more CPU power than voxel collisions, or just a small amount more?

I think that most 3D collision boundary implementation will do this kind of work much more efficiently than any voxel implementation. Just look at the simple numbers:
A single 3D boundary cube will require eight 3D points to represent it. Lets say one 3D point consists of 3 single-precision floats for a total of 12 bytes (32bits * 3). That means for any cube of any size, you will need 96 bytes to properly do collision checking on a cube. To determine if 1 cube is colliding with another cube (assuming you just don't use the optimized 3D libraries) would a simple check. I forget the actual formula, but it's not very CPU intensive.

Now a voxel based implementation of a small object (let's say 8 x 8 x 8) would require you to have a minimum of 64 bytes (8bits cubed). At first that doesn't sound bad at all, but this is for a small object. Increase that to 32 x 32 x 32 and now we are looking at kilobytes of memory needed to do the collision checking. Then add on algorithm needed to actually do a bit by bit check and you are talking alot of work.

So, right now, boundary collision is your best and fastest choice and is much more efficent.

Quote:
Original post by Sylon
The other thing is, the reason I really wanted pixel-perfect collisions is because I want objects to "roll" over rounded surfaces, instead of just cubic blocky heights or triangular ramp heights...I want organic hills. If there is a non-voxel collision method to get that, then awesome. Polygonal collision boundaries look like a good way to go. Someone at GarageGames told me that he's making an Isometric engine which will allow some kind of sub-cell collision checking within tiles I think...and they might be given height values too! I COULD probably ask him more about that.

As long as you don't want object to be able to go under a tile, then height maps are the way to go here. It's fast and efficient and gives you pixel-perfect heights at any 1 point. By storing the information in a simple 2d array with a char offset, you can have very large rolling hills. A 3D terrain engine could also give you the same effect, but I'm not completely sure on the pixel perfect height evaluation.

The purpose of the char offset allows you to break the 256 pixel maximum height that a single 2D char array (which is what you want to use to minimize memory use) and also allow you to reuse the same tile at different heights. For every unit the offset is increase, the tile is raised 256 pixels. This allows you a maximum of 64k pixels high, but only use 1 extra byte more than the 2D char array.


Quote:
Original post by Sylon
Okay, now back to shadows baby!

So I was talking to guys at devmaster. One of them told me this:

-----"i think its possible, if you have absolute world coordinates for each pixel, which you could get from the base position of the sprite, then using the heightmap/coordinate map to create the exact world position of the pixel, you could use it to detect if its in shadow or not.

you could use geometry shadow volumes to do it.

you make the volume out of the outlines of the sprites (as long as you find its supposed exact 3d position) and extrude away from the light and then its
just a containment test per pixel to find out if its in shadow or not. (including ground tiles)"-----

I don't get the extrude part. BUT! I illustrated what I understand he meant by the world coordinates. So basically (correct me if I'm wrong) the world has absolute x and y values for each pixel right? Then, for objects' base pixels, x and y values are coded (absolute within the object, but relative to the world pixels?) and for any pixels in an object that supposedly have height, instead of coding their x and y values normally, we'd code say all pixels "above" x1y1, to be x1y1 as well! Then when a transparent shadow sprite crosses a world pixel, and an object's x1y1 pixel is sitting on that world pixel, THOSE pixels in the object which were coded as x1y1 will become shaded! Because the shadow will offset to those pixels! If that's confusing I drew my understanding here:

Shadow Offsetting

Shadow Offsetting

The first pink arrow shows an object pixel offsetting the cast shadow pixel.

The pink bracket in the 3rd diagram shows a row of pixels on that cubic object, which are all coded with the same x/y coordinates as the pixel at th base of the object, so they all get shaded by the cast shadow because it's as if it "moved" to all of them.

The last diagram has an unrealistic effect but for code purposes it has to be that way (if my understanding is right).

What we can get is that ramp-shading effect, where rounded and ramp objects can BEND cast shadows, as long as someone codes the heightmaps right?

So, how does this look for making pixel-precise cast shadows? I don't want a lighting system, just shadow sprites that follow objects and get cast over other objects, that's what I want. Does this take the same processing power as voxel collisions??

And, if I choose the polygonal collision checking method, would this kind of thing still be available?

If you use a simple 2D height map, then it should work ok. There are quirks you will need to keep an eye out for, though. It's hard to explain, but oddly shaped objects will cause you the most problem and I would, in your implementation, test with objects that are concave and have the left-most points in the back (furthest from the viewer).

Share this post


Link to post
Share on other sites
Hey!

Quote:
Original post by Dino
However, you think it is worth it and that is all that matters.


That's what I was thinking too! Hehehe.

Quote:
Original posy by Dino
So, right now, boundary collision is your best and fastest choice and is much more efficent.


Nice.

Quote:
Original post by Dino
As long as you don't want object to be able to go under a tile, then height maps are the way to go here.


DANG!

Maybe I'm confusing tiles with objects? I was thinking of making stackable objects, with different floor levels and stuff.



SW of the dog character you see some blocks, with one shaded by the one above it. I was think I could make a game with elevated levels like this, and yes characters going under objects. In this case are objects different from tiles? I want my world to be basically BUILT by stacking cubic objects, and then any organic objects with rolling or lumps, would be stacked on top of the cubic objects to basically give form to hills and stuff. The "tiles" would be such as the metal floor you see in the screenshot of HOH--just at the bottom of the stacked objects. Really the objects would be what gets walked on 99% of the time.

Can I give the organic heightmaps to the objects and stack them, and make it so some of them can be traveled under?

I figured the whole 3d polygon collision mesh would allow for jumping in 3d space, such as for jumping into elevated cave hole in mountainsides, or into windows, under/between multi-level bridges, etc.

LARGE hills I was thinking could be sacrificed--to build large hills I would instead just stack cubic objects in a large 3d formation and at their tops, place an object with a ramped or lumped heightmap (there would be enough of these "top" objects that you could make it look seamless when you set them near each other). Doable?

Here is a pic to explain, don't mind the mismeasurements of tiles or the bad art!:

Hills and elevations

I would like 90 degree rotations of maps (I will make 4 sides to everything) and jumping around elevations.

Quote:
Original post by Dino
If you use a simple 2D height map, then it should work ok. There are quirks you will need to keep an eye out for, though. It's hard to explain, but oddly shaped objects will cause you the most problem and I would, in your implementation, test with objects that are concave and have the left-most points in the back (furthest from the viewer).


As long as they're just quirks I'm sure I can find a way around them, or be able to sacrifice them. Thanks!

Share this post


Link to post
Share on other sites
I always considered tiles a 2d image used solely for terrain rendering. However, give what you want to accomplish, I would be more inclined to say that your terrain is built using a voxel-like system. In your picture there, every cubic area can be represented as 1 type of terrain building block, kind of like a voxel. But where a voxel is a cube, your building blocks are cubic in containment only, but have an organic surface inside your cube.

Given this, I would revisit the whole voxel approach for your terrain. Try going at it like this:


struct BLOCK
{
unsigned int offset; //Height offset from ground 0
char *topography; //The height map of this block
void *data; //Any block specific data
};

struct BLOCKLIST
{
unsigned int count;
BLOCK *blocks;
}

struct TERRAIN
{
unsigned int width; //Number of tiles in the X direction
unsigned int height; //Number of tiles in the y direction

BLOCKLIST *tiles; //The actual layout of your terrain
}



You would then initialize the TERRAIN like this:

TERRAIN t;
unsigned int mem_size;

t.width = 32;
t.height = 32;

//Allocate the minimum memory needed for this terrain and initialize
//all the values to 0
mem_size = t.width * t.height * sizeof(BLOCKLIST);
t.tiles = (BLOCKLIST *)malloc(mem_size);
memset(t.tiles, 0, mem_size);



You would then build each individual BLOCKLIST entry with your terrain building blocks. Given this structure, I don't think you need to get 3D libraries involved because collision detection is built in due to the terrain being made up of those building blocks. You will need to implement a simply gravity system to pull the objects down so that they do follow the terrain, but that's easy.

Share this post


Link to post
Share on other sites
The exact pixel perfect collision system kind of eludes me at the moment, but as for creating a map such as the one you have drawn there (really not bad at all btw), I believe it should be possible to realize that with a simple isometric engine.

Are the characters in there fair representations in regards to their size? Because if so, I really wonder if a pixelperfect collision detection system will have any benefit over any other system.

Share this post


Link to post
Share on other sites
Interesting approach to getting organic 2d worlds. Personally I'd go with a world like Dino described, made up of fixed-size cubes with 'fuzzy' tops represented with a heightmap. Then you could hold your world as a big 2d array, where each slot represents a vertical slice of cubes. Each slice would then be a linked list of cubes within it. That takes advantage of the mostly sparse nature vertically while still giving you nice fast array lookups for any given area.

For rendering, if you had a second sprite with the depth information (like in your first post), then shadows could be done quite easily in a pixel shader. You'd only get top-down drop shadows, but it'd look like the animations you've created.

Share this post


Link to post
Share on other sites
Gamedev is full of geniuses!

Dino, that's awesome. What happens if I use that actual code in my game and decide to make the game commercial? Would I have to contact you? Chances are I will make my game free (I will work on it as a hobby for years, so I'll probably have a job for myself and I HOPE be able to pay a team to help me, but as far as making the game commercial, not sure). I don't think anyone has ever went through the effort to make that much code for me. LOL. Thanks man!

I think I see what you mean by the concave shading quirk now:



I have theories but I'll spill it elsewhere. I will test those leftmost pixel and concave cases when I work on implementation though, thanks for pointing it out!

Traveler--

Yeah, that's about their *relative* sizes to the tiles and blocks...for real I'd like them to be maybe 24x48 or, with blocks being like 32x32. Yeah as long as they roll over hills as they run, and can jump between stuff and possible over and around a mass of lumpy tree roots, I guess I don't mind the non-pixelperfect collisions. Polygons for tree roots might do it and stuff. But I'd think if the hills could be rolling, that I could do the same kind of heightmap stuff for the hills, with trees and branches and rocks and stuff too, right?

Orangytang--

Awesome! You get some rating points too! I'm keeping notes on all this stuff. I will save this topic discussion in like My Documents, it was the best I've ever had.

[Edited by - Sylon on November 10, 2006 5:19:41 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Sylon
I think I see what you mean by the concave shading quirk now:


Ah, the age-old 'double shadow' problem that crops up in every shadowing method. [grin] You'll get variations on this with self shadowing of cubes too.

So far I can think of two possible solutions: 1. store another mask layer indicating which bits contain baked-in shadows, and so don't need to be further darkened. Or 2. tinker with the depth sprite so those pixels are at maximum height - that way they'll always be fully lit, and you won't get the shadow applied a second time over the hand-painted version.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Partner Spotlight

  • Forum Statistics

    • Total Topics
      627661
    • Total Posts
      2978496
  • Similar Content

    • By Jcyshadow97
      Hi,guys.I m working on a Fantasy RPG.Currently i m work alone on the project.I really need someone can make UI stuff.If someone can handle it please feel free to contact me on email: 270514974@libero.it.
      Thank you guys and sorry for my english.
       
       



    • By STRATUM the Game
      Hey, everyone! This is my first post here.
      I would like to know what you think about my project called STRATUM. It's a 2D platformer that is heavily based on storytelling and boss fighting while trekking through the world.

      Everything in STRATUM takes place in the first century AD, in a world that wraps our own universe, called  The Stratum. A parallel Universe that is the home of the Christian deities . In this game you will play as a Dacian warrior, unfamiliar with everything in this world, you’ll get to know and understand The Stratum together with him.
      The main thing that I want with STRATUM is to reinvent the known lore and history of the Christian deities and realms. 
      The story is unconventional, it plays down a lot of the mysticism of Hell or Heaven and it gives it a more rational view while keeping the fantastic in it. What do I mean by that? Well, think about Hell. What do you know about it? It's a bad place where bad people go, right? Well, that's not the case in STRATUM. I don't want to describe such a world. In STRATUM, there is a reason for everything, especially for the way Hell is what it is in the game. "Hell" is called The Black Stratum in the game.
      This world is not very different from Earth, but it is governed by different natural laws.
      The story will also involve the reason why this world entered in touch with ours.

       
      What do you think about all that I said? Would you be interested in such a game? I have to say that everything is just a work of fiction made with my imagination. I do not want to offend anyone's beliefs.
      I want this to be a one man game. I have been working alone on it (this was my decision from the beginning) from art to effects to programming to music to sound effects to everything.
      I also have a youtube video HERE if you want to see the way the game moves and the way my music sounds.
      Please, any kind of feedback will be highly appreciated. If you have something bad to say, do it, don't keep it for yourself only. I want to hear anything that you don't like about my project.
       
    • By LimeJuice
      Hi, it's my first post on this forum and I would like to share the game I am working on at the moment.
      Graphics have been made with Blender3D using Cycle as a renderer and I am using Unity3D. It's a 2D game, one touch side-scrolling game for iOS and Android.
      Here some pictures, and you can have a look to the gameplay on this video :
      Feedbacks ?
      And if you want to try it, send me your email and I will add you to the beta tester list!
       
       








    • By Kirill Kot
      An adventure indie game with quests in a beautiful, bright world. Characters with unique traits, goals, and benefits. Active gameplay will appeal to players found of interactivity, especially lovers of quests and investigations.
      Available on:
      Gameroom (just open the web page and relax)
      AppStore
      GooglePlay
      WindowsPhone

    • By Kirill Kot
      Big Quest: Bequest. An adventure indie game with quests in a beautiful, bright world. Characters with unique traits, goals, and benefits.
      Mobile game, now available on Gameroom. Just open the web page and relax.
  • Popular Now