Full file path for textures
-
On 30/03/2015 at 16:06, xxxxxxxx wrote:
Yes there is, Cinema searches for the files in exactly the order Andreas described.
Originally posted by xxxxxxxx
- suggestedfolder + srcname
- if srcname has a path, it tries to use it as is
- GetDocumentPath() and GetDocumentPath()/tex
- GeGetStartupWritePath() and GeGetStartupWritePath()/tex
- GeGetStartupPath() and GeGetStartupPath()/tex
- then all GetGlobalTexturePath() recursively
- and as if this wasn't enough, it checks for a NetRenderService context and runs through all assets using ConvertRelative2Absolute()
The first file you find this way is the same file that Cinema will use.
-
On 30/03/2015 at 17:30, xxxxxxxx wrote:
Let me explain in more detail:
My customers drop a texture on a plane, and my plugin detects that and gets the full path with:shader[c4d.BITMAPSHADER_FILENAME]This works fine, unless C4D finds out that the path to the file is already set in the preferences.
In that case, the code above only returns the file name portion and not the path.In this example, C4D is not searching for the file is it?
It already has the full path when the file is dropped on the plane.If my plugin searches in the order above, then it could find a similar file name in another folder couldn't it?
-
On 31/03/2015 at 06:32, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Let me explain in more detail:
My customers drop a texture on a plane, and my plugin detects that and gets the full path with:shader[c4d.BITMAPSHADER_FILENAME]This works fine, unless C4D finds out that the path to the file is already set in the preferences.
[...]Are you talking about the Preferences > Files > Texture Paths settings?
-
On 31/03/2015 at 08:52, xxxxxxxx wrote:
Yes, but the same thing happens if the image file is in the document path.
C4D only exposes the file name, and not the path when you call:shader[c4d.BITMAPSHADER_FILENAME]If I then do a recursive search in the order Andreas suggested, my plugin could find the same file name, both in the document path, and in one of the Preferences>Files>Texture Paths.
I don't see a way to know for sure which one it would be in that case. -
On 31/03/2015 at 08:54, xxxxxxxx wrote:
Hi terrachild,
two posts ago you were asking "C4D is not searching for the file is it?"
But yes it is, and it does so exactly in the order I described. -
On 31/03/2015 at 08:57, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Yes, but the same thing happens if the image file is in the document path.
C4D only exposes the file name, and not the path when you call:shader[c4d.BITMAPSHADER_FILENAME]If I then do a recursive search in the order Andreas suggested, my plugin could find the same file name, both in the document path, and in one of the Preferences>Files>Texture Paths.
I don't see a way to know for sure which one it would be in that case.Yes there is, the first file that is found by following the order Andreas described is the file that Cinema
will use. -
On 31/03/2015 at 12:21, xxxxxxxx wrote:
Okay, Niklas, I did some more testing.
It seems that if you drop a texture on a plane, C4D always looks first to see if it is in the document path; and if it isn't, then it prompts you with: "This image is not in the project search path..."It seems to do this even if you have set up texture paths in: Preferences > Files > Texture Paths
**
**
If it is in the project search path, then it will use it, and expose only the file name with:shader[c4d.BITMAPSHADER_FILENAME]I can detect that, and then prompt the customer with a file browser to give the path.
Just to confuse the matter more: If you drop a texture on a plane from a folder named 'tex', that is located next to the project file, then C4D doesn't give you the prompt to copy. If the texture is in a nested folder like this "tex/1/pic.jpg", it doesn't give you the prompt. If the texture is in a nested folder like this "tex/2/pic.jpg", it does give you the prompt. It doesn't search the folders in the project path very consistently.
I guess I need to know if C4D always ignores the texture paths, set in the preferences, and prompts to make a copy of the texture?
If so, I'm fine. I can just tell the customer to always select 'No' at the prompt, and force C4D to expose the full path from Python.
Why is it ignoring the texture paths set in preferences when you drop a file on a plane though?
Thanks for you help NiklasR!
**
**
**
** -
On 01/04/2015 at 10:05, xxxxxxxx wrote:
Hi Chris,
Cinema 4D doesn't store anything else than what you see in the bitmap shader. It is either a absolute path or just the filename, if the texture is in the texture search path. The texture search path I described earlier in the exact same order, Cinema 4D searches.
I also did some test and I can't reproduce your findings.
Here's what I did:
I set up the following project structure:
./test_scene
./test_scene/tex
./test_scene/tex/1
./test_scene/tex/2
The scene got stored in ./test_scene and in each of these directories I put an image. Furthermore I stored an image in the "global" search path (under Windows that's in Users\USERNAME\AppData\Roaming\MAXON\CINEMA 4D R16_... ex), which kind of works the same as any path configured additionally in the preferences.
From all these places I dragged in the image and I never got asked, if the file should be imported, and C4D stored only the filename in the bitmap shader.
Then I dragged in an image from an arbitrary directory (not in the described search paths) and I was asked, if the file should get imported. I answered "No" and the absolute path got stored in the bitmap shader.
So I can confirm for me Cinema 4D behaves like its code suggests and as I described. -
On 09/04/2015 at 10:26, xxxxxxxx wrote:
Hi guys,
Just my 2 cents about the dilemma of how far an application should search (not just Cinema 4D, any app on a computer that has file storage using directories), and the fact that two files with different content can have the same name.
You reveal two competing problems:
1. "It's bad when the wrong file is chosen, it's best if it would just fail and prompt the user for the correct file"
2. "It's bad that an app doesn't search far and wide enough to find the file"
This is a fundamental computer issue with no clear solution, so everyone is expected to work within these limitations, even if somewhat masked by GUI based OSes. When trying to solve 1, you increase the chances that 2 occurs, and vice versa. That's why there are specific paths checked in a rigid order, from the closest in the directory hierarchy (usually a subdirectory) to farthest away, often passing through mostly reliable 'shared' directories. Going up a level in the directory hierarchy usually exposes you to increased chance of finding the wrong file, as we may inadvertently call similar but different content by the same file name by habit. At the extreme, searching all the hard disks on a computer for a file is asking for trouble, hence why that is very rarely done, even as a last resort.
However, there's the other angle to consider that was stated above: "you can't control customers". The assumption that if they are using your software, which is certainly aimed at experienced computer users, they should know how to use a computer properly. That includes understanding the dilemma about file naming and directory organization. You should consider it a problem outside of your responsibility, as you can't control sloppy computer file (dis)organization on someone else's system. If it worries you a lot or they have given you trouble in the past, you should provide guidelines and warnings to your customers about file search paths. This is the norm for other applications, even if it's not always clearly stated.
I hope that helps.
Joey Gaspe
SDK Support Engineer -
On 09/04/2015 at 12:21, xxxxxxxx wrote:
My problem is very simple actually:
- A user drops an image file on a plane.
- My plugin detects that and needs the full path.
That's it.
C4D has the full path when the user drops it. It doesn't, or shouldn't have to, search for it. All programs have the full path to a drag and dropped file. Why can't I get this?
But I don't seem to be able to get that path. It isn't stored in the shader settings unless C4D displays the pop-up dialog I mentioned earlier that asks if you want to make a copy of the file, and the user selects 'No'.
If C4D finds the file in one of its search paths, then that dialog doesn't pop up, and only the file name is stored in the shader.
If only the file name is stored in the shader, then I guess I have to do a search in the order that C4D does it.
Here's what doesn't make sense to me about this: If the user drops a file on a plane, that image is going to be used no matter what. Is that correct.?
Even if C4D searches, using the order mentioned above, and finds a different image with that same name earlier in its search order than the dropped file occurs in its search order, are you saying it will use the out of order search result? If not, then if you drop one file, it could display a different one. Is that correct? Surely, it won't do that.
If this out of search order file is displayed when it is dropped, then what about the next time the file is opened and C4D searches. Will it display the different image found earlier in the search?
Good lord, I just need the path of a dropped image.
-
On 10/04/2015 at 06:50, xxxxxxxx wrote:
Hi,
I did some more testing on this topic.
Let's assume you have this structure:
./test_scene
./test_scene/tex/walter.jpg
And in the global texture search path you have another walter.jpg.
If you now drag the walter.jpg from the global search path into your scene, C4D will actually ask you "This image is not in the project search path. Do you want to create a copy at the project location?", although the image is in the global search path. It does so, in order to resolve the file collision. If you choose "Yes, import to project dir", the file will get renamed and copied into ./test_scene/tex/, only the filename will be stored in the scene. And if you answer "No", the absolute path will be stored in the scene.Which in the end means for you: You can still use the above mentioned search order, if you only have a filename, as C4D already cared for the file collision.
-
On 11/04/2015 at 00:17, xxxxxxxx wrote:
Thanks Andreas.
I'll start working on the recursive search algo.