Update for March 11 (2015): I've added a section on display and tips. Updated caveats.
~/ refers to /assets/minecraft/
Change the file structure:
1. Move the "model" files (which define what variants use which models) from ~/models/block to ~/blockstates
2. (optional) Move mesh files from ~/models/meshes to ~/models/todo so you can convert them one by one instead of seeing them completely broken, as well as being able to see what needs to be done
3. converted models go in ~/models/block
It is recommended that for actually converting the models, you replace the text you want to replace with the 'replace' tool in your text editor (commonly ctrl+h) rather than manually typing changes. If your text editor has a tabbed interface (and the 'replace' dialogue carries over) this makes it much easier (speaking from experience here, using a program on Linux called Gedit)
Convert the models:
1. Add a "textures" object just before the "elements" object. It should define the textures you use, and should look like this:
2."useAmbientOcclusion" should be replaced as "ambientocclusion"
3. "faceData" should be replaced as "faces"
4. "textureFacing" should be replaced as "texture"
5. The "facing" value should be replaced with the texture. This should be the value you added in step 1 but with a # symbol at the start. So from step 1 would look like this:
"down": {"uv":[ 3, 6, 5, 8], "texture": "#texture"},
This is how default uses it mostly. You can use other names in step 1 if you wish (for the non-particle one at least) and add more if needed. For instance, you could use #top and #side if you want those textures to be unique.
6. (optional) remove "inventoryRender3D" as it is not used anymore. Items now have their own model files, including for blocks' inventory model.
7. (optional) remove the "type" element, such as "type": "cube", as it is not used anymore. Planes don't exist anymore, now just cubes are used so there aren't cubes/planes having different data structures/options or something like that.
lighting is still broken in some cases (like some 3D models with blocks above them, causing them to have darkened faces)
culling operation (if a block causes culling on another block that has it enabled) is still hardcoded. As an example, with culling enabled on reeds, full blocks cull the tops, but not itself (even though it should). Iron bars on the other hand, is culled by itself, even other variants of it, causing visible faces to be culled
cannot rotate elements on more than 1 axis. This makes simple stereotypical swords (with sharp edge and sharp tip) impossible to create, along with recreating cobweb in 3D.
So, let's get started!
Go to ~/.minecraft/versions/
Click the folder of the most recent MC version with models in them
Open the .JAR with an archive manager
Go to ./assets/minecraft/
Files in blockstates folder: These files specify which models are used for which variants
Files in models folder: These files are the models themselves, there is a block folder (placed in-world) and item folder (things in the inventory)
When you wish to edit a block, drag it into the same folder (mimic the structure as the .JAR) in your working resource pack folder.
I do not recommend copying all of the models to your pack, this is a bad practice. Either get them from the .JAR when you need them (c'mon, it's not that much work) or drag them somewhere where you can quickly get to them.
Tip! If you plan to edit many models, it is recommended that you drag the entire models folder into a convenient location, such as your documents folder. Delete this new folder and do this again if new versions with a different model format comes out.
Before starting, it's important to know what you're going to do, as well as what file you need to edit.
A very good planning tool is (drumroll).....
Your image editor!
You'll want to draw a top-down view of the model you plan to make:
This may be fine for simple models (that don't vary much, such as tall boxes), but for more advanced models, you'll want a front view (and maybe side) as well. Your older textures will be great for this:
You also need to find out which model to edit which one you'd place when facing north (which puts in on the south face) which should be model3.json. You want this so you just input X&Z from your top-down image and X&Y from your front-facing image (side images give you Z and Y).
While you create your image in your image editor for the purpose of coordinates, note that the formats are different. Images use pixels while the block model format uses vertices. To oversimplify it, pixels are like "faces" in 3D graphics, in that they (square faces) have 4 vertices.
To illustrate:
So, how do we accommodate for this? Well, fairly simply, when you're hovering over (to find the coordinate) a pixel on the left-top of the square (what you intend to create as a model), use the coordinate as-is. When you're hovering over a pixel on the bottom-right of the square take the pixel coordinate and add 1 to each value.
This can be easily seen with the cube model file: The top left pixel, (0,0) is used as-is, while the bottom-right pixel (15,15) when used in the model is (16,16). This applies to both model and UV mapping.
Important! The model coordinate system and the UV mapping system are different. The model coordinates behave as you would logically expect, but the UV mapping system has the Y-coordinate reversed. This is why I instruct you to take coordinates from the top-left first. This will not cause problems if you have a symmetric texture as I did, aside from confusion when you thought you modelled a top element and you actually modelled a bottom one. You may prefer to flip your texture vertically when getting coordinates for the model (and flip again for UV coords). Why is this? Well, probably from some older technical limitation on how graphics cards worked that image editors adapted to, as now all image editors (and other stuff, like Flash) use this down-is-up system. Mojang not using this for UVs would just add confusion. Something to note.
You'll want to start with the top/bottom faces of your shape:
The top view gives you X&Z, and the front view gives you X&Y (if your model is too complex, you might want to make a side view, too). Well how do you get the coordinates from an image?
Hover with your mouse over the pixel you want. There should be some sort of info in your image editor to tell you what pixel the mouse is over, such as in GIMP, it's on the bottom-left (below the horizontal scroll-bar). Choose from the top-left first.
Next, choose the bottom-right, and remember that since you are using the bottom-right vertex of the pixel you are hovering over, to add 1 to each coordinate value:
Why add 1? As I said, you aren't specifying pixels, you're specifying vertices.
The beautiful thing about using one of your textures as a front-view to find coordinates is that the texture will likely use the same coordinates! Sometimes you may want to choose a texture from somewhere else, and in this case, remember that while the model coordinates are upside-down, the UV coordinates are to be used as-is. UV mapping still used vertex coordinates, so it's not much different than making the block model.
This is why the default cube is, for example
[ 0, 0, 16, 16 ]
Because it maps from (0,0) to (16,16).
Important! You need to be familiar with JSON to work in this format. Whitespace is not important, however, commas and "containers" (curly/square brackets, quotation marks) are. ESPECIALLY COMMAS.
Also remember to pay close attention to where you are placing code to be in the right container, and make sure you have the same amount of opening and closing brackets/quotation marks.
Going along with my example, here's the code for the left post, here is what you get:
{
"__comment": "left post",
"from": [ 1, 0, 13 ],
"to": [ 4, 16, 16 ],
"faces": {
"down": {"uv":[ 0, 8, 3, 11], "texture": "#texture", "cullface":"down"},
"up": {"uv":[ 0, 8, 3, 11], "texture": "#texture", "cullface":"up"},
"north": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270},
"south": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270, "cullface":"south"},
"west": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270},
"east": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270}
}
},
Notice the UV coords for all but down/up are the same:
[ 1, 0, 13, 16 ],
That's because (1,0) and (4,16) are taken straight from the same texture used to find the coords for the box model.
The result of my ladder model:
Tip! If you flip the UV coods, it will flip the texture (such as using [16, 0, 0, 16] instead of [0, 0, 16, 16]). Also, there is a rotation property that allows you to rotate texture mapping:
This is useful when you need a texture, but there isn't a good selection in a horizontal space.
So you've made some super amazing models (or you're trying now) out of cubes. Now what? Specifically, what do you do with those faces that are inside the model and you can't see?
Simply put, remove the entire line from the "faces" section! -source
Example:
Man, the east and west faces aren't even visible, is there anything I can do to stop them from rendering at all?
Something else you should do: set "cullface" to true on top/bottom faces (that will be obscured by blocks above/below them). To test this, go into spectator mode and fly under the ground, it will allow you to see what faces you can't see are rendering. With culling and removing faces lines (as shown above) you should try to eliminate all faces that you shouldn't be able to see.
When you need to use the same model for multiple variants, possibly rotating them, inheriting them is the way.
Quite simply, first you make a model to act as a parent. This can easily be done like any other model, only you leave out the texture paths at the top but leave the references in the faces themselves. Then you make another model that calls to the "parent" model and fills in the path for the texture references.
Many models won't look right based on how you design them, they may be too small in the world/inventory/item frames (they WILL), or just not have right positioning. The display section goes directly after the closing bracket of elements (don't forget the comma!) and the ending curly bracket. Here should be some sane values:
Ground is for the dropped (floating) version of items, fixed is for item frames.
180 Z rotation is needed in 3rd person because they made 0 upside-down.
3rd person also needs to be scaled down, 1 is huge (normal block size).
Scale of 2 is needed in ground/fixed because custom models typically look really small, especially non-blocks.
Tip! You can remove sections of display you don't need! If you only need to fix the 3rd person display, just include that line. If you don't need to move the item, you don't need the 'translation' section!
Here is a simple model to show you what a model (on its own) will end up looking like:
remember that omitting UVs (the system projects the texture!) is your friend. Don't be ashamed to re-use textures this way, it can look decent (or even good!) and that's another texture that doesn't have to load, making your pack a bit lighter
a trick I recently used: need an element to appear on one model but not another? Use a texture projection where nothing will map to it. hopper_top is a good one for thatif your model is centered, chances are a projection of a centered texture may line up
don't forget that animations are applied from textures. Simply loading still water or lava onto a bucket model is amazing, it even displays the animation in the inventory
if you have a model-heavy pack, it can allow you to really clean up your pack. if you make your own custom folders for new/significantly modified textures and delete unused block/item textures, it makes it more manageable.
try to use textures as efficiently as possible. Try to fit it into 16x (or whatever your resolution of pack), but if you have tons of extra room, you might want to make a shared atlas. For instance, I use plant_atlas_0 for mushrooms (both small ones), sugarcane, and wheat (all stages).
There are the sample models, and more in my resource pack, Vivid Torrential Changes. If you wish to snoop around and see how I did something, go right ahead, but only use the models in your pack that I've released here. I will release more later, but please don't use models I haven't released.
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Helpful guide, and I learned I have been placing my UV in the wrong order.
I've been doing: down, up, north, east, south, west
Instead of: down, up, north, south, west, east
Wonderful tutorial!
I think it might help to more clearly state that the coordinates refer to the corners of the pixels rather than the pixels themselves. In playing around with this I was quite confused about why the coordinates ranged from 0-16, indicating that there were seven pixels to a side.
But maybe that's just me.
Wonderful tutorial!
I think it might help to more clearly state that the coordinates refer to the corners of the pixels rather than the pixels themselves. In playing around with this I was quite confused about why the coordinates ranged from 0-16, indicating that there were seven pixels to a side.
But maybe that's just me.
I didn't do this? I stated that you choose vertices not pixels/faces, showed a picture with green dots in the corner, and said that when choosing a coordinate to the bottom-right of a box (as seen if it were a selection in the image editor at least) to add 1 to each coordinate value like the pixel (15,15) becomes (16,16), isn't that clear?
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
I didn't do this? I stated that you choose vertices not pixels/faces, showed a picture with green dots in the corner, and said that when choosing a coordinate to the bottom-right of a box (as seen if it were a selection in the image editor at least) to add 1 to each coordinate value like the pixel (15,15) becomes (16,16), isn't that clear?
Hmm... So you did. I suppose I'm just not too bright when it comes to learning stuff like this. My apologies.
Yeah, I'd like to create a model for minecart tracks very similar to my ladder model.
Sadly, we can't do anything like that yet, as 14w07a/14w08a don't have a model file for it. So it's looking like we'll have to wait until next week to see if we get more model files. 14w08a was released today (wednesday, huh?) and didn't add any more models. Dinnerbone said it's unlikely that we'll get another snapshot with more features this week.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
My big issue is photoshop don't show the type of coords that gimp does, and I don't know gimp at all. The coords it shows seem to be very picky on how wxact you are to each corner. I don't get how to make that grid show up like you have it.
the 1.0 isn't so much the top corner, it's the second pixel across, each starting at 0, then 1, then 2, going across and down...
so.. the 'top corner' stuff is more along 'select pixel one'
Oksy so... make top down...
then p[ick the 2nd pixel along the top, thaats 1,0... and them pick the pixel at the bottom of my front face...
thats 1,5... and now we need to add one to this, so thats 2,6...
okay thats fine and all.. but how does that translate into the modle? What do I put in on 'from' and what do I place in 'to'? theres three numbers in each and none of this part is explained.
So now I am royaly confused. I cant even make the first 'post' for the first step as I don't know what to change in the 'from' and 'to' and the three numbers needed... I just know pixel locations in the image. :/
So now I am royaly confused. I cant even make the first 'post' for the first step as I don't know what to change in the 'from' and 'to' and the three numbers needed... I just know pixel locations in the image. :/
The three numbers are the x, y, and z coordinates. The top down view of your ladder shows the x and z values and the front face shows the x and y values. For the top down view the origin is in the top left with the positive x going to the right and the positive z going down. For the front view the origin is in the bottom left with the positive x going to the right and the positive y going up.
Really, the best way to do this would probably be to just build your model in the game using wool. Then face towards the 'front' of your model and start counting from the back left bottom corner. Remember that for the model you are actually counting the edges between blocks rather than the blocks themselves. (So the bottom left back block goes from 0,0,0 to 1,1,1)
Rollback Post to RevisionRollBack
Tis far better to be a witty fool than a foolish wit.
My big issue is photoshop don't show the type of coords that gimp does, and I don't know gimp at all. The coords it shows seem to be very picky on how wxact you are to each corner. I don't get how to make that grid show up like you have it.
the 1.0 isn't so much the top corner, it's the second pixel across, each starting at 0, then 1, then 2, going across and down...
so.. the 'top corner' stuff is more along 'select pixel one'
Oksy so... make top down...
then p[ick the 2nd pixel along the top, thaats 1,0... and them pick the pixel at the bottom of my front face...
thats 1,5... and now we need to add one to this, so thats 2,6...
okay thats fine and all.. but how does that translate into the modle? What do I put in on 'from' and what do I place in 'to'? theres three numbers in each and none of this part is explained.
So now I am royaly confused. I cant even make the first 'post' for the first step as I don't know what to change in the 'from' and 'to' and the three numbers needed... I just know pixel locations in the image. :/
The top left of the entire image SHOULD be (0,0) so there's no issue there.
The "from" is the corner where a cube starts, and the "to" is where the opposite corner ends.
So, for your top step, it should be a bit like this
It's a bit hard for me to explain, but you've got to work with the 2D images to think about what it should be in 3D. To make that model, I did it point-by-point, saying, "well, I want to go from this corner here, to this corner, so I need the Z value from the top, and the X&Y from the front".
I hope this helps..... I do need to explain it a bit better, but I had hoped that giving the numbers and showing them plugging in would be good enough for now.
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
The first pixel is 0,0, not the top most corner of the first pixel. The next pixel across is 1,0 next pixel is 2,0 and so on.
The red pixel is 0,0, the next pixel over as highlighted is now 1,0.
So the first silver post goes from 1,1 to 1,5, +1, making it 2,6?
and it sticks out from the top view from 1,0 to 1,1
so does that mean I put
"from": [ 1, ??, 1 ],
"to": [ 2, ??, 2 ],
Or... something? I don't know where the middle numbers are coming from as this methood is only giving me 4 outcomes. Or if I';m even working with the first and last numbers...
What image, top or front, and what 'corner' goes to what number? is the first number the first pixel of the object in the top down? is the 3rd the bottom pixel of...something.. or.. what?
'Go from top of this, and bottom of that' only gives 4 of the 6 numbers that I see, 8 numbers if you count the 2nd number in the bunch. 1, 2... 1, 2... or is that 1, 6... I really don't know.
So the first silver post goes from 1,1 to 1,5, +1, making it 2,6?
and it sticks out from the top view from 1,0 to 1,1
so does that mean I put
"from": [ 1, ??, 1 ],
"to": [ 2, ??, 2 ],
"from": [ 1, 1, ?? ],
"to": [ 2, 6,?? ],
X and Y from the front image. You don't know Z yet.
"from": [ 1, 1, 0 ],
"to": [ 2, 6, 2 ],
From the top image. you use the Y coord as the Z coord.
note that this will actually make the bottom-left metal post as the Y is reversed for image editors. However, this won't matter as your ladder is symmetrical anyways, so it'll turn out the same. If you want your ladder to be as is (which is not symmetric or evenly distributed) flip the image before grabbing the model coords. But make sure you use the UV coords from the texture how you already have it.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
However, this won't matter as your ladder is symmetrical anyways, so it'll turn out the same.
His ladder isn't symmetrical along the y axis though. So he should add 1 to the y values you have for it to turn out right. (The bottom rung is actually 2 pixels up from the bottom instead of 1)
Rollback Post to RevisionRollBack
Tis far better to be a witty fool than a foolish wit.
His ladder isn't symmetrical along the y axis though. So he should add 1 to the y values you have for it to turn out right. (The bottom rung is actually 2 pixels up from the bottom instead of 1)
Her*.... and so it is.... I wonder if that's intentional? It would cause a tiling error, though, well actually, they would need to be either 1 taller or 1 shorter to be equally spaced.
And it's even easier to make a non-symmetric model properly by flipping the image and THEN grabbing the values..... because then you're grabbing the values as is (just remember to flip it again to get the UV coords)
EDIT: Removing the top "rows" of everything makes it symmetric and evenly distributed (and then flipping the top 2 pixels of the metal fasteners to keep their "cylindrical" shading.
EDIT2: Found this on reddit..... would somebody who uses it mind linking this thread on there?
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
what do you mean "left post" and why does there have to be multiple uv's? Ive been using multiple plane types with one uv on each. so the code is really long. is it necessary? and would you know of a program to do this automatically? Sorry for all of the questions. I'm really trying to get into this because they said this was also going to help with the modding api which is what im looking forward to and yes im creating a 3d ladder with my own texture.
what do you mean "left post" and why does there have to be multiple uv's? Ive been using multiple plane types with one uv on each. so the code is really long. is it necessary? and would you know of a program to do this automatically? Sorry for all of the questions. I'm really trying to get into this because they said this was also going to help with the modding api which is what im looking forward to and yes im creating a 3d ladder with my own texture.
By "left post" I am referring to the left element of my ladder model, that's what I'm "creating" with the first box.
Yes, it's sort of necessary to define the texture on every face. However, if you'll notice, on my models, similar faces all use the same texture, they don't need to be different. So you can copy+paste it (and change a few things) to make it easier.
I'd say use boxes ("cubes") if you can (unless you need 45 degrees rotation for some reason?), that way you don't need to specify every vertex of every face (even if you have to define the UVs)
Does that help?
Sorry, I don't know of any tools. The format is still early days and might even change again next week, so people could make their own tools, but most will probably be cautious on doing so.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Update for March 11 (2015): I've added a section on display and tips. Updated caveats.
Change the file structure:
1. Move the "model" files (which define what variants use which models) from ~/models/block to ~/blockstates
2. (optional) Move mesh files from ~/models/meshes to ~/models/todo so you can convert them one by one instead of seeing them completely broken, as well as being able to see what needs to be done
3. converted models go in ~/models/block
It is recommended that for actually converting the models, you replace the text you want to replace with the 'replace' tool in your text editor (commonly ctrl+h) rather than manually typing changes. If your text editor has a tabbed interface (and the 'replace' dialogue carries over) this makes it much easier (speaking from experience here, using a program on Linux called Gedit)
Convert the models:
1. Add a "textures" object just before the "elements" object. It should define the textures you use, and should look like this:
"textures": {
"particle": "blocks/wheat_stage_7",
"texture": "blocks/wheat_stage_7"
},
2."useAmbientOcclusion" should be replaced as "ambientocclusion"
3. "faceData" should be replaced as "faces"
4. "textureFacing" should be replaced as "texture"
5. The "facing" value should be replaced with the texture. This should be the value you added in step 1 but with a # symbol at the start. So from step 1 would look like this:
"down": {"uv":[ 3, 6, 5, 8], "texture": "#texture"},
This is how default uses it mostly. You can use other names in step 1 if you wish (for the non-particle one at least) and add more if needed. For instance, you could use #top and #side if you want those textures to be unique.
6. (optional) remove "inventoryRender3D" as it is not used anymore. Items now have their own model files, including for blocks' inventory model.
7. (optional) remove the "type" element, such as "type": "cube", as it is not used anymore. Planes don't exist anymore, now just cubes are used so there aren't cubes/planes having different data structures/options or something like that.
So, let's get started!
Go to ~/.minecraft/versions/
Click the folder of the most recent MC version with models in them
Open the .JAR with an archive manager
Go to ./assets/minecraft/
Files in blockstates folder: These files specify which models are used for which variants
Files in models folder: These files are the models themselves, there is a block folder (placed in-world) and item folder (things in the inventory)
When you wish to edit a block, drag it into the same folder (mimic the structure as the .JAR) in your working resource pack folder.
I do not recommend copying all of the models to your pack, this is a bad practice. Either get them from the .JAR when you need them (c'mon, it's not that much work) or drag them somewhere where you can quickly get to them.
Tip! If you plan to edit many models, it is recommended that you drag the entire models folder into a convenient location, such as your documents folder. Delete this new folder and do this again if new versions with a different model format comes out.
Before starting, it's important to know what you're going to do, as well as what file you need to edit.
A very good planning tool is (drumroll).....
Your image editor!
You'll want to draw a top-down view of the model you plan to make:
This may be fine for simple models (that don't vary much, such as tall boxes), but for more advanced models, you'll want a front view (and maybe side) as well. Your older textures will be great for this:
You also need to find out which model to edit which one you'd place when facing north (which puts in on the south face) which should be model3.json. You want this so you just input X&Z from your top-down image and X&Y from your front-facing image (side images give you Z and Y).
To illustrate:
So, how do we accommodate for this? Well, fairly simply, when you're hovering over (to find the coordinate) a pixel on the left-top of the square (what you intend to create as a model), use the coordinate as-is. When you're hovering over a pixel on the bottom-right of the square take the pixel coordinate and add 1 to each value.
This can be easily seen with the cube model file: The top left pixel, (0,0) is used as-is, while the bottom-right pixel (15,15) when used in the model is (16,16). This applies to both model and UV mapping.
Important! The model coordinate system and the UV mapping system are different. The model coordinates behave as you would logically expect, but the UV mapping system has the Y-coordinate reversed. This is why I instruct you to take coordinates from the top-left first. This will not cause problems if you have a symmetric texture as I did, aside from confusion when you thought you modelled a top element and you actually modelled a bottom one. You may prefer to flip your texture vertically when getting coordinates for the model (and flip again for UV coords). Why is this? Well, probably from some older technical limitation on how graphics cards worked that image editors adapted to, as now all image editors (and other stuff, like Flash) use this down-is-up system. Mojang not using this for UVs would just add confusion. Something to note.
You'll want to start with the top/bottom faces of your shape:
The top view gives you X&Z, and the front view gives you X&Y (if your model is too complex, you might want to make a side view, too). Well how do you get the coordinates from an image?
Hover with your mouse over the pixel you want. There should be some sort of info in your image editor to tell you what pixel the mouse is over, such as in GIMP, it's on the bottom-left (below the horizontal scroll-bar). Choose from the top-left first.
Next, choose the bottom-right, and remember that since you are using the bottom-right vertex of the pixel you are hovering over, to add 1 to each coordinate value:
Why add 1? As I said, you aren't specifying pixels, you're specifying vertices.
The (simplest) UV format is:
"direction": {"uv":[ x1, y1, x2, y2], "texture": "#textureidentifier"},
The beautiful thing about using one of your textures as a front-view to find coordinates is that the texture will likely use the same coordinates! Sometimes you may want to choose a texture from somewhere else, and in this case, remember that while the model coordinates are upside-down, the UV coordinates are to be used as-is. UV mapping still used vertex coordinates, so it's not much different than making the block model.
This is why the default cube is, for example
[ 0, 0, 16, 16 ]
Because it maps from (0,0) to (16,16).
Important! You need to be familiar with JSON to work in this format. Whitespace is not important, however, commas and "containers" (curly/square brackets, quotation marks) are. ESPECIALLY COMMAS.
{
"__comment": "left post",
"from": [ 1, 0, 13 ],
"to": [ 4, 16, 16 ],
"faces": {
"down": {"uv":[ 0, 8, 3, 11], "texture": "#texture", "cullface":"down"},
"up": {"uv":[ 0, 8, 3, 11], "texture": "#texture", "cullface":"up"},
"north": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270},
"south": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270, "cullface":"south"},
"west": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270}
"east": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270}
}
},
Will cause the model not to work, because if there is more than one item, a comma is needed after all but the last.
Similarly,
{
"__comment": "left post",
"from": [ 1, 0, 13 ],
"to": [ 4, 16, 16 ],
"faces": {
"down": {"uv":[ 0, 8, 3, 11], "texture": "#texture", "cullface":"down"},
"up": {"uv":[ 0, 8, 3, 11], "texture": "#texture", "cullface":"up"},
"north": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270},
"south": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270, "cullface":"south"},
"west": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270},
"east": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270},
}
},
Will fail.
Also remember to pay close attention to where you are placing code to be in the right container, and make sure you have the same amount of opening and closing brackets/quotation marks.
Going along with my example, here's the code for the left post, here is what you get:
{
"__comment": "left post",
"from": [ 1, 0, 13 ],
"to": [ 4, 16, 16 ],
"faces": {
"down": {"uv":[ 0, 8, 3, 11], "texture": "#texture", "cullface":"down"},
"up": {"uv":[ 0, 8, 3, 11], "texture": "#texture", "cullface":"up"},
"north": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270},
"south": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270, "cullface":"south"},
"west": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270},
"east": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270}
}
},
Notice the UV coords for all but down/up are the same:
[ 1, 0, 13, 16 ],
That's because (1,0) and (4,16) are taken straight from the same texture used to find the coords for the box model.
The result of my ladder model:
Tip! If you flip the UV coods, it will flip the texture (such as using [16, 0, 0, 16] instead of [0, 0, 16, 16]). Also, there is a rotation property that allows you to rotate texture mapping:
"north": {"uv":[ 0, 13, 16, 16], "texture": "#texture", "rotation":270},
This is useful when you need a texture, but there isn't a good selection in a horizontal space.
So you've made some super amazing models (or you're trying now) out of cubes. Now what? Specifically, what do you do with those faces that are inside the model and you can't see?
Simply put, remove the entire line from the "faces" section! -source
Example:
Man, the east and west faces aren't even visible, is there anything I can do to stop them from rendering at all?
{ "from": [ 3, 0, 0 ],
"__comment": "outer north plank",
"to": [ 13, 3, 3 ],
"faces": {
"down": {"uv":[ 3, 0, 13, 3], "texture": "#texture"},
"up": {"uv":[ 3, 0, 13, 3], "texture": "#texture"},
"north": {"uv":[ 3, 0, 13, 3], "texture": "#texture"},
"south": {"uv":[ 3, 0, 13, 3], "texture": "#texture"},
"west": {"uv":[ 0, 0, 0, 0], "texture": "#texture"},
"east": {"uv":[ 0, 0, 0, 0], "texture": "#texture"}
}
},
*reads grum's comment*
YES!
{ "from": [ 3, 0, 0 ],
"__comment": "outer north plank",
"to": [ 13, 3, 3 ],
"faces": {
"down": {"uv":[ 3, 0, 13, 3], "texture": "#texture"},
"up": {"uv":[ 3, 0, 13, 3], "texture": "#texture"},
"north": {"uv":[ 3, 0, 13, 3], "texture": "#texture"},
"south": {"uv":[ 3, 0, 13, 3], "texture": "#texture"}
}
},
Fixed!
Something else you should do: set "cullface" to true on top/bottom faces (that will be obscured by blocks above/below them). To test this, go into spectator mode and fly under the ground, it will allow you to see what faces you can't see are rendering. With culling and removing faces lines (as shown above) you should try to eliminate all faces that you shouldn't be able to see.
When you need to use the same model for multiple variants, possibly rotating them, inheriting them is the way.
Quite simply, first you make a model to act as a parent. This can easily be done like any other model, only you leave out the texture paths at the top but leave the references in the faces themselves. Then you make another model that calls to the "parent" model and fills in the path for the texture references.
Simple structure:
{
"parent": "block/your_parent_model",
"textures": {
"texture_reference": "blocks/your_texture"
}
}
Many models won't look right based on how you design them, they may be too small in the world/inventory/item frames (they WILL), or just not have right positioning. The display section goes directly after the closing bracket of elements (don't forget the comma!) and the ending curly bracket. Here should be some sane values:
Ground is for the dropped (floating) version of items, fixed is for item frames.
180 Z rotation is needed in 3rd person because they made 0 upside-down.
3rd person also needs to be scaled down, 1 is huge (normal block size).
Scale of 2 is needed in ground/fixed because custom models typically look really small, especially non-blocks.
Tip! You can remove sections of display you don't need! If you only need to fix the 3rd person display, just include that line. If you don't need to move the item, you don't need the 'translation' section!
Here is a simple model to show you what a model (on its own) will end up looking like:
The texture is 8x8 but uses the whole thing.
a trick I recently used: need an element to appear on one model but not another? Use a texture projection where nothing will map to it. hopper_top is a good one for thatif your model is centered, chances are a projection of a centered texture may line up
There are the sample models, and more in my resource pack, Vivid Torrential Changes. If you wish to snoop around and see how I did something, go right ahead, but only use the models in your pack that I've released here. I will release more later, but please don't use models I haven't released.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
I've been doing: down, up, north, east, south, west
Instead of: down, up, north, south, west, east
I think it might help to more clearly state that the coordinates refer to the corners of the pixels rather than the pixels themselves. In playing around with this I was quite confused about why the coordinates ranged from 0-16, indicating that there were seven pixels to a side.
But maybe that's just me.
Also, I agree on the torches. Looks lovely.
I didn't do this? I stated that you choose vertices not pixels/faces, showed a picture with green dots in the corner, and said that when choosing a coordinate to the bottom-right of a box (as seen if it were a selection in the image editor at least) to add 1 to each coordinate value like the pixel (15,15) becomes (16,16), isn't that clear?
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Hmm... So you did. I suppose I'm just not too bright when it comes to learning stuff like this. My apologies.
Yeah, I'd like to create a model for minecart tracks very similar to my ladder model.
Sadly, we can't do anything like that yet, as 14w07a/14w08a don't have a model file for it. So it's looking like we'll have to wait until next week to see if we get more model files. 14w08a was released today (wednesday, huh?) and didn't add any more models. Dinnerbone said it's unlikely that we'll get another snapshot with more features this week.
Huh, you mean when the model system is to a point where modmakers can use it to more easily make models for their mods?
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
the 1.0 isn't so much the top corner, it's the second pixel across, each starting at 0, then 1, then 2, going across and down...
so.. the 'top corner' stuff is more along 'select pixel one'
Oksy so... make top down...
then p[ick the 2nd pixel along the top, thaats 1,0... and them pick the pixel at the bottom of my front face...
thats 1,5... and now we need to add one to this, so thats 2,6...
okay thats fine and all.. but how does that translate into the modle? What do I put in on 'from' and what do I place in 'to'? theres three numbers in each and none of this part is explained.
So now I am royaly confused. I cant even make the first 'post' for the first step as I don't know what to change in the 'from' and 'to' and the three numbers needed... I just know pixel locations in the image. :/
Really, the best way to do this would probably be to just build your model in the game using wool. Then face towards the 'front' of your model and start counting from the back left bottom corner. Remember that for the model you are actually counting the edges between blocks rather than the blocks themselves. (So the bottom left back block goes from 0,0,0 to 1,1,1)
The top left of the entire image SHOULD be (0,0) so there's no issue there.
The "from" is the corner where a cube starts, and the "to" is where the opposite corner ends.
So, for your top step, it should be a bit like this
It's a bit hard for me to explain, but you've got to work with the 2D images to think about what it should be in 3D. To make that model, I did it point-by-point, saying, "well, I want to go from this corner here, to this corner, so I need the Z value from the top, and the X&Y from the front".
I hope this helps..... I do need to explain it a bit better, but I had hoped that giving the numbers and showing them plugging in would be good enough for now.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
The red pixel is 0,0, the next pixel over as highlighted is now 1,0.
So the first silver post goes from 1,1 to 1,5, +1, making it 2,6?
and it sticks out from the top view from 1,0 to 1,1
so does that mean I put
"from": [ 1, ??, 1 ],
"to": [ 2, ??, 2 ],
Or... something? I don't know where the middle numbers are coming from as this methood is only giving me 4 outcomes. Or if I';m even working with the first and last numbers...
@.x I much rather work in real 3D.
So heres the deal. Screw xyz.
What image, top or front, and what 'corner' goes to what number? is the first number the first pixel of the object in the top down? is the 3rd the bottom pixel of...something.. or.. what?
'Go from top of this, and bottom of that' only gives 4 of the 6 numbers that I see, 8 numbers if you count the 2nd number in the bunch. 1, 2... 1, 2... or is that 1, 6... I really don't know.
This is correct.
"from": [ 1, 1, ?? ],
"to": [ 2, 6, ?? ],
X and Y from the front image. You don't know Z yet.
"from": [ 1, 1, 0 ],
"to": [ 2, 6, 2 ],
From the top image. you use the Y coord as the Z coord.
note that this will actually make the bottom-left metal post as the Y is reversed for image editors.
However, this won't matter as your ladder is symmetrical anyways, so it'll turn out the same.If you want your ladder to be as is (which is not symmetric or evenly distributed) flip the image before grabbing the model coords. But make sure you use the UV coords from the texture how you already have it."I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Her*.... and so it is.... I wonder if that's intentional? It would cause a tiling error, though, well actually, they would need to be either 1 taller or 1 shorter to be equally spaced.
And it's even easier to make a non-symmetric model properly by flipping the image and THEN grabbing the values..... because then you're grabbing the values as is (just remember to flip it again to get the UV coords)
EDIT: Removing the top "rows" of everything makes it symmetric and evenly distributed (and then flipping the top 2 pixels of the metal fasteners to keep their "cylindrical" shading.
EDIT2: Found this on reddit..... would somebody who uses it mind linking this thread on there?
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Done
Thank you
EDIT: Thanks
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
By "left post" I am referring to the left element of my ladder model, that's what I'm "creating" with the first box.
Yes, it's sort of necessary to define the texture on every face. However, if you'll notice, on my models, similar faces all use the same texture, they don't need to be different. So you can copy+paste it (and change a few things) to make it easier.
I'd say use boxes ("cubes") if you can (unless you need 45 degrees rotation for some reason?), that way you don't need to specify every vertex of every face (even if you have to define the UVs)
Does that help?
Sorry, I don't know of any tools. The format is still early days and might even change again next week, so people could make their own tools, but most will probably be cautious on doing so.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin