GLTF Parser Hooks

My toolkit packages up a script bundle along with gltf… Inside the scene.extras.metadata i keep a tag with the project script. I was going for a a self loading asset for the project script just like a texture asset.

That way the developer does NOT have know the project script file or anything… the project script bundle is just a another asset of the gltf scene. This project script contains custom material classes and shaders so that why i need it BEFORE the loadSceneAsync starts parsing the nodes which in turn creates the materials.

It would be really kool for my extension to have a ZERO code setup for its complete usage… Lights, Cameras, Physics, Terrains, Custom Shaders … the whole nine yards… and all that can simply be load with SceneLoader Load, Append or ImportMeshes call and nothing else :slight_smile:

I am actually going for the WHOLE toolkit to just be a (optional) Managed Scene Component API

it just needs to be loaded on the page… The CVTOOLS_unity_metadata extension handles all the rest if the GLTF file is loaded and it has CVTOOLS_unity_metedata in the extensionsUsed.

You still do babylon asset loading JUST LIKE NORMAL… The loader will handle everything :slight_smile:

BTW… this all work beautifully… If i HIJACK the rest of node loading like i do with my custom finishLoadSyncAsync (which is just a copy of load loadSceneAsync WITHOUT the extension stuff at the top)

Getting it to work WITHOUT hi-jacking the load process would be even better :slight_smile:

Okay, I understand. Your current hack isn’t going to work in all scenarios since the loader is expecting all the Babylon objects to be created after loadSceneAsync is called before the promises complete. It will break some of the functionality in the loader (e.g. the compileMaterial flag won’t work properly anymore), but it might not be an issue for your scenario. I will see if there is a way around this or add a hook for it.

Thanks for looking into this as well :blush:

Yo @bghgary … I have another issue… I have a tree mesh… 1 single mesh but 5 separate materials (submeshes) … When i export… i of course export the Mesh Node with its primitives (THE SUBMESHES)… But when babylon renders the scene it turns my one single node mesh with primitives into a TransformNode and puts all the primitives (submeshes) and separate child mesh nodes.

This seems to be cause me a problem with shadows… Now i have to check if the mesh is actually a mesh or transform node… if its transform node i have to check its children for primitive meshes… I then try to aadd all the primitive meshes to the light shadow map render list… I see them in the render list but i DONT SEE my shadows. FYI… all the meshes that were not broken down in to child submshes show up fine in the render list.

I dont know if i can duplicate this in the playground i will try. But my question is my cant we have a single mesh with submeshes… Why do we have to break them apart and make a transform node and put all the submeshes as actual separate mesh nodes. In my old toolkit i serialize mesh with submeshes all the time. And the show up in babylon as a single mesh.

Can we put some kind of option in the loader to load as single mesh instead of breaking them all apart like we do now ???

The loader used to do this, but there were so many edge cases that didn’t work properly that we decided to split them.

We can put an option to use submeshes when possible. It will take some time to get right though. If you feel strongly about this, open a request on GitHub and we will look into it.

Shadows should work regardless of the use of submeshes, so let’s check that when you have a PG.

Thanks @bghgary … Trees was not a good example for the shadows as they are static and should be baked anyways… But i have a few characters that i used my Maya Art Tools to combine into a single mesh… but it had submeshes… when i load those thru babylon gltf they go right back to the separate pieces i combined them into.

I guess i would like to know whats the main benefit of keeping submehses separate… i think it would cost the same amount of draw calls if 1 single mesh had 5 materials (submeshes) vs 1 parent transform node with 5 separate child meshes each with a single material (from the source submesh)… What the difference beside the convenience of a single mesh to interact with vs 5 separate child meshes to keep track of… ANY ???

It makes performance worse, but it fixes issues. For example, in glTF, one primitive can have normals, but the next one might not. We tried a few way to do this with Babylon, but ended up scrapping it.

Hey @bghgary … I am trying to figure out where the animations get parsed to in GLTF…

I would expect the each skeleton bone would have something in bone.animations but that array is null on all the bones of a skeleton from a gltf… Where do the animations go in GLTF ???

They all get assigned to nodes which are then linked to bones. But why not use animation groups?

Because i am going to be creating an animation state machine… It is a FRAME BY FRAME animation system that can SAMPLE any animation track at any given frame time on ANY layer…

blend all those Bone Matrix Values together and do a final bone update matrix… This allow me to have the Unity like animation system with support for Avatar Layer Masks, Transitions, Blend Trees …etc . (Although i am still stuck on 2D polar space game math to properly calculate input weights… but thats another story)

Just so i know… whats the low down with animation groups… Can point me to docs on that.

And i know you been super busy with your conference and all… But have you had a chance to think about how your going to handle:

A… No splitting up sub meshes in to separate primitive meshes (This really screws things up a bit)

B… How to get around PBR Specular Hijacking the GLTF export workflow so my loadMaterialPropertiesAsync never gets called

Thanks Gary :slight_smile:

Yo @bghgary … I notice the default or first animation group is always playing… Can i disable that feature… I don’t want my animations to just start playing the first animation group… But instead i will be using an animation state machine to play my animations.

This just need to be implemented.

Currently, I’m thinking to expose the registration order, but not sure yet.

Yes. See https://doc.babylonjs.com/api/classes/babylon.gltffileloader#animationstartmode

Yo @bghgary … Sorry to harp on this… but is there an option to NO CREATE the animation group. I need to create the animation groups my self for my animations for the animation state machine. So i need the GLTF loader to NOT create them. An option on the loader for that would be great… Please :slight_smile:

AnimationGroups are relatively cheap. Does having them cause you problems?

Please file issues on GitHub so that I can keep track.

Yo @bghgary

Do you create the Animation Group in loadAnimationAsync ?

If so… no need for for NO CREATE option on the loader… I can handler there?

Can we please EXPOSE loadSkinAsyn on the GLTFLoaderExtension just like loadAnimationAsync… That way i can handle creating my skins there and NOT have to ‘MacGyver’ my skins like i am doing now.

Yes, but it’s not currently easy to override to not create animation groups.

The other functions are not exposed currently because I’m not confident in their contract yet. I can expose an experimental one for now if you are okay with it possibly changing in the future.

Yo @bghgary

Please do expose the functions to override:

loadAnimationAsync and loadSkinAsync.

FYI: My extension creates custom skins with shared skeletons… Because I currently cannot override loadSkinAsync i kinda MacGyver my own skin by NOT serializing the GLTF Skin node but instead serialize the gltf skin info as extras.metadata… Then in code when i PARSE the Skinned mesh renderer node… i just create my own babylon skeletons there… that is why i have to create my own custom animation groups as well… so the targets are my bones and NOT the GLTF TransformNodes.

But if you expose the loadSkinAsync to override… I can just do it there and not have to go all MacGyver :slight_smile: