does the number of textures slow down the render?  what number is to big?

the reason i am asking is because sometimes i try to make the full suit of costume with one UV template. you get a lower number of textures but its hard to get details.

the problem is of course that i dont use black/white textures for bump and specular. all my bump  and specualr maps are different . so sometimes i have 3 maps. color,bump and specular.

now if i would have 3 UV templates for a bodysuit then with bump and specular this would be 9  maps. this would slow down the render right?

what would be your advice?

You can combine your monochrome maps.

The three color channels of a color image are independent. If you were to place bump in red, and specular in green, you'd still have a 3rd unused channel you could use for something else. If your costume is only a few colors, you could place a mask in the third channel and use it to drive a Blender or a Color_Ramp to select the actual colors.

Thus you'd only have one image for color (selector), bump, and specular. They would really be three images, but you'd only load 1.

To separate the channels, you connect the Image_Map node to a component (Comp) node. Component 0 is the red channel, 1 is green, 2 is blue. Set the color to white and connect it to your combined Image_Map. If you used the strategy I described, then Comp 0 is bump, Comp 1 is specularity, and Comp 2 is your color selector.

Taking this idea a bit further, since one can embed bump information in a colour map, I wonder if one can extract bump information from one of the colour channels of a colourMap. I know, I know: bump is a completely different sort of information that what one would be able to extract from a colourMap, but might it be because there's just too mch, and it's the wrong way around, like eyebrows, for instance. I guess I'm probably way off, but if for instance one could pinpoint the colour of say the eyebrow with component, then reverse it and use it as bump?

Probably not making any sense...

Quote - You can combine your monochrome maps.

The three color channels of a color image are independent. If you were to place bump in red, and specular in green, you'd still have a 3rd unused channel you could use for something else. If your costume is only a few colors, you could place a mask in the third channel and use it to drive a Blender or a Color_Ramp to select the actual colors.

Thus you'd only have one image for color (selector), bump, and specular. They would really be three images, but you'd only load 1.

To separate the channels, you connect the Image_Map node to a component (Comp) node. Component 0 is the red channel, 1 is green, 2 is blue. Set the color to white and connect it to your combined Image_Map. If you used the strategy I described, then Comp 0 is bump, Comp 1 is specularity, and Comp 2 is your color selector.

but in my bump i dont just have positive. i also have negative. white is positive,grey is middle and black is negative. in my bumps maps i have both black and white. i watched a lot of  tutorials for production texturing and for realism i think its best if you have seperate maps. because in the bump maps i have a lot of information.

i understand that my textures (freestuff) are not the most realistic textures on the internet. but i do think that they are more accurate then 70% of poser textures.

my questions was more about the amount of texture maps.

i am now using 4K maps. sometimes 3k. if i would sperate objects  then i wouldnt need 4K maps for details. 2K would be enough. imagine that you have a 2k map for gloves. this is enough.

the question now is if i would have for example 10 2k textures would this slow down the rendertime a LOT?

thanks

Quote - Taking this idea a bit further, since one can embed bump information in a colour map, I wonder if one can extract bump information from one of the colour channels of a colourMap. I know, I know: bump is a completely different sort of information that what one would be able to extract from a colourMap, but might it be because there's just too mch, and it's the wrong way around, like eyebrows, for instance. I guess I'm probably way off, but if for instance one could pinpoint the colour of say the eyebrow with component, then reverse it and use it as bump?

Probably not making any sense...

impossible. because you dont have the control how much bump is on that area. even if you would have eyebrow at the same direction like skin.....you still wouldnt have the amount of bump correct. you need full control how much bump is on the skin,eyebrow,nose . then you also need wrinkles. wrinkles are not part of the color texture.

my advice is to paint a seperate texture for bump. the difference is not small ....but HUGE.

Aha!  Thanks for the tip, BB.  Some texture packs I bought a while ago now make perfect sense.

ice-boy:

bagginsBill's suggestion will still work for you. The Bump and Displacemsnt channels of the Root Node convert everything to greyscale. Color does not matter for those channels. Red would be "seen" on those channels as black/grey/white. You can use a node to convert a specular map encoded in color to a greyscale image. Thus, in one map you could have Bump, Displacement, and Specular maps.

