8 replies to this topic

[Sylon]

Hi everyone!

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, amost domelike hills and stuff. And they'll have 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).

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 over its head!

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 grayscale might not do it because that only allows 256 colors and I need to tell the computer lots more information than that. 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 to make it more simple (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. The structure/orientation of the slice is a different story though.

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!

[rouncer]

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)

but, you have a few tiles there that should be self shadowed, that looks a little trickier than just formulating it from outlines. so maybe you need
something else.

but a tree with a hanging over branch would shadow properly onto the sprites
underneath it, if you do keep these coordinates for them.

that idea for splitting sprites up into depth sections to uncover the under portion could work.
if you do draw and design the models for front facing and back facing, youd
use the front facing sprite to create the shadows, and the back facing sprite
to draw and detect shadows. (so the shadow is created from the front facing
portion instead of the back, which would still look alright by the way. because
thats how shadows were usually made for 2d games, just using the sprite
itself)

your shadows couldnt really go sideways tho, they could only go in and out
diagonally and straight.

anyway, the idea looks cool :) i had to post.

[Sylon]

Funny Rouncer, I posted this on gamedev.net many times before and though I got a few neutral replies, nothing was ever as positive as your post here! :yes:

Quote

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.

My code comprehension is limited but this sounds...simple! So in world space, objects/tiles (their pixels?) would have 3d position information, and as a sprite moves across the tiles, the sprite's own "heightmap" (invisible mask with 3d information on each pixel??) would be able to dictate whether that portion of the sprite appears as "drawn last (in front)" or "drawn behind" the other objects and/or their shadows?

Quote

because thats how shadows were usually made for 2d games, just using the sprite itself)

Just to clarify, I kind of want my game objects to cast shadows directly underneath themselves, as if the light is always coming from the zenith point at 90 degrees above. I was planning on designing each object's cast shadow, pre-rendered for all static ground objects and animated objects/character/enemy sprites (just using the sprite itself to cast a shadow underneath it would look wrong). Would this help speed the engine or is best to let the engine calculate it in-game? Going for a large amount of sprites and objects in my game. The reason I want them cast directly underneath is mainly to avoid complex coding issues like making a shadow climb up a wall as an object gets nearer to the wall, etc., and HOPEFULLY to put more pressure on me, the artist, rather than the programmer.

The idea is that these alpha transparent (50% black) shadows would follow sprites or objects, and when the shadows collide with other objects in 3d space, the shadows would conform to the figure of that object as that object's heightmap would dictate. The individual pixels in the shadow would have to be offset in height, depending on which pixel it collided with in the object's heightmap. Am I making sense I hope? I hope I didn't overlook some kind of code mechanics...errg!

I don't care much for a lighting engine, as I will just pre-render any diffuse, speculative or ambient lighting effects for ground objects.

Quote

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)

Ah-HA! I was thinking about this, but wouldn't it require the programmer to code some horrendous volume coordinates? Is there a way for the artists to just make an invisible RGB mask like I suggested, to overlay on the objects/tiles, to tell where the pixels are in 3d space?

If there was a super-artist who could do anything (like me), ask yourself what you would make him do, to make coding easiest for this kind of 2d game! :lol: As long as it doesn't excessively sacrifice computer memory...

About the slice thing. Yeah it's still tough to wrap my mind around what I myself am suggesting, not to mention what you're saying. For self-shadows under objects like fences and overhangs within tiles, do you think it's possible I just pre-render transparent images like the rest and let it sit directly under the tile?

I'll ask more about the slicing thing later hehe.

[geon]

Actually, what you are trying to do IS 3D. As you mentioned it is called voxels.

I have never thought of the idea to use voxels for low-res pixel art, but it would be possible. Just don't try to do it in a regular paint-program. There is something here that could be more suitable:
Voxel3d

If your resolution is low enough, it might actually be possible to make a renderer for a game like that. Just remember that the 3rd dimension adds A LOT of data if you are not carefully. But using tiles, combined with an octree, might work.

[Sylon]

Hi Geon! Man, I'm thrilled about having another positive programmer reply!

geon said:

Actually, what you are trying to do IS 3D. As you mentioned it is called voxels.

Yes! Except I wouldn't want 360 degree rotations, or the ability to zoom in and out of views. The camera would be a fixed 45 degree ortho angle too (because all the pixel art would be pre-rendered).

geon said:

I have never thought of the idea to use voxels for low-res pixel art, but it would be possible. Just don't try to do it in a regular paint-program. There is something here that could be more suitable:
Voxel3d

Okay! So! This raises questions. Are you saying that if I make a voxel model, that in a 2d pixel art game, coders could use the voxel model as an invisible pixel-precise "bounding box" built into the sprites, to handle collisions and to bend cast shadows around the 2d sprites properly?

If you are suggesting I use voxel models as the sprite image itself, that would get tricky for me, the artist, considering I want the maps to be rotatable for 4 different views (every 90 degrees).

If it's possible to just keep the voxel models as invisible 3d masks that 2d images react to for collisions/shadows I'd love it! If I could use voxel models as the sprites and objects themselves, I MIGHT be happy but I'd have to ask more questions to people :lol: .

About low-res...well...not sure how low I'm fantasizing...How does 1280x1024 sound? Of course with a frame surrounding the in-game viewer. Displayed in 2d, tiles would be 32x32, normal objects at 32x64 and larger monsters at 128x128. I am scared of your reply to this.



I had this voxel debate with programmers on gamedev.net and I got replies that weren't as positive as you or Rouncer's. Here they are:

Quote

Quick question: Why a voxel game? Wouldn't it be easier to produce a polygonal game?

