I’m writing a module to deal with creating menu’s. As part of this, you can call:
menu.add_image(position, size, path)
Now, it’s simple enough to change the image a material uses, but they share the same material across every instance of the object.
My first thought was to use libnew to separate them, but unfortunately libnew new’s the meshes but leaves the materials still linked.
The only way I can see to work around this is to use my uniquelibload function loading the blend from a string so the objects actually are completely unrelated.
Can anyone see any other ways of having two objects (added from an invisible layer) have different images? Can you create a new material at runtime somehow?
I really have now idea. I stumbled across a similar issue on the puzzle games. The final solution was to have unique objects (different UV but same material).
You might want to pack your images in an atlas and simply change UV layout, instead of getting into openGL material instancing.
I did consider the UV sheet idea, but it means that instead of specifying the images path you have to specify the XY co-ordinates of all four corners. That doesn’t make for a ‘nice’ API.
I think I’ll just use the unique libload method. I know it’ll work fine, and only take about 3 lines more code to add in.
Hmm. I came across this bug while googling for potential solutions:
“Objects Sharing meshes do not share GLSL shaders”
Sounds like it’d do what I want. But it’s a bug…
Humpgh, it seems videotexture isn’t working with libloaded materials in GLSL mode, but it does work in multitexture mode. Tomorrow I’ll build a dedicated test for this and if this is the case, submit it to the tracker.
Time for problem analysis again to see if there’s another workaround…
I had the same problem and unfortunately I hadn’t found any solution to dynamically add new material…
Although, I overcame this by duplicating my object (a plane) in advance in a blend file.