Status of support for Marker/Trail Attributes about burrito HOT 6 OPEN

I already created a task list today at coderedart/jokolay#4 , I will just copy paste some of that stuff

from burrito.

I think it makes sense to track various tags in a meta issue or a milestone that links to any necessary sub-issues. Once the first draft of the burrito schema decided then it makes sense to also include the chart in some more publicly documented area such as the readme or a wiki.
The following points can be moved to the relevant bugs.

I agree with your conclusion on height offset being mostly irrelevant, the only use-case I could imagine off the top of my head would be to adjust the height of an entire path at the same time. If that is a real use-case it can just become a feature inside of the editor panel instead of being an attribute.

minSize and maxSize was something I looked into but did not fully implement. There is already a bit of shader code here that might help with implementation. The catch is that that value is just a flat scale multiplier and not a pixel size so some work would need to be done to convert that using the size of the icon texture.

from burrito.

minSize and maxSize have been a pain point for blish too it seems. I just changed the renderer from 3d to 2d, just to support this particular attribute in my overlay.

Will you be creating a meta issue/milestone for this? i have no idea how those work.

from burrito.

In burrito all that will probably need to be done is just dividing textureSize(texture_albedo) by the min and max to get a float scale value in the vertex shader. It should be tied into #16 when that is implemented too.

A task list makes the most sense compared to a milestone in this situation. I dont think special permissions are required to create one.

from burrito.

is that okay? i suck at formatting

from burrito.

I agree with your conclusion on height offset being mostly irrelevant, the only use-case I could imagine off the top of my head would be to adjust the height of an entire path at the same time. If that is a real use-case it can just become a feature inside of the editor panel instead of being an attribute.

Another common use case is combining it with the behaviors as a node might be on the ground and you want the trigger radius tight around that object (to avoid triggering the behavior when the player isn't actually at whatever it is) but you don't want the marker rendered on the ground - you want it higher so that it's easier to see. That's not to say there aren't better ways of handling that, but that's been a common use I've observed.

from burrito.