Hey Everybody,

I've been out of the scene for a while. I was wondering what the current methods, standards, etc. are for redistributing modified versions of Poser characters.

For example, if I wanted to put up a freestuff item based on Poser 6's James character, and I wanted to re-UV map the object, what (if any) is the current standard for doing this. Traditionally, we are not supposed to redistribute the OBJ files, or the original textures. Have these rules relaxed, or is there a commonly used utility for encoding the modified object, that requires the original object as a "seed". I do recall a utility back in the day that did this,  but like I said, I've been out of the scene for a while.

So, to put in another words. If I want to redistribute a modified version Poser/DAZ character as a freestuff item then what are my options?

Konan

The encoder you mention is RTE Encoder, from rtencoder.com.
It's still pretty much the standard.... was revised recently to use Python
as a more Poser-friendly format.

Welcome back Konan, the standards are still the same. :)

Quote - Welcome back Konan, the standards are still the same. :)

Thanks buddy.

Hmmm, so at this time, the use would have to download and install RTEncoder and do the whole song and dance. Hmmm. They mention that there is now a python script for doing it on OS X, which requires a python installation on the user's side.

I'm asking this since I'm getting ready for a free stuff giveaway spree, and I'm thinking of making stuff based on Poser's own characters. However, I would like to have the freedom to re-UV map the objects, and perhaps create maps that are "painted over" the existing maps, where elements of the existing maps are still there. The reasoning for the latter is so that I could paint a head texture with a seamless transition to the body. An perhaps the existing body texture would be tinted to match the hue of the new head.

Also, I would like the user to be able to simply download the package, run something like an installer, and have everything set up and ready to go. I could do something like this myself, but I figured it is best to see if a solution exists already.

Now, if I do use RTEncoder or a similar method, can I assume that it would be fair game to use the OBJ file as the seed, even if the package includes the textures (this is of course for Poser's own models, where the textures are not sold separately)? I'd assume as much.

Doesn anybody know if there is a small decoder for RTEncoder that can be redistributed with a package?

Konan

Boy, you have been out of the loop.  The way things are going now, there may be no need to paint textures any more.  Shaders is the in-thing these days.

Hehe. I seriously doubt that shaders can replace texture maps. There are of course a time and place for shaders, and a time and place for textures. Try doing this with shaders. I dare ya! ;)

Konan

*Hehe. I seriously doubt that shaders can replace texture maps. There are of course a time and place for shaders, and a time and place for textures. Try doing this with shaders. I dare ya! ;)

*Shaders alone are not enough, but texture-maps aren't enough either: a shader with some texture maps (color,bump and shine) and some procedural nodes for the finishing gives the best results, look for a thread about the VSS-program of baggingsbill, and find out what make poser rock at the moment!

regards,

Bopper.

There is a java implementation of RTEncoder HERE

I myself like to use three different texture maps for each body part.  One regular that I plug into diffuse, specular, and ambient.  One desaturated and enhanced (I usually darken it to a -10, and raise the contrast to a +30 in photoshop) that I plug into diffuse value, specular value, Highlight, and Ambient value.  Aside from these two, I usually add a bump map to both bump and displacement which I set at values of 0.1 and 0.001 respectively.
Ambience is always set to White, but its value is always set to either 0.001 or even 0.0001.  That way, it absorbs the light, but does so as if it were set to black.
The desaturated map I generally reduce the texsture strength to 0.5 or even to 0.25.  By plugging it into the various Value slots, it does something similar to what multiple layers do in Photoshop, it enhances the final render, adding depth and richness to the overall figures appearance.
DPH

Speaking of alternative UVs, I was wondering if it was possible to change texture coordinates on an actor from within Poser. If so, it should be quite easy to write a script that could hot-plug an alternative UV mapping. I'd be happy to write that script if someone could give me some pointers. Mostly, whether Poser Python can do it, and whether the .uvs format used by UVMapper is free to use and well-documented. If not, I'd have to come up with my own format and a tool to extract the UVs from an .obj file. No biggie, but of course using an existing format is usually preferable.

DPH, could you show a side by side and a screenshot of the materials room?

