by Gez » Fri Dec 05, 2014 13:20
GZDoom's model code is very limited. They're something tacked on as possible replacement for sprites, that's all. So instead of taking full advantage of the possibilities models afford, they share some of the limits of sprites. This is particularly true for things like lighting and translucency. There's also the same rendering issue that they will not get rendered at all if the sector where their origin point is located is not visible, which can result in glitchy-looking "peekaboo" behavior when you have a large model in a tiny sector.
There's no doubt that models are better supported in engines such as Doomsday and Risen3D, since they consider models an integral part of the aesthetics they want to offer (doesn't Risen3D load a model pack by default?) rather than just some extra feature some people may want to use some of the time.
GZDoom's model code is very limited. They're something tacked on as possible replacement for sprites, that's all. So instead of taking full advantage of the possibilities models afford, they share some of the limits of sprites. This is particularly true for things like lighting and translucency. There's also the same rendering issue that they will not get rendered at all if the sector where their origin point is located is not visible, which can result in glitchy-looking "peekaboo" behavior when you have a large model in a tiny sector.
There's no doubt that models are better supported in engines such as Doomsday and Risen3D, since they consider models an integral part of the aesthetics they want to offer (doesn't Risen3D load a model pack [i]by default[/i]?) rather than just some extra feature some people may want to use some of the time.