erich666 / Mineways

Exports models from Minecraft for 3D printing or rendering
http://mineways.com
Other
408 stars 60 forks source link

TileMaker to output height map from normal map's alpha channel #74

Closed tasiotas closed 3 years ago

tasiotas commented 3 years ago

Hi,

I am working with resource pack that has height map in normal map alpha channel. I assume POM(parallax occlusion) textures store it this way.

For example: https://www.curseforge.com/minecraft/texture-packs/tesellax-ultra-realistic-resourcepack

The problem is TileMaker is outputting normal map without alpha, so height is lost. Do you have any method for working with POM packs?

Thank you!

erich666 commented 3 years ago

Thanks for noting your problems. I'm having a tough time trying to figure out what to do with Tessellax's normal maps, to be honest. Note that this resource pack uses the RGB channels in the usual way, providing an RGB -> XYZ normal map. This is a standard way for textures to be specified. Unfortunately, Tessellax's normal maps are quite underpowered, for some reason - the red and green channels are barely different than the "0" value of 127, meaning no change in the surface normal.

I'm working from an old 32x32 version of Tessellax. Unfortunately, the download button for the page you give doesn't work. I expect that's because he's now on Patreon with his higher res versions (which I haven't bought). However, the 32x32 pack can be downloaded by using the links further down on the right, for the 1.12 version of Minecraft. If you know of a better, free, download site, let me know - he may have fixed or changed his files by now. Also, there's a well-known "filtering problem" with normal maps. If you filter them from high res to low res by just using color averaging, the bumpiness goes away. This may be the case here.

The alpha indeed has a heightfield description, as is sometimes done if you want to do POM texturing at the same time. Most DCC renderers I know don't bother with POM nowadays (and games avoid it almost entirely). It was a nice enough technique in theory, ten years ago (and I wrote a lot about it), but it's quite expensive to render on a GPU - lots of texture accesses per pixel needed to access the heights, especially at shallow view angles.

Anyway, Mineways focuses on normal maps and simply converts heightfields into normal maps. Since normal maps already exist for Tessellax, in the RGB channel, the POM heightfield seems superfluous to me. Which renderer do you use that supports POM?

In theory I could add yet another option to ChannelMixer, saying to read the alpha channel of normal maps as heightfields. The one advantage of doing this is that you can then modify the "steepness" of the heightfield with the -h # option in TileMaker. But, given that I've only seen this problem of "nearly flat" RGB normal maps in Tessellax and not the other 20+ PBR packs I've tested, I'm not so excited to code this special purpose thing up. If you are game, you could use ImageMagick to strip out the alpha channel and turn it into a grayscale image (at least I think ImageMagick can do this), then use these as the input normal maps for TileMaker, which will recognize them as heightfields.

I'm open to suggestions, and especially open to new information. If you know how to contact the author, let me know (I couldn't find info on his Patreon page). I do see that my default Minecraft.mdl material file for normals doesn't currently let you adjust the normal map strength, which would help. I'll try to fix that.

tasiotas commented 3 years ago

Here is link to Tessellax 128 free pack, its from his Discord chat. You can contact him there. https://www.mediafire.com/folder/in84glc08x0e9/128x128

I just picked Tessellax for testing, no intention to stick to it if it doesnt work well, but so far it looks good. No problem with normals like you described. Perhaps 32x32 has barely any detail, try free 128. Im happy to try different tex pack with height channel.

I dot really care about POM, because in my DCC I will use displacement. Thats why I look for POM pack, since they have height encoded in textures.

Thanks for suggestion with stripping alpha from normal and use it as input in TileMaker, that should work. Though, there is one more thing I just noticed in Mineways that might block me.

Now I switched to File type: Export tiles for textures, to overcome mipmap problems. Unfortunately, Mineways only exports diffuse and normal maps per tile. I can again try to trick MW and input different maps one by one, but its gonna get complicated pretty quickly. How do you feel about adding metalness, roughness and since we are here, height?

erich666 commented 3 years ago

First, thanks for the higher-res pack. It's indeed the case that these normal maps are better - the normals haven't been averaged away. Here's a view of some logs, etc.:

image

This is in Omniverse Create - looks good.

How do you feel about adding metalness, roughness and since we are here, height?

Let's start with this: they're in there. You need to hand in _s.png or _mer.png files. See the docs. But, that's only for USDA export. Note you could export the scene twice, once to OBJ (with tiles for textures) and once for USDA. The MER textures will be output for USDA; you can then use these as you wish.

However, you're indeed correct, Wavefront OBJ does not include or export MER textures, because I don't know of any way to specify metallic, emissive, or roughness (vs. specular power) textures in Wavefront MTL. If you know of any semi-standard extensions to Wavefront OBJ's MTL description that lets me specify MER textures, I'm happy to add these - it's pretty easy, just an hour or two of work, once I know the MTL format. Do you know of any DCC that reads in such data? I would want to know that, for testing.

