I have moved to
3.0.10, and here is a question that appeared – how do I handle the
sortId parameter when creating my custom
TechniqueDef instances? What confuses me is that the comentary says that the id should be unique among all the techniques, but then, if only a certain amount of them is created manually, and the rest is handled by the default JME asset pipeline, how do I keep consistency in these ids? Though the parameter is perfunctory, I guess it’s very important for JME. I could make a counter and assign every new instance a new
sortId, but then how do I guarantee that it does not collide with whatever JME is using inside?
So, what do I do with that parameter?
Well that is really meant to be an internal stuff… not sure why you are creating your own TechniqueDef…
Well, this is from a custom pipeline that loads shaders in runtime and can create techniques with them in an already-existing material (I know that material parameters are important, so it is assumed that the loaded shaders are compatible with the material, this is ensured elsewhere). So then, changing to a shader loaded in runtime is a matter of creating and switching the technique, not creating an entirely new material, which is a far greater task. I have examined your new class described here Live reload of material for shader dev but it also does a whole material reload.
What do you think? Is it better to stick to material reload? In my app the shaders can be received from network or UI, so, coupling this with loading a material file from disk or a material description string from elsewhere seems a bit an overkill… or doesn’t it?
Could you please give an advice on that matter? (see my usecase explanation in the previous post)
I’d go for the whole material reload, because that’s the intended way to do. There is a lot of internal states in techniques and you can’t just replace it like this.
Also there is not that much overhead to create a new material each time.