Hello everyone. I'm new here. I have a question, and I figured if there was any place to ask it, this would be that place.

Is it feasible to do the following?

-- Use prerendered sprite sets (36 X 36, 1 view for every 10 degrees in x and y rotation) for every object in a 3d scene. With realtime z-plane rotation and scaling from hardware included we can view an object from any direction and any distance, and the image quality is as good as your prerendered sprites (no realtime rendering of polygons).

This results in an object that can be rotated around QTVR-style in 10-degree increments, but we cannot move the light source(s) or drop any shadows onto other objects.

-- For moveable light sources, use alpha blending for simulated lighting. For every object we have a 100% ambient-lit sprite set, and 6 sets of sprites where the object is lit from each of the 6 3D cardinal directions, but the object is textured gray. We choose a lighting direction and fade between the "lighting maps" before multiplying the "texture sprite" by the "lighting sprite" to obtain the representation of our lit object.

Nothing could get too close to the camera or you would run into perspective issues. Also it would work best against a prerendered backdrop (no camera movement).

The shadow-casting problem seems unresolvable, but this gives you a photo-quality realtime 3D engine with only a few drawbacks. Tell me if you think this idea is too processor-intensive (there's a lot of scaling, rotation, and blending of 2D sprites involved, and the memory requirements would probably be large), or if it might work with OpenGL or something else. If this idea is too flaky, or if I didn't explain it well enough, tell me that too. But I think there may be possibilities with this, and it seems like it could be amazing for photorealistic 2D platform games in 3D perspective.

-Duncan Malashock

I think you're making life too hard for yourself. Watch the E3 Doom III or Half-Life 2 footage and then come back

Really, I think this will just look like Marathon or Duke 3D, no matter how good your art is.

Quote:Originally posted by OneSadCookie
I think you're making life too hard for yourself. Watch the E3 Doom III or Half-Life 2 footage and then come back

Really, I think this will just look like Marathon or Duke 3D, no matter how good your art is.

Well I won't deny those games both look superb, but with this idea you're not restrained by texture size or polygon count on anything. With prerendered backdrops and prerendered sprites, how do you figure the result couldn't far surpass the image quality realtime 3D can muster? With obvious limitations (it would be a fragile illusion, and only effective for certain purposes). Did I mention it would NOT be first-person? Third-person is the only perspective this would work for.

--Duncan

P.S. Thanks for your quick reply

Quote:Originally posted by dmalashock
Hello everyone. I'm new here. I have a question, and I figured if there was any place to ask it, this would be that place.

Is it feasible to do the following?

-- Use prerendered sprite sets (36 X 36, 1 view for every 10 degrees in x and y rotation) for every object in a 3d scene. With realtime z-plane rotation and scaling from hardware included we can view an object from any direction and any distance, and the image quality is as good as your prerendered sprites (no realtime rendering of polygons).

This results in an object that can be rotated around QTVR-style in 10-degree increments, but we cannot move the light source(s) or drop any shadows onto other objects.

-- For moveable light sources, use alpha blending for simulated lighting. For every object we have a 100% ambient-lit sprite set, and 6 sets of sprites where the object is lit from each of the 6 3D cardinal directions, but the object is textured gray. We choose a lighting direction and fade between the "lighting maps" before multiplying the "texture sprite" by the "lighting sprite" to obtain the representation of our lit object.

Nothing could get too close to the camera or you would run into perspective issues. Also it would work best against a prerendered backdrop (no camera movement).

The shadow-casting problem seems unresolvable, but this gives you a photo-quality realtime 3D engine with only a few drawbacks. Tell me if you think this idea is too processor-intensive (there's a lot of scaling, rotation, and blending of 2D sprites involved, and the memory requirements would probably be large), or if it might work with OpenGL or something else. If this idea is too flaky, or if I didn't explain it well enough, tell me that too. But I think there may be possibilities with this, and it seems like it could be amazing for photorealistic 2D platform games in 3D perspective.

-Duncan Malashock

An entry from last year, Melee I think, had most of the technology necesary to pull this off. It had realtime rotated, scaled, lit sprites done entirely in software. I think it also did edge anti-aliasing and transparency, but I'm not sure. I wrote the original rasterizer (and came up with the name Ploy) but William did a LOT of customization. .

As for shadows, if you're casting them onto something big you can just take the view of the object from the perspective of the light and project it onto the surface recieving the shadow, and then draw the sprite completely blacked out (and maybe partially transparent).

Oh, and one note, it would be better to divide the sphere around the object into a more uniform division than lat/lon increments. Think geodesic.

Quote:Originally posted by dmalashock
Well I won't deny those games both look superb, but with this idea you're not restrained by texture size or polygon count on anything. With prerendered backdrops and prerendered sprites, how do you figure the result couldn't far surpass the image quality realtime 3D can muster?

concerning texture sizes your method would certainly have large disatvantages since you need to scale your objects too and that is less flexible. polygon count is not a big issue nowadays. i very much doubt you can surpass the image quality of realtime 3d with your method especially not with how you do the lighting.

With your method you'll likely be _more_ limited by texture resources than most 3D games. You'll also have a very limited quality of animation (too many frames increases texture limitations + puts a huge burden on artists).

There's a reason games don't work as you suggest

Quote:Originally posted by inio
An entry from last year, Melee I think, had most of the technology necesary to pull this off. It had realtime rotated, scaled, lit sprites done entirely in software. I think it also did edge anti-aliasing and transparency, but I'm not sure. I wrote the original rasterizer (and came up with the name Ploy) but William did a LOT of customization. .

I'm interested. But I can't find it. Do you have a link?

Quote:As for shadows, if you're casting them onto something big you can just take the view of the object from the perspective of the light and project it onto the surface recieving the shadow, and then draw the sprite completely blacked out (and maybe partially transparent).

I thought along those lines, but that would imply a surface receiving the shadows to begin with, and there aren't any 3D surfaces in this method, unless there was a groundplane.

Quote:Oh, and one note, it would be better to divide the sphere around the object into a more uniform division than lat/lon increments. Think geodesic.

Wow, good point.

-Duncan

Quote:Originally posted by OneSadCookie
With your method you'll likely be _more_ limited by texture resources than most 3D games. You'll also have a very limited quality of animation (too many frames increases texture limitations + puts a huge burden on artists).

Not sure what you mean by "quality of animation." If you mean you'd need a different sprite set for each facial expression on a character's head, that's true. If you mean you'd need a different sprite set for every physical position a human figure could be put into, well, that depends on how you do character animation. Texture animation in this model is definitely pretty unfeasible, I agree. But I'm not sure I get your meaning.

--Duncan

Well, you've got 36 views of each character, and you need to animate each character at at least 25-30FPS to look as nice as you can do with traditional 3D methods, so each frame of the animation is actually 36 frames, one for each view. That still won't give you interpolation between frames of the animation if the frame rate of the game happens to be higher than the frame rate of the animation.

Also, assume you render your characters at 64x64 pixels (probably too small to look good), 25 fps x 5s of animation (idle, running, walking, picking up, dead, dying, shooting, jumping, &c is probably more than 5s worth of distinct frames...) x 36 views x 64 x 64 x 4Bpp is a little less than 141 MiB of textures (uncompressed) just for one character...

[edit]whoops, math was screwy[/edit]

Quote:Originally posted by inio
An entry from last year, Melee I think, had most of the technology necesary to pull this off. It had realtime rotated, scaled, lit sprites done entirely in software. I think it also did edge anti-aliasing and transparency, but I'm not sure. I wrote the original rasterizer (and came up with the name Ploy) but William did a LOT of customization. .

If it was William (w_reade) then the entry was MAFFia. You can find the source on the site.

Roatated, scaled, lit sprites with edge antialiasing and alpha blending? I'm flattered that you thought it might be me, but all MAFFia used was bog-standard GWorlds with CopyBits/Mask. The only custom drawing in there was the fire and a FloodFill routine that I wrote because I couldn't get the Apple one working right .

I don't know what game you're talking about, I'm afraid. Will Thimbleby, year before last, perhaps?

I think that the first Wing Commander used a similar technique of using pre rendered sprites at various angles and sizes. Of course this was before 3D graphics cards were common. It seems like it would work pretty well for inorganic things that didnít have a lot of moving parts. Wing Commander was a pretty incredible game in its day; the gameplay overcame any shortcoming it might have had in the graphics.

--Jim

Mario Kart on the SNES used it to surprisingly good effect too, but in a much more restricted setting than you're proposing...

I believe that rendering distant objects to texture and billboarded-quad'ing them is good in some circumstances, but that's just an LOD technique really, not really related to this.

Quote:Originally posted by jabber
If it was William (w_reade) then the entry was MAFFia. You can find the source on the site.

No, not that william.

Just looked, it got renamed to incursion before it was entered it seems. During dev it was called melee (as will most likely become clear when the source is released). The graphics engine is called ploy.

[update]It seems the server it's on has sped up, so just get it from the games page.[/update]

If it's slow (slower than the lesser of your connection speed and 16kB/sec) I downloaded a copy to
here.

BTW, it turns out we talked about edge anti-aliasing during dev, but that didn't ever get implemented. Instead William added mip-mapping.

Quote:Originally posted by OneSadCookie
Well, you've got 36 views of each character, and you need to animate each character at at least 25-30FPS to look as nice as you can do with traditional 3D methods, so each frame of the animation is actually 36 frames, one for each view. That still won't give you interpolation between frames of the animation if the frame rate of the game happens to be higher than the frame rate of the animation.

Oh, absolutely, it would be insane to try character animation with this technique, if you only use one quad/object to represent your character. But let's say the animation is physical, with each major body part having its own separate object. This can allow for as wide a range of physical character animation as realtime can, although we can't change the textures without consuming a ridiculous amount of space.

Quote:Also, assume you render your characters at 64x64 pixels (probably too small to look good), 25 fps x 5s of animation (idle, running, walking, picking up, dead, dying, shooting, jumping, &c is probably more than 5s worth of distinct frames...) x 36 views x 64 x 64 x 4Bpp is a little less than 141 MiB of textures (uncompressed) just for one character...

You see, that's all running under the assumption that the entire body is represented with one object, and that's what would make it akin to the marathon/duke 3d style you mentioned before. But if your character is animated with sections and joints rather than prerendered positions, you need far less overhead. I'm also working on physics-based character animation techniques rather than using preprogrammed walk cycles and the like, so this system would have its advantages in that area...

Man, you guys are sharp! My sincere thanks for the very well-informed comments and critiques so far.

--Duncan