[B3 Bug] Parallax Mapping results in bizarrely-warped textures

#1 Totally offtopic but Google or Firefox neither one like your image host website....
Just thought you might want to verify.

EDIT: removed screen captures now that HT is aware of the potential problem.

Back on topic: I haven't had much usability of parallax myself.

#2 *edit: Ah, well, there's the problem. Apparently someone spammed an old, unused forum I installed on there ages ago for testing with some malicious links. Fantastic. :P

#3 The parallax scale in the material editor is a 0 to 1 slider, but only small values... usually less than 0.3 work.

This isn't parallax occlusion mapping which is expensive on even high end cards. This is parallax offset mapping which will break down if the parallax scale is too steep.

#4 I had/have this problem as well. Anything above a parallax scale of .1 results in a circular warping of the texture around the center bottom of the viewport, and when applying it to terrain it randomly does it even at .1 scale. I've not had a problem using .1 scale for anything other then terrain but the terrain was fairly easy to fix by simply going into the painter and painting a random section of terrain.

Screenshot of warping issue as seen at above .1 scale or randomly at .1 scale:This artifact is only visible in first-person.

Also noticed this odd glitch for one of my terrain textures after setting it back to .1 parallax scale:It may not be obvious in that picture but the ground actually appears to rise up a little beneath the player. It's only visible in first-person as well.

Hardware Specifications:
GFX: ATI Radeon HD 4800
RAM: 4GB
CPU: 3.16GHz Intel Core 2
OS: 64-bit Windows Vista

I've never particularly liked offset parallax mapping because of glitches such as these which, for the most part, are just part of how the shaders work if the settings aren't just right. Parallax occlusion and relief mapping are certainly more expensive relative to normal mapping and offset mapping, but on anything Geforce 7x00 and ATI equivalent or above there is usually more then enough power to do it along with a complex scene and still manage 30+ fps. (Obviously you would want to avoid such expensive effects until you know you can afford them though)

#5 Bryan's got a much more accurate picture of what happens. Above 0.1, that "sinking circle" effect always appears. Below or at 0.1, it may or may not appear, but can be removed by painting a spot of terrain with the brush.

Technically, 0.1 seems a bit warped if you look down while turning, but within the constraints of parallax wackiness. If that's the expected range in which the effect is realistic (0-0.1), then the only bug here is that something apparently doesn't always update until a square of terrain is actually painted.

#6 Added as an additional response to bump the topic. Annoying, yes?

Anyway, I can now confirm that parallax doesn't appear to be working correctly on my system. Instead of creating a vertical offset based on the normal map, it's just creating a flat vertical offset on the whole texture. The linked youtube video will make it a bit clearer. I suggest putting it in HQ and fullscreen so you can see what actually happens.

www.youtube.com/watch?v=DmMpmQt1uwg

For reference, this was intended to be a reproduction of the scene used for the release blog screenshot. I produced a flat green texture with grid lines and some text and used that as the detail (and diffuse, actually) texture. I added a relatively high-scale normal map from the WarriorCamp assets, which is where all the rock texture is coming from.

Halfway through the (very short) video, I change parallax from 0.0 to 0.1, resulting in the entire texture being "lifted" off of the geometry (watch for the offset between the white texture grid and the green geometry grid). This offset appears to totally ignore the normal map itself, treating the entire texture as maximum height, except directly around the camera (resulting in the appearance of a pit around your feet).

#7 yeah, I'm getting the same as Bryan,
at 0.1 parallax.
64bit system.

#8 @Bryan & Henry - Do you happen to have your normal map as a DDS file in your tests? Are you using DXT5 or DXT5NM?

#9 I use PNG for all my images. I personally don't think the loss of quality due to the DDS compression formats is worth the decreased load time from not having to recompress the texture in hardware.

#10 saw this aswell yesterday with jpg as normal and detail and i saw this

#11 I'm also using PNG for everything. I'll give the other formats a try just to cover all the bases and update this post with the outcome.

#12 me2...

#13 *freakout*

@Bryan:

Quote:
I use PNG for all my images. I personally don't think the loss of quality due to the DDS compression formats is worth the decreased load time from not having to recompress the texture in hardware.

