Lol! You've more willpower than me then...I'm in deep and succumbing to the narcotic powers of stone.
Illegal substances aside...excellent stone and granite!
Yeah, I decided the new 1.8 stone would probably be ok as 4x4 squares as you don't get it in great sheets like the standard stone. It's always frustrating to have to curtail random detail because of patterning at distance, but I think you've got a good compromise there with the second rendition of stone. Like you though, I liked the first more 'stoney' and detailed version, they always look way better down in the caves, but just suffer for construction purposes.
Hey, I wouldn't worry about too much ctm though, your pack still seems to be a lot smoother than mine and I'm sure you've got more ctm than me now.
Yeah. The real dilemma i ran into with the regular stone ctm is ores... i wanted to do a massive repeat ctm sheet, 12x12 was my original plan, but i ended up going with just 5x5, which tiles horribly since it's used over such large areas and has so much detail with cracks and lumps and such. I had to do that because of ores. If i have 12x12 stone, that's 144 tiles. Then there's 7 ores, and i'd need to do a repeat ctm sheet of the same size for each, meaning ores would require 1008 tiles. That's just too many.
I mean, there is another option, i could do a massive repeat sheet for stone, then for each ore use ctm to use the same 144 tiles as the base layer for all the ores, then make the actual ores as transparent decals to be applied with renderpass 3 over the stone layer, so i could just use a few tiles per ore and do random ctm. I mean, that would probably work, but i'm not sure if it would be optifine friendly, since i'm not entirely sure optifine has renderpass support.
If i go that route, i could easily just edit the base color layer on the stone i already made and use it as one of the new stone types.
I'm just not sure if it would cause performance issues... I mean, do renderpass layers cause any extra GPU stress or anything? Ever since i built myself this monstristy of a gaming pc, i can't tell what hurts performance anymore.
I might go with that. Since there's always a regular copy of the regular texture in the textures folder anyway, if i use matchTiles to apply the stone layer for the ores rather and name the file something other than the texture name, that should keep optifine from reading it, and have it default to the base texture in the textures folder. It won't give it CTM support though, but my pack really is meant to be used with McPatcher anyway.
Yeah. The real dilemma i ran into with the regular stone ctm is ores... i wanted to do a massive repeat ctm sheet, 12x12 was my original plan, but i ended up going with just 5x5, which tiles horribly since it's used over such large areas and has so much detail with cracks and lumps and such. I had to do that because of ores. If i have 12x12 stone, that's 144 tiles. Then there's 7 ores, and i'd need to do a repeat ctm sheet of the same size for each, meaning ores would require 1008 tiles. That's just too many.
I mean, there is another option, i could do a massive repeat sheet for stone, then for each ore use ctm to use the same 144 tiles as the base layer for all the ores, then make the actual ores as transparent decals to be applied with renderpass 3 over the stone layer, so i could just use a few tiles per ore and do random ctm. I mean, that would probably work, but i'm not sure if it would be optifine friendly, since i'm not entirely sure optifine has renderpass support.
If i go that route, i could easily just edit the base color layer on the stone i already made and use it as one of the new stone types.
I'm just not sure if it would cause performance issues... I mean, do renderpass layers cause any extra GPU stress or anything? Ever since i built myself this monstristy of a gaming pc, i can't tell what hurts performance anymore.
I might go with that. Since there's always a regular copy of the regular texture in the textures folder anyway, if i use matchTiles to apply the stone layer for the ores rather and name the file something other than the texture name, that should keep optifine from reading it, and have it default to the base texture in the textures folder. It won't give it CTM support though, but my pack really is meant to be used with McPatcher anyway.
You've hit the nail on the head there with what worries me. The complexity of having to try and satisfy all users, whether they be vanilla, MCPatcher or Otifine and all the rest with favorite mods.
Now you mention that Optifine might not support renderpass, then I'm going to just try and make the ores random and fit them as best I can into the repeat stone. My theory is if my present mixture of old 32x and 64x ores don't look massively horrible in the way they blend in at the moment, then actually basing my new attempts at ore on the new stone texture might have a chance of at least looking better. With enough cracks, shadows and texture going off in all directions the new ores might not show up too bad where the seams are. Well, I can hope!
You've hit the nail on the head there with what worries me. The complexity of having to try and satisfy all users, whether they be vanilla, MCPatcher or Otifine and all the rest with favorite mods.
Now you mention that Optifine might not support renderpass, then I'm going to just try and make the ores random and fit them as best I can into the repeat stone. My theory is if my present mixture of old 32x and 64x ores don't look massively horrible in the way they blend in at the moment, then actually basing my new attempts at ore on the new stone texture might have a chance of at least looking better. With enough cracks, shadows and texture going off in all directions the new ores might not show up too bad where the seams are. Well, I can hope!
Well, after finding out that optifine doesn't support biome specific textures, i'm too far in to care anymore, i think.
At this point as long as the pack will somewhat function with optifine, that's fine with me, but it's really made for mcpatcher's features. But optfine is slowly implementing mcpatcher's ctm features as it is anyway, so someday it should work fine.
I'm probably going to go with the renderpass method, since it's so much more flexible. I'm just trying to figure out what performance issues it might cause first.
NOTE: I am just experimenting with the old lapis texture, this isn't the redone one.
Basically, there's 2 layers to it. The base layer of the ore block, which just re-uses the same tiles as stone, then the overlay which has an ore texture that fades out at the edges.
If i go this route, i'll redo regular stone to be a much bigger repeat ctm sheet than the 5x5 one i'm using now, while at the same time reducing the number of tiles needed. This will make caves and exposed stone look much better. Right now, stone has 25 tiles. Each of the 7 ores would require 25 tiles as well to use the regular repeat ctm method. So... 200 tiles in total for all of the stones and ores. If i go the renderpass method, i might go up to a 10x10 or larger stone texture (100 tiles) but then only use 3-4 tiles per ore with random ctm overlays.
However, this incredibly flexible option comes at a slight cost. There's a bit of a rendering issue with transparency. I'm sure it will be fixed eventually, since it's a known bug, but for the time being, this happens:
When viewed through something transparent like water or glass, the ores seem to render on top of the transparent object. I realize you won't be seeing too many ores through glass, but they do end up under water from time to time. Is this annoying enough to bother anyone? Or is it worth it for the nicer stone texture?
Also, if anyone's wondering how i got the lapis ore to show up properly in the inventory, that was a particularly difficult trick that i will now brag about.
Usually, you will only see the base layer on the held block, which would make lapis ore identical to stone in the inventory, but i found a way around that.
What i did was made a placeholder tile, which is the one you see as the lapis ore in the inventory, and is the same thing that would go in the textures folder for the few non-mcpatcher users... Anyway, for the base layer of the lapis ore, the one that just uses the same tiles as the stone texture, i replaced the first tile in the repeat sequence with the placeholder.
Then i made another properties file directed at the placeholder, and used random ctm to select both the placeholder tile and the first tile of the stone repeat ctm sheet. I weighted the placeholder at 0 and the stone tile at 1.
So this way, the game sees the placeholder as the true first tile, therefore using it as the image for the inventory block, but it will never actually appear ingame because it's weighted at 0.
The renderpass when fixed still seems the most flexible system to me when it gets fixed, but I'm still going to see how successfully (or not) simple random ores on stone turns out.
Did you manage to test for how renderpass textures might effect performance? I get very slight jitter as I pass any glass construction using normal stained glass, whether it be using vanilla, my pack or any other. All I can assume is that Mojang do things less efficiently than MCPatcher, as I never got the slightest jitter with BetterGlass before, or it could just be the sheer quantity of layers of transparent colored surfaces now having to be calculated as you move around.
The renderpass when fixed still seems the most flexible system to me when it gets fixed, but I'm still going to see how successfully (or not) simple random ores on stone turns out.
Did you manage to test for how renderpass textures might effect performance? I get very slight jitter as I pass any glass construction using normal stained glass, whether it be using vanilla, my pack or any other. All I can assume is that Mojang do things less efficiently than MCPatcher, as I never got the slightest jitter with BetterGlass before, or it could just be the sheer quantity of layers of transparent colored surfaces now having to be calculated as you move around.
Anyways...good work on the ore research!
Well, there's really not going to be all too many ores on the screen at any given time. I mean, unless anyone gets extremely lucky.
But i do worry about the fact that each ore will be using the massive stone repeat sheet as an under layer. I asked in the mcpatcher thread, and the answer i got from kahr, wasn't too clear, but indicated that it would be rendering the stone ctm again for every ore, plus rendering each block twice due to the double layer. I'll need to experiment with performance...
I don't suppose you know how to actually measure and test for a performance difference?
Andesite. Since i was too lazy to google what andesite actually is, i made it a clumpy yellow rock.
Yep. It's another stone texture. Not a recolor, which would probably actually look better since the edges would meet up better.
But i was thinking of doing an overlay around the edges of the alt stones using the classic ctm and the regular stone texture, so it sort of blends. However, i'm not too sure how well it would work due to the fact that regular stone uses repeat ctm, and i couldn't really incorporate that into classic ctm edges. It would cause a hard seam still between the rock types, but at least the colors could blend... Unless of course i were to apply the same overlay layer around the edges of regular stone... that could work.
At some point i'm worried this would cause a drop in performance. I added some overlay layers in the last update. Did the performance drop noticably?
Well, there's really not going to be all too many ores on the screen at any given time. I mean, unless anyone gets extremely lucky.
But i do worry about the fact that each ore will be using the massive stone repeat sheet as an under layer. I asked in the mcpatcher thread, and the answer i got from kahr, wasn't too clear, but indicated that it would be rendering the stone ctm again for every ore, plus rendering each block twice due to the double layer. I'll need to experiment with performance...
I don't suppose you know how to actually measure and test for a performance difference?
Yeah...I saw kahr's reply, but I couldn't quite make out how many times stone was being rendered when using renderpass for random textures.
Andesite. Since i was too lazy to google what andesite actually is, i made it a clumpy yellow rock.
Yep. It's another stone texture. Not a recolor, which would probably actually look better since the edges would meet up better.
But i was thinking of doing an overlay around the edges of the alt stones using the classic ctm and the regular stone texture, so it sort of blends. However, i'm not too sure how well it would work due to the fact that regular stone uses repeat ctm, and i couldn't really incorporate that into classic ctm edges. It would cause a hard seam still between the rock types, but at least the colors could blend... Unless of course i were to apply the same overlay layer around the edges of regular stone... that could work.
At some point i'm worried this would cause a drop in performance. I added some overlay layers in the last update. Did the performance drop noticably?
For some reason I can't see the screenshot.
In measuring performance, other than using Fraps, I'd only be going on a hunch and a guess. Seriously though, I haven't noticed any difference in frame-rate with your latest update from v.13, but I'm probably not the best one to judge, as although my PC is about 2 years old now, it has an I7 processor, 24gigs internal memory and a top of the line nVidia graphics card, so you might need the opinion of someone who was on the edge of acceptable performance with v.13 to chip in here.
For me, the biggest difference I've seen in performance was with the introduction of stained glass in general (not your stained glass specifically)...I get noticeable stutter panning alongside any run of stained glass, even just using vanilla Minecraft. When I get about 20 blocks away from the glass, things run smoothly again! As I don't look at any MC bug news, I don't even know if it's a recognized bug!
Yeah...I saw kahr's reply, but I couldn't quite make out how many times stone was being rendered when using renderpass for random textures.
For some reason I can't see the screenshot.
In measuring performance, other than using Fraps, I'd only be going on a hunch and a guess. Seriously though, I haven't noticed any difference in frame-rate with your latest update from v.13, but I'm probably not the best one to judge, as although my PC is about 2 years old now, it has an I7 processor, 24gigs internal memory and a top of the line nVidia graphics card, so you might need the opinion of someone who was on the edge of acceptable performance with v.13 to chip in here.
For me, the biggest difference I've seen in performance was with the introduction of stained glass in general (not your stained glass specifically)...I get noticeable stutter panning alongside any run of stained glass, even just using vanilla Minecraft. When I get about 20 blocks away from the glass, things run smoothly again! As I don't look at any MC bug news, I don't even know if it's a recognized bug!
I too have a compter too powerful to suffer from any changes. I need something that can give me actual numbers, aside from FPS. I need memory usage statistics. I'll see what i can find though.
Not sure why the screenshot isn't showing for you, since it's just hosted on imgur which usually works great.
Very weird. It's broken for me now too. It must have somehow gotten deleted.
Here it is, re-uploaded.
That is some fabulous rock! It would also make an excellent, dirt or clay...in fact I think you've just discovered the ultimate multipurpose texture!
I also like the transition from wall to floor too. What's strange though is the way the floor texture looks worn and smooth and the wall looks more indented, jagged and cracked, but I'm assuming they're the same and it's the angle that creates the illusion.
That is some fabulous rock! It would also make an excellent, dirt or clay...in fact I think you've just discovered the ultimate multipurpose texture!
I also like the transition from wall to floor too. What's strange though is the way the floor texture looks worn and smooth and the wall looks more indented, jagged and cracked, but I'm assuming they're the same and it's the angle that creates the illusion.
Top marks!
It is indeed the angle. What i do to achieve this is make the "hard" edges just a bit blurred. At a distance, they still look hard, but up close the softness comes through more.
Though there shouldn't be any confusion as to what dirt is, since in my pack i went with a rich, dark dirt.
Hey Murder, this is my favorite texpack! I just thought I'd stop by and be useful!
There are a couple of weird problems I've noticed with a couple of your textures. I've noticed it so far on planks (not particularly glaring) and on soul sand/assorted organs (really gratingly obvious!)
I've included a couple screenshots to demonstrate. Top, bottom and two faces (I didn't note cardinal directions, I'm sorry!) look just fine, a disgusting cube of gore with a big ol' eye in the middle.
However, on the two side faces opposing the good ones... Well, it doesn't blend quite so seamlessly, as you can see here.
Oddly, it's perfectly fine VERTICALLY, it's only horizontally that the textures are jumbled.
Does this occur for you as well? Is this possibly due to the fact that I have been using OptiFine instead of MCPatcher?
Also, somewhat unrelated:
If you drag the framerate limiter under video options all the way to the right, then hit F3 and watch the FPS display, you can see differences in framerates well beyond what your monitor can display. If you get, say, 3,000 fps on the renderpass 3 ores and 5,000 on the regular ones, you know the performance impact is tangible for those of us with weaker systems.
Sorry for rambling, but I think this texpack is pretty much the greatest thing since ever. I for one don't mind massive size increases, by the way, so if you feel up to doing absurdly large CTM sheets because you feel like it or whatever, I'm not gonna whine about the zip's size.
Hey Murder, this is my favorite texpack! I just thought I'd stop by and be useful!
There are a couple of weird problems I've noticed with a couple of your textures. I've noticed it so far on planks (not particularly glaring) and on soul sand/assorted organs (really gratingly obvious!)
I've included a couple screenshots to demonstrate. Top, bottom and two faces (I didn't note cardinal directions, I'm sorry!) look just fine, a disgusting cube of gore with a big ol' eye in the middle.
However, on the two side faces opposing the good ones... Well, it doesn't blend quite so seamlessly, as you can see here.
Oddly, it's perfectly fine VERTICALLY, it's only horizontally that the textures are jumbled.
Does this occur for you as well? Is this possibly due to the fact that I have been using OptiFine instead of MCPatcher?
Also, somewhat unrelated:
If you drag the framerate limiter under video options all the way to the right, then hit F3 and watch the FPS display, you can see differences in framerates well beyond what your monitor can display. If you get, say, 3,000 fps on the renderpass 3 ores and 5,000 on the regular ones, you know the performance impact is tangible for those of us with weaker systems.
Sorry for rambling, but I think this texpack is pretty much the greatest thing since ever. I for one don't mind massive size increases, by the way, so if you feel up to doing absurdly large CTM sheets because you feel like it or whatever, I'm not gonna whine about the zip's size.
You're still using 1.7.2, aren't you? That was a minecraft bug that was fixed in 1.7.3. Update, and it shall be resolved.
Also, judging by that messed up sand, you're using optifine. I suggest using mcpatcher. If performance is an issue, lower your render distance. My pack is actually meant to be used with a lower render distance, since i was going for a foggy atmosphere, hence the sky.
When I try to put the texturepack on then it takes me back to the game but the texturepack isnt working... plz help me.
Make sure you have a 64 bit version of java installed and updated. If you don't minecraft will run out of memory when you try to use my pack, because it's limited to under 1gb.
I love what you've done with the texture pack! It is so beautiful put together and has come so far since I first discovered your spectacular texture pack! Keep up the good work!
Rollback Post to RevisionRollBack
"Every man is a moon, and has a dark side which he never shows to anybody."
- Samuel Langhorne Clemens
I love what you've done with the texture pack! It is so beautiful put together and has come so far since I first discovered your spectacular texture pack! Keep up the good work!
-
View User Profile
-
View Posts
-
Send Message
Retired StaffYeah. The real dilemma i ran into with the regular stone ctm is ores... i wanted to do a massive repeat ctm sheet, 12x12 was my original plan, but i ended up going with just 5x5, which tiles horribly since it's used over such large areas and has so much detail with cracks and lumps and such. I had to do that because of ores. If i have 12x12 stone, that's 144 tiles. Then there's 7 ores, and i'd need to do a repeat ctm sheet of the same size for each, meaning ores would require 1008 tiles. That's just too many.
I mean, there is another option, i could do a massive repeat sheet for stone, then for each ore use ctm to use the same 144 tiles as the base layer for all the ores, then make the actual ores as transparent decals to be applied with renderpass 3 over the stone layer, so i could just use a few tiles per ore and do random ctm. I mean, that would probably work, but i'm not sure if it would be optifine friendly, since i'm not entirely sure optifine has renderpass support.
If i go that route, i could easily just edit the base color layer on the stone i already made and use it as one of the new stone types.
I'm just not sure if it would cause performance issues... I mean, do renderpass layers cause any extra GPU stress or anything? Ever since i built myself this monstristy of a gaming pc, i can't tell what hurts performance anymore.
I might go with that. Since there's always a regular copy of the regular texture in the textures folder anyway, if i use matchTiles to apply the stone layer for the ores rather and name the file something other than the texture name, that should keep optifine from reading it, and have it default to the base texture in the textures folder. It won't give it CTM support though, but my pack really is meant to be used with McPatcher anyway.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou've hit the nail on the head there with what worries me. The complexity of having to try and satisfy all users, whether they be vanilla, MCPatcher or Otifine and all the rest with favorite mods.
Now you mention that Optifine might not support renderpass, then I'm going to just try and make the ores random and fit them as best I can into the repeat stone. My theory is if my present mixture of old 32x and 64x ores don't look massively horrible in the way they blend in at the moment, then actually basing my new attempts at ore on the new stone texture might have a chance of at least looking better. With enough cracks, shadows and texture going off in all directions the new ores might not show up too bad where the seams are. Well, I can hope!
-
View User Profile
-
View Posts
-
Send Message
Retired StaffWell, after finding out that optifine doesn't support biome specific textures, i'm too far in to care anymore, i think.
At this point as long as the pack will somewhat function with optifine, that's fine with me, but it's really made for mcpatcher's features. But optfine is slowly implementing mcpatcher's ctm features as it is anyway, so someday it should work fine.
I'm probably going to go with the renderpass method, since it's so much more flexible. I'm just trying to figure out what performance issues it might cause first.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffNOTE: I am just experimenting with the old lapis texture, this isn't the redone one.
Basically, there's 2 layers to it. The base layer of the ore block, which just re-uses the same tiles as stone, then the overlay which has an ore texture that fades out at the edges.
If i go this route, i'll redo regular stone to be a much bigger repeat ctm sheet than the 5x5 one i'm using now, while at the same time reducing the number of tiles needed. This will make caves and exposed stone look much better. Right now, stone has 25 tiles. Each of the 7 ores would require 25 tiles as well to use the regular repeat ctm method. So... 200 tiles in total for all of the stones and ores. If i go the renderpass method, i might go up to a 10x10 or larger stone texture (100 tiles) but then only use 3-4 tiles per ore with random ctm overlays.
However, this incredibly flexible option comes at a slight cost. There's a bit of a rendering issue with transparency. I'm sure it will be fixed eventually, since it's a known bug, but for the time being, this happens:
When viewed through something transparent like water or glass, the ores seem to render on top of the transparent object. I realize you won't be seeing too many ores through glass, but they do end up under water from time to time. Is this annoying enough to bother anyone? Or is it worth it for the nicer stone texture?
Also, if anyone's wondering how i got the lapis ore to show up properly in the inventory, that was a particularly difficult trick that i will now brag about.
Usually, you will only see the base layer on the held block, which would make lapis ore identical to stone in the inventory, but i found a way around that.
What i did was made a placeholder tile, which is the one you see as the lapis ore in the inventory, and is the same thing that would go in the textures folder for the few non-mcpatcher users... Anyway, for the base layer of the lapis ore, the one that just uses the same tiles as the stone texture, i replaced the first tile in the repeat sequence with the placeholder.
Then i made another properties file directed at the placeholder, and used random ctm to select both the placeholder tile and the first tile of the stone repeat ctm sheet. I weighted the placeholder at 0 and the stone tile at 1.
So this way, the game sees the placeholder as the true first tile, therefore using it as the image for the inventory block, but it will never actually appear ingame because it's weighted at 0.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDid you manage to test for how renderpass textures might effect performance? I get very slight jitter as I pass any glass construction using normal stained glass, whether it be using vanilla, my pack or any other. All I can assume is that Mojang do things less efficiently than MCPatcher, as I never got the slightest jitter with BetterGlass before, or it could just be the sheer quantity of layers of transparent colored surfaces now having to be calculated as you move around.
Anyways...good work on the ore research!
-
View User Profile
-
View Posts
-
Send Message
Retired StaffWell, there's really not going to be all too many ores on the screen at any given time. I mean, unless anyone gets extremely lucky.
But i do worry about the fact that each ore will be using the massive stone repeat sheet as an under layer. I asked in the mcpatcher thread, and the answer i got from kahr, wasn't too clear, but indicated that it would be rendering the stone ctm again for every ore, plus rendering each block twice due to the double layer. I'll need to experiment with performance...
I don't suppose you know how to actually measure and test for a performance difference?
-
View User Profile
-
View Posts
-
Send Message
Retired StaffYep. It's another stone texture. Not a recolor, which would probably actually look better since the edges would meet up better.
But i was thinking of doing an overlay around the edges of the alt stones using the classic ctm and the regular stone texture, so it sort of blends. However, i'm not too sure how well it would work due to the fact that regular stone uses repeat ctm, and i couldn't really incorporate that into classic ctm edges. It would cause a hard seam still between the rock types, but at least the colors could blend... Unless of course i were to apply the same overlay layer around the edges of regular stone... that could work.
At some point i'm worried this would cause a drop in performance. I added some overlay layers in the last update. Did the performance drop noticably?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYeah...I saw kahr's reply, but I couldn't quite make out how many times stone was being rendered when using renderpass for random textures.
For some reason I can't see the screenshot.
In measuring performance, other than using Fraps, I'd only be going on a hunch and a guess. Seriously though, I haven't noticed any difference in frame-rate with your latest update from v.13, but I'm probably not the best one to judge, as although my PC is about 2 years old now, it has an I7 processor, 24gigs internal memory and a top of the line nVidia graphics card, so you might need the opinion of someone who was on the edge of acceptable performance with v.13 to chip in here.
For me, the biggest difference I've seen in performance was with the introduction of stained glass in general (not your stained glass specifically)...I get noticeable stutter panning alongside any run of stained glass, even just using vanilla Minecraft. When I get about 20 blocks away from the glass, things run smoothly again! As I don't look at any MC bug news, I don't even know if it's a recognized bug!
-
View User Profile
-
View Posts
-
Send Message
Retired StaffI too have a compter too powerful to suffer from any changes. I need something that can give me actual numbers, aside from FPS. I need memory usage statistics. I'll see what i can find though.
Not sure why the screenshot isn't showing for you, since it's just hosted on imgur which usually works great.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffVery weird. It's broken for me now too. It must have somehow gotten deleted.
Here it is, re-uploaded.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat is some fabulous rock! It would also make an excellent, dirt or clay...in fact I think you've just discovered the ultimate multipurpose texture!
I also like the transition from wall to floor too. What's strange though is the way the floor texture looks worn and smooth and the wall looks more indented, jagged and cracked, but I'm assuming they're the same and it's the angle that creates the illusion.
Top marks!
-
View User Profile
-
View Posts
-
Send Message
Retired StaffIt is indeed the angle. What i do to achieve this is make the "hard" edges just a bit blurred. At a distance, they still look hard, but up close the softness comes through more.
Though there shouldn't be any confusion as to what dirt is, since in my pack i went with a rich, dark dirt.
There are a couple of weird problems I've noticed with a couple of your textures. I've noticed it so far on planks (not particularly glaring) and on soul sand/assorted organs (really gratingly obvious!)
I've included a couple screenshots to demonstrate. Top, bottom and two faces (I didn't note cardinal directions, I'm sorry!) look just fine, a disgusting cube of gore with a big ol' eye in the middle.
However, on the two side faces opposing the good ones... Well, it doesn't blend quite so seamlessly, as you can see here.
Oddly, it's perfectly fine VERTICALLY, it's only horizontally that the textures are jumbled.
Does this occur for you as well? Is this possibly due to the fact that I have been using OptiFine instead of MCPatcher?
Also, somewhat unrelated:
If you drag the framerate limiter under video options all the way to the right, then hit F3 and watch the FPS display, you can see differences in framerates well beyond what your monitor can display. If you get, say, 3,000 fps on the renderpass 3 ores and 5,000 on the regular ones, you know the performance impact is tangible for those of us with weaker systems.
Sorry for rambling, but I think this texpack is pretty much the greatest thing since ever. I for one don't mind massive size increases, by the way, so if you feel up to doing absurdly large CTM sheets because you feel like it or whatever, I'm not gonna whine about the zip's size.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffYou're still using 1.7.2, aren't you? That was a minecraft bug that was fixed in 1.7.3. Update, and it shall be resolved.
Also, judging by that messed up sand, you're using optifine. I suggest using mcpatcher. If performance is an issue, lower your render distance. My pack is actually meant to be used with a lower render distance, since i was going for a foggy atmosphere, hence the sky.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffMake sure you have a 64 bit version of java installed and updated. If you don't minecraft will run out of memory when you try to use my pack, because it's limited to under 1gb.
- Samuel Langhorne Clemens
-
View User Profile
-
View Posts
-
Send Message
Retired StaffHow's the server going?