When ya makeing Displacement maps

Does Poser Pro 14 support .exr ? or just .tif ?

Thanks a lot

16 bit grayscale TIF is what I use. 32 bit (ie. EXR) isn't supported.

I use png.

They can technically be psd, tif, png, jpg and even tga (i think??). Obviously lossless formats will provide just that. If it's just for you, go all out. If you are creating a product then you must decide between quality and file weight/size...as well as map size (2k, 4k or the dreaded 1k).

Quote - 32 bit (ie. EXR) isn't supported.

Why do you say that?

Why do you think they aren't supported?

W.I.P. just so ya no what kinda of mesh where talking about at the moment.

Mesh 262kb

Flame map 2048x2048
texture 347kb
alfa 186kb

Wick 2048x2048
texture 99kb

Candle 4096x4096
texture 366kb
specular 200kb guess
displacment 8,193kb guess

Candle holder 4096x4096
texture 1,693kb
specular 900 kb guess
displacment 8,193kb

=20,439kb=19.96mb
I'll make a game version with smaller maps ,normal maps.
So they can have quality or small game size files.

I'm guessing 1024x1024 are the smallest maps used with Poser ?

Whats the average folder size of Poser Pro 14 venders ?

Quote - You can easily use .exr images in poser for displacement. 

Why do you think they aren't supported?

 

Thanks bantha ,ah ,now I'm curious to see the mesh that displacement belong to :)

Commerically is fine, just understand that your candle is not the only item on the end-users hard drive...they have tons more stuff.

If it were me (not telling you what to do) I would put everything on one 1024x1024 texture map. You can start off with 2k or 4k map but then size it down appropriately.

The other piece to the puzzle is now the poly count...that needs to be as low as possible while still retaining its shape. The candle might start to show edge faceting due to the lower poly count. No worries, now introduce yourself to the CreaseAngle, this setting can retain hard edges or smooth away faceting.

Something else to mull over is the candle will probably not be the center piece to a render, it will be in the background...you might be able to get away with just a normal map. That would be a lighter hit on the end users computer during rendering time.

Well since ya got to start some where.
Thought I'd start buy turning Tears in to 3D .
Of course people can use the candle for what ever they wanted.

There's more then I knew to consider when making content.
guess I could zip them separate so the end user can get the file size they want.

I do appreciate all the help & advice :)

Quote - > Quote - 32 bit (ie. EXR) isn't supported.

Why do you say that?

Because I've made a faulty assumption :)

Never seen any info that Poser could handle 32-bit floating-point maps for displacement, so I assumed it couldn't. Thanks for posting the demo image - I'll have to experiment this weekend and see what the difference is in practice.

Quote - Thanks bantha ,ah ,now I'm curious to see the mesh that displacement belong to :)

I kind of cheated. The EXR image I used is a studio lighting, it's not meant to be a displacement map. But I did not have the time to create one, so I took what I had.

But EXR is EXR, no matter what it shows.

I tried 32-bit tiff as displ. map and it gave "bad file error".  didn't try exr.

Quote - I tried 32-bit tiff as displ. map and it gave "bad file error".  didn't try exr.

16 bit tiff would be the tiff format we support at the moment. I believe EXR is supported as an image format but we don't support (to my knowledge anyway) vector displacement. So if you're goal is to use an EXR to that end, you probably won't get the result you're expecting. Admittedly, my tests in this regard have been few, finding 16 bit tiff displacement to be sufficient for most Poser needs.

If you don't click the "3 channels" in zBrush.
When ya save a 32 bit .tiff .
Even zBrush will give you a error when you try to load it back in to zBrush.

zBrush
Displacment .exr are gray like .tiffs .I think that means there just 2D.
As far as I know ya can't get colored maps out of tools/displacment maps.
Vectors .exr are colored .I think to have 3D maps ya need color.

When I get the mesh & all these maps done.
We can terrorize Pro 14 by seeing what does and don't work and have some fun :)

So this is the starting point.

very educational :)

Quote - Now using a 32 bit exr - I had to play with the displacement value a lot to get a similar result to the 16 bit map - and note the increase in render time ...

Re-render that again - a single pass is not representative, it's better to do a "best out of three" comparison.