konan, that looks like a KILLER texture... I would love a character like that. Can you isolate your texture modifications to a transparent overlay? RDNA sells .psd overlays for their commercial textures in some cases I think. An alternative would be to find a merchant resource lisceneced for freebie products... do such exist? With nodes the overlays could even be added in Poser rather than Photoshop but I don't know the setup for that. An overhead intensive way to composite is with a duplicate figure textured and transmapped to be used as a second skin with a little displacement set to place the surface a little outside the main skin.

I do beieve RTEncoder can be used to encode textures as a difference file though but I have not done this. As for the re-mapping... I think the alternatives are a .uvs for the geometry using UVmapper Classic or to have Poser create a new UV by saving after using the Grouping Tool and then Objaction Mover or RTEncoder for encoding of the .obj but the .UVS is much smaller.

Anyone remember Staale Loseth's tricking for loading two textures on a figure without nodes in Poser 4? I have been wondering if that would work for tattoos or does it create too much overhead.

You are working with James? Cool.

Quote - DPH, could you show a side by side and a screenshot of the materials room?

konan, that looks like a KILLER texture... I would love a character like that. Can you isolate your texture modifications to a transparent overlay?
...
You are working with James? Cool.

Thanks man. Yes, it is James. That was just a quick once over to test the concept. I'll be doing a good version as soon as I decide on whether to use the existing UV mapping or use the auto-UV mapper in Blacksmith3D-Paint. The existing UV mapping has a few places where it is not so good (around the nostrils and on the ears). The auto-Mapping makes all of those nooks and crannies look much better since texture stretching/overlap is dramatically reduced.  However, if I want to distribute the item as a free item, then the issues we are discussing above come into play.

In the end, I shouldn't be such a perfectionist and just deal with the existing UV mapping. I dunno. We'll see :D

Konan

Quote - Speaking of alternative UVs, I was wondering if it was possible to change texture coordinates on an actor from within Poser. If so, it should be quite easy to write a script that could hot-plug an alternative UV mapping. I'd be happy to write that script if someone could give me some pointers. Mostly, whether Poser Python can do it, and whether the .uvs format used by UVMapper is free to use and well-documented. If not, I'd have to come up with my own format and a tool to extract the UVs from an .obj file. No biggie, but of course using an existing format is usually preferable.

Actually it is possible to do this entirely in Poser's material room- no scripts needed. Basically, for any given point in map A, you need to know where to go in map B to get your pixel value. This requires two coordinates for each point in the UV map. Such information can be encoded in two channels of an RGB image, for example red and green.

Let's call this the texture converter map, or TCM. Using a Comp(onent) node, you can extract the RED value from the TCM and plug that into your texture map U_Offset. Similarly, you Comp the GREEN value from the TCM and plug that into your texture map V_Offset.

All that remains is to produce the TCM. I've been thinking about how to do this, but I haven't done any coding for it. I'm imagining a tool that shows you two image maps. You click on a reference point in A, and the corresponding point in B. If you do this for enough points, the tool could then interpolate all the coordinate transformations and generate the TCM.

Quote - > Quote - Speaking of alternative UVs, I was wondering if it was possible to change texture coordinates on an actor from within Poser. If so, it should be quite easy to write a script that could hot-plug an alternative UV mapping. I'd be happy to write that script if someone could give me some pointers. Mostly, whether Poser Python can do it, and whether the .uvs format used by UVMapper is free to use and well-documented. If not, I'd have to come up with my own format and a tool to extract the UVs from an .obj file. No biggie, but of course using an existing format is usually preferable.

Actually it is possible to do this entirely in Poser's material room- no scripts needed. Basically, for any given point in map A, you need to know where to go in map B to get your pixel value. This requires two coordinates for each point in the UV map. Such information can be encoded in two channels of an RGB image, for example red and green.

Let's call this the texture converter map, or TCM. Using a Comp(onent) node, you can extract the RED value from the TCM and plug that into your texture map U_Offset. Similarly, you Comp the GREEN value from the TCM and plug that into your texture map V_Offset.

All that remains is to produce the TCM. I've been thinking about how to do this, but I haven't done any coding for it. I'm imagining a tool that shows you two image maps. You click on a reference point in A, and the corresponding point in B. If you do this for enough points, the tool could then interpolate all the coordinate transformations and generate the TCM.

Sounds like a good idea, but numeric resolution will no doubt stifle the attempt. You see, the red, green or blue channels can only have a value between 0 and 255. If we are attempting to use these color values as UV coordinates, then we will essentially divide the color channel (red) by 255 to get a value between 0 and 1. Now, with that being said, our values will be like 0, 1/255,  2/255, ... 254/255, 255/255. Therefore, the in values between will get snapped to the closest integer (divided by 255).  In other words, 1.4/255 would be the same as 1/255.

Now, if you used an RGBA image, you could RG for your U coordinate and BA for your V coordinate, hence increasing your resolution since it will be like 1/65535, 2/65535, etc.

eeek, math! ;)

Now for our purposes here, this would definitely be the 'hard way' of doing things, but I do like the idea. I could have other useful applications.

Konan

konan, there is somewhat of a discussion about optimal mapping for a figure skin in the Antonia thread here. Is there a way to explain in principal how the Blacksmith-auto mapping reduces distortion? Could it be used to create a regular and consistent standard UV for a figure?

Quote - konan, there is somewhat of a discussion about optimal mapping for a figure skin in the Antonia thread here. Is there a way to explain in principal how the Blacksmith-auto mapping reduces distortion? Could it be used to create a regular and consistent standard UV for a figure?

Great question! Ok, here's the deal...

You see, the problem comes from the simple fact that in general, you cannot create a 2D mapping of a generic 3D surface without creating seams. Traditionally, textures are painted in a 2D program such as Photoshop. To paint textures in Photoshop, one would like as few UV seams as possible and preferably hidden away where they are not that noticeable. This much you all know I'm sure.

Now, in the process of minimizing our seam count, we end up distorting a good number of the UV's, so the shape of a polygon in the UV space becomes significantly different than the shape in XYZ space. This causes the texture to appear stretched in these areas. Think of the poles in a spherical mapping (a map of the earth vs. a globe of the earth.) and how the land around the north pole looks as wide as the circumference of the earth at the equator (on the map) while it is actually much smaller (on the globe).

Now, with Blacksmit3D-Paint, the goal was to be able to UV map any object with the click of a button, so the user could simply "just paint on it". There are of course special cases where the user needs to manually UV map the object, but we won't get into them now. The only way to achieve this, in general, for 99% of 3D models, was to simply give up on seam reduction, and simply make the software paint across these UV seams as "perfectly" as possible.

So, when Blacksmith3D-Paint auto-UV maps an object, it takes chunks of the surface that are relatively flat  in relation to each other, and UV maps them to a plane. It takes all of these chunks and packs them tight in the UV mapping space, while leaving a bit of space between the chunks (for technical reasons). Since each of these chunks is a simple planar mapping, where the shape of the polygon in UV space is very similar to that in XYZ space, there is little to no texture distortion.

So, the moral of the story is this...

Less Texture Seams = More Texture Distortion

... and if the sections are planar mapped as described above then

More Texture Seams = Less Texture Distortion

That pretty much sums it up,
Konan

konan: That's what I was trying to tell people in that thread. As painting programs that work in model space like Blacksmith3D-Paint become better and more available, seams will become less of an issue. Even if people did most of their texturing the traditional way, it should still be much easier to fix problems across seams by switching into a 3d painting program and just paint over them. But it looks like that approach is still hard to sell, even for a small number of 'extra' seams at problem spots like breasts and the nose/lip region.

So I've come to the conclusion that for now, having two alternative UVs - one for the traditional and one for the 'modern' way of texturing - would probably be best.

I think bagginsbill's idea is very interesting, but probably more so for procedural materials than traditional texturing. For me, the optimal solution would still be some way of 'hot-plugging' a .uvs file into an existing figure.

Hmm, I guess I'll wander off now and have a look at the Poser Python documentation.

konan, would it be alright for you to post a sample texture of a face with UVs created by Blacksmit3D-Paint so I can see how the texture is broken up and placed on the flat plane?