Closed erich666 closed 3 years ago
Oh, one other comment: the grass overlay is partially green, mostly grayscale. Is this an error? I'd prefer grayscale, or green, but the mixture is what's causing my software to flip a coin and it currently decides "hey, this grass is colored, I don't need to tint it."
If it's on purpose, OK, I'll add code on my end to do a count, "more green, or more gray". I should probably do that anyway.
Update: done, I've added a voting system to decide if a tile is gray and should be tinted (i.e., if 2/3rds gray, consider it gray with minor modifications). This works well for your leaves, too, where there are colors on purpose (stems, etc.). Anyway, it's still something for you to consider: for this grass_side tile, is the green fringing meant to be there or just some artifact of the process?
One more "everyone's a critic" note - finding it today, I at first thought my own programs had broken. The nether portal image could use some love. Right now it's opaque purplish-pink, a solid color. I'm hoping for semitransparency and some groovy pattern.
And another: the normal map on water doesn't repeat, which I expect you know. But, please put it on your list. You can see the effect here:
If I use a repeating normal map, I get what I'd expect, no creases:
Oh, and one more shot, as it looks so cool.
Quick and late response:
Prismarine rough has been included in releases, but has eluded version control. It's now in the repository.
I replaced the water textures with some that are hopefully more seamless: https://github.com/jasonjgardner/jg-rtx/blob/0c98c87b463f4f664d4df6382057588d84a9d120/development_resource_packs/JG-RTX/textures/blocks/water_flow.png
The green on the grass is not entirely intentional. The grass side texture really should be grayscale. I'll clean up those green fringes.
Sorry for the delay!
Ha, no rush on my end - I'm happy you're inspired to keep developing this nice resource pack.
My one "this will save me a minute each time I convert it" wish is that you make a separate rail_detector_powered.png tile, similar to how rail_golden.png has a powered version (that is barely different). Right now I manually copy rail_detector.png to be rail_detector_powered.png
Oh, and one other oddity is redstone torches. The redstone_torch_off.png seems to have a very slight semitransparent white area around its tip, ranging from an alpha of 69 on down, with a color of white. I'm not sure if this is by design. These torches may look good in MinecraftRTX, but look a bit odd in Omniverse, FWIW:
I guess I could open a new issue, but hope you'll simply notice this one. I'm adding a TGA reader on my side, so no worries there. But, I get, with today's 0.15.1 set of textures:
DUP WARNING: Duplicate file ignored; file 'glass.tga' is a different name for the same texture 'glass.png'.
DUP WARNING: Duplicate file ignored; file 'grass_side.tga' is a different name for the same texture 'grass_side.png'.
And, FYI, so that you know they're not doing anything currently:
WARNING: Image 'itemframe_background_normal.png' was not used because it seems to have all the same normals, no changes detected. WARNING: Image 'quartz_block_top_normal.png' was not used because it seems to have all the same normals, no changes detected. WARNING: Image 'polished_blackstone_normal.png' was not used because it seems to have all the same normals, no changes detected.
One more warning I didn't notice yesterday:
WARNING: The file 'stripped_big_oak_log.png' is not recognized and so is not used. WARNING: The file 'stripped_big_oak_log_mer.png' is not recognized and so is not used. WARNING: The file 'stripped_big_oak_log_normal.png' is not recognized and so is not used. WARNING: The file 'stripped_big_oak_log_top.png' is not recognized and so is not used. WARNING: The file 'stripped_big_oak_log_top_mer.png' is not recognized and so is not used. WARNING: The file 'stripped_big_oak_log_top_normal.png' is not recognized and so is not used.
There's AFAIK no "big_oak" in Minecraft, just oak and dark oak (which you also have textures for). So maybe these textures are orphanned and not used?
You're right about the stripped_big_oak
stuff. That should indeed be stripped_dark_oak_log
. Thank you for pointing that out. I think the stripped dark oak in the current release looks bad, but hadn't noticed the correct texture was not in use.
I noticed the flat normal maps too. I intentionally left them in the folder so I could come back and try to make it more interesting. I should have left them out of the texture set and release though.
I'm going to close this issue. You'll encounter these two issues with the latest release, but I'll be sure to take care of them before the next. I'm sure you will encounter some new problems. I didn't test it out in ChannelMixer and TileMaker before uploading the release. 😕
I noticed the flat normal maps too. I intentionally left them in the folder so I could come back and try to make it more interesting.
I figured, and just passed on the warning in case you weren't aware that they were currently doing nothing, in hopes you'd come back to them. Glad to know they're on your list.
I report these next few each release. Is there a "prismarine_rough.png" texture, but it's named something else?
RGB MISSING WARNING: File 'prismarine_rough_normal.png' exists but there is no corresponding color file. and RGB MISSING WARNING: File 'prismarine_rough_r.png' exists but there is no corresponding color file.
And, a rail_detector_powered.png would be nice (with the red bit brighter):
RGB MISSING WARNING: File 'rail_detector_powered_m.png' exists but there is no corresponding color file. and RGB MISSING WARNING: File 'rail_detector_powered_e.png' exists but there is no corresponding color file. and RGB MISSING WARNING: File 'rail_detector_powered_r.png' exists but there is no corresponding color file.
Otherwise things look good, warning-wise. There are a few "these do nothing" normal maps, FYI:
WARNING: Image 'itemframe_background_normal.png' was not used because it seems to have all the same normals, no changes detected. WARNING: Image 'quartz_block_top_normal.png' was not used because it seems to have all the same normals, no changes detected. WARNING: Image 'polished_blackstone_normal.png' was not used because it seems to have all the same normals, no changes detected.
By the way, I asked NVIDIA about the "save to TGA, not PNG" directive they give. It turns out that someone there was using some program (name unknown) that, when it would save RGBA images to PNG, would replace fully transparent texels with a white RGB color (it's transparent, right?). Why that program did that, who knows, but doing so messes up mipmaps. Of course, black in these pixels also messes up mipmapping, but it's less noticeable. Anyway, if the tools you are using don't do this (stupid) thing, PNG's fine. The right answer is to dilate your textures (search that article for "Solidify"), but no one except pro game developers do that.
The payoff, just a quick test, and I still need to fix grass sides (which are my bane - people set these like 8 different ways):