Attached Link: http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2756064

I have build some good materials to simulate the plain silver as also the rippled fabrics.
As shown in the original image part in the middle the body suit has some lace or clamped association or so along the outer leg sides.

My question now, is it possible to do such thing only using procedural shader's ??

I have not found how to trigger the correct position only using math nodes or such thingies.
So I have included the bodysuit's (in this example it's build up using V4 bodysuit) uv-map to simulate something at the leg side. But using the uv-map gives me only 20-50 pixels so it's to less to get something really detailed (might be only for my texturing skills :rolleyes: ).
And that this small region must be used for some displacement, naturally according to the rest of the cloth displacement, makes thing's not easier.

Thanks in advance for giving some idea's or advice

Jo

I've been casually lurking in that thread - nice job.

I haven't read very closely so I'm not quite up to speed on the issue.

This is V4, right?

Are we shading a body suit that is like V4's stupid UV map? (I don't have this item and have never seen it)

If so, this is a very complex UV mapping problem. If I understand the issue, the UV map density is really low here and so you can't get that kind of detail from an image map, right?

So procedurally we can do it, but the UV axes don't line up. And there is a discontinuity in UV coordinates between upper thigh and lower thigh, as well as a huge abrupt change in UV density. Am I understanding the problems or off base?

We could work on transformations, I suppose, but how about some out of the box thinking first?

The side lace-up looks like it could be modeled as a separate conforming clothing item, just a strip up the side of the leg. It seems to stick up from the rest of the legging. You could model that with a good straight UV map and just apply a tiled image of the lace only.

Or what about re-mapping the legs altogether first?

Or what about using stockings, such as SVDL's free lingerie? I bet those are UV mapped nicely.

Just some ideas. Meanwhile, I could certainly come up with a math formula that produces that lacing pattern procedurally (not easy but could be done.) The question is how to transform the bad UV coordinates into nice orthogonal UV coordinates.

You mentioned "included the bodysuit's uv-map" - where is that so I can look at it? I can't find the link in all that writing you did in the other thread. :)

Never mind I find the BS-LegSeams.jpg file. So the UV seams are actually right there on the side of the leg? Wow that's doubly complicated.

Hmmm. Let me see what I can come up with.

I have an idea about using a piece-wise linear function to track the seam, and use that to "straighten" and "expand" the UV map.

Hi Bagginsbill,

Quote - - This is V4, right?
Are we shading a body suit that is like V4's stupid UV map? (I don't have this item and have never seen it)

Yes, it's V4 and in example her bodysuit from DAZ. I used that cause it has some nice morphs to give the pants and arm sleeve a bit flare not as tight as a pantyhose or stocking.
That bodysuit has a compltely different uvmap compared with V4 ... especially regarding the legs and arms. Legs are 4 pieces left/right as back and front. Back an front match exactly there the lace now is placed. So that makes the additional problem that the back and front side of the lace are on 2 different pieces in the map. Makes it more difficult to have them right matched.
As said I'm not such a great texturing specialist.

If my 2D skills would be better I might never have come to 3D ... buildings, cars, technical drawings as also trees or birds ... ok ... but something looking like human beings, even if aliens,  no, no,  better to have 3D to make 2D images ...

But back to theme, morkonan, who is building that moonbase jumper might use the shader on the V4 as a second skin.

So my idea was to create something that might be used on the bodysuit (or other clothing) with a bit transparency but on other hand could be used also as material for a second skin without transparency.
As far as the fabrics without that lace it works very well.

So thinking that the uv's might be different I needed something to set the correct position of the lace depending of the carrying figure. That was the base idea to combine a uvmap for that part with all around as procedural.

