Feature Request: easier 2.5d sprite placement

[jaymzjulian]

This one should be fairly simple, i think, but hey, i might be a crackmonkey . In one of my experiments, I'm making a field of trees on a 3d plane (trying to create a jungle effect, essentially), and I want the trees to be scaled 2d sprites rather than 3d objects (think like the trees in mario64 ).  (in the game, things are going to hide behind the trees - ).  Of course if I _just_ want the trees, this is pretty simple - i just project myself and z-clip, and life is good, but of course I don't want something that simple .

My current attempt at this this involves defining my tree as a Sprite3d, and then rotating the object so that it always points at the camera, which actually does work, but is super annoying, of course, and I've never gotten _quite_ right (it looks _great_ as long as I don't try and have a free camera!).  So what I really want in my life, is something that looks like:

Code Select Expand


' have a normal-ish 2d sprite - but maybe a differnet type for the system if that helps it
my_2d_sprite = LineSprite25d({ ... 2d object ... })
' place that sprite in _3d_ space, which will draw it at that location zoomed by
' whatever the projection would have x/z*d be
SpriteTransform(my_2d_sprite, { 3d_coord} )


and then have it drawn as a scaled 2d object, where the scale is appropriate for the place it is in 3d space. 

[Vectrex32]

Interesting. I guess this would be applicable to any object that looks the same from all sides. Can you think of other games where this sort of thing is done?

- Bob

[jaymzjulian]

Yeah, any object like that makes sense - particularly, any object that's complex enough that if you're in a low poly situation, the 2d sprite fake-rotations are cheaper/better than you'd get with 3d (i'm actually planning to use 2d scaled sprites for the enemies in the game as well, and just arranging to have them "always facing the player" - but on a 3d terrain)

trees are a great example because they're _so_ complex if you actually render them in full 3d, but human type shapes are actually the other example where i think it makes a lot of sense, for much the same reason - you need a LOT of polys to do that well in 3d, but relaly only 16 or so 2d rotations to make it look decent with 2d sprites.

off the top of my head - keeping to the mid 90s, since that's when it was mostly prevalent .  Obviously newer games tend to not, because you know, what's a few thousand polys these days?

* mario kart 64 - all of the racers are acutally 2d sprites on a 3d polygon track
* obviously doom and contemporary engines such as build (dn3d and friends) - 3d (though raycasted, still projected!) environment, 2d enemies with pre-calculated 2d sprites for each z-rotation.
* starfox - explosions, ejected pilots, and asteroids are all sprites, most of the rest is polys

[jaymzjulian]

i had one other thought related to this - something that could be generally useful for experiments like this, but possibly isn't "general purpose" useful, is a function like ProjectWorldToScreen(point), which takes a 3d point and outputs a "projected" point via the same code that already projects things - i freely acknowledge, though, that would be working around the system somewhat, so you may not necessarily want to provide that, but it would actually solve the problem in this case, since i could project (x,0,z) and (x,height_of_tree,z), and set the scale to (height_of_tree/(y2-y1)) and be done with things.  My actual impedence mismatch when playing with this is I end up using slightly differnet math to yourself, and so things drift.  That way, though, you wouldn't need a whole 2.5d system, just a simple basic function that could be provided saying essentially "here's how you place a 2d object in 3d space" that's like 4 lines long.