3D Graphics glitch?

[Xerxes77]

Trying the newly released 4.01 version of Final Struggle, I found a weird glitch in the 3D view:


The three cavalry units in the pic above are at a lower level than the elevation they're facing (hard to distinguish due to the very subtle color grading), which explains why the bases of the leftmost two units are partially obstructed. However, the rightmost unit appears to be climbing the slope.


The same units, with hex contours on.


And the corresponding 2D view.

I noticed this happens in all scenarios, but only in certain hexes. Is this a known limitation of the 3D engine, or a glitch introduced in this version? Or is it somehow a corrupted file on my end? I don't have any of the other Nap titles to check.

[LarkinVB]

Since I didn't mess with that part of the code, I guess it is an engine limitation. Please provide the hex coords so I can check what's going on.

[Xerxes77]

Since I didn't mess with that part of the code, I guess it is an engine limitation. Please provide the hex coords so I can check what's going on.

Hi Larkin, the examples above are from the Getting Started scenario and the three hexes are (2,10), (3,10) and (4,9). There are other instances of units straddling slopes at (9,9) and (18,4).

[-72-]

Since I didn't mess with that part of the code, I guess it is an engine limitation. Please provide the hex coords so I can check what's going on.

Hi Larkin, the examples above are from the Getting Started scenario and the three hexes are (2,10), (3,10) and (4,9). There are other instances of units straddling slopes at (9,9) and (18,4).

Having a bit of experience in this area ... I don't really thing it is a 'glitch' as much as it is a 'quirk' of the isometric view.

I think this is a layer draw order issue, which can't be changed by modifying the art files - it would be in the programming itself, and any art modifications would only able to try to mask this. 

Basically, a known issue. If you were to set those units up right next to a woods hex area -with woods instead of a hill, you'd see the same thing happening - but it would look like being mostly in the woods (educated guess) -it has to do with layer drawing order that the engine programming does -not really anything that Nick can change himself. (Educated guess).

[Xerxes77]

Since I didn't mess with that part of the code, I guess it is an engine limitation. Please provide the hex coords so I can check what's going on.

Hi Larkin, the examples above are from the Getting Started scenario and the three hexes are (2,10), (3,10) and (4,9). There are other instances of units straddling slopes at (9,9) and (18,4).

Having a bit of experience in this area ... I don't really thing it is a 'glitch' as much as it is a 'quirk' of the isometric view.

I think this is a layer draw order issue, which can't be changed by modifying the art files - it would be in the programming itself, and any art modifications would only able to try to mask this. 

Basically, a known issue. If you were to set those units up right next to a woods hex area -with woods instead of a hill, you'd see the same thing happening - but it would look like being mostly in the woods (educated guess) -it has to do with layer drawing order that the engine programming does -not really anything that Nick can change himself. (Educated guess).

Thank you, I was thinking along the same lines, that this had to do with the drawing order... but the fact that this affected some hexes and not others bothered me.

And then after a few more tests I discovered that if you turn the straddling units clockwise or counterclockwise in the same hex they occupy, they will sometimes appear correctly covered! And conversely, units displaying correctly will appear as straddling the two hexes when turned in a certain direction.

So it seems a unit will show the correct cover depending on its facing. Considering a rotation consists in simply replacing a sprite with a different one, I think we could actually be dealing with a small glitch, of course this is pure speculation on my part.



EDIT: Just created this small animation to illustrate the visual issue (used a leader and kept rotating him in place). As seen above, the base only crosses the hexside in certain positions. As far as I can tell the Civil War games are not affected and all the bases clip properly whatever the facing.

[Xerxes77]

Just a quick update to confirm that in the Civil War demo all units are clipped correctly when standing behind an elevation, regardless of their orientation.

Considering the engines are mostly shared between series, hopefully this is something that can be tweaked in the Nap games.

[LarkinVB]

Problem is noted and will be resolved with the next patch cycle.

[Xerxes77]

That is so awesome, thank you :-D