OTOY Forums

I'm trying to reproduce the problem ... I hope to have good news as soon as possible.

-Juanjo

Guys, I am going to need something to reproduce this problem here, because I can't figure how it can be possible

A good clue could be to know the image paths after the broken links ... what can you see in the texture paths, and what path should be the right ones?

Thanks,
-Juanjo

I've done some quick tests here but haven't managed to reproduce as yet.

When it loses connection with the images the paths are completely empty in the Octane node viewer (as below). You can recreate that just by moving one of the LiveDB textures into another folder.

Thinking aloud - does LW ever move images when you save objects (either through layout or through modeler/hub)? Just wondering if it maybe LW moving them to another subfolder when you update a model...

Nope, LW doesn't move the images while saving the objects or the scene. The issue must be related to a change in the path reported by the LW SDK as image content folder, but I can't figure how this path can change inside a project if the user doesn't change it.

I'm going to make more tests here while working in the next plugin build, that I want to release next week, to try to reproduce the problem.

Thanks for your patience,
-Juanjo

Ok. I've found a really weird behavior in LightWave that can explain the problem with the broken LiveDB texture paths.

At least here, if I load an image (using for example the image editor) from a folder outside the current content directory, LightWave changes the "Images" content folder automatically to the path of this image without notice.

This is what is breaking the LiveDB texture paths. They are stored internally using relative paths, and this change made by LightWave in the "Images" content folder without notice, destroys the texture full path.

Attached you can see what happens, and not only with the images ... loading objects from outside the content folder also changes the "Objects" directory path.

I think that the solution is going to be to use the absolute content folder as base path for the LiveDB textures ... the problem can be that after this change, the current materials available in old scenes will be broken, but I am not sure how to fix this problem without this change. Really I don't understand why LightWave has this behavior, that is not logic at all

Thanks,
-Juanjo

Ok. I've fixed this problem referencing the LiveDB textures to the main content folder, that is not changed by LW each time you load an image file.

The drawback is that the old LiveDB materials are going to lose the texture paths. I'm sorry for that, but really I cant figure how to fix this problem without break the old LiveDB material nodes. At least all should work fine from now on. It was a plugin design problem on my side due to not be aware about this weird and unwarranted LightWave behavior with the content subfolders, that IMHO should be always fixed along the project if the user doesn't change them.

Please, test it in the upcoming build and let me know if you find new problems with this feature.

Thanks,
-Juanjo

Thanks !

Great thanks Juanjo.

Thanks Juanjo, work fine now !