How can I make my compass point to where I want NSEW to be?

SO I have a working compass, but it doesn’t point to where I want North South etc to point how can I change this ?

You can use the control rotation, camera rotation or pawn rotation depending from which relative rotation you wish to read the compass. Can’t see the material setup so I don’t know what is going on there. Are you sure you should divide the scalar argument by 360? or does it take 1 to 360?

That is, assuming you want to read north as the default absolute world vector. Else you need to offset that rotation with the difference to any north direction you have in mind.

2 Likes


This is the material setup, also the compass does work as is…I just want it to point north in a different direction…if that makes sense.

Ok, I assume that Yaw 0 is currently north, to make the north in the material.
If you offset the yaw (add or subtract an amount) in either the material or in the blueprint you show on the first image, then you “change” the direction. If you add 90 as offset to the yaw, your control rotation of the controller would have to provide -90 to get back to “north”.

2 Likes

First of all, what is north?
Even on earth we have true north and Magenetic north. Look it up.

The best way to work within unreal, since occasionally you may want your compass to point at something other than true north (like a magnet?)
Is to create an item/actor you throw in the scene and use as the location for where to point to.

Second.
Usually in a material degrees are pointless. You want a value range from 0 to 1, or, 2 PI radians. Depending on what it is and how you make it move around.

A simple material parameter collection value of the location of the true north item would probably serve better as you can do your own material math within a custom UV (so on the gfx) and compute the orientation whatever way you need it.

Third.
You never update things like a compass “on tick”.
For several reasons behind the obvious ones. One of them being, you simply do not need to.

The material will be updating with its own location. The location of true north you feed it, would only need updating if the object is moved.
This can happen at runtime, so build functions on the true north item to update the MPC if you need it.

Fourth.
Within the realm of UV math you have above, your maximum range for yaw is within 0 to 1.
So 1/360 would be your minimum value.
This ofc is immidiately prone to all sorts of issues from floating point precision.
Will it work? Sure, it should.
But make sure the values you feed in are always normalized in the 0 to 1 range. Or go even further and only provide degree specific values (multiples of 1/360).
Again, if you just do the math in the material based off the true north location, you wouldnt have as much of an issue.

Compasses don’t point to true north, they point to magnetic north. But it doesn’t matter here at all so I’m not sure why mention it? They didn’t mention and gave no indication they are simulation grid/magnetic deviation - and that doesn’t have anything to do with true north either.

Seems like you are adding complexity instead of simplicity, for what reason?

Not sure how the material is working but you can just use a constant. 0 means x+ is north. 90 means y+ is north, etc.

If you wanted to simulate grid/magnetic deviation you just add/subtract that to the constant.

Don’t see any reason not to update it on tick. You want smooth lerping, and there is no real math or anything heavy involved. Much simpler to do it on tick than any other method, isn’t it?

One issue with point to some actor is that unless you have the actor crazy far away, you can get inaccuracies. But this is more of an issue for very precise simulations, which I don’t think is involved here?

Since it is clear - and it is also highlighted by your own admission - that you don’t know any better, I for one would appeiciate if you stopped giving people bad advice and making them trash their projects.

You have done so repeatedly, and were even told not to by staff at least once in the past year.

You aren’t “expressing an opinionon”, you are talking about technical things you do not understand.

Explain how my advice is bad here then, and defend against the counterpoints I made.

Are you confusing me for someone else? I’ve never got any messages from mods.

Flagged post happen from any community member flagging it, that’s nothing to do with staff.

Who is trashing their projects based on forum advice? Have you done that? Don’t you use version control and keep control of your project when trying new things?

My current game project is entirely based around the realistic use of compasses - a skill I’ve used professional for much of my adult life. Have you got any projects with such heavy use of compasses? You’ve said some inaccurate, non-sequitor stuff about true north so I think probably not.

Just because you feign confidence doesn’t mean that you are right, ya know. And it doesn’t fool anybody.

I think that overcomplicating simple things as a general principle is more likley to spell trouble for people, compared to updating a compass on tick.

So can you explain how feeding a constant value to describe north into the material is going to trash someones project? That is what I am doing in my project which military professionals are using right now to get advantage for some of the most challenging courses in the military. I don’t use a material though, I am actually rotating a static mesh, but the value to describe north shouldn’t matter if you are pumping it into a MPC.

And can you explain how true north is relevant to the problem here?

  • Image used:
    Compas

  • Material:


    The offset basically just shifts the image horizontally, so it should be between 0.0 and 1.0 since it will loop.

  • Result:
    UpdatingCompass

Hope this helps.


I compare the current yaw with the value of prev frame to know if it has changed to update. This was pdlaced in the function that updated the yaw (in c++ since its what I currently have setup)… so its technically using the tick of the movement component? :rofl:

1 Like

I appreciate the info, Thank you!

Thank you for this!

This worked perfectly! ty!

Ty all for the input! Two solutions worked well for me here. Both sort of interchangeable. @pezzott1 Solution also works. Ty again!

1 Like

Almost. Use object rotation.
A little of trig between the 2 to get the rotation to feed as yaw.
The camera that the UI is attached to rotates, so the rotations nodes will work.

Then your mpc can be left as the position of whatever north you want.

There’s no need to update parameters constantly - not even with the yaw change, since all of it can happen within the material.

Made a quick test using cameras forward vector, but some nodes do not work when set in image widget:


Can’t think of a solution that does not rely on some actors tick to update the material other than setup a 3d widget and attach it to the camera.

Expanded the material to test on widget element and actor in world:

Did you try any of the Object rotation / pivot nodes?

Yes. They all work on a 3D widget attached to the camera, but not when the material was applied in a widget added to the viewport.

I’d have to set it up to test it as in my project(s) the UI is within a helmet, so not a UI material.

What about WPO?
Assuming it prints out, you’d have to subtract acror location from it - and you’d have to use an mpc again, so it defeats the purpose. But if it works, maybe the pivot large values can be used to normalize it?

There should be more than 1 option exposed to the UI either way. Its possible the latest changes gutted the functionality of it…