'Line Trace by Channel' appears to be offset at high speeds

Development World Creation
, , , ,
1

Hello everyone. Thanks for taking the time to read this.

I have been having an issue with the ‘Line Trace by Channel’ variable as of late. I am drastically updating my solar system app that I created a few years back, so I have to deal with very small and very large assets (because the planets scale up and down), which can travel at very high speeds.

I have already written up a page on the UE4 forum regarding this, and it appears that at least one other team is having the same issue.

Here is the link to that page: 'Line Trace by Channel' appears to be offset at high speeds - Blueprint - Unreal Engine Forums

I have tested this out in a few different ways, and the end result is always the same. At higher speeds, the ‘hit’ detection appears to be calculated ahead of where the object is heading. I even put an "OnClicked’ node on the planet to see if that would give a different result, and the hit detection is in the same place as the ‘line trace’.

To help fix this issue, I have included a very stripped down version of my project for anyone to check out if they want to see exactly what I’m seeing. Re-creating a bug can be a pain in the butt, so I am trying to minimize that as much as possible. The file is very small (Only about 4.5 megs)

Here is the link: https://dl.dropboxusercontent.com/u/80093308/TSS_EYB-4.7.2_Testing_Purposes.rar

Here is a very quick run through of the app. When you start it in the editor, you will fly into Earth. I have a simple ‘double click’ detection set up, so if you click on any planet twice, you will focus in on it (or reset if you’re already focused on it). On the upper left hand side you will see a toggle for scaling up the planets. To control the speed of the planets orbit (which is where the issue really happens), I have set up a simple button press from 1 to 9, 1 being the slowest, and 9 being the fastest.

To see exactly what I see, keep the planets small, and choose 1 or 2 for speed. You will see things working relatively normal. Now, if you bump it up to 4 or 5, you will see the collision detection is ahead of the planet. When the planets are larger, they have a bit of this issue as well, but due to their size it isn’t as obvious.

I hope someone can help me out with this bug, It would be greatly appreciated!
(I hope my files help)

2

Hi C Albeluhn,

Thank you for the thorough report and test project! :slight_smile: I was easily able to reproduce the issue you described.

I’ve entered it as JIRA UE-11536 in our tracking software and our developers will be investigating it further. We’ll update back here when there is news.

Cheers,

TJ

3

Thanks TJ!

I’m glad you were able to reproduce the bug on your end as well (and that it’s not just my computer), and also that nothing was missing from the file I provided which would prevent you from seeing it.

I hope you guys can find an easy fix (easier is better after all), and I look forward to hearing back from you guys.

Till then, take care! :slight_smile:

4

Hey TJ.

I have noticed a few new graphical glitches in the scene I mentioned in my first bug report. I wasn’t sure if I should post it here or make a new one, but I figured it might be best to keep everything together in a single post.

The issue I am running into is more than likely due to the enormous distance I’m using for the outer planets such as Neptune. When you have the planet scaled up things don’t look too bad. However, when you have the planets at their realistic size and you zoom in all the way, you will see two main things.

  1. The animation of the planet appears to ‘jitter’ when you run the program at any speed (based on the 1 to 9 button setup mentioned earlier).

  2. The second issue is a little bit harder to see due to the first issue. If you look at the default checkerboard texture on the planet, there is a slight ‘wobble’ to the update of the material. The closest I can describe it is the wavy heat distortion that hot roads give off.

Both issues slowly decrease as you focus on the planets closer to the center of the map. It’s not until you get to the third planet from the outside that the effects are greatly decreased, and by the fourth planet in the effects are basically gone.

I hope you can see the same thing I’m seeing on my end. If not, I can try to take some footage of the issue for you. Just let me know.

Till later, take care!

5

Hi C Albeluhn,

Thanks for trying to keep everything together. In this case though I think it would be best to create another report because the issues are so different. I would keep it in the Bug section but it seems like it will be rendering related.

6

Hello again TJ.

Thanks for the quick reply! I’ll get a bug report done up for you guys on this issue the minute I have some free time, and I’ll do the same as I did above where I provide a test project file to make things a bit easier to see.

7

I just came across this and I am too late it seems, but there’s a tiny chance you’re still interested, or more likely someone else will arrive here.

This absolutely sounds like a limitation of 32 bit floating point numbers, both issues.

I’m guessing you define the sun as the origin and so Neptune is a great distance away. To zoom right in on the planet would require a huge amount of precision in the way the location value is stored. 32 bits just won’t do.

My proposed solution to this would be two entirely separate models - a planet centric model, and a sun-centred one (a ‘heliocentric model’ if you will :P). When you are zooming in, at a certain point the camera is teleported to the planet-centric model. Depending on what planet you are approaching, you’d have to switch out which model is the centre one and re-position everything. It should be totally seamless though.

A lot of work but them’s the breaks. Or you could see about using 64 bit floats, but I’m not sure about any 3d engine that actually uses them. They are all compiled for 64 bit architectures of course but storing objects with 64 bit cartesian coordinates, I don’t know.

8

I just thought of another option that would probably be easier - essentially play ‘musical chairs’ with the origin. When you get close to a planet, you move every single mesh, as well as the camera, so that now the nearby planet is the origin. Should work pretty well!

9

Thank you for repotring this bug. This is really big problem, that people meet while using line traces. Actually not only in case where you’re having planets, but also in case (i’ve had such one), where you need to simulate wheels, but you can’t use physics constraints because of different reasons. Thank you so much man!

10

Maybe. But the same problem appears to e also on lower speeds, so i believe it’s not exactly 64 bit problem. if it is, then maybe it is the problem with engine calculations - it needs more memory to manipulate with floats,and to return result completely, instead of truncating it.

11

@C_Albeluhn was this ever fixed or changed?

We did run into a similar or the same issue on 5.3, but there should be a new physics engine?

Basically we do a LineTraceSingleByChannel on a moving object and the hit results start to get wrong or don’t hit anything if the object starts to move faster. If the object slows down again, the hit results stabilize and are correct again.

12

So, there are options to do things on a specific ‘group’ of the frame. The ‘tick’ function for example. If you click on any blueprint and go to the ‘lass defaults’, under ‘actor tick/advanced’ you’ll see an option for ‘tick groups’. This might help you out.

The fastest way to explain it is simply, this controls what time of that frame things are updated. There options are ‘Pre Physics, During Physics, Post Physics, Post Update Work’ options. For my project, I did major time calendar calculations on the ‘Pre Physics’ tick group, updated the location of the assets on the ‘During Physics’ group, and did a line trace when clicking on the ‘Post Update Work’ group. This helped make sure things were calculated in order before I did my line trace.

I hope this helps!