Tuesday, April 12, 2016
Ghost files?
Vaguely related to yesterday's item about UV mapping. A few months ago I bought a copy of the UU3D uvmapper, after Cox's UVmapper prog ceased updating its registration. I still use the simpler version of Cox's prog for most purposes, and occasionally use UU3D for fancy stuff like equal-area mapping or 'perpendicular to face' mapping.
UU3D does one extra fancy thing that I've never seen in any Windows program for any purpose. It picks up the innards of an OBJ file before it's loaded into UU3D, and persists in holding the originally fetched innards after I load a revised version.
Example for clarity: I built this simple rack thing in Amapi.
The original output, as sorted in Kedit, had these Groups and Materials:
I DIDN'T LOAD this original into UU3D. Following my usual workflow, I immediately edited the names down and eliminated some 'dummy' stuff that Amapi always leaves. I want the vertical parts to look like wrought iron and the horizontal rods to be silvery. So I only need two Materials.
After this editing, I loaded the file into UU3D. and here's what UU3D sees as the materials:
It sees the PRE-EDIT names.
For comparison, the basic Cox UVmapper reads the edited version correctly:
This has happened several times now, and I've verified it SLOWLY AND CAREFULLY with an intentionally made file, just in case I've been unconsciously loading the 'usual' files. What's going on? The edited OBJ file does NOT contain any remnant of the discarded names. I looked at one in a binary viewer. UU3D doesn't appear to be running in the background where it could grab things quietly. So where is it getting the pre-edit OBJ file? Must be using the File Descriptor Table to locate the penultimate version of the file instead of directly loading the ultimate version as all ordinary programs do. Why would you want to do that? (Especially strange since UU3D stands for Ultimate Unwrapper, not Penultimate Punwrapper.)
= = = = =
Sidenote: While checking the link for Cox's UVmapper, I noticed that Cox has finally re-entered the arena with a new update after several years of absence. I updated and paid full freight. In theory I could try for an upgrade price, but the full price is WORTH IT for a prog that I've been using every day for 10 years. Yay. Good to have a proper tool back in the toolbox.
The original output, as sorted in Kedit, had these Groups and Materials:
I DIDN'T LOAD this original into UU3D. Following my usual workflow, I immediately edited the names down and eliminated some 'dummy' stuff that Amapi always leaves. I want the vertical parts to look like wrought iron and the horizontal rods to be silvery. So I only need two Materials.
After this editing, I loaded the file into UU3D. and here's what UU3D sees as the materials:
It sees the PRE-EDIT names.
For comparison, the basic Cox UVmapper reads the edited version correctly:
This has happened several times now, and I've verified it SLOWLY AND CAREFULLY with an intentionally made file, just in case I've been unconsciously loading the 'usual' files. What's going on? The edited OBJ file does NOT contain any remnant of the discarded names. I looked at one in a binary viewer. UU3D doesn't appear to be running in the background where it could grab things quietly. So where is it getting the pre-edit OBJ file? Must be using the File Descriptor Table to locate the penultimate version of the file instead of directly loading the ultimate version as all ordinary programs do. Why would you want to do that? (Especially strange since UU3D stands for Ultimate Unwrapper, not Penultimate Punwrapper.)
= = = = =
Sidenote: While checking the link for Cox's UVmapper, I noticed that Cox has finally re-entered the arena with a new update after several years of absence. I updated and paid full freight. In theory I could try for an upgrade price, but the full price is WORTH IT for a prog that I've been using every day for 10 years. Yay. Good to have a proper tool back in the toolbox.Labels: TMI
¶ 6:04 AM
