• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Problems with setting camera height offset

Status
Not open for further replies.
Level 6
Joined
Apr 4, 2010
Messages
74
Me and a friend has been working on a map that plays out in first person.
We have a trigger that runs quite often that is made to move the hero around and set the camera height.

In order to set the camera height, we use the function "GetLocationZ(Location)" to find the terrain height at the position of the hero.
We had a bug because of the fact that the optimal camera height and terrain height isn't the same but abit of math fixed it.

Anyways, here is the problem:
When you walk close to the edge of a cliff, the camera gets further and further down towards the ground and eventually ends up below the terrain. We do not have the same problem when just changing terrain height to create cliffs, but my friend/terrainer insists that we use cliffs since he has a hard time making stairs otherwise, and he has already done alot of terrain this way.

I've run a text message to show me the Zheight and the result that the camera should pan It's height to, and its always the same even though the height gets farther and farther down. I think this has something to do with the fact that the camera goes up and down when it faces a cliff in overview mode.

Here is the part of the trigger that matters:
  • hello world
    • Events
      • Time - Every 0.08 seconds of game time
    • Conditions
    • Actions
      • Set Loc = (Position of PlayerCamUnit[(Integer A)])
      • Custom script: set udg_ZHeight = GetLocationZ(udg_Loc)
      • Set TempReal[2674] = (1.00 - (ZHeight / (ZHeight + 26.00)))
      • Camera - Set (Player((Integer A)))'s camera Height Offset to ((ZHeight x TempReal[2674]) + 200.00) over 0.00 seconds
      • Custom script: call RemoveLocation (udg_Loc)
Integer A represents the player and PlayerCamUnit is the hero.
So I need to find a way to prevent the height to change near edges of cliffs, perhaps another function/action that changes the height?

Here are screenshots of what happens.
The real behind the "Z:" is the actual terrain height.
The real below that is what the calculated (camera) height is.
The trigger runs fast, therefore there is alot of text messages

When standing at center of cliff
unledbqj.png

Here is what happens at edge of cliff, as you can see the reals are the same.
I accidently overlapped the pictures (sry) but it still shwos what I want.

unled2is.png


Anyone has any ideas?

Summary to clear misunderstandings
I use getLocationZ to calculate terrain height. I want to use this to set camera height.
But when im near edge of cliffs the camera ends up below the terrain even though the terrainheight is the same as when im above it, at center of the cliff.
I think this has something to do with wc3's standard way of panning camera when it ends up at cliff terrain. Anyone has a smart sulotion?
 
Last edited:
Level 28
Joined
Jan 26, 2007
Messages
4,789
I've been trying to re-create this bug, but to no avail.
Every time I stand next to the cliff with my hero, the camera height doesn't change (neither does the location Z).
I tried reducing the collision size, as maybe that prevented my hero from getting 'too close' to the cliff's edge, but again: no results.
Then I just made him flying, for the heck of it, and moved him as close as I could without changing the location Z: the camera height did not change.

The camera source should be the same as the unit's source.

Edit: Oh, no! There's the bug! It's due to the math-thing of yours. I'd remove it altogether if I were you...
At a height of 640, the camera height will be 224.985
At a height of 1280, the camera height will be 225.482

So that's a 640 Z height increase, and a staggering 0.497 camera height increase (while 1 cliff level is a 128.00 height change). See the problem there? That's not going to cut it. At a height of 640 it looks nice and all, but once you get lower/higher, it starts to get stupid.

I know the camera height doesn't change completely correctly when the terrain height changes (it does it a bit automatically, but just not accurate enough), but you're overcompensating Warcraft's mistake by making it almost impossible for the camera height to get a visible change.
 
Level 6
Joined
Apr 4, 2010
Messages
74
I've been trying to re-create this bug, but to no avail.
Every time I stand next to the cliff with my hero, the camera height doesn't change (neither does the location Z).
I tried reducing the collision size, as maybe that prevented my hero from getting 'too close' to the cliff's edge, but again: no results.
Then I just made him flying, for the heck of it, and moved him as close as I could without changing the location Z: the camera height did not change.

The camera source should be the same as the unit's source.

Edit: Oh, no! There's the bug! It's due to the math-thing of yours. I'd remove it altogether if I were you...
At a height of 640, the camera height will be 224.985
At a height of 1280, the camera height will be 225.482

So that's a 640 Z height increase, and a staggering 0.497 camera height increase (while 1 cliff level is a 128.00 height change). See the problem there? That's not going to cut it. At a height of 640 it looks nice and all, but once you get lower/higher, it starts to get stupid.

I know the camera height doesn't change completely correctly when the terrain height changes (it does it a bit automatically, but just not accurate enough), but you're overcompensating Warcraft's mistake by making it almost impossible for the camera height to get a visible change.

I thought that wasn't the problem since the Zheight always remains the same, and it works perfectly fine at the center of the cliff. But ok.

That math thingy was actually written by you, but it wasn't very accurate at medium heights so I changed +256 to +30 or something which made the scales look better.

If I change it to +256, it still goes down to slightly underground, though.
But if you're sure that there is no way to set height ignoring the fact that it likes to go down around edges, I'll guess I have to be happy with that and tell him to not make high heights with normal cliff.

Thank you and +rep!
And a huge thank you for that math thingy, even though it might be abit late to thank you.
 
Level 28
Joined
Jan 26, 2007
Messages
4,789
That math thingy was actually written by you, but it wasn't very accurate at medium heights so I changed +256 to +30 or something which made the scales look better.
I know that :p
The problem is that I've never used that with cliffs, never realized that would bug it. Also, when I made that system: I knew it still wasn't perfect, I still had issues with a camera that was either too low or too high, this 'imperfection' gets worse the higher/lower you get (maybe the +26 would've been better, I don't know).

I will search for a better method tomorrow, I really hope I stumble upon something useful :/
 
Level 6
Joined
Apr 4, 2010
Messages
74
I know that :p
The problem is that I've never used that with cliffs, never realized that would bug it. Also, when I made that system: I knew it still wasn't perfect, I still had issues with a camera that was either too low or too high (maybe the +26 would've been better, I don't know).

I will search for a better method tomorrow, I really hope I stumble upon something useful :/

Well as you say, wc3 isn't designed for first person.
Still, its fun to kind of break the rules. Like people always search for glitches :ogre_hurrhurr:

Thanks again!

EDIT:
On another note, how do I set this to "solved"?
 
Level 28
Joined
Jan 26, 2007
Messages
4,789
Well, moderators can set threads to solved, but that's a lot of work for them (checking all threads whether one of them might be solved...).
So mostly, threads here just 'die out' :p

Well as you say, wc3 isn't designed for first person.
Still, its fun to kind of break the rules. Like people always search for glitches
I completely agree with that :D
 
Status
Not open for further replies.
Top