The greyscale image itself is pretty lo-res and crude. That would not look sharp in a 3D program that supports micropolygon displacement even and there are geometry errors in your map already. This in no way can produce a flawless displacment based on an even grid. Aside from that, really the overall document size matters for that kind of thing up to a certain point because the document size determines the size of the grid and its density. You realyl should rvisit your artwork and start over.
And thanks so much for responding.
"The greyscale image itself is pretty lo-res and crude." Well, okay, though I did save it as a JPG which seems to have forced it into 8-bit mode. It started life as a 16bit file, which I would have thought could provide enough resolution, shouldn't it?
"there are geometry errors in your map already. This in no way can produce a flawless displacment based on an even grid. " I'm quite prepared to believe that, but what are the errors? My greyscale image starts as a BMP file; is that itself a problem, because it imposes the 'even grid'?
"You really should revisit your artwork and start over." Okay, but what is it that I'm doing wrong? What do I have to change? Clearly I'm more of a novice than I realised - I would really appreciate it if you could tell me what I'm doing wrong and how I should start over, or if you could point me to a source of the knowledge I clearly lack.
Your source map has aliasing artifacts because you applied some twist or other deformer - the squares are not squares but have dents and eroded edges here and there. Furthermore, yes, using a compressed format that introduces its own artifacts is not a good idea. Use native PSDs or TIFFs. I'm not sure whether PS actually uses 16bit values for displacements. In my tests the difference was marginal, so I'm reasonably sure it only uses 8bit values to derive the heights. And at least double the size/ resolution of what you have. You can always downsize the result later. This will help the distribution of the mesh grid points and PS may actually use more (dunno the internal limit, but it always seems to stop at 1000x1000 at most). At least try to max out that. Still, don't expect miracles. Sharp edges are a b* tch to capture with uniform displacement techniques. They only work reasonably with round-ish stuff where the shading smoothing would disguise lack of resolution. For anything else, adaptive techniques are better suited.
"Your source map has aliasing artifacts because you applied some twist or other deformer - the squares are not squares..." Well, the shapes are not really supposed to be squares - they are rhombus-like shapes from a kind of Fibonacci-series-based figure. I was hoping that PS would be able to handle arbitrary shapes.
"Furthermore, yes, using a compressed format that introduces its own artifacts is not a good idea. Use native PSDs or TIFFs." Well, I think BMP files don't have any more compression than TIFF files - each point in a grid has its own R,G and B values associated with it, so there is a complete grid of points each of which can have any colour. But I can see that having a totally regular grid, whether from a BMP file or from a TIFF or any other kind of file, might create problems if one is trying to produce a kind of embossed figure with an arbitrary shape.
"I'm not sure whether PS actually uses 16bit values for displacements. In my tests the difference was marginal, so I'm reasonably sure it only uses 8bit values to derive the heights. And at least double the size/ resolution of what you have. You can always downsize the result later." Aha, now I think we're getting to it - I have used 16-bit resolution for the height given in the greyscale file, (and I am 99% sure that PS does utilise 16-bits for this), BUT I haven't really exploited it well - I've only used a timy part of the rang; I think what I need to do is to use a lot more of the 16-bit resolution/range, which will produce an image with much greater depth, and THEN take this image and scale down the height/thickness dimension in the final image - this is what I take you to mean when you say "you can always downsize the results later". This should at least make the surface smooth.
I think there'll still be a problem with the sharp edges, though. There's a limit to the resolution I can use - the files get just too big! I've noticed that the triangles in the mesh that PS produces, have much poorer resolution that the resolution of actual points in the images. I mean that there might be an area of say 12 by 12 points or dots in an image, within which there may be fairly detailed changes of colour, shading etc; BUT if a 3D mesh is created that will define the contours for that area, it will only occupy 1 triangle or so, so the shape resolution is a lot coarser than the image resolution, one might say. I was hoping there might be a preference setting that I could alter, that would make the mesh triangle resolution a lot higher.
"...adaptive techniques are better suited." Ummm, don't really know what that means or how it applies to graphics...
Thanks for your thoughts. Any more comments gratefully appreciated!
I'll have a go at doing what I say in the 'aha' para above.
If it's possible in your setup, try 32 bits/channel as well.
"If it's possible in your setup, try 32 bits/channel as well.
I don't think the issue is 'depth resolution', especially in the light of the previous exchanges, so I think 16 bits resolution for the depth dimension is fine (as long as I use it properly). The remaining issue is the resolution along the X and Y dimensions, rather than the Z one, that is, the resolution in the X and Y direction of the triangles that make up the mesh.
Or do you mean something else?
All I know is that when I was working on a complex 3D rendering, I ended up switching to 32 bits/channel and some things ended up working more smoothly. I think some parts of the rendering process are done in 32 bits anyway, so it's not necessarily slower.
Might be worth a try on a throwaway file just to see if it helps with the smoothness in your results.
I see the mistake I was making: I was starting with a RGB file in which R, G and B values each had 1 byte assigned to them. (8 bits per channel mode, or 24 bit mode, or RGB888). Within CS5 I was turning this into a "16Bit greyscale" file, which I take to have 16 bits for the whole white->grey->black range. And thus more resolution.
BUT The original image had 8Bit resolution, so the greyscale image derived from it only had a 'meaningful' 8 bits - the conversion to 16Bit greyscale didn't magically create more resolution. That's what causes the discontinuities and lack of smoothness when this data is used to create a 3D mesh.
So, back to the artwork, as Mylenium said.
This is where I run into more problems.
My original image (RGB888) was written directly as a BMP file from a Delphi (Pascal-like) program. And was easily readable by CS5.
I wanted to create a higher-resolution RGB image from my Delphi program, and then convert it to (a higher resolution) Greyscale.
I investigated file header characteristics for a RGB101010 file, that is, a file where the R value is defined by 10bites, and likewise the G and B values.
I altered the header in a way which I hope reflected this. But CS5 couldn't read it in - I get a message:
"Could not complete your request because the file-format module cannot parse the file"
So I'd made a mess of the header/file format (quite possible) or CS5 wasn't able to read a valid RGB101010 file.
So I thought I'd go into CS5 and create and then save a high-resolution RGB file, check the header file etc byte by byte, and compare this with the file I had created.
But I discovered that CS5 doesn't let you save a RGB file with resolution higher than 8Bits/channel, to a BMP file. So I couldn't do what I planned, and it occurred to me that perhaps CS5 doesn't recognise higher-resolution RGB files.
So I turned my attention to the possibility of adapting my Delphi program to directly generate a high-resolution greyscale file, but there doesn't seem to be a defined BMP format for this.
I looked at the possibility of generating a greyscale TIF file, but the format seems so complex that it would take a major rewrite, which I don't really think I can face.
I feel I've been going round in circles a bit here.
If I could make the 8 Bits of my original file to become the LEAST significant 8 Bits in a converted 16Bit greyscale version, I might be able to work with that.
Anyone got any thoughts about a solution to my predicament?
Don't worry about TIFF files and header complications. Photoshop can read a file of bytes with no header - a raw data file. Generate a file containing the 16-bit heights, scanning from left to right in each row from top to bottom. Give it a .raw extension, then Ps will consider it to be of type "Photoshop Raw". When Ps opens it, a dialog will be presented in which you tell Ps how to interpret the data as an image. You supply the width, height, number of channels, bit depth, endianness, etc.
The main reason for the jagged edges and shadows in your posted rendering was the relatively low number of polygons in the regular array mesh generated from the heightmap image containing sharp edges. To make matters worse, the edges were jaggier than the pixel grid in many places.
To get non-jagged edges and shadows in your rendering of a heightmap with sharp edges, each polygon of the mesh will need to be smaller than a pixel of the rendered image. Photoshop creates a mesh containing far fewer polygons than the count of pixels in a heightmap. Therefore the resolution of the heightmap image will need to be higher than the resolution of the rendered image unless the mesh is sufficiently distant from the camera to result in it filling only a small region of the rendered image.
Here is a simplistic example where it was necessary to use a heightmap image with 8 times the horizontal and vertical resolution of the rendered image.
First, the result when using the black and white heightmap with the same resolution as the rendered image.
Next is a rendering, at the same resolution as before, but the heightmap and mesh were created in a document with 4 times the vertical and horizontal resolution of the initial attempt. Still slightly jaggy.
Finally, the same rendering resolution again, but the heightmap and mesh were created in a document with 8 times the vertical and horizontal resolution of the initial attempt. This time the mesh has sufficient density to be rendered with no jaggies.
Thank you for your RAW suggestion. I have been experimenting with it, and my depth file is now being happily read in by CS5, but I haven't quite sussed the byte order/exactly how many bits are relevant so the depth maps I am creating are not quite what I predicted.
But that's definitely the right approach. Thank you for your suggestion!
Thank you so much for taking the trouble to create this reply. I'm still wrestling a bit with byte order etc in my raw file, and the procedures I'm going to have to change to get meaningful significance when I generate my depth map, so I haven't had a chance to go through your last post in much detail. Hope to get round to it tomorrow. But now, I have to get my head down...
All the best,