Skip to content

Allow registering default material adapters in GltfLoader#1811

Closed
Minikloon wants to merge 1 commit intojMonkeyEngine:masterfrom
Minikloon:register-default-material-adapter
Closed

Allow registering default material adapters in GltfLoader#1811
Minikloon wants to merge 1 commit intojMonkeyEngine:masterfrom
Minikloon:register-default-material-adapter

Conversation

@Minikloon
Copy link

I want to use Gltf but I don't want to use PBR, so I made this adapter: https://gist.github.com/Minikloon/93728e7ad494373b70753c072e36a77a

Now I don't want to register it on every model key!

@Minikloon
Copy link
Author

rip conflict with #1810

@pspeed42
Copy link
Contributor

pspeed42 commented May 7, 2022

Do you load GLTF directly into your game or do you use the recommended and much smarter approach of converting it to j3o first? Because it's quite common to have to fix a dozen things during the gltf->j3o conversion process and this could in theory just be another standard thing to fix during conversion.

For example, JmeConvert allows you to specify scripts to post-process the model during conversion and it would be a pretty standard script to convert all materials to something other than PBR.

@Minikloon
Copy link
Author

I saw from JmeConvert that you use the adapters map of the GltfModelKey. I could've used that but then I'd want a ModelKeyFactory.

If I wanted to setup an art pipeline rn, I'd override com.simsilica.jmec.Convert::runProcessors and run java code there. But even then it's post-processing. Hooking into the loading dodges having to fully understand the jme layout.

@pspeed42
Copy link
Contributor

pspeed42 commented May 8, 2022

re: "I'd override com.simsilica.jmec.Convert::runProcessors and run java code there."

If you are calling it from code then you can already run Java code there and if you are calling it from the command line then you already can use groovy which is like Java++.

I'm not against fleshing out the GltfLoader API but in the long run you will be happier with an asset pipeline that gets you to a j3o file that is ready to load, properly scaled, cleaned up, generated j3m files, etc... rather than constantly hacking in "one more thing" at load time.

@Minikloon Minikloon closed this May 28, 2022
@stephengold
Copy link
Member

@Minikloon Why did you close this PR?

@Minikloon
Copy link
Author

I'll re-open if I work more with jMonkey.

@stephengold
Copy link
Member

But why not just leave it open until then?

@Minikloon
Copy link
Author

I don't like PRs in limbo, they make me worry that I will have to make changes someday.

@stephengold
Copy link
Member

good to know

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants