I understand that the higher texture packs are 32x32 and so on and so forth but, what about lower texture packs who exactly do they work with things like entities and what are the lower resolutions. What would be an entity lowest size do an example with division and variables so I can reproduce in java

Its all multiples of 2. So 1x1, 2x2, 4x4, and 8x8. Not much to it.

how does that work with entities answer the question and 1x1 isn't a multiple of 2 so didn't explain it right. Take the 64x64 entity and give me how it would work with every lower resolutions showing the math

how does that work with entities answer the question and 1x1 isn't a multiple of 2 so didn't explain it right. Take the 64x64 entity and give me how it would work with every lower resolutions showing the math

If the base image is 64x64... then make it 32x32, 16x16, 8x8, 4x4, 2x2, or 1x1...

1x1 does fit in this because it follows the "power of 2" rule. 1x2=2, 2x2=4, 4x2=8, 8x2=16, 16x2=32, 32x2=64, etc. 64-128-256-512-1024-2048-4096, so on and so fourth.

If the vanilla texture is 64x64, and you want to make it fit an "8x pack", then you simply drop it down a level to 32x32, since 8x is one step down from 16x.

This is rather basic here... can't get much simpler than that.

If the base image is 64x64... then make it 32x32, 16x16, 8x8, 4x4, 2x2, or 1x1...

1x1 does fit in this because it follows the "power of 2" rule. 1x2=2, 2x2=4, 4x2=8, 8x2=16, 16x2=32, 32x2=64, etc. 64-128-256-512-1024-2048-4096, so on and so fourth.

If the vanilla texture is 64x64, and you want to make it fit an "8x pack", then you simply drop it down a level to 32x32, since 8x is one step down from 16x.

This is rather basic here... can't get much simpler than that.

Yeah the main issue with supporting lower res in a java program texture pack converter I am making is that not all the numbers work right

Example: bed is 64x64 but, texture pack maker has made a bed of 32x32. Now the leg is normally 3x3 but, their legs positions are now all screwed up. They are not even 1x1. since the bed leg I would need to convert to either xbox or pc would be 3/2 which is in int 1 or double 1.5. The double value seems a bit accurate but, what am I suppose to do with that extra info the rest just looses quality and pixels and I am not even sure if the bed will be 1x1 properly or if the model is doing something weird like I think it's doing for a 32x32 bed on the legs.

So yes in the example the bed can be converted properly all except for the legs since the bed is a square and can be divided by 2 but, the rest cannot what the heck do I do with that?

Take the original bed texture, and scale it to the size you need. Apply your texture. Done. The resolution is for the overall size of the image, not the individual sections of it. There is no "3x3" texture in the game, period. You are referring to a single section of the UV mapping of the texture.

From here on out, pictures of what you are trying to do would be very helpful.

Take the original bed texture, and scale it to the size you need. Apply your texture. Done. The resolution is for the overall size of the image, not the individual sections of it. There is no "3x3" texture in the game, period. You are referring to a single section of the UV mapping of the texture.

From here on out, pictures of what you are trying to do would be very helpful.

I told you a java program. I am trying to support custom resolution by changing my input numbers based on the resolution of the texure and scale it.

explain the uv mapping of the texture and model system since I can't find out how it works

That little 3x3 section is mapped to whatever model based on the UV mapping of said model.

Minecraft is super simplistic in the regard since the models are all just boxes and plains. If you want to know how exactly, I suggest getting a Minecraft modeling software and play around with the vanilla models.

That little 3x3 section is mapped to whatever model based on the UV mapping of said model.

Minecraft is super simplistic in the regard since the models are all just boxes and plains. If you want to know how exactly, I suggest getting a Minecraft modeling software and play around with the vanilla models.

That doesn't' tell me minecraft's alignment on x y or what uv lock is. Any idea what package it's in?

That doesn't' tell me minecraft's alignment on x y or what uv lock is. Any idea what package it's in?

I think you're thinking about it wrong. It's hard to tell from how you phrase things. No offense intended, of course.

All of the coordinates are hard-coded into Minecraft, most likely as a decimal number between 0 and 1. So 0,0 is the top-left corner of the image. Since we're talking about coordinate values, that doesn't mean the top-left pixel, but the top-left corner of the top-left pixel. Think of it more like a grid. So the exact center would be 0.5,0.5 regardless of the number of pixels. It's literally "50% of the width by 50% of the height".

Minecraft internally translates these values between what IT uses and the 0-16 coordinate system that's used in the model system. so 0,0 is the same in both systems, but 16,16 in the model file maps to 1,1 in texture space. Both are saying "all the way across by all the way down", just in different ways. There's math involved, and you probably understand it better than I do.

So what you need to do is stop thinking about where an area begins in terms of pixels, and start thinking about where it begins in terms of percentage. Does that make sense to you?

As to what UVLock does, it preserves what texture is projected onto each side when the model is rotated. So for example let's say you have a log block and you always want moss to be on the side that faces north in the world... but you also want it to be able to rotate randomly around because you modeled in some twigs sticking out of it. Having the UVLock set to true would make it so that no matter what direction the model is rotated, the textures mapped to each side will change sides according to the WORLD'S orientation and not stick to the BLOCK's orientation as one would expect. If you've used 3d modeling software, it's basically like using projection mapping but not moving the projector when you move the model. It's the kinda thing that literally only works because we're dealing with cubes.

I hope that explains things a little better. I hope that I understood what you're asking about (I'm still not convinced I did) and I hope that helps you.

I think you're thinking about it wrong. It's hard to tell from how you phrase things. No offense intended, of course.

All of the coordinates are hard-coded into Minecraft, most likely as a decimal number between 0 and 1. So 0,0 is the top-left corner of the image. Since we're talking about coordinate values, that doesn't mean the top-left pixel, but the top-left corner of the top-left pixel. Think of it more like a grid. So the exact center would be 0.5,0.5 regardless of the number of pixels. It's literally "50% of the width by 50% of the height".

Minecraft internally translates these values between what IT uses and the 0-16 coordinate system that's used in the model system. so 0,0 is the same in both systems, but 16,16 in the model file maps to 1,1 in texture space. Both are saying "all the way across by all the way down", just in different ways. There's math involved, and you probably understand it better than I do.

So what you need to do is stop thinking about where an area begins in terms of pixels, and start thinking about where it begins in terms of percentage. Does that make sense to you?

As to what UVLock does, it preserves what texture is projected onto each side when the model is rotated. So for example let's say you have a log block and you always want moss to be on the side that faces north in the world... but you also want it to be able to rotate randomly around because you modeled in some twigs sticking out of it. Having the UVLock set to true would make it so that no matter what direction the model is rotated, the textures mapped to each side will change sides according to the WORLD'S orientation and not stick to the BLOCK's orientation as one would expect. If you've used 3d modeling software, it's basically like using projection mapping but not moving the projector when you move the model. It's the kinda thing that literally only works because we're dealing with cubes.

I hope that explains things a little better. I hope that I understood what you're asking about (I'm still not convinced I did) and I hope that helps you.

This is helpful but, I already know a working way for higher res. Coord * res multiplier. res multiplier = res/img.getWidth(). I might look into the percentage thing for lower resolution.

if what you telling me is true they are using cos/sin all the way never understood what they do or how to use them. But, I think it's not doing the actual math java and or the open gl is. So it maps it to the model yes but, let's assume nothing brain recking and that the model of the block is the image. so the center would be img.getWidth()/2 + 0.5, img.getHeight()/2 + 0.5.

I am basically asking for some math equation writing help

would dividing by the res multiplier be the answer for lower res I seem to keep getting var = math.floor(x/resMultiplier)

Edit: not sure if always is working I mean I could test it with the bed legs that don't fit proper scaling dimensions but, since 1 pixel = 4 pixels not sure if is the right output. You said percentage well that's the same as dividing so point.getX/Y()/resMultiplier divide for lower res multiply for higher res then math.floor for the actual point your saying to grab?

If you're asking me for math help then don't. I understand how it works visually and intuitively, not in terms of code or maths. Sorry. Hopefully someone else will be able to help you out because I'm not a programmer at all.

If you're asking me for math help then don't. I understand how it works visually and intuitively, not in terms of code or maths. Sorry. Hopefully someone else will be able to help you out because I'm not a programmer at all.

Well let's just hope my initial claim that dividing or multiplier the right numbers will work via scaling everything. The Resource pack converter will hit the mc forum eventually within a good month give or take a few weeks.

I figured out an algorithm for zombie villagers and boats to and from 1.9

I understand that the higher texture packs are 32x32 and so on and so forth but, what about lower texture packs who exactly do they work with things like entities and what are the lower resolutions. What would be an entity lowest size do an example with division and variables so I can reproduce in java

Its all multiples of 2. So 1x1, 2x2, 4x4, and 8x8. Not much to it.

Cast aside your festive doylaks: dragon stuff is about to happen.

Multiplayer is lonely once you understand how it actually works.

Alpha 1.0.4

how does that work with entities answer the question and 1x1 isn't a multiple of 2 so didn't explain it right. Take the 64x64 entity and give me how it would work with every lower resolutions showing the math

If the base image is 64x64... then make it 32x32, 16x16, 8x8, 4x4, 2x2, or 1x1...

1x1 does fit in this because it follows the "power of 2" rule. 1x2=2, 2x2=4, 4x2=8, 8x2=16, 16x2=32, 32x2=64, etc. 64-128-256-512-1024-2048-4096, so on and so fourth.

If the vanilla texture is 64x64, and you want to make it fit an "8x pack", then you simply drop it down a level to 32x32, since 8x is one step down from 16x.

This is rather basic here... can't get much simpler than that.

Cast aside your festive doylaks: dragon stuff is about to happen.

Multiplayer is lonely once you understand how it actually works.

Alpha 1.0.4

Yeah the main issue with supporting lower res in a java program texture pack converter I am making is that not all the numbers work right

Example: bed is 64x64 but, texture pack maker has made a bed of 32x32. Now the leg is normally 3x3 but, their legs positions are now all screwed up. They are not even 1x1. since the bed leg I would need to convert to either xbox or pc would be 3/2 which is in int 1 or double 1.5. The double value seems a bit accurate but, what am I suppose to do with that extra info the rest just looses quality and pixels and I am not even sure if the bed will be 1x1 properly or if the model is doing something weird like I think it's doing for a 32x32 bed on the legs.

So yes in the example the bed can be converted properly all except for the legs since the bed is a square and can be divided by 2 but, the rest cannot what the heck do I do with that?

Take the original bed texture, and scale it to the size you need. Apply your texture. Done. The resolution is for the overall size of the image, not the individual sections of it. There is no "3x3" texture in the game, period. You are referring to a single section of the UV mapping of the texture.

From here on out, pictures of what you are trying to do would be very helpful.

Cast aside your festive doylaks: dragon stuff is about to happen.

Multiplayer is lonely once you understand how it actually works.

Alpha 1.0.4

I told you a java program. I am trying to support custom resolution by changing my input numbers based on the resolution of the texure and scale it.

explain the uv mapping of the texture and model system since I can't find out how it works

Basically I need to know how minecraft knows how to grab what pixel and I can support xbox bed to pc bed. and windows 10 to pc as well

By UV mapping.

https://en.wikipedia.org/wiki/UV_mapping

That little 3x3 section is mapped to whatever model based on the UV mapping of said model.

Minecraft is super simplistic in the regard since the models are all just boxes and plains. If you want to know how exactly, I suggest getting a Minecraft modeling software and play around with the vanilla models.

Cast aside your festive doylaks: dragon stuff is about to happen.

Multiplayer is lonely once you understand how it actually works.

Alpha 1.0.4

That doesn't' tell me minecraft's alignment on x y or what uv lock is. Any idea what package it's in?

I think you're thinking about it wrong. It's hard to tell from how you phrase things. No offense intended, of course.

All of the coordinates are hard-coded into Minecraft, most likely as a decimal number between 0 and 1. So 0,0 is the top-left corner of the image. Since we're talking about coordinate values, that doesn't mean the top-left pixel, but the top-left corner of the top-left pixel. Think of it more like a grid. So the exact center would be 0.5,0.5 regardless of the number of pixels. It's literally "50% of the width by 50% of the height".

Minecraft internally translates these values between what IT uses and the 0-16 coordinate system that's used in the model system. so 0,0 is the same in both systems, but 16,16 in the model file maps to 1,1 in texture space. Both are saying "all the way across by all the way down", just in different ways. There's math involved, and you probably understand it better than I do.

So what you need to do is stop thinking about where an area begins in terms of pixels, and start thinking about where it begins in terms of percentage. Does that make sense to you?

As to what UVLock does, it preserves what texture is projected onto each side when the model is rotated. So for example let's say you have a log block and you always want moss to be on the side that faces north in the world... but you also want it to be able to rotate randomly around because you modeled in some twigs sticking out of it. Having the UVLock set to true would make it so that no matter what direction the model is rotated, the textures mapped to each side will change sides according to the WORLD'S orientation and not stick to the BLOCK's orientation as one would expect. If you've used 3d modeling software, it's basically like using projection mapping but not moving the projector when you move the model. It's the kinda thing that literally only works because we're dealing with cubes.

I hope that explains things a little better. I hope that I understood what you're asking about (I'm still not convinced I did) and I hope that helps you.

This is helpful but, I already know a working way for higher res. Coord * res multiplier. res multiplier = res/img.getWidth(). I might look into the percentage thing for lower resolution.

if what you telling me is true they are using cos/sin all the way never understood what they do or how to use them. But, I think it's not doing the actual math java and or the open gl is. So it maps it to the model yes but, let's assume nothing brain recking and that the model of the block is the image. so the center would be img.getWidth()/2 + 0.5, img.getHeight()/2 + 0.5.

I am basically asking for some math equation writing help

would dividing by the res multiplier be the answer for lower res I seem to keep getting var = math.floor(x/resMultiplier)

Edit: not sure if always is working I mean I could test it with the bed legs that don't fit proper scaling dimensions but, since 1 pixel = 4 pixels not sure if is the right output. You said percentage well that's the same as dividing so point.getX/Y()/resMultiplier divide for lower res multiply for higher res then math.floor for the actual point your saying to grab?

If you're asking me for math help then don't. I understand how it works visually and intuitively, not in terms of code or maths. Sorry. Hopefully someone else will be able to help you out because I'm not a programmer at all.

Well let's just hope my initial claim that dividing or multiplier the right numbers will work via scaling everything. The Resource pack converter will hit the mc forum eventually within a good month give or take a few weeks.

I figured out an algorithm for zombie villagers and boats to and from 1.9