Hi Aaron,
first of all - Aline and A* have both been a great help in the current project I’m working on, especially Aline is a tool I will be recommending my Unity3D clients from now on.
One thing popped up as a minor annoyance recently though:
Lines keep the same width in pixels regardless of the distance from the camera. I think this is especially prevalent when using a “WithLineWidth” scope.
My expectation would be for the line to not appear like it changes thickness as I move trough space. (Except if I explicitly want that to happen ofc)
Looking around on the forum I did not see anyone talking about this.
This issue felt basic, but I’m not sure if I might be missing something.
In most cases I am not troubled by it, but for some applications (like a level editor I built, featuring an optional overlay with Labels over objects) this behavior gets out of hand and clutters the screen.
Should there currently be no simple way to resolve this I’d like to propose the following:
I believe there is currently a scope for drawing in screen space - when not using this scope (or possibly a new similar scope) I would expect the line width to not be tied to screen pixels, but rather have a width in world space.
Cheers!
2 Likes
Hi
This is a good idea and has been requested by others.
Until I implement this you can emulate it using something like WithLineWidth(20.0f / distanceToCamera)
Still hope this feature will be coming at some point.
The main reason why the workaround with distanceToCamera is not ideal at the moment is that it works well if I only need to draw gizmos (only scene camera) or only need to draw ingame elements.
But as soon as the scene camera and scene camera are not at the same positions the drawn elements look very disproportionate.
Just chiming in to say I too would really like this. The workaround doesn’t really work because the further away a position on the line is from the point that was used for the distance calculation. The thinner the line will become.
Any chance we might be able to get an update with this feature?
Gonna continue this conversation as this exact suggestion is what I need in my game, it’s really annoying being tied to screen space rather than world space and just makes everything look like a mess, not my specified values. Please implement this feature and let it work how it does right now when using the .InScreenSpace scope, but in world and local space, it should be world space pixels, rather than screen space pixels.
Please do let us know what’s going on with this implementation, also a side note, the emulation you gave doesn’t work properly and I can’t actually fix this issue in my project unless I do some mess of calculations to allow it to figure it out, but on performance tight games, that isn’t really something I can do especially since there will be a lot of draws going on.
I’m not sure why this hasn’t been implemented in 4 years, although I really need this implementation, and I’m sure others would too, maybe an option in settings that allow people to keep the current functionality for those who like it as it is, and we others can have it disabled?
I think this is a valid feeling and a valid feature request. That said, a lot of feature requests are made between ALINE and Astar and, as I’m sure you can sympathize with from your own experience as a developer, you have to pick and choose your battles wisely. Don’t take this as direct pushback as much as it is my (personal) answer to your question–
It’s been a good amount of time since this has had any discussion though. I’ll ping Aron on this and maybe we can get his feedback on where he’s at with this suggestion/feedback. Thanks for adding your thoughts to the discussion, genuinely 
1 Like
It’s understandable, I don’t think it would be an easy implementation as the systems all base around pixels (assumption), and changing that would be a pain, just seeing the time it hasn’t been implemented without any notice of why is a bit confusing, even a simple message saying it can’t be implemented would be great.
Thanks for replying though, I do understand if it’s not possible, and will find a decently functional workaround if it’s told that it’s not possible to do relatively easily/not worth implementation.
My point previously might have came across wrongly, I simply would like to have an update on this to know if I should put the effort in to making a decently functional workaround rather than having a solution be implemented.
1 Like
Hi
This is not the direction I’m aiming for ALINE to go in, though I will consider this feature request. It has some performance implications and technical considerations.
I don’t expect it to be a focus for the near future, though.