This is an interesting concept. One could have the Bump maps for the head, the torso, and the limbs in one map, and seperate them out with nodes. I wonder if there would be any savings on memory usage with this strategy?

lmk

ikendall you will need to show me an example how could this work.

red will only be red. it can not be black/grey/white

@ lmk - that's exactly what I've seen on some packs I bought.  IIRC, there's a wet skin shader by Rubicon Digital which has the maps laid out in that way.  I couldn't figure out what was going on but BB's explanation nailed it.

There is most likely a saving, since there's only one map loaded when - by other methods - three or four may be needed.

Brilliant concept, actually - going to need to try it via Photoshop - combining the different maps using colours, then using the Component node to separate the colour info out of that single image to use in the various channels.

Quote - This is an interesting concept. One could have the Bump maps for the head, the torso, and the limbs in one map, and seperate them out with nodes. I wonder if there would be any savings on memory usage with this strategy?

Whether you use 100 textures of 8k by 8k or 4 textures of 2k by 2k, there is no difference in how much memory FireFly needs for rendering them, it's using a texture on demand system (comparable to http://graphics.pixar.com/library/TOD/paper.pdf). To get the best performance from that, it's better to put data that belongs to the same point in the model in one texture (for example, bump, specular and highlight size for the head) rather than putting data for multiple body parts in one texture.

I have been too busy to come back and explain. It's very helpful that others chime in.

ice-boy: Do this simple experiment. 

Load any "color" image you want - anything at all - into the material room.

Attach a Component node as I described.

Examine the preview of the component node. It is not red or green or blue or any other color.

The red channel of an RGB color image does not have "red" stuff in it. It has numbers. These numbers indicate how much red to draw. Similarly the green channel does not have "green" stuff in it, nor the "blue" channel any blue stuff. These are just luminance values - gray-scale numbers.

When you examine one by itself, via the Component node, all will be revealed.

I forgot to give an analogy that I was thinking about. 

Cookie jars are for storing cookies, no? What if I want to put coins in there - will they come back out as cookies? Will the cookie jar refuse to hold the coins since they are not cookies? Nonsense.

And if I place cookies in my coin purse, does the purse refuse?

Similarly, the red channel can store various amounts of red stuff, or it can hold bump map heights, if I choose to use it that way. Amount of red, amount of bump, both are numbers and can be stored in 2-dimensional arrays of numbers called images. I can store them any way I like, and different ways offer different advantages with respect to space, time, and convenience. (Never all three are good at once)

However, this is a Poser trick. Many other 3D apps could not deal with this because they do not have such good facilities for doing math with images. That's why you don't see this kind of magic used very much.

You could use an HSV node or one of the math funtion nodes to remove the color from one of your existing maps and then plug that into specular and bump. 

BTW, forgive my ignorance, but is there a specific reason to spilt things into R, B, and G?

Quote - You could use an HSV node or one of the math function nodes to remove the color from one of your existing maps and then plug that into specular and bump.  BTW, forgive my ignorance, but is there a specific reason to spilt things into R, B, and G?

Bump and displacement don't use colour at all... to them it's all shades of grey. The amount of red in an image would be picked out using a Component() node, which, when fed into one of these channels, would simply be seen in terms of shades of grey, not the colour itself. That way, you could colourise a bump map with red and a spec map with green, say, and have that in one image, which the Component node could separate out to use where you need it.

Quote - To get the best performance from that, it's better to put data that belongs to the same point in the model in one texture (for example, bump, specular and highlight size for the head) rather than putting data for multiple body parts in one texture.