Even normals for OBJ's MTL is iffy - I think I've seen only one system that actually supports that extension (RGB normal maps came into existence decades after OBJ was developed).

Anyway, USDA supports MER textures just fine, so I'm putting most of my time into this newer format. Houdini is starting to support USD, along with other programs, so I think it's time better spent.

in my DCC I will use displacement

Which DCC? I'm starting to get interested in displacement, so I'd like to try this out (assuming I can find a free version).

Now I switched to File type: Export tiles for textures, to overcome mipmap problems.

Right thing to do. I've been tempted to make it the default for OBJ rendering export (3D printing is better using the single texture).

Thanks for the higher-res Tesellax. There are a number of PBR resource packs that have wider coverage. I link to some sources on this page. The two popular formats are metallic in red, emission in green, roughness in blue (MER); or, roughness in red, green is reflectance/metallic, alpha is emission, the LabPBR format, which Tesellax sort of follows.

Tesellax is odd in that it includes emissions in separate _e.png files. Which means you need to be careful: if you run ChannelMixer, you'll get a few _e.png files for grass sides, etc. - I'm debugging this now. Just delete those after running ChannelMixer.

erich666 commented 3 years ago

Aha, it looks like a weirdness with Tesellax: some of the grass_s.png files have alpha channels which are not all 255 or 0 around their fringes. ChannelMixer then thinks that this must be a LabPBR emission channel, in the alpha channel, and so makes _e.png files. Delete them. :) I'm not going to try to have ChannelMixer try to clean up after errroneous texture maps with strange alphas (the *_s.png files don't need alphas at all, unless needed for emission).

By the way, I did go ahead and added a "normal map strength" parameter so that I can more easily turn up normals' strength in the future, in Omniverse Create. So, thanks for inspiring me to do that.

tasiotas commented 3 years ago

Let's start with this: they're in there. You need to hand in _s.png or _mer.png files. See the docs. But, that's only for USDA export. Note you could export the scene twice, once to OBJ (with tiles for textures) and once for USDA. The MER textures will be output for USDA; you can then use these as you wish.

Oh, I see. I didn't use USDA for exporting, as it doesnt provide option for each block as a separate geo/group. But since it will output textures, then I will give it a try. Thanks

However, you're indeed correct, Wavefront OBJ does not include or export MER textures, because I don't know of any way to specify metallic, emissive, or roughness (vs. specular power) textures in Wavefront MTL. If you know of any semi-standard extensions to Wavefront OBJ's MTL description that lets me specify MER textures, I'm happy to add these - it's pretty easy, just an hour or two of work, once I know the MTL format. Do you know of any DCC that reads in such data? I would want to know that, for testing.

So I don't use MTL files at all. I import OBJ to Houdini and create my own materials. In Houdini I can extract material name from attributes, and then compile texture path based on this and feed it into single shader for all blocks. So I just need properly named textures. I think I can put it together with what I have and what you suggested above.

Which DCC? I'm starting to get interested in displacement, so I'd like to try this out (assuming I can find a free version).

I use Houdini with Arnold. That combination is not free, as only Houdini Indie and up support 3rd party rendering. But you can try free Houdini version with their new rendering engine Karma, it works well with USD and displacement.

Thanks for the higher-res Tesellax. There are a number of PBR resource packs that have wider coverage. I link to some sources on this page. The two popular formats are metallic in red, emission in green, roughness in blue (MER); or, roughness in red, green is reflectance/metallic, alpha is emission, the LabPBR format, which Tesellax sort of follows.

Tesellax is odd in that it includes emissions in separate _e.png files. Which means you need to be careful: if you run ChannelMixer, you'll get a few _e.png files for grass sides, etc. - I'm debugging this now. Just delete those after running ChannelMixer.

Again, I am not worried about maps being in the wrong RGB channels, as I assemble materials by myself. Though I have to admin, I have it working in Houdini, but still need to see if it will work in Omniverse/USD.

Thank you for all help so far. I think I have all the pieces I need. Will reopen this if need more help. Can't wait to show you my instancing in USDA, looks very promising!

erich666 commented 3 years ago

Thanks for your detailed answer. If you do find there's any "just this one little change will save me a lot of time," please do let me know.

Maybe I'll change "custom material" for OBJ export to also export all PBR textures and add hooks into the MTL file. That would be easy to do and I think be backward compatible for the most part.

But you can try free Houdini version with their new rendering engine Karma, it works well with USD and displacement.

Right, I've been using the free one, for testing UsdPreview import, which was added in Mineways 8.02. Get that version of Mineways and give USDA export a try. The materials currently are not perfect - emitters and glass are not there yet, and the beta Karma renderer appears to ignore normal maps set (though the OpenGL renderer does show them). See https://github.com/erich666/Mineways/issues/70

I would love any input you might have on this new feature. I'm not familiar with Houdini (at all), nor with its material system, nor with UsdPreview, for that matter - this new functionality was mostly added by someone else. So if you know of any ways to improve the UsdPreview materials, that would be a big help.