Lines Mesh center offset?

Questions
1

I was working on converting a SVG to a mesh today in the playground, and I came across something weird.

I was able to generate a list of x,y coordinates for drawing my shape. i convert that to a list of Vector3(x,0,y) vectors, and pass it to MeshBuilder CreateLines.

works fine, draws it, looks good.

but when i set the line mesh position to Zero, it…doesn’t show up there.

I thought when you made a mesh with MeshBuilder, you could then set position, and it would use the center of the mesh to position it.

I am not sure why, but my bounding box info seems a little odd.

In the end, I ended up importing the SVG into Blender and exporting a GLTF object…and that is having the same issue!

however, the playground just has the values as x,y coordinates, which removes anything blender is doing. what am I missing here?

https://www.babylonjs-playground.com/#QBUZ09#5

Thanks

2

Hiya K. Cool project!

https://www.babylonjs-playground.com/#QBUZ09#7

I’m just playing-around. I did some massive up-scaling of bat in line 69, and forced “eyeball-it” positioning in line 70, and then baked those positions/scalings. You can see that “the bake” resets the position to 0,0,0, and the scaling to 1,1,1… as shown by line 72 console report.

Still, these are all “kludgy” methods, and hasn’t really answered your question. Sorry.

Notice I put all my junk… into lines 65-73… within a scene.onReadyObserve. Lines 67 and 68 were original lines from you. Carefully notice their output when INSIDE the on-ready block… versus NOT inside an on-ready block. They produce different outputs.

Why? It is my theory that .absolutePosition property is not “updated” until scene is-ready. That is why MOST folk use .getAbsolutePosition() METHOD… instead of .absolutePosition PROPERTY.

As soon as I put line 68 into an onReadyObservable code-block, it started producing different values than the #5 playground. So… something is strange, there. The .absolutePosition property… seems to be somewhat “late-updating” and COULD be messing with us. :slight_smile:

Possibly, a bat.refreshBoundingInfo() might be needed at some point, too, though its current boundingBox is looking pretty good.

Stay tuned for more/better comments, and/or teach us what you learn… about “squaring-up” your lines mesh… with world origin (0,0,0). Watch out for WORLDspace and LOCALspace confusions/issues, and be careful if/when setting a parent on bat (which you haven’t, yet, but might, eventually). All these things can/will affect your points-positions and master linesMesh position.

3

I took a stab at again today. I have solved this in blender, by manually resetting the origin to the center of the image.

I looked at the SVG file. SVG defines a viewBox where its coordinates live. i noticed it is 0 0 210 297. if I were a betting man…(and i am!), i think 0 0 is the bottom left corner, and 210 297 the top right. or top left, bottom right.

either way, 0 0 is not the center. and so even though the coordinates are just spots in space, and i’m drawing lines and it’s all good, i feel like this might explain something about why it thinks the origin is like, way back.

https://www.babylonjs-playground.com/#QBUZ09#8

you can see the origin for the bat is nowhere close to where it needs to be. no idea how to fix. i tried (look at bottom) to use a pivot point to fix it, but no joy. I just copied the code from another demo playground. course i think this might allow the rotation and such to act from the new spot, but it’s not working with the position attribute.

it’s a mystery! i looked at the matrixes for localworld and world and pivot, and they all match the pip object, so i feel like the matrix data is fine. it’s almost like there’s a secret offset value somewhere

4

Hi again, K. Yeah, I agree. That matches webGL textures/UVs, too. Lower left 0,0… upper right 1,1 (for uvs). Yep, you got that part figged exactly correct. I think you’re on the right trail… inches from success.

Thx for report/playground… and for the things you are teaching us. Hopefully, more helpers have more ideas, soon.

5

Been thinking about this thread. Sounds like you both have figured out the issue…when you create the lines, that new object " bat" inherits the “offset” that exists in the starting points themselves. Since the starting points are not centered around world.zero, the lines assume the same offset.

We have the ability to move an object’s pivot point: Placing a Pivot - Babylon.js Documentation

It seems like what you’d really want here is a helper function that automatically centers the pivot in the bounding box of the object. Would that be helpful in a situation like this?

6

i see the issue now. Meshbuilder defaults to drawing from 0,0,0. so if the coordinates are far away, it doesn’t realize that they are not centered on 0,0,0.

wow that took a lot of effort.

Wingnut: I suspect the scene ready thing has to do with the call to scale. if I scale it directly in my for loop, I am able to create it bigger and just move it. I avoided the scaling earlier as to avoid introducing side effects.

working PG: https://www.babylonjs-playground.com/#QBUZ09#10

PirateJC, i tried to use the Placing a Pivot in multiple ways, and I was unable to do so in a way that lets me move the position value.

I suspect the Pivot Point is more about rotating and scaling, and not used for calls to positioning. maybe a translate command might work.

I even tried the section on doing it pre-3.2, where you set the PivotMatrix and pass false. although I may have been using the wrong vector value… hmm…

yea, i was trying to use the destination vector of Zero. working Pivot example:

https://www.babylonjs-playground.com/#QBUZ09#11

It would be nice to have a parameter or option in the Meshbuilder to tell it to set the origin to the boundingsphere center? I imagine this is a common scenario.

I’m a noob, but I found an option in Blender in about 5 minutes where it said “set origin to bounding box center”. which is how i fixed my export to GLTF offset with it. i