Does that mean in the case you have a big map that includes bump, specular, highlight and setup it to offest to use in anycase the corresponding part of the map (I think I've seen this in a post in the past) is better than 3 maps?

Does poser handle greyscale maps without converting them to rgb? I already know that it can load them (eg pgm-format), but i do not know if this actually saves memory or if everything is converted to rgb while loading anyway. If the former is the case it would probably be easier (and faster) to just simply use greyscale images instead of stuffing bump, specular etc. into the different channels of an rgb image.

Quote - > Quote - To get the best performance from that, it's better to put data that belongs to the same point in the model in one texture (for example, bump, specular and highlight size for the head) rather than putting data for multiple body parts in one texture.

i dont understand what you mean.

Quote - I have been too busy to come back and explain. It's very helpful that others chime in.

ice-boy: Do this simple experiment. 

Load any "color" image you want - anything at all - into the material room.

Attach a Component node as I described.

Examine the preview of the component node. It is not red or green or blue or any other color.

The red channel of an RGB color image does not have "red" stuff in it. It has numbers. These numbers indicate how much red to draw. Similarly the green channel does not have "green" stuff in it, nor the "blue" channel any blue stuff. These are just luminance values - gray-scale numbers.

When you examine one by itself, via the Component node, all will be revealed.

i have been using this for over a year. but not for bump and specular. but for masking. i created 3 different masks with blue,green and red colors. then with the Component node i seperated them. but i understand how it works since masks are black/white.  

but i still dont understand how i could use a bump and specular image together since with bump i am using black,grey and white .

Masks are not black and white. At the boundary, there are many shades of gray.

You're making assumptions that I don't know about, which is why I'm having a hard time to explain this.

Stop assuming and just read this.

Each of the R, G, and B planes of a color image is a gray-scale image, representing a luminance value. In other words, an RGB image is actually 3 gray-scale images, glued together like plywood.

PNG images with alpha channels are actually RGBA, which means there is a 4th gray-scale image included in the sandwich.

The number of bits in each gray-scale image varies with different file formats. Also, the format varies; 8-bit fixed point integers are the most common, but floating point and other options exist. In these representations, we're talking about the bit-depth and format of any of the gray-scale parts of the sandwich. The full color image is in any case just 3 or 4 of these glued together. (Note: JPEG is much more complicated than this. JPEG converts the image into frequencies and throws some of that info away, then stores it in a crazy format I can't explain without a lot of math.)

This also brings us to millighost's question. Is it the same or different to use:

A) 3 separate gray-scale images

or

B) 3 separate full-color images each of which is only being used to hold shades of gray (each part of the sandwich is identical and therefore redundant)

or

C) 1 glued-together color image that contains 3 gray-scale images equivalent to A

to hold our three maps (e.g. bump, specular value, highlight size).

Now I think most people should suddenly realize, or perhaps always knew, that B is the most stupid. What you may not have realized is that is what is being done with almost every commercial texture set in the Poser/Daz world. The stupidest most wasteful approach is the standard in our community! JPEG images are 3 gray-scale images sandwiched together. Further, while methods vary, generally speaking the green channel of JPEG has twice the resolution as the red and blue channels, so you'd get a better bump map if you sucked out the green component of a JPEG and threw away the red and blue.

OK so millighost was asking really about case A versus case C; is there any advantage to processing a single 3-layer sandwich instead of three separate gray-scale images?

Really, is the answer not obvious?

Here's an analogy that might help. Is it simpler (less work) to park 3 small cars or one big car?