I ask this because a voxel engine probably won't gain much from 3D accelerated hardware, and per-voxel shadowing would tend to require a lot of computational horsepower. I also can't remember if voxel engines "support" rotation on the X axis (looking up and down) properly, so there's a potential effect lost.

So guys, if I pre-rendered cast shadows and they only had to bend over invisible voxel masks, would that be easier on the computer than if it had to render its own cast shadows from the voxel models PLUS bend them around other models?

And, with an orthogonal isometric fixed camera angle, where I would like the map to rotate in four 90 degree angles (but camera is fixed at overhead 45 degrees for all), would voxel engine support for x-axis rotation even matter?

Quote

If you really want good shadows you *probably* might as well go all the way to using polygon-based models. Then you can use Stencil shadows. Which are probably going to look better and draw faster than inventing some odd sprite/voxel combo deal.

"Odd" sprite/voxel combo deal? How odd do you guys think it is? I mean as long as someone knows how to code it and the computer can handle it, I'm up for killing time making voxel models and sprites baby!

Quote

Voxels aren't expensive to work with; they are just expensive to draw in large numbers (since there is no 3D accelerator support). I can kind of see how per-voxel shadowing could be faster. Per-voxel collision would be expensive, so again you'd be using a bounding box system like in the polygon-based gameworld.

Per-voxel collisions would be expensive...well guys, do you think in the future when comps get to like 6 Ghz with like 5 GB RAM and video cards start factoring in voxel games, it won't be so bad to have per-voxel collisions?!

[juhnu]

You could use depth-sprites with the newest hardware, but that would limit your target audience of course so I would rather forget the idea of using depth-textures and use 3D-objects with projective texture mapping instead.

You can still create your art in 2D as before, but instead of drawing it on screen as a 2D-rectangle, you map your art projectively onto a 3D-primitive, such as a box (you can do this inside your 3D-editor of choice), and then render it with a correct camera setup. To get an exact 1-1 texel to pixel mapping you need to use an orthogonal camera setup, but it's probably nicer if you used a weak perspective(and forget the absolute 1-1 mapping requirement) projection instead as that would give you the parallax effect for free.

[Sylon]

Juhnu, so there IS such a thing as these "depth-sprites"? Have they been made before? Also, if these depth-sprites are what I'm looking for, how would that limit my target audience? Because with billboarded sprites on 3d objects with projective texture mapping, the cast shadows won't be able to creep around the lumps and folds of the sprite image. It would be flat.

I was told about the orthogonal 1-1 texel to pixel ratio setup but...hmm maybe I should finish my newest animation. Really, audience or not I am looking for what I'm looking for only unless it's impossible to code or takes too much computer memory in-game.

Also I decided to sacrifice the parallax effect, though it would have been nice.



Does anyone know the answers to my questions in the post above Juhnu's?

[geon]

Sylon said:

Okay! So! This raises questions. Are you saying that if I make a voxel model, that in a 2d pixel art game, coders could use the voxel model as an invisible pixel-precise "bounding box" built into the sprites, to handle collisions and to bend cast shadows around the 2d sprites properly?

If you are suggesting I use voxel models as the sprite image itself, that would get tricky for me, the artist, considering I want the maps to be rotatable for 4 different views (every 90 degrees).

No. I mean the voxel model would be the graphics. The renderer would draw it to a 2D surface, where each voxel would be shown as a few pixels. This would give the artist a bit less controll over how things are actually looking at the screen, but the gain would be huge. (No need to hand-draw the same object from sereval angles.) Also, totally destructable environments could easily be implemented. (Think Liero/Worms, but in 3D.)

Sylon said:

About low-res...well...not sure how low I'm fantasizing...How does 1280x1024 sound? Of course with a frame surrounding the in-game viewer. Displayed in 2d, tiles would be 32x32, normal objects at 32x64 and larger monsters at 128x128. I am scared of your reply to this.

Ah... That starts to sound like a lot. But still, you don't need to update the screen where nothing is happening, so it could still work. Since you would just scroll the whole screen to move the camera, very little needs to be rendered if most of the surroundings are static.

I was more thinking something like 640x480 with 32x32x32 tiles.



I had this voxel debate with programmers on gamedev.net and I got replies that weren't as positive as you or Rouncer's. Here they are:

Sylon said:

So guys, if I pre-rendered cast shadows and they only had to bend over invisible voxel masks, would that be easier on the computer than if it had to render its own cast shadows from the voxel models PLUS bend them around other models?

And, with an orthogonal isometric fixed camera angle, where I would like the map to rotate in four 90 degree angles (but camera is fixed at overhead 45 degrees for all), would voxel engine support for x-axis rotation even matter?

If there would be a lot of dynamic shadows, there would be no or little gain from prerendering them. But for static environmens, it should be just fine.

The camera angle will be very limited (like in SimCity 2k), as you mention. But if you are fine with that, I guess it doesn't matter.

Sylon said:

Per-voxel collisions would be expensive. (...) in the future when comps get to like 6 Ghz

Not really that expensive. Depends on what you compare it to. For reasonably sized scenarios, it should work. Remember, though, that "reasonable" size might not be enough to draw very hight resolution voxel sprites. I would be happy with a 8x8x16 voxel charakter in a 32x32x32 voxel tile.

[Sylon]

Thanks Geon! Dang the voxel idea is tempting because of the reduced animation workload but I just took a look at some Westwood Studios voxel models and also some amateur ones and I can't seem to part with my pixel art skills.

Also thanks Rouncer! You know your stuff. I'm probably gonna have to ditch the crevice idea though.