Woah woah...you have that all wrong. PNG/JPG/etc textrues are NOT compressed in video memory, they are compressed on disk. A PNG/JPG texture takes up 32-bits per pixel (even without alpha, a video card will just make an R8G8B8X8 texture for alignment purposes). A DXT texture is block-compressed (so bits-per-pixel doesn't really apply) and gains a compression ratio of 4:1 (DXT5) or 8:1 (DXT1). This memory remains compressed, and gets uncompressed during sample time by the video hardware (for free).

Straight-DXT is never appropriate for tangent-space normal maps. In tangent space, Z is always positive, this means that the Z can be reconstructed via: z = sqrt(x*x + y*y). To make better use of the block compression (In DXT5, color blocks are compressed separately from alpha) you should put Y in Green, X in Alpha, 1.0 in red, and 0.0 in blue. There is an NVIDIA tool which does this for you; converting regular normal maps to DXTnm format.

Edit: It occurs to me that this information should be in the docs somewhere. I will try to make that happen.

#14 @Henry - I had this issue to when using PNGs, but after reading the post made by Tom, I tried DXT5_NM and my parallax maps are working great. I understand that that may not be an option for you, or perhaps the engine is supposed to be working with PNGs as parallax maps, but I just used the Nvidia plug-in to create what I needed.

-Ryan "Mustache Monster" O'Donnell

#15 @Ryan:

Yeah, that seems to work correctly, thanks for the tip. I was under the impression that anything that works as a regular normal map (PNG's and JPEG's both work fine as simple normal maps) should also work for parallax, but that may just be my lack of understanding of the inner workings of modern rendering techniques.

Anyway, the DXT5_NM exported (from Photoshop w/ the nVidia plugin) normal maps are working quite well with parallax. I should mention that whatever format the DDS normal maps included in the WarriorCamp assets are in, they do not work with parallax.

There are a few odd rendering artifacts/glitches that come up now that parallax is working, but I believe there's another thread addressing that already.

#16 I asked because DXT5nm would be messing up your parallax... the fact that you say its fixing it is very odd.

I'll have to look closer at this one.

#17 @Pat:
I never said anything about compression in PNG, Jpeg, or any other format. Any texture can be compressed in texture memory whether it's originally from a DDS file or PNG file but DDS uses the graphics card supported memory compression algorithms within the file itself making loading faster since the file doesn't have to be uncompressed, loaded into memory, and then recompressed in texture memory. These algorithms are incredibly lossy algorithms that drastically reduce the quality of most textures however and the actual file support in most applications tends to be rather nonstandard making DDS even more a pain to work with.

EDIT: Just tested with DXT5 compressed textures and the parallax works fine even up to a parallax scale of 1 minus the fact that it begins to look really silly beyond .4 scale. I don't know about DXT5nm as I don't have anything that will reliably generate a file using that format.

#18 I was getting the "swirly thing" with parallax until I just realised that parallax of course works off the data in an alpha channel... doh.

DXT5 seems fine (it can go quite mad quite quick: 0.005 seems best for grainy terrain, 0.015 for grass, 0.03 for non-grainy textures, things really start to break up and go "liquidy" after that).

DXT5nm doesn't appear to do anything, it just looks flat. This might be because I cleared the channels which don't get used in the swizzle.

edit
Confirmed, leaving the channels in which are normally unused in swizzle, will give the data for parallax.

#19 We really should NOT be using DXT5 for normal maps in any case unless your using DXT5nm. And in true DXT5nm those channels are 0 and you cannot add data to them.

If you want parallax in a normal map and want DDS compression... use DXT3 with explicit alpha and live with some normal map artifacts. Or deal with an uncompressed normal map... but 4:1 compression is a bad thing to loose.

#20

Quote:If you want parallax in a normal map and want DDS compression... use DXT3 with explicit alpha and live with some normal map artifacts. Or deal with an uncompressed normal map... but 4:1 compression is a bad thing to loose.

Are textures not using the hardware accelerated compression on load when not using the DDS file format? PNG files are often quite a bit smaller then DDS files due to a superior compression and at the same time lossless, but I also want to be able to have the textures compressed in graphics memory when loaded into cards that don't have that much memory while still being able to provide full quality textures on cards that can hold them. I don't know how to do it in DirectX but in OpenGL a single function call is all that is needed to have the texture compressed using any of the supported algorithms after loading.