There's also no established convention (that I'm aware of) for how to encode an RGB image for this purpose. I've settled on Red = Specular, Green = Bump and Blue = Displacement, but that's fairly arbitrary (it's the order they appear in the Root node, top to bottom). This leaves Transparency unaccounted for, but I think this is best served with a single-channel (grayscale) image.

The screenshot shows a color image consisting of a triangle, a square and a circle separated out into 3 grayscale images for those who fancy experimenting. (BB, please tell me there's a more elegant way of accomplishing this!).

ok how would i change those two maps into one map with only red and green?

I got your analogy last night, but it was getting late and I didn't post these follow up I should have:

1. Wouldn't the fact that some of the colors on the RBG be missing a color or two or have them at a very low number make them a little more problematic for use as a specular or bump map?  If red was 20 and blue was 16, you need to hope green has the information on the map you are looking for.  I thought specular and bump maps need to be black to white in color for best effect.

2.  Are there any realistic times where you need 2 or 3 seperate maps (not including transmaps) that splitting up RGB won't cut it?

3.  If I had a bump and specular map as seperate ones as a creator, I'm assuming I should combine them into two channels of an RGB to save the end user's processing time.

Also this is a bit tangental to the discussion but if I added 6 extra image maps to a material, but I didn't connect them to anything, would their being there slow down processing time?

Quote - I've been using (B) for my own stuff for a while, mainly for props; I think the main disadvantage of this is having to use Poser's clunky math nodes to extract the requisite part / channel / call it what you will.

There's also no established convention (that I'm aware of) for how to encode an RGB image for this purpose. I've settled on Red = Specular, Green = Bump and Blue = Displacement, but that's fairly arbitrary (it's the order they appear in the Root node, top to bottom). This leaves Transparency unaccounted for, but I think this is best served with a single-channel (grayscale) image.

The screenshot shows a color image consisting of a triangle, a square and a circle separated out into 3 grayscale images for those who fancy experimenting. (BB, please tell me there's a more elegant way of accomplishing this!).

those are very simple examples that i have been using for years. simple. transforming a bump map and a specular map with a lot of different shades of grey,black and white would be hard right?

The key is creating the image that combines those maps. I create these as usual (in grayscale), then when they're all done combine them in Photoshop by copying each grayscale map and pasting it into the relative (Red, Green or Blue) channel in Photoshop. It can create a weird-looking color image, but that's not important. If you're using GC, the color image should be linearized (Gamma =  1).

Quote - transforming a bump map and a specular map with a lot of different shades of grey,black and white would be hard right?

Those types of maps are (or should) already be greyscale maps, so no effort required. Combining 2 or 3 greyscale maps into a colour image, shouldn't be much effort either as doing a channel combine is available in 2D programs like PSP, PS and Gimp (and no doubt many others).

For reference there are other potential ways of using colour images to generate multiple masks -> http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2227023

Quote -   > Quote - To get the best performance from that, it's better to put data that belongs to the same point in the model in one texture (for example, bump, specular and highlight size for the head) rather than putting data for multiple body parts in one texture.

i dont understand what you mean.

Putting head bump in the red channel, body bump in the green channel and hand bump in the blue channel: bad idea.

Putting head spec in the red channel, head bump in the green channel and head hightlight_size in the blue channel: good idea.

Consider shading a polygon in the face: the render engine will need specular, bump and highlight_size values for that polygon. If all of them are in one texture pixel in separate channels, it will take only a single texture fetch to get all three values. If they are in three separate maps, it will take three texture fetches to get those values.

I copy each and paste into one of the three channels of an image.

Quote - (BB, please tell me there's a more elegant way of accomplishing this!).

I already did. I explained it already - use the component node. Comp 0 is red. Comp 1 is green. Comp 2 is blue.

Not only is this fewer nodes, but it is less CPU work. The way you did it requires first a color multiply (with [1, 0, 0] for red, [0, 1, 0] for green, etc.)

Then you convert to a number because you connect to a math node. This computes an average of the three channels (2 additions and a divide by 3) which is totally a waste of time.

Then the result has to be multiplied by 3 again.

The component node is straightforward. There is no math - no conversion. It simply pulls out one slice of the sandwich.

Quote - I got your analogy last night, but it was getting late and I didn't post these follow up I should have:

1. Wouldn't the fact that some of the colors on the RBG be missing a color or two or have them at a very low number make them a little more problematic for use as a specular or bump map?  If red was 20 and blue was 16, you need to hope green has the information on the map you are looking for.  I thought specular and bump maps need to be black to white in color for best effect.

I don't know what you're talking about here. The red channel is an independent gray-scale map and has whatever it has regardless of the contents of the other two channels. The same is true of blue and green. A color image is literally 3 gray-scale images combined in a sandwich, with each passing through a different color phosphor once it reaches your screen. No data pass between the layers, ever. Everything in RGB is done three times, once for each channel, with almost no information across channels being combined. The only exception is the HSV node.

Quote - 2.  Are there any realistic times where you need 2 or 3 seperate maps (not including transmaps) that splitting up RGB won't cut it?

No - splitting the RGB channels produces identical data as if they were separate gray scale images. Whatever you put in, you get back out. They do not interact. They do not interfere. They are completely independent data collections.

Quote - 3.  If I had a bump and specular map as seperate ones as a creator, I'm assuming I should combine them into two channels of an RGB to save the end user's processing time.

The word should is too strong. This is a bit of an esoteric angels-on-a-pin discussion. You're not going to save a lot of render time by combining the maps. However, you may save a lot of texture memory.

Quote - Also this is a bit tangental to the discussion but if I added 6 extra image maps to a material, but I didn't connect them to anything, would their being there slow down processing time?

I don't know. If they get mip-mapped no matter what, then yes it adds time. I'm not sure if Poser pays attention to maps before or after figuring out if they are needed. Anyway, I'm talking about render preparation (loading textures). Once the render starts, a million unused maps have no impact. In theory.

cspear,

I just noticed your last node was divide by 0. Very bad and not what you want. That produces infinity, which draws like a 1, but it is infinite.

You want to multiply by 3 if you're going to use the conversion from color to grayscale via plugging into a math node. That means 3 * ((r + g + b) / 3).

Also, your way loses gray levels which is just undesirable all around. You want the antialiased transitions from black to white.

Crud, sorry about the last questions, I just realized I was in the wrong frame of mind for the first one and second one.  I was still thinking of stripping the color out of the base texture map and how that would work, and not a combined map.

One important thing to do when using that trick is to not use JPEG as file format, otherwise you will not get a clean separation between the three color channels.

Quote - One important thing to do when using that trick is to not use JPEG as file format, otherwise you will not get a clean separation between the three color channels.

Yup, it's PNG for this sort of thing.

ok thanks BB i will try it out.

but back to my first questions. so if i have 10 small textures i will not get a lot longer rendertime? it will only take more time for loading right?

i need to make a decision today because 4K texturs for a full bodysuit(all realesed for free in the freestuff section) is not enough. 4K is not enough detail for close ups. so i think i will seperate them. gloves,boots,body,pants,......

I think the texture prep time is mostly total pixels, regardless of how many maps, up to a point. The reality is if you had 16 thousand maps, each at 1 thousand pixels, that would be slower than 16 maps, each at 1 million pixels, even though the total pixels is the same.

If you separate the maps for different parts, you will slightly increase the texture preparation time. If at the same time, you increase the total number of pixels, then you will slow it down in rendering. I don't know by how much. I do know that when I put a 10K by 5K panoramic image into the EnvSphere, that render times involving reflections become HUGE.

Is that because of the 50 MP in one image? I don't know. If you make 50 MP total in 12 separate images, will it be as bad as my 50 MP image? I don't know.

Whoa, 4k x 4k texture in size in terms of pixels?  That's pretty huge.

Hey check this out. I already explained the Comp node and the three-channel image business to ice-boy back in 2009.

http://www.renderosity.com/mod/forumpro/showthread.php?message_id=3462549&ebot_calc_page#message_3462549

How soon we forget -- I know I'm guilty of that! Do you know how many times I've had to go back to the Nodes for Dummies thread for stuff? You'd think I'd get it by now!

bagginsbill i already said that i know that you explained this . i also said that i have been using this for months for masking.

bagginsBill:

In an earlier message you mentioned that the green channel of a JPG image has twice the resolution of the red and blue channels. Would there be any advantage to using a Comp Node (1) to filter out the red and blue channels before connecting a "grey scale" JPG map (provided by a vendor) to the Root Node for displacement, bump, specular, etc.

lmk 

I looked up the details and found I was incorrect - I must be thinking about some other format that I can't even remember what it is right now. I remember one in which green (what we're most sensitive to) resolution or bit depth was double the others, but it's not JPEG.

The JPEG internal data is Y, Cb, Cr, which is basically luminance, hue, and saturation or something like that. Anyway, the hue and saturation data resolution is often cut in half because we don't notice it. That's what I was thinking of, by mistake.

The gray-scale data is luminance, so there's nothing to gain from any tricks.

I read also, while looking for the details I mis-spoke about, that there is a gray-scale (single channel) version of JPEG, used for x-rays or something. Interesting. That should be used for all the other maps besides color maps.

Ikendall, The Bayer filter pattern on a camera sensor has twice as many green pixels as blue or red, if that's what you mean. That doesn't equate to twice the resolution, since the missing color values for each pixel (e.g. the missing red and blue values for a 'green' pixel) are interpolated from neighbouring pixels. 

The JPEG specification allows for images in grayscale, RGB and CMYK, and there's a proprietary derivative that handles LAB color. Poser doesn't like CMYK JPEGs, so don't bother with that. 

Ah yes - it was the Bayer pattern I was thinking about. The green channel of actual digital photographs has more detail than the others. Has nothing to do with JPEG. It's not necessarily twice the detail, but it's not the same either.