I implemented this as a workaround for a bug when using Qt and OSG together. On some computers, the files are not loaded properly, while the same file is loaded properly on other computers.
The workaround was to convert the mesh file to an OSG file first, via the command osgconv toto.dae toto.dae.osg, and then load it.
When the file "toto.dae" is requested, this code first checks if "toto.dae.osg" (and not "toto.osg") exists. If it does, it considers "toto.dae.osg" is the result of the previous command. This is a bit weak, I agree. It was quick to implement and was not likely to cause any problem to anyone (apparently, I was wrong).
A more robust solution to this problem is to use the hash of files to name their OSG convertion. This requires a bit more code though.
Regarding this pull-request, I'm not against. But we will face the OSG/Qt issue again in some time and I do not like this.
I implemented this as a workaround for a bug when using Qt and OSG together. On some computers, the files are not loaded properly, while the same file is loaded properly on other computers.
The workaround was to convert the mesh file to an OSG file first, via the command
osgconv toto.dae toto.dae.osg, and then load it.When the file "toto.dae" is requested, this code first checks if "toto.dae.osg" (and not "toto.osg") exists. If it does, it considers "toto.dae.osg" is the result of the previous command. This is a bit weak, I agree. It was quick to implement and was not likely to cause any problem to anyone (apparently, I was wrong).
A more robust solution to this problem is to use the hash of files to name their OSG convertion. This requires a bit more code though.
Regarding this pull-request, I'm not against. But we will face the OSG/Qt issue again in some time and I do not like this.