[JASS] SetCameraTargetControllerNoZForPlayer() and GetLocationZ()

[nesatauri]

So, while my main project rots away in the back of my mind, I turned my attention to an old interest:First Person Cameras. I still haven't installed tFT on my laptop, so I wanted to see how much I could do with the RoC functions. I already had made a couple of FPS maps on tFT which were leaky as hell, so I had a general idea of what I had to do.

However, those old maps were limited because back then I hadn't figured out how to move the camera in the Z direction correctly, so the terrain was flat. Well, I got a bit ambitious and wanted to overcome this, so after a bit of fiddling around I found that calling SetCameraTargetControllerNoZForPlayer() over and over again would almost keep the camera at a Z appropriate to the terrain height.

I say almost because in spots were the terrain was higher than the base cliff height (because of cliffs or raised terrain) I noticed that the camera's Z Offset would lower lower and lower, the higher up I went, even going so far as to make the camera target go below the terrain. I used GetCameraTargetPositionZ() to find out what was happening and found that the camera target wasn't climbing to the same Z height as the unit the camera was supposed to be targeted on.

GetLocationZ() isn't available unless you install tFT, so I wanted to ask you: Is GetLocationZ() any better at finding the terrain's Z height than SetCameraTargetController() GetCameraTargetPositionZ() is?

If it is, a FPS camera that adjusts to bumpy terrain should be only take a little more work with tFT functions.

-----
Anyone know what bug Purplepoot is talking about [post=338101]here[/post]?

 

[xXx-Tricky-xXx]

yes, you will need TFT, GetLocZ is a requirement for any camera. LocZ will in some cases give you the effect you might want, but it is very flawed. It will inaccurately calculate height values on hills, bumps, water, anything that is not originally flat in war editor. The bug he may be speaking of is very well what I just mentioned, and the only way I found around this camera flaw is to use terrain deformation to create hills etc. LocZ is near 100% accurate using terrain deforming via triggers, even on hills that touch the limit of the map.

To my knowledge, no one has figured out how to get around this problem. There is, however, a formula that I think is supposed to fix this problem, but I myself cannot get it to work, because the formula itself is very vague on the variables. I found it a few days ago.

FPSMod Camera Tutorial - Wc3campaigns

 

[nesatauri]

Aha, so I guess SetCameraController() uses the same method of finding Z height as GetLocZ(). Bummer... It would of been nice if I could correct SetCameraController()'s errors with GetLocZ(), but if they are both just as horrible at finding Z height... darn.
From your link.

After a bit of research I figured out that the Z Axis for the camera's target has a height map which isn't actually flat. In fact there's a Z Correction height map that blizzard automatically generates for its camera target to follow, the way this height map looks is difficult to describe but it could be imitated if every terrain up or down that you made in the editor was about 1/5th as high/low and about 3 times as wide. It's almost like every change makes much smaller but much wider ripples in the camera map, causing it to go up as it approaches mountains even though it is still on flat terrain.

Hmmm thats interesting. I guess GetLocZ and SetCameraController aren't experiencing the same bug if this is the case. GetLocZ should just use the terrain height map (war3map.w3e I think). The separate camera height map explains very nicely what I have been seeing with SetCameraController. I wonder if the camera height map is generated by world editor and put into the map archive like war3map.w3e is or if it is generated when the map is played. TheEpigoni wasn't very clear on that.

His method of adjusting the height seems needlessly complicated compared to what I was thinking of doing. Feel free to steal my ideas

• Dynamic Angled FP Camera 1
  • Events
    • Time - Every 0.05 seconds of game time
  • Conditions
  • Actions
    • Set CameraEyePosition[1] = ((Position of CameraEyeUnit[1]) offset by (0.00, 0.00))
    • -------- CameraEyeUnit is the unit with which the camera source should stay with --------
    • Set CameraTargetPosition[1] = ((Position of CameraEyeUnit[1]) offset by ((Eye_Target_distance x (Cos((Facing of CameraEyeUnit[1])))), (Eye_Target_distance x (Sin((Facing of CameraEyeUnit[1]))))))
    • Unit - Move CameraTargetUnit[1] instantly to CameraTargetPosition[1]
    • -------- CameraTargetUnit is the unit the camera should be locked onto eventually --------
    • Set CameraEyeZ[1] = (Z of CameraEyePosition[1])
    • Camera - Lock camera target for Player 1 (Red) to CameraTargetUnit[1], offset by (0.00, 0.00) using The unit's rotation
    • Set CameraTargetZCorrection[1] = ((Z of CameraTargetPosition[1]) - (Target Z of current camera view))
    • -------- Compares the camera height to terrain height --------
    • Camera - Set Player 1 (Red)'s camera Z Offset to (CameraTargetZCorrection[1] + EyeLevel) over 0.00 seconds
    • Camera - Set Player 1 (Red)'s camera Rotation to (Facing of CameraEyeUnit[1]) over 0.00 seconds
    • -------- And the rest of this is just stuff to make the camera angle of attack do nice things --------
    • Set CameraTargetZ[1] = (CameraTargetZCorrection[1] + (Target Z of current camera view))
    • -------- Or just use GetLocZ, duh --------
    • Camera - Set Player 1 (Red)'s camera Angle of attack to (Atan2((CameraEyeZ[1] - CameraTargetZ[1]), Eye_Target_distance)) over 0.00 seconds
    • --------- better to use custom script here rather than GUI, GUI uses Atan2BJ instead of Atan2 --------
    • Custom script: call RemoveLocation( udg_CameraEyePosition[1] )
    • Custom script: call RemoveLocation( udg_CameraTargetPosition[1] )