Poser converts all textures to tiled mip mapped OpenEXR files before handing them over to FireFly, and it does that in a background thread. It may have been that your TIFF was already converted when you started the render, but the OpenEXR file had not been tiled and mip mapped yet when you started. The time it took to convert then became part of your overall render time. FireFly itself is completely oblivious to what file format the textures were saved in originally, since Poser 7 it only reads tiled OpenEXR through a texture cache. The tiling and the cache should in theory allow it to render billions of textures with ridiculous amounts of pixels each using just a couple of hundred MB of RAM - at least in our tests, we haven't found a limit in practice yet.

Stewer - I have always assumed that there was a direct relation between the quantity and size of texture maps used in a render and the RAM usage - ie. a 2048 square map would require less RAM at render than a 4096 map - but you're saying that's not the case if I'm reading you right.

That's great information, thank you - it changes the way I look at texturing for Poser. Think I might have to rebuild my current project :)

BTW, I re-rendered (had the test scene saved, so just started up and plugged in the exr map) - 5 sequential renders timed at 6m32s, 6m24s, 6m17s, 6m11s, and 6m12s. Thought it might be the case as before running the tests above I'd made a series of test renders with the various maps to get the displacement values, so they all would have been converted.

stewer : the don't matter texture size is for any and all kind of textures ,normals
,bumps ,displacments ,specular ,alfa's etc etc that Poser supports ?

& will Poser Pro 16 support Vectors ?

Thanks

Quote - Stewer - I have always assumed that there was a direct relation between the quantity and size of texture maps used in a render and the RAM usage - ie. a 2048 square map would require less RAM at render than a 4096 map - but you're saying that's not the case if I'm reading you right.

At render time, FireFly gets a limit of a max amount of RAM it will use for textures. The limit will depend on the number of rendering threads and, in the case of a 64 bit instance, the amount of physical memory in the machine.

When converting the textures, Poser will read the textures one at a time in full resolution, so resist the temptation to compress everything into one 100k by 100k texure :) The OpenGL preview cannot use the texture cache, so there you are still limited by VRAM, preview texture size and the number of textures in the scene.

Quote - BTW, I re-rendered (had the test scene saved, so just started up and plugged in the exr map) - 5 sequential renders timed at 6m32s, 6m24s, 6m17s, 6m11s, and 6m12s.

I took another look at the screen shot, and the difference in displacement value is the culprit. Poser automatically estimates the displacement bounds from it, and the large displacement bounds make the scene using OpenEXR use more render time and memory. If you want to scale the displacement without affecting the displacement bounds, use a math mutliply node.

BTW, I recommend using either displacement or normal/bump and not applying a bump map on top of displacement.

Quote - stewer : the don't matter texture size is for any and all kind of textures ,normals  ,bumps ,displacments ,specular ,alfa's etc etc that Poser supports ?

All textures are treated equally by the render engine.

Quote - & will Poser Pro 16 support Vectors ?

I cannot comment on future versions and features.

Quote - Poser converts all textures to tiled mip mapped OpenEXR files

Half or Full float ?

Half - given that the vast majority of textures used are 8bit/channel anyway, this already more precision than most people need. Do you have a case where you would need 32bit/channel float?

Nah, just curious.

Using a math node worked beautifully. Here's the full scene. The ground mesh is 24,000 polys and covered by a single 4096 square pixel map, same lighting and render settings as before. I did a bunch of test renders to get the scale to match from both maps - the value in the displacement was left at 0.035 so the only change to the material screenshots I've already posted was the addition of a math multipy node with the 1st value left at 1 and the 2nd value at 155 for the exr map. Rendering the same image as posted before they both looked the same on screen, so I zoomed right into the model (the area circled in red) to see whether an extreme closeup would show if there was any more detail being carried in the 32 bit map.

This is close-up with the 16 bit map - render timed at 34 seconds, task manager showed ffrender using up to about 695Mb RAM. Note the pixellation.

This is killer educational :)

Had nearly forgotten how much I like using Poser. 

The overall difference on this model is not extreme, but the exr carries more detail and to me is noticeably sharper. As there is hardly any cost in rendering it would appear to be a no-brainer that it's worth using. I really want to make something new now I have a better understanding of what Poser can handle, but unfortunately I'll be away from my main computer for a couple of weeks :(