Maybe a stupid question, but I couldn’t find anything about it:
What causes various Curve assets to spawn exactly 1m above their intended placement?
Doesn’t matter where they are in the asset file.
It works properly only inside the same asset file.
v3.6.5
It it just me? 
Am I going crazy?
What do you mean by Curve assets ?
Curves like Hair or Curve like a Bezier Curve or NURBS path ?
Hair set-ups may lack of info about Surface to stick to.
Curve set-ups may have scaling issues due to a default radius, different than in original blend.
Normally, simple objects should look the same, unless they were dependant of a scaled parent not linked in final file.
Just standard NURBS and Bezier. No parents, no Collections, no Transforms whatsoever.
To make sure: I’ve made a clean file, added a Bezier Circle (or any other type) at World Origin, then “Mark as Asset” without any edits.
Opened a new General file, dragged the Asset.
… and it jumps +1m on local Z-axis from placement grid overlay thing:
Dont know why, but just test it and its the same here.Its definitely the placement command itself that contains the z offset.
I have made a beziercircle an asset and that adds itself at 1, just when I reopen the asset file itself and place it from the assetbrowser into its own sourcefile, then its at height 0
Seems a small bug. I have two files now, one with a circle one with a rectangle.
Whenever they dont get dragged into their sourcefile, they get that offset. Works in both directions.
OK. I was stupid in my first check. I linked the object.
I confirm the bug with 3.6.5 during an Append.
And it is Radius value that is taken into account instead of Z dimension.
If, you set radius of circle to 0, there is no offset. If you set it to 3, the offset corresponds to 3 BU.
And here I thought I must have messed something up.
I’m trying to remember if this behavior was present in early versions of AB. I feel like I’ve used curves before without issues, but there’s a high possibility I’m remembering it wrong.
Out of idle curiosity (feel free to ignore): does it happen in other versions as well? 4.0?
(yeah yeah, being too stubborn to run multiple versions on my PC myself - I like things neat, so sorry 
)
Oh wow, that’s an interesting find. Wonder how that happened… 
Maybe the parametercount changed and someone placed the tadius parameter at a wrong position
I’ve run into this on 3.6.0 and just moved on because I figured there wasn’t a fix for it. Converting the same object to mesh works as expected so it’s definitely a Curve object thing.
Yes. It happens in 4.0 and 4.1, too.
Thanks for the input, guys.
I guess if it’s a proper bug, it needs to be reported then. At least, so far I don’t see any existing reports on the issue…
Welp, guess I’ve got be a responsible community member for once and do the thing
Additional observations:
I started assigning various values to different curve points just to see what happens.
It appears to offset at largest Radius value available.
But it also moves object in XY so that the point with said radius is directly above the target placement.
Or if there are several points with that value, it centers their median point. I think.
Maybe these radius values are like weights.
Not sure if I completely got your testcase, I think its like this:
The placement isnt based on the origin nor is it based on the basic object transform. Its bounding box based. So it tries to place it like that. The object origin is adapted to reflect that, So its not neccesarily in the object params at height 4 for maxradius 4 but the bounding box center is. And its indeed the largest radius that is taken into account as this z value. Just as you said.
The other values xy seem chosen corrrect to align the bounding box to the dragpos, but as the height is set based on the wrong parameter in gets a visual offset in perspective mode… In top view it aligns perfectly with preview for me. Is that the same for you?
Even if I stay in perspective with an “almost” topview and get a visual offset that seems too strong, checking it in ortho after placement shows that it aligns perfectly to the are I chose before.
This is what I mean:
I dropped from Top Ortho view to World Origin both by eyeballing or snapping to grid/ single vertex.
In normal cases (meshes) it indeed seems like it should center on Bounding Box… but this is just weird.
Yes true, same here, didnt have that case in my tests. It doesnt happen if the higher weights are eg not at right and bottom but left and right. It takes the radius into account for the bounding box calculation IMO, but still just a guess.
Funny little bug.
