Vertex Group from blender [solved]

What is the process for storing the the indices of a vertex group that is on a mesh in blender exported to BJS?

Like lets say I have a specific selection of vertices that I set in blender and I need to be able to reference all of their positions once imported into a scene and some manipulation has happened to them?

Knowing a vertex index you can get that vertex using:

let positions = mesh.getVerticesData(BABYLON.VertexBuffer.PositionKind);

let myVertex = positions[index]

But how do I store a group in blender, then reference it in the imported .babylon scene?

I don’t think it is supported

What would be the best way to make it supported? :slight_smile:

Im looking at

and I’m trying to figure out when and where the script accesses the vertex groups for skeletal weights.
If I can find that section then I can prolly figure out how to make an option to store specific vertex groups on export as extra metadata.

Actually as I am reading through it I think its accessing that as vertex data not as a ‘tag’. Might have to think about this more.

It looks like you can access the VertexGroups with bpy pretty easy, I just now gotta think about where and when on the exporter I should do it.

I wonder if just for my use case if I write up a python script just to export the indices as a comma separated list for whatever vertex groups I need and then reference those… though making them supported on the importer exporter might be useful for others.

yeah that looks like the best way for now

First look at what @ozRocker did in the old forum. Also, the exporter writes the faces of triangles, and does not consult vertex groups.

There are many reasons that vertex groups may not line to what gets exported.

  • Your mesh may have quads or other ngons.
  • Your mesh could have multiple materials requiring duplicate certs.
  • Some modifiers add vertices, e.g. mirror.

Best option is to make a shape key based on a vertex group. Set a large difference on those verts. Upon load compare positions to morph target. That’s them. Throw morph target away.

Interesting, do you have a link to an example?

oooooooooooo, I love you long time.

hmmmm that might work as a temporary solution, long term goals will be to just get CSV’s embedded with just the indices list for the vertices.

I think Ill give that a shot and see how complex its going to be with 38 vertex groups, it might be too much and I am just gonna have to suck it up and program a python script.

1 Like

38 keys way too many. Ignore. BJS’es morph targets take up vertex shader resources. Unless you can find a way to force recompile of material after you sucked out info & deleted targets.

This is why .babylon & in general JSON files are shit. I do not use them. Morph targets suck too, btw.

My shapekeys are implemented as groups across different parts of the mesh & not on the GPU (that is a liability not a feature). You cannot put arbitrary data into a JSON file that the load program does not know about. When I generate inline Javascript, I could care less what the loader uses or not.

Ooh, now that I got that out of my system, You might add a UI switch into the mesh custom properties to export shapekeys as vertex groups. Use most of the shape key processing. BUT, you are also going to need to edit the load code & possibly Mesh too, to get the stuff into the scene.

1 Like

for now I am exporting my vertex groups with this script:

import bpy

modelName = "Model__male"
groupName = "Full.Chest.Measure"

ob =[modelName]
groupIndex = ob.vertex_groups[groupName].index

group = []

for v in
     for g in v.groups:
          if == groupIndex:

#change file location to real location
outputFile = '.../VertexGroup.txt'

group = ",".join([ str(v) for v in group ])

f = open( outputFile, 'w' )

And now I am going to see if those reference the same indices once imported, if so then I should have a solution for now.

“This is why .babylon & in general JSON files are shit. I do not use them. Morph targets suck too, btw.”
hahah a man after my own heart!


Knowing a vertex index you can get that vertex using:

let positions = mesh.getVerticesData(BABYLON.VertexBuffer.PositionKind);

let myVertex = positions[index]

That does not seem to work, I tried:

let positions = meshes[2].getVerticesData(BABYLON.VertexBuffer.PositionKind)					
						let id = vID*3
						let v0 = positions[id]
						let v1 = positions[id+1]
						let v2 = positions[id+2]						
						var b = BABYLON.MeshBuilder.CreateSphere("sphere", {diameter: 0.2}, scene)
						b.position = new BABYLON.Vector3(v0,v1,v2)

But that does not work, here is the points it ends up grabbing:

The circles are the vertices by the ID from my blender script…

So this makes me realize that maybe the vertex IDs in blender are not the same once they come over to a .babylon file?

Maybe I should use vertexColor and use that to establish the groups?

This is highly possible as data is repacked before exporting (to avoid duplicates)

So what would be a work around that you can think of?

I think there is an option to not optimize the vertices if I remember correctly

I’ll look that up thank you.

1 Like

The ‘no optimize’ thing is long gone. It transitioned into flat shading prior to version 6. In blender 2.80, basically the normal type (smooth, flat, or custom) in use by Blender is the same one the exporter uses.

The exporter processes FACES by material in the order they are provided by the “quad / NGON converter” thing. Vertices of different triangles which also match on normal, UV, UV2, vertex color, matrix weight & indices are shared. This means in order to get vertex groups to come out right, a map needs to be built as these other types are being processed in the first pass.

This is already being done, since a shape key has the same mapping issue as a vertex group. I say again, look at what @ozRocker did. He solved the problem correctly, except that he did not make it optional.

Use his version 5.6 file in replacement. You are using Blender 2.7x, so this should be fine as long as you use the very last version of the exporter before 6.0. If you make a PR for the change to the loader & Mesh.ts, I’ll bring the changes into the current code base & add the UI to make it optional, someday.

1 Like