If you see my map (didn't know that I mentioned somethere to include the complete uvmap ) that black lines are round 20 pixels (back and front) in total and the underlying polygons are only 5-6 in total parallel along that lines. So there is not much volume to do something.

Quote - - So procedurally we can do it, but the UV axes don't line up. And there is a discontinuity in UV coordinates between upper thigh and lower thigh, as well as a huge abrupt change in UV density. Am I understanding the problems or off base?

Additional direct in the middle, e.g. exact the border of the uvmap, is a straight seam that can be morphed to be seen in the figure. That's cause it looks as if the fabrics isn't right fitting even if the uv is matching front and back. But thats not a problem, needs only to morphed zero to go straight.

Quote - -The side lace-up looks like it could be modeled as a separate conforming clothing item, just a strip up the side of the leg. It seems to stick up from the rest of the legging. You could model that with a good straight UV map and just apply a tiled image of the lace only.

Modeling as a conforming clothing is for sure a good idea and if it would be for Posette it would have been my first ... but V4, uh, why does she have so much morphs and magnets and other memory killers ...

Quote - - Or what about re-mapping the legs altogether first?

It should be a most simple solution, also I think remapping would not solve the problem with view to versatility of such a material.

Quote - - Never mind I find the BS-LegSeams.jpg file. So the UV seams are actually right there on the side of the leg? Wow that's doubly complicated.

Yeah, they are on position.

Be coaxed :thumbupboth:  Knowing your talents from several postings I would not have bothered you if it's not challenging ... 
I often had colleagues that in front of looking to a problem and trying to solve first asked for some training curses. Not my way ... training on the job is the better solution. What can be done should be tryed ... but, ok, than might be a point there it is better to ask a expert as to waste time and energy on a might be misleading way ... so here we are ...

Quote - - I have an idea about using a piece-wise linear function to track the seam, and use that to "straighten" and "expand" the UV map.

Hey, that sounds good ... though I have no idea how this might look in source ...

But this will also need a 2D map to find the correct position, right ?

See, I didn't see any solution to place a procedural shader on a specific position if it's not a mat zone as such. Ok, there is a function to get exact x,y,z-positions but only in viewspace. So I looked desparately for such function giving that point on a figure.

That fabrics material for example is derived from a stripy material I have created for stockings of the "Pippy Longstockings"-type (in german Ringelsöckchen). And there my first approach went over that x,y,z space component with the problem that the material didn't follow the clothing.

So then went over to that u-v-components but they don't give any chance for a precise positioning in the mat zone or did I overlook something.

Well, I've been very successful with UV coordinates in poser nodes. They are very very very precise, even if a corresponding 2D image map would be sloppy.

For example, I am able to create threads on a scale of 200 threads per inch that are entirely driven by the UV coordinates of the geometry. Even at these tiny scales, the coordinates are accurate, and so any procedural arithmetic works perfectly. As a result, I often can re-scale otherwise low-detail image maps to cover very tiny areas of UV space, even with twisting and bending.

Here are some examples: some cloth weaves I did procedurally.

http://poserbagginsbill.googlepages.com/weaves

If you scroll down to the blue one, you will see some extreme zoom renderings showing the incredible detail at such small UV scales. Individual fibers are visible and these were driven by UV coordinates.
 

Hey, that's really great ... looks absolutely natural ...

Is it done in Poser's shader system or in a "full-grown" app like 3DSMax or C4D or only renderer specific ?

If Poser how will this influence rendertime? Do you have a mt5 so I could test a bit ?

I think the UV map is not bad only that the coordinates from back and front seem's not match exactly. But the polygons are running straight along the used seam. Only problem that the map is very tiny to be used for texturing.

But with such a procedural shader this should not be a problem as I understand.
Otherwise rendertime will also be no problem if using two different material collections. One with less/no detail for normal scenery images and a second one if making a closeup and also only if legs are in view.

Think we should give that a try ... means I will need a small example to figure out how to do so.

B.t.w. I just had a look to a other thread regarding "making surfaces glow". By using spot or point lights I have found that these don't respect physical limits. They illuminate things through non transparent objects like wall's or such. Mean's a person behind the wall will get light and throw shadows  as if directly in the spot/point light.
That seem's to be a poser and/or render engine bug. Did you have also such experience and might be you found a workaround ?

Those are all in Poser, using Poser procedural materials (lots of nodes, many were over 100). I develop complex shaders using a tool I wrote called matmatic. With matmatic, we describe the nodes we want and how to connect them using simple Python scripts and standard mathematical expressions.

For example, in matmatic I can make a nice swirly glass with built-in gamma correction like this:

gamma = 2.2
glassColor = Clouds(GRAY2 ** gamma, Color(.3, .5, 1) ** gamma)
reflection = Reflect() ** gamma
fakeFresnel = Blend(.04, 1, EdgeBlend(0, 1, 1) ** 4)
specular = Glossy(WHITE, 1, .001)
diffuse = Diffuse(glassColor, .8 * (1 - specular) * (1 - fakeFresnel))
combinedEffects = Blend(diffuse, reflection, fakeFresnel) + specular
output = combinedEffects ** (1 / gamma)
Surface(1,0,1,0, Alternate_Diffuse = output)

This generates a shader with 14 nodes. A render of it is attached.

This is not too hard by hand, but when you get over 25 it is difficult. Over 50 nodes, and it is extremely difficult. Over 100 nodes by hand is close to impossible.

But more than that, the scripts let me define re-usable material effects, which I can combine and swap easily. For example, I have a true Fresnel reflection shader network that is over 20 nodes all by itself. Yet I can use that with one line of script.

Quote - If Poser how will this influence rendertime? Do you have a mt5 so I could test a bit ?

Sure - I've done performance tests. Some procedural nodes are cheap, others are not. It depends on what you're trying to do. The woven cloth shaders use so many nodes that they are indeed expensive, even if most of them are simple arithmetic. Sometimes I "bake" the procedural texture into an image and just use that.

I'll find some links for you. You should learn to use matmatic and the Loom script I provide to do those cloth patterns., Then you can download hundreds of cloth patterns and make them use any colors you want.
 

Here is where to get matmatic:

http://sites.google.com/site/bagginsbill/free-stuff/matmatic

This rendo thread has tons of material info - many postings by me. Scroll down to find a whole section on matmatic.

http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2722867

The Node Cult forum is loaded with matmatic stuff. Search it. (Make sure you search archives - the regular display only shows recent threads.)

http://www.runtimedna.com/mod/forum/messages.php?Archive=Yes&forum_id=92

Threads about the Loom:

Loom: http://www.runtimedna.com/mod/forum/messages.php?ShowMessage=265148
Making your own patterns: http://www.runtimedna.com/mod/forum/messages.php?ShowMessage=265475
Using downloaded patterns: http://www.runtimedna.com/mod/forum/messages.php?ShowMessage=265484
Prints and paisleys with the Loom: http://www.runtimedna.com/mod/forum/messages.php?ShowMessage=338877
Showing off with the Loom: http://www.runtimedna.com/mod/forum/messages.php?ShowMessage=266347

Thanx for these links ...

Matmatic is already on my harddrive but only as download in archive. I'm hanging lot's back with updating my runtimes. As first I updated my V4 runtime. Year's ago people often used no path's in zipfiles so you needed to sort the things by hand to directories.

Now the runtime structure is in zip but people often forget to have the correct path's also in the CR2, PP2, PZ2, .... so again lot's of work even if using a organiser software.

So V3/M3 is awaitung update and than architectural runtimes and so on ... and there is also a bunch zip's with scripts, python, tools, ... From that your leg stocking shader's have the highest priority ... b.t.w. really great stuff.  Especially that idea with the color matrix is super. With the normal poser/windows color selector it's sometimes a lot of trial and error to find a correct choice cause you have to go back and fore a lot to see if the color really looks well on the complete cloth part. So having a bunch of fine tuned matching theme related color's in one pallet is a great help. :thumbupboth:

As far as I have lurked through the matmatic thread's I understood that it will help greatly to create patterns, textures and so on of all kind.
But has it also abilities to position the pattern exactly on the figure where it belongs.

So my main problem at the moment is less to have a texture as such but to have it at that small leg seam.

B.t.w. in my legseam material I have combined the uv-map with the stripe shader in the last node going to the displacement channel. For that combination I used the ADD function that gave a clear black und white map. So should work as none or full displacement.

Yesterday I have looked much much closer to the rendering and found that white is not equal white in that last node. That makes different displacement along that seam there it should have the same amount.

Mathematical it is correct. So there the black parts of both inputs comes together it's zero. Black and white adds correctly to 1 and where both inputs are white the result is 2.
But I was surprised that Poser 7 is using the numerical equivalent of that transaction and not the shown grafical interpretation. So in this fact we have white (1) and whiter than white (2).
Is this a new behavior in P7 or did P6/P5 it in the same manner. I didn't recognise that before.
I now have changed the ADD to MAX. So using this I get only 0 or 1 but this might not be sufficent in case grey value's are used in such surroundings.

As also I have found that under some circumstances it's not enough to set transparency to 1 to have some clothparts invisible. I had to go to 2 or even 5. I didn't see such behavior before and hidding part's by full transparency is a often used trick of cloth texture designers.

I know that poser creators switched something in that themes, e.g. the filtering options for texture maps. But did they also change on the interpretations of that numerical parameters ?

Colors have always been full range numbers in Firefly shaders, since Poser 5 and up. WHITE + WHITE = 2 * WHITE has always been the case.

The preview of such things, of course, cannot show you double white. Nor can it show you negative colors, but they exist and I use them a lot.

Frequently in making color patterns using matmatic I may say something like this:

(3 * a + 100 * b) / 103

If a and be are numbers, this is perfectly reasonable for any numbers even those outside the range 0 to 1.

For colors, we whink this is impossible, because (3 * RED + 100 * BLUE) / 103 seems like nonsense. But of course colors are not colors at all until we try to draw them. Until then, they are just vectors with 3 elements. [r, g, b]

So all the Color_Math nodes in Poser should really be called Vector_Math nodes because that is what they are.

Our displacement maps, when visualized as a gray-scale image, do seem to be limited to 0 to 1. But as soon as you start to combine them using math, they can easily go outside that range and quite often this is completely desirable.

If you wish to limit something to the range 0 to 1, whether a single number or a color (vector) you simply use a Math:Clamp or Color_Math:Clamp node. All values will be limited to 0 to 1.

In matmatic, given you want to limit the sum a + b, you say:

Clamp(a + b)

It does not matter if a and b are numbers or colors - matmatic will use the correct node automatically.

"So my main problem at the moment is less to have a texture as such but to have it at that small leg seam."

So leaving aside the issue of what the texture actually looks like, I set about experimenting with using nodes to force a tileable texture to be able to shrink to a tiny area and follow a curve.

Here is the tile I'm starting with. I downloaded this from here:

http://www.sharecg.com/v/27272/texture/Hi-Res-Cable-Knit-Textures

These are free textures by Agatha Paige. (Thanks go to Agatha - very nice work.)
 

This shot is with the camera at 20mm so we can see the entire UV space on a one-sided square. The tile you see above has been shrunk to cover 1/80th of the original size.

This reveals that no detail was lost. We can start with a fairly small tile and compress it to a tiny fraction of the UV space with no loss of information. Neat.

To get this level of detail with a full UV map texture, it would have to be 40000 pixels wide and 40000 pixels high.

The two places where you see the number 80, that is where I'm setting the transformed size of the original tile - 1/80th size.

I despair of this ever working here, however. Since the strip must span a seam, we must generate two strips. OK no big deal. But I fear that the corresponding pieces of the left part and right part are not rotated the same. If the UV map projection of the leg piece is rotated, we must also rotate the tile. I doubt we can come up with a function that will cause the two halves to line up perfectly, even if we get them to follow the seam.

I really think you should be working with some other cloth instead of that one. It is incredibly stupid - really obnoxious - that the seam is on the outside of the leg instead of the inside.

Stockings and leggings often have features on the back or outside or front, and a clothing item with a seam in any of those places is just stupid. The only proper place to cut and unwrap the cloth from is the inner leg.

You may be curious about what's going on with the Fractal_Sum node. This has nothing to do with this clothing item. I just needed some interesting curve to demonstrat bending the strip, so I used this node to make a curve. For the real thing, we'd need a specific curve, not a random one.

Anyway, I exploited here an interesting undocumented feature of the Fractal_Sum node. (A few others do this same thing.)

The FS node creates a 3-dimensional pattern that is superimposed on your model. This pattern, based on random numbers arranged with varying frequency, is normally sampled by the shader for each point of your geometry. Whatever value actually exists at that point in the 3d noise function is used by the shader.

Normally all you can do to alter the geometric layout of the pattern is mess with the scale parameters. The coordinates of your object are transformed using these scales to look up a value in the 3d noise. The coordinates come from your model, not the final transformed world coordinates.

But! I found that if you plug any node into those scale parameters - any node at all - they no longer use the model coordinates. Instead, they strictly use the value that is plugged in!

So what I did here was to plug in a math node into the Y_Scale and Z_Scale. This effectively freezes those axes. The pattern then transforms from being 3-dimensional to 1-dimensional. If you were to plug a math node into only one of those 3 parameters, then you would get a 2-dimensional pattern.

Now the remaining parameter, the X_Scale, I plugged in the V coordinate from my UV map. Thus the noise pattern is entirely varying only along the V dimension. Any change in U, X, Y, or Z is not involved in generating the pattern. Only the V coordinate causes any variation. Thus, I made a node that produces random values vertically, but constant values horizontally.

Neat huh?

Hi,

I yesterday experimented a bit with P6 and so found that the mathematical behavior was the same.
Seem's I had the luck never to come to that up to now ... ok, I used displacement sparse, much more often bump. Displacement is a bit more critical in strenght of effect ... the values needs very fine tuning.

Whow ... that's what I'm looking for ... great, great, great, ... :thumbupboth:

Even that pattern you used ... ok, the outside lace could be cut away but that 2 crossing "ropes" being the main part could be easily seen as 2 strings concatenating the both sides of the pants. Having some values from greyscale on that map we have a fine dsiplacement or bump map as also a color map.

And with not very much nodes we can use that in all conditions. So no need to change material for closeups. Superp ...

40000 * 40000 pixels ... I for sure have overseen some advertising Smith Micro gave out than transferring Poser to the CRAY ...   I think also in 10 years no normal pc would be able to handle such size images.  So your  method  comes in handy for long times ...

This node setup look's not very complicated ... very understandable.
So instead of the fractal sum parts the uv-map, which is giving the desired path, have to implemented. Am I right ?
And that then combined with the rest of all outside material. Sounds as not too complicated procedure. Good to have tomorrow as a free day ... I'm experimenting on that.

Normally a value plugged into the scale channels should, as I understood, give the posibility to externally control (multiply) the scale value. In this sense your exploitation might be more a found bug than a undocumented feature. As I have read these are all features from the underlaying render engine which is no invention of poser. So could be interesting how this renderer is treating that feature if not implemented in poser but stand alone.
But never the less, feature or bug, until the next full version number we are sure that it's working ... as I know poser developing also for some more versions ...

The problem with the seam on the uv-map for the bodysuit is not a great one. That needed seam is so small that I have no problem to hold the complete area on one side (front or back) of the bodysuit. Or I take a pattern that not neccessarily needs to match between front and back.
Especially I think of a "boatswain's seam" which in realitiy is used sewing two parts of a sail without any overlapping of the sail parts. So the fibre seen rightside over the sail will vanish under the leftside sail and vice versa. And then it's no problem that the fibres don't match in the middle.
So this problem could seen as solved.

And for use as V4 second skin it's even no problem cause at the position where the lace shall be the uv-map isn't split.

I'm with you in your critics where the cut's of the bodysuit are placed. They are not only on the outer leg side but also at the inner. The uv-map of the legs is made up from FOUR pieces, left front, left back and right front, right back. I think they did this in accordance to a pant which normally have seams at that places. And alongside the outer seam's the bodysuit has a morph to simulate such a real seam.

But on other hand I don't anderstand this ... V4 and the bodysuit coming from the same house (DAZ). Second skins on V4 and the bodysuit are two connatural posibilities to have a full body clothing so it would be a great advantage to have a similar map. Not in mat zones but in the all over shape ... rather strange ... :unsure:

I come back with some experimental results ...

I did some experiment's with more or less success ...

This is your original setup used on the bodysuit. I have set the 2 in the math node for the fractal sum path to 20 only to have the pattern seam more visible in front. With 2 it's right between the legs.

As I understood we have 3 parts in that setup.

First the fractal sum with companion is giving the needed path.

Second at the bottom the math nodes with v-component. That V goes also to the fractal sum (X) only to "matched" V with the x-y-z coordinates for the visibility at the match point. I'm right.
The visibility for V is running through the complete material group ... in our exercise.

So third at the top we have the u-component and here neccessarily the path from fractal sum is needed to have the right direction for the seam.

In both, 2. and 3. part, the reduction for the used pattern is done. In this case 1/80th to fit nice to the path.

So pushed a clamp node between ... the preview of the math nodes looks similar but as I thought there is only a tiny part really white=1.

So after clamp the pattern material stretches over the complete white area.

B.t.w. I have used the same pattern like you. Only I colored some cord's with blue and red for the crossing and green for that outside. It's only the have better view on the small render preview window.

I have put one on the bodysuit uv-map right in front down the right leg. As shown in the picture.

Normally, as with the map I used before, we need that line directly at the left border of the right front leg and accordingly on the other part for the left leg. But as try out that one line will be enough.

Avoiding all u-component stuff and the fractal sum path the outcome was like expected ...

The path is where it belongs by uv-map. U is directed by the map and V comes from the v-component running through the complate group. OK, fine.

Only the pattern's replication is to high cause we omitted completely the factor 80 for the U part.

As you might see there are some white dots on the right leg. So something is happening but nothing usefull I suspect.

Ok, in one fact it was successful. The path has gotten back it's shape but it lost the position.
So changing the 1 in the math node 5 will let the path hiking round the leg.

And here we are.
What have I overseen or where is my error in reasoning ??

We need the both math nodes with 80 for sizing the pattern to be used. And we need a path on which that pattern shall be projected. And that path have to be defined externally so one can position it where needed on a cloth or second skin.

The fractal sum is working with the x, y, z axis (planes). So this values have to be transformed to U-V to match correct to the figure.
Using a uv-map we have UV-coordinates directly which have to be used.

Or is the path given in the UV-map made to big ???

It looked so nice with the first try except that nasty missing replication factor 80 ...

   :crying:   :unsure:   :huh:

Hmm. I didn't read all you wrote, because you're on the wrong track from the start.

The curve input, to replace the Fractal_Sum, must be a gradient in the V direction, with no change in the the U direction.  The idea is for each row, there is U_Offset that should be used to move that row into position on the figure.

You don't want the offset to vary within a row. So in any given row, every pixel should have the same gray value. We really only want to represent a 1-dimensional array of numbers, laid out vertically.

When you used the black-and-white pattern, you were doing all or nothing, and it was changing within the row. You want to use an image that has a gray value between 0 and 1 that defines the offset within that row, period.

For example, let's say that at some point you desire the U_Offset to be .675. You should put Gray level 255 * .675 = 172.125 in that row all the way across. Of course you cannot do fractions, so you would use 172.

This may cause some noticeable jumps - we'll see. You may have to encode the data in a 16-bit tiff instead.

Just a thought and probably mentioned in the thread here (i didnt read it all ) is to place the lacing on the edge of one piece to make it easier to texture , then the material on the other piece just has to be fabric. It may make problems by not having the seam placed correctly elsewhere though.

carry on  

Jo,

I copied the seam guide and drew my own curved line, trying to track the edge of the leg.

I then wrote a program in Python (real Python not Poser Python) using the Python Imaging Library (PIL). In this program, I found the position of this curve and converted the x offset of the curve into a gray-scale image. 

The first time I did this, the resulting data was too coarse, resulting in stair-step jumps of the stripe on the render.

So I changed the range. I observed that for the curve I wanted it, the x offset was between .23 and .29. Using this information, I shifted the output of my grayscale image to mean a number between .23 and .29. In the shader I then used .23 + .06 * grayscaleCurveImage. This produced much better results.

Because the seam guide you gave me was so low in resolution and detail, and my lack of drawing skills, the resulting data was uneven. There were some incorrect data points. I changed the python script to smooth them out using low-pass filtering, but the random occasional incorrect offsets are still there.

If you could draw the curve more precisely, it would work fine.

In order to produce two such curves on the same material, we have to do this over again for another curve. Then we cut and paste the two gradients as appropriate for each section of the UV map. For one leg, we use data from one of the gradients. For the other leg, we use data from the other gradient.

We can produce any number of stripes on the same shader network in a single gradient image, so long as they don't have to touch.

If the 256 steps from .23 to .29 are still too rough, we can do other tricks to encode more precision. I did some extensive work in the past on an encoding in RGB (using 24 bits) that can survive Poser's interpolation between pixels. The resulting data is effectively 13 bits.

If you're not familiar with the issue, here it is. If you encode a 16-bit number across two channels (for example, red * 256 + green = the number) you can store much more precise information. However, as Poser interpolates independently in each channel, you find areas where the red goes up at the same time that the green goes down. For example, from 255 to 256, the red goes from 0 to 1, and the green goes from 255 to 0. When Poser interpolates between these pixels, you can get a Red=1 Green=127 pixel. This is the problem - the low order channel (green) makes these big drops to go into the next range.

I got around this by spreading the low order information between green and blue, redundantly. In areas where the green makes this sudden retrograde transition, I encode the same information in blue but shifted by 128, putting it right in the middle of its smooth range. And vice versa, if the blue is in retrograde, the green is at 128. Using this technique, I can get an effective bit density of 13 bits per pixel. And no matter how drastically Poser tries to interpolate (and mess up) the data, it always survives.

The decoder for this is not too hard.

However, I have no more time today to work on this. I will come back to it as soon as I can. Then I will also share with you the Python script. I assume you are technical enough to be able to go get real Python and PIL and install these on your computer.

Hi Bagginsbill,

we are not so much different.

I also left the v-component untouched and wanted to get the u-offset from the bodysuit map instead of taking the fractal sum as a path. As seen in one of my pictures in middle.

Only I was in the opinion that the missing U value could be taken directly from the linein the map.
And found that the line was to wide. So needed is only, let's say 1 pixel in each row.

And that have to go as a x-coordinate into the process like given by the fractal sum.

In original the uv-map of the suit is 25002500 pixel (a V4 map according to that is original 30003000). You take the map from left to right (x-coordinate) as 0 to 1. So 1 means pixel 2500.
Than your line for the right leg seam is iterating between .23 and .29.
To understand if now I would make a line for the left leg I would end up round .55 to .65. This is roughtly estimated by view. Correct ?

And than you put this x coordinates into a greyscale image in vertical order. That's the point I didn't get. I would have done that in horizontal order thinking I would need the horizontal variation of the line.

So the main point is that the uv-map isn't useable in direct manner in the material. We first have to transpose the coordinate information from the uv-map to a new greyscale image.
This can be done only outside of poser by an supporting piece of software.
We have to count the pixel number in x direction and transform it to a most widely spread greyscale. In principle black is the most left position going to white as the most right position.

So you python script is mostly appreciated. I have VB and a graphical library for that on my puter. That should work easily on the same. Was for my last project, a program to measure the internals of a scanned cut tire section. Only a matter of mouse position and a bit pythagoras to get points and calculate length of line between given points.

So that should do the job in finding pixels and recalculating them.

Nice, very nice, seem's we are coming forward.

B.t.w. I'm really not bad in logical analytics. It's neccessary to see and understand customer's need if developing program's for that. I'm for sure a good software developer with databases and admistrative stuffs but would not be a good one for gaming software for example.

And here the connection or say the twist between 2D and 3D relations is not easy for me.

For example to have that pattern map in front and that pathworks stuff connected to these map was something new to me. Ok, I have read the documentation (not much about that) and tutorials to this theme.

But how do you find such idea's. Only as enthusiast with long trial and error experience in the first time or do you do this by profession having learned in some academic year's ?

No training whatsoever in graphics. Just lots of experimenting for fun.

I studied computer science and electrical engineering in college but graphics hardware at the time was impossibly expensive. None of my professional software development experience is 3D stuff. Some 2D image manipulation, but only to create nice effects in business and network applications. (For example, how to dynamically stain an image or convert to gray scale to indicate that an icon has been selected, or a business process in some specific state with color, without making graphics people produce variations on the icon.)