#Can't find anim textmaps
13 messages in this thread
Gentlemen,
A simple problem, I hope… In creating an animated texture map (r2), the
renderer (MatEd/Editor/or Keyframer) can't find the sequentially numbered
.gif files. It can find the individual files but not the group. What am I
doing wrong? (The file selection in the MatEd reads flame*.gif)
Thanks,
Chris
Chris,
using the wild card is a bit problematic if you ask me. Preferably,
you should use an .ifl and then you can visually check it with a text
editor to make sure you are not picking anything up. Also make sure
the map-path for the images is at the top of the map-path list. To
make an .ifl go to the directory where the files are and type:
dir flame*.gif /on /b >flame.ifl
or you could download the utility makifl.zip which will create a text
file list of the files, even if they don't exist (also potentially
problematic too). Give it a try and let me know.
Thanks Martin. I don't know if you saw Gary's or Greg's comments but I tried
it their way to no avail. Your suggestion with the IFL did work. Thanks again,
Chris
Chris,
Glad to be of assistance, sir. I recommend always using .ifl files to ensure no
errant files sneak into the wildcard (*.gif) description. Safe mapping <g>.
Chris:
>> (The file selection in the MatEd reads flame*.gif)
You problem lies in the fact that you have five characters and three
numbers. 3DS prefers four characters and four numbers (test*.gif)
if you use an .ifl 3ds doesn't mind how many characters you are using, what?
>> if you use an .ifl 3ds doesn't mind how many characters you are using,
>> what?
Correct, assuming you keep it to less than 8 total! <g> I was
referring to his problem not finding his flame*.gif files.
GregP's answer is absolutely correct. On top of that MartinF's note
re using ifl files is a great suggestion. They're much more
flexible.
I tried Greg's suggestion by renaming all the files so that the first 4
characters were alpha followed by numbers masked through 0000 to no avail. It
was the same problem. It could find the individual files but not the
asterisked group (FLAM*.GIF). I was able to make it work using Martin's
suggestion of the IFL. I'm still quite curious now as why the *.GIF did not
work.
Thanks,
Chris
Without seeing your specific system, files, et al I can tell you what's going
on.
– G
Chris:
>> It could find the individual files but not the asterisked group
>> (FLAM*.GIF).
This is strange, because we do this with Targas all the time. I'll have to
test it with a group of GIFs to see what happens.
Greg Pyros
I seem to recall a similar problem I ran into a while back. I was
using project files since I tend to work on several jobs at once.
Because of this, I keep separate map paths for each project. I can
do this easily *without* changing my 3DS.SET file. Before I start a
new project I create a set of directories to hold all my maps for
that project. Then, I jump into 3DS and select Configure. From
there I type in the map paths for the project. Next, I save the
project file.
The result is that 3DS will always use the map paths stored in the
.prj file as opposed to what is in the 3DS.SET file. I recall the
problem because I changed the map paths in the 3DS.SET and when I
restarted 3DS and loaded a project file the new map paths settings
had no effect. When I checked the Configure box I found that the map
paths associated with that project had not changed to match what was
in my 3DS.SET. Instead, they were right where I left them when I
changed them by hand.
However, upon starting a new project, the map paths in Configure are
preset to match the 3DS.SET until manually changed.
Actually, I think this is a really great feature. It helps me
maintain organization between projects. I can backup and restore
entire projects without worring about path problems. I'm not sure if
this same phenomenon will occur with simple .3ds files. By the way,
I prefer .ifl files too.
Thanks much James. That's a good idea that I will use. The IFL's have worked
nicely although I still wonder why the individual GIF's could be found but the
wildcarded group could not. According to the docs and a suggestion by Greg
Pyros, it should it have worked but alas… As long as there was another way
around (which there usually is) I don't bother getting frustrated.
Thanks again,
Chris