Hi folks,

I was just wondering about user-friendly ways of distributing alternative UVs for figures. Just think of all the remapped Vickies that take textures made for other Vickies. If I'm not mistaken, the usual way of distributing such modified figures uses diffs or encoded files that have to be restored against the original figure files using RTEncoder or Objaction Mover. Wouldn't it be much easier to just distribute the UVs without the geometry and use Python scripts to load them into an existing figure?

The main reason though I'm interested in this is that there's obviously a discrepancy between what's best in UV mapping for the 'traditional' way of texturing via Photoshop and the more 'modern' way that would use a 3d painting application. For the traditional method, seams have to be avoided at all cost, whereas for the 3d method, seams are usually fine and the focus is on avoiding distortion wherever possible. This would suggest that new figures should be equipped with two alternative UV mappings - one that supports the traditional and one that supports the modern way.

In this thread, Cage posted a script demonstrating how new UVs can be plugged into an existing actor by basically creating a clone of the original geometry with the new texture information added and replacing the old geometry with that clone. I was wondering if a similar scheme could be used to apply a new UV mapping to a complete figure. I imagine there would be two scripts: one to extract pure UV information actor by actor and writing it into a special file, and another to read a file created by the first script and replace the UVs of the current figure. This shouldn't be too hard to implement, but I wonder what people think about the time and space efficiency, or if there would be other potential problems that I can't see at the moment.

Or, of course, maybe it's been done already and I would just be wasting my time. :biggrin:

Thanks for any input.

Cheers,
O.

Hmm.  The question makes me think about geometry insertion poses.  I haven't tried to use them to replace or reset geometry for all actors in a figure by using the figureResFile line, but a default actor can be restored using a pose, by using figureResFile.

I would approach it by writing out a new .obj file and routing the figure to use that .obj as its geometry base.

There's a geometry insertion pose script in this thread....

I'm rushing to avoid being kicked offline by AOL, and I fear I haven't explained well....  :(

After thinking about the suggestion a bit, I think the best approach would be to work on the level of the .obj and .cr2 files.  Distribute the new UVs as just the vt lines from the altered .obj.  (Perhaps the file could include the original .obj name and the name for the destination .obj, too?)  The script could just read the original .obj and replace the .vt lines, saving an altered copy.

Then the script would read a .cr2 which uses the original .obj and simply replace the figureResFile lines with the path for the new, altered .obj.

Set up the GUI to allow the user to browse for the paths of each of the source and destination files.

Presumably such a script would be simpler and faster than trying to work with the actor geometries, within Poser, and would have the added benefit of being able to be run outside of Poser, if desired.  If I were writing such a script, I'd give it the capability to handle .obz and .crz files, as well as the uncompressed defaults.

Yes, that seems to be a better solution. I like the idea of having a script that could work both from within Poser or independently.

Just a little addition/correction: in addition to the "vt" lines, one would also need the middle parts of the face specifications in case the seams had changed. You know, if there was a line like "f 1/2/3 4/5/6 7/8/9" in the modified .obj file, one could write that out as, say, 'ft 2 5 8' in  the UVs file. Of course one would have to make sure that the order of faces in the original and the modified .obj file was the same.

UVMapper can export the UV information from an OBJ, and can apply that UV info to another OBJ. It can even grab just the UV info from an external OBJ and apply it to the loaded OBJ.
Of course, this only works if the OBJs have the same facet structure.

The UV information file saves with an .uvs extension. It may be useful to use UVMapper (the free Classic version would be just fine for this job) to extract the UVs from an OBJ file and inspect the resulting .uvs file.

If you distribute those new UVs as .uvs, you have the advantage of using a standard (sort of) format. It shouldn't be too difficult to write a Python script that parses an .uvs file and applies that information to an existing .obj file - or even, within Poser itself, to the loaded object, using TexVertices and TexPolygons

What is the file size of a .uvs file, compared to the original .obj?  I thought the sizes were roughly the same, and the benefit of the approach suggested here might be a slimmer file format for the exchange.  But I haven't checked .uvs to be sure.  Hmm.

Just looked it up. I've got an UVS file for remapping V3: 3.88 Mb. The V3 .OBJ file is 8.21 Mb,
It looks a lot like an .OBJ file, with the v and vn lines stripped out, and abbreviated "f" statements. In fact, it's exactly what odf describes.
Only one extra: there's also usemtl statements in the UVS file.

Aha!  So a new script to read .uvs files might open the possibility of gzip compression for the files, perhaps, to slim them.  But little else.  And if you're distributing the .uvs in a zip file anyway, the benefits of compressing the file itself are questionable.  Hmm.