Spring RTS Engine

I have a problem with the easyFacing widget I dont seem to understand. The widget draws an arrow that indicates the facing of the factory when you are placing them.
So I use TraceScreenRay and Pos2BuildPos to translate the current mouse cursor position to the build position.
But when you move the mouse over a feature the return value of TraceScreenRay returns the height of the feature (I think). The returned y-value is higher than before. According to my understanding the second parameter "onlyCoords" indicates that features should not be taken into account? At least when it is true all return values have the type "ground".

Here are two screenshots that show the issue. Since the ghosted factory is identical the widget is supposed to draw the arrow at the same position in both images which is not the case.



In the console there are the debug outputs shown. I think it has something to do with the feature that gets hit by the screen ray. The y-value of the TraceScreenRay is different then also.
In the end the z-Value of the BuildPos is different which should not be the case.

Last but not least, thats the source code in question: Thanks for hints!

But when you move the mouse over a feature the return value of TraceScreenRay returns the height of the feature (I think)

if you hover the mouse over feature/unit it gives the ID of feature/unit.

maybe get height coordinate like this?
http://springrts.com/phpbb/viewtopic.ph ... ay#p506505

knorke wrote:

But when you move the mouse over a feature the return value of TraceScreenRay returns the height of the feature (I think)

if you hover the mouse over feature/unit it gives the ID of feature/unit.

It does only do that if the parameter "onlyCoords" is false. In my case it actually returns ground coordinates. You can see that in the screenshots in the output line "Trace: type: ground".
Only If I set onlyCoords to false then I get type "feature" when hovering over a feature.

i'd check to see if it isn't just giving the coords of the unit/feature when onlyCoords is set to true, i.e if it isn't just doing getPosition() on the id of the traced unit/feature and returning that

TraceScreenRay always checks for intersections with units/features, no matter the arguments. If 'onlyCoords' is on and the ray intersects with a unit or feature, it returns the point of intersection on the collision volume (rather than the unit or feature ID).

I made a feature request some time ago, but nothing came of it: http://springrts.com/phpbb/viewtopic.ph ... 07#p454407.

Workarounds:
a) Use GetGroundHeight(x,z) instead of y value, gives ok results for low units, and bad results for high units (esp. air units)
b) Using some vector maths with the camera, make an approximation of the true intersect position by following the ray from the collision point until y has decreased by (y - getgroundheight(x,z))
c) Implement the trace-ray-to-ground code from spring in lua. I've actually done this, and its quick, but it's 100 lines long which made it too complicated to risk putting into custom formations (which is where this tracescreenray oddity is commonly problematic)

TraceScreenRay is correct, it's Pos2BuildPos that fails (engine & lua use different rounding schemes).

I think Nio is right: you get the coordinates where the ray hits the collision volume of the feature.
But it does not help to just exchange the y-value because the x- and/or z-values are also wrong.

Look at the picture, the problem gets worse when the camera angle is changed (thats why I think the problem is the feature collision intersection):


Pos2BuildPos might also have a problem but as the pictures show the error is bigger than a different rounding result would have.

So I am afraid there is no clean solution to this currently Would be cool to have another parameter for TraceScreenRay to make it ignore features and only intersect with ground.

If this is implemented I would like to tack on another request. When using tracescreenray on a point outside the map, return a virtual point where terrain would be if it were extended to that point.

fix LuaUnsyncedRead::TraceScreenRay when onlyCoords=true
7d95cfe9cd
Browse code
rt authored 8 hours ago

https://github.com/spring/spring/commit ... 355f65a495

Yay big thanks rt! (Kloot?)

I dont exactly understand what the new behavior will be judging from the source code. Will it ignore features when onlyCoords is set or will it return the ground coordinates of a feature which intersects the ray?

The former.

You can test it with http://springrts.com/dl/buildbot/defaul ... ortable.7z.

CarRepairer wrote:If this is implemented I would like to tack on another request. When using tracescreenray on a point outside the map, return a virtual point where terrain would be if it were extended to that point.

I already made that patch two years ago - it's how my SmartSelect widget works outside the map.

http://springrts.com/wiki/Lua_UnsyncedRead#Screen_Trace

Use true for the includeSky parameter to make it work.

I use this to keep perfect track of the selection rectangle while you're dragging it, even if the camera/screen change angle/position during the drag. Works perfectly.

TraceScreenRay(x, y, true, false, true), then WorldToScreenCoords the result at any time to get the screen position of where you originally clicked.

aegis wrote:

CarRepairer wrote:If this is implemented I would like to tack on another request. When using tracescreenray on a point outside the map, return a virtual point where terrain would be if it were extended to that point.

I already made that patch two years ago - it's how my SmartSelect widget works outside the map.

http://springrts.com/wiki/Lua_UnsyncedRead#Screen_Trace

Use true for the includeSky parameter to make it work.

I use this to keep perfect track of the selection rectangle while you're dragging it, even if the camera/screen change angle/position during the drag. Works perfectly.

TraceScreenRay(x, y, true, false, true), then WorldToScreenCoords the result at any time to get the screen position of where you originally clicked.

Wow I wish I'd known that earlier. I can finally improve my camera widget now.