Well, maybe not...

 

[xXx-Tricky-xXx]

that is similar to what I attempted, minus the angle of attack part you added, and a few other lines. But ofcourse, mine didnt work. I havent tried to 100% replicate yours to see if it works but, you might want to mention what the eye distance is, it can drastically change the effect of the camera if you have it as a negative or a positive value and the distance. Is it the distance of the unit that is being moved, or is it going to be 100 behind the unit to make up for the target distance that is at a minimum value of 100.

I can try to scrape up my attempt if i can find it, and compare later but Ill probably refix it a bit first now that I am looking at yours. I was using get camera eye position isntead of Z of yours, i dont know the difference though, since neither works right now I cant tell. But eye position script will tell you the Z of the current camera precisely.

Also, try adding hills and stuff in map editor, and test it in game, see how it works, im very curious. There is no problem with camera at all using LocZ when you have a 100% flat map and just make a ton of terrain deformations using permanent crator and its flawless, but its hard to make a map look good using triggered elevation. I have no idea why map editor height values would effect the camera or locz and crators dont, very odd.

 

[nesatauri]

Also, try adding hills and stuff in map editor, and test it in game, see how it works, im very curious. There is no problem with camera at all using LocZ when you have a 100% flat map and just make a ton of terrain deformations using permanent crator and its flawless, but its hard to make a map look good using triggered elevation. I have no idea why map editor height values would effect the camera or locz and crators dont, very odd.

I'll have to go out, buy, and install tFT first, but I'll be free to do that tomorrow hopefully. I don't remember exactly how the tFT camera stuff works (had tFT on a computer long ago but I lost the computer and the disk ) but I can probably make it work without that cameraTarget dummy unit.

Eye_Target_distance is a bit less than 100, I think around 70, and the cameras distance to target is 100, so that the camera source is actually inside the Eye unit (so the rifleman's gun shows up ) and to get a good angle for the camera.

Actually, now that I think of it, Antiarf's Vector System might give me better results for camera angles, I would just have to shift my brain into vector calculus mode again. (thinking out loud)

Anyhow, I've been making really weird terrains using Zepir's world editor and that thing about the cameras following a different height map has to be true. There also seems to be a different height map for flying units too. And yep, they're dynamically created at game time so its not like you can rip them out of the map and change them

It would take a lot of mathwork to get the terrain you want out of those deformation triggers. I forgot about their existence, I must have never used them. Maybe GetLocZ works really well with deformations from triggers and not so well with deformation from the original map because the game compresses the height map, smoothing things out. I don't know...

 

[xXx-Tricky-xXx]

hmm, ya indeed it sucks that they both use different heights, i guess I may have to just trigger every hill bump and slant, oh well, that is unless your attempt works.

I like what you have done with the target centering on the units head, but I prefered using the right triangles to find the x and y coordinates in the lock camera to unit. I dont think its different either way, but it was just preference I guess, i am assuming the move unit thing was just a test for you and it is not precisely how you intend to use it. You are kind of doing that wierd, using a camera value to move a unit, instead of defining its own speed first.

Ive had my first person shooter beta due month or two ago but never got around to getting it ready because of this stupid height issue, but I guess i may just have to make a simplified map and hope it doesnst look liek crap from using crators.

 

[nesatauri]

yeah, that target unit is probably unnecessary, The camera would end up at the same Z at the same exact spot you put your camera target anyway due to that camera height map. Maybe it can serve as a crosshair later on (not that thats necessary either, maybe to make the game more immersive)

Huh... GetLocZ must have come in a patch... it wasn't on the tFT install. Updating ...

 

[PurplePoot]

Just have a second, but as for

Anyone know what bug Purplepoot is talking about here?

It was actually bad behaviour with fly height that shouldn't've been happening, but either way, it's actually irrelevant to GetLocationZ().