• 1

    posted a message on Flowerpot alt textures issue for snapshot/1.13? [FIXED! ♥]

    1.13 has major resourcepack changes, several textures, and models files have been renamed. Some blockstates have been renamed and some blockstates have been moved into separate blocks entirely.


    Flower pots no longer have a 'contents' blockstate each flower within a flower pot is now it's own block. You need to split your flower pot blockstate into each new blockstate. potted_allium.json, potted_azure_bluet.json, potted_blue_orchid.json ...

    1.13 has major resourcepack changes, several textures, and models files have been renamed. Some blockstates have been renamed and some blockstates have been moved into separate blocks entirely.


    Flower pots no longer have a 'contents' blockstate each flower within a flower pot is now it's own block. You need to split your flower pot blockstate into each new blockstate. potted_allium.json, potted_azure_bluet.json, potted_blue_orchid.json ...

    Posted in: Resource Pack Help
  • 7

    posted a message on A Basic Guide to Optifine Entity Modelling

    A quick guide to help get started with entity modelling in optifine.

    I hope to update this guide as time goes on, but currently this won't go too in depth with what you can do.


    Intro

    Optifine's entity modelling allows you to replace or add to different parts of an entity, ie head, body, arm1, arm2, leg1, leg2.

    The parts that each entity has is different and the full list of parts can be found in optifine's jem documentation.

    Optifine also has jpm documentation.


    To help there is some existing entity modelling test resourcepacks which you can use to help see how the files can be made: my tests, sp614x's tests, sp614x's tests #2, and a remodeled creeper I made.


    Working directory: all custom entity files will be placed into assets/minecraft/optifine/cem in your resourcepack.


    jem Files:

    A jem file is required when entity modelling, it is the main file which specifies how to re-model an entity.

    You simply need to create a jem file named as the entity that you want to have a custom model, ie zombie.jem.

    A full list of entities and the names of the files can be found in the optifine's jem documentation along with a list of parts which can be replaced in each entity.


    jem stands for JSON Entity Model, meaning that the file must be written in valid JSON.


    Firstly "models" is a required parameter which is an array, it will contain objects which then contain models and which parts they replace.

    "models": [
        {
            "part": #part,
            #model
        }
    ]

    #part must be replaced with one of the parts specified in the optifine's jem documentation. ie "head", "body", "leg1".
    #model can be replaced one of two things, you can use a jpm file, or you can specify the model in-line by creating the elements within the jem file itself.


    You can replace #model with elements (explained further down), or with "model": "file_name.jpm".


    There is some other values that will come in handy which are: "attach": < true | false >, "translate": [x, y, z], "rotate": [x, y, z].

    "attach" will default to false if left out, but if set to true will add the model to the part specified rather than replacing it.

    "translate" will move the element the number of pixels on the specified axes.

    "rotate" will rotate the element on the axes the amount of degrees.


    jpm Files:

    jpm stands for JSON Part Model, which means that the file must be valid JSON. jpm files must be located within the optifine/cem folder.

    A jpm file is purely a part which can consist of multiple elements which can then be used by jem files when replacing parts.


    These files do not need to have specific names. But you need to create at least one element.


    Instead of writing jpm files by hand, Cubik Studio (~ €20), a modelling program which supports Minecraft json block models, also has the ability to export jpms from the program itself.

    You can also use blockbench a free block modelling program, which can be downloaded or used online, which can also export optifine jpms.

    This means you won't have to write a jpm by hand but can just create and export models from Cubik Studio or blockbench.


    Creating Elements:

    "texture": "path/to/texture.png",
    "textureSize": ['width', 'height'],
    "boxes": [
        {
            #texturing
            "coordinates": [0, 0, 0, 2, 2, 2]
        },
        {
            #texturing
            "coordinates": [3, 4, 0, 2, 2, 2]
        }
    ]

    "texture": "path/to/texture.png", "textureSize": ['width', 'height'], "boxes": [ { #texturing "coordinates": [0, 0, 0, 2, 2, 2] }, { #texturing "coordinates": [3, 4, 0, 2, 2, 2] } ]

    This is a basic method of creating elements, note that "coordinates" works quite differently from that when block modelling. The first three values are the location of the element, the next three are actually the width, height and depth.


    "coordinates": [0, 0, 0, 2, 2, 2]

    "coordinates": [3, 4, 0, 2, 2, 2]

    Both of these elements will be the same size but will be in different places.


    Texturing Elements:

    There is two ways to texture elements but first you need to specify the texture that will be used by the element by specifying the path following assets/minecraft ie, "texture": "textures/entity/pig/pig.png". You also need to put the size of the texture in pixels ie, "textureSize": [64, 32].


    When texturing an element you can specify the uv mapping of individual faces with: "uvUp", "uvDown", "uvNorth", "uvEast", "uvSouth", "uvWest".

    ie "uvUp": [0, 0, 4, 6]. The first two numbers are the most top left coordiante of the area you want to have the texture then the next two will be the opposite most right down corner.


    The second method is to use "textureOffset" which works with a unwrapped box texture layed out in this specific format. You specify one set of coordinates which is the most top left coordinates of the rectangle drawn around the unwrapped box. From this example the coordinates would be [0, 0], ie "textureOffset": [0, 0].


    box texture layout


    Animations:

    Custom animations can be applied to each part of the entity, they are created by mathematical equations located within the jem file for mobs. You can read the optifine documentation on animations for more information.


    The animation equations used for custom animations are located within an object, within an array called "animations" which will be inside the object within the "models" array in the jem file.

    "models": [
        {
            "animations": [
                {
                    #equations
                }
            ]
        }
    ]

    Each equation will start with a key for the model the animations will affect. This is done through use of a model variable in the format <model>.<variable>:


    The main two model properties are:

    part - part refers to the part that the custom model has been attached to or replaced, this will animate the existing part and the model that has replaced/added to the part.


    this - this refers to the part that has been added, this will not affect the original part, this can be seen clearly if the new model has been attached instead of replacing.


    The variable has 12 possible values and this will define the type of animation and the axis that will be affected.

    The type can any one of 4 possible values:

    rotation (r), offset (o), translation (t), scale (s)

    Followed by one of the three axis (x, y, z)

    Note the difference between translate and offset. Offset refers to an absolute value for the model whereas translate will refer to a relative value, which will be relative to the existing location of the part model.


    eg "part.ty", "this.ox", "part.rz"


    Following the model variable will be a string which contains a mathematical equation.

    There's several variables and functions which can be used within equations.


    variables:

    model variables - Already stated, these can be used to get values from other parts on the entity.

    time - This is the world time in ticks and can be used on all entities.

    limb_swing, limb_speed - Can only be used with 'living' entities, the swing and speed of entity limbs, these will change when the entity is moving.


    operators:

    + addition, - subtraction, / division, * multiplication, % modulo (gives the remainder after division)


    functions:

    sin(), cos(), tan(), abs(), round(), sqrt() and many more, listed in the optifine documentation.


    e.g.

    "part.ty": "abs(2 * sin(time / 10)) + 12"
    "part.tx": "abs(sin(time / 10))"
    "part.rz": "0.2 * abs(sin(time/10))"

    These animations are used on pigs in my model tests


    Animating Existing Parts:

    Custom animations can be applied to existing parts of an entity, this is done by not specifying any models but setting "attach": true for the part and setting the animations.

    "part": #part,
    "attach": true,
    "animations": [
        {
            #equations
        }
    ]

    Moving the Origin of a Part

    This is a small problem which seemed impossible to acheive, the idea was to be able to change the origin for limbs as the point from where limbs were swinging couldn't be changed with translate. This would allow legs to be bigger or smaller, further apart or closer together than the original entity.


    The way this can be done is using animations to simply translate the limb a fixed amount, and it will move the origin of the part itself.

    "part": #part,
    "animations": [
        {
            "part.ty": 2
        }
    ]
    Posted in: Resource Pack Discussion
  • 1

    posted a message on How to change block texture parts (i.e. from all the same texture to different textures)

    The problem has nothing to do with leaves and their parents, the problem is in your json.

    {
        "parent": "block/cube_bottom_top",
        "textures": {
            "bottom": "blocks/leaves_jungle_bottom",
            "top": "blocks/leaves_jungle_top",
            "side": "blocks/leaves_jungle",
        }
    }

    You have an extra comma after the last texture, the textures compound should be

    "textures": {
        "bottom": "blocks/leaves_jungle_bottom",
        "top": "blocks/leaves_jungle_top",
        "side": "blocks/leaves_jungle"
    }

    You can use something like jsonlint to check if your json is valid.


    Although, even if you change this I bet you'll be back asking why jungle leaves are black and white and not green, this is due to tintindex which can be seen inside this snippet from leaves.json:

    "elements": [
        {
            ...
            "faces": {
                "down":  { "uv": [ 0, 0, 16, 16 ], "texture": "#all", "tintindex": 0, "cullface": "down" },
                ...
            }
        }
    ]

    So I would recommend changing your jungle_leaves.json to something like:

    {
        "parent": "block/block",
        "textures": {
            "particle": "leaves_jungle",
            "side": "leaves_jungle",
            "top": "leaves_jungle_top",
            "bottom": "leaves_jungle_bottom"
        },
        "elements": [
            {   "from": [ 0, 0, 0 ],
                "to": [ 16, 16, 16 ],
                "faces": {
                    "down":  { "texture": "#bottom", "tintindex": 0, "cullface": "down" },
                    "up":    { "texture": "#top",    "tintindex": 0, "cullface": "up" },
                    "north": { "texture": "#side",   "tintindex": 0, "cullface": "north" },
                    "south": { "texture": "#side",   "tintindex": 0, "cullface": "south" },
                    "west":  { "texture": "#side",   "tintindex": 0, "cullface": "west" },
                    "east":  { "texture": "#side",   "tintindex": 0, "cullface": "east" }
                }
            }
        ]
    }

    This should fix your problem.

    Posted in: Resource Pack Help
  • 1

    posted a message on 1.8 TUTORIAL - Alternate textures and custom models

    The reason it isn't working is because of your blockstate file.

    Quote from Mutim_Endymion»

    And blockstates are:

    {
    "variants": {
    { "model": "dragon_egg" },
    { "model": "dragon_egg/dragon_egg2" }
    }
    }


    You've specified 2 models without telling Minecraft which variant it is for, each model must be inside an object or list (if multiple models) referring to a variant in a blockstate file.


    The blockstate file should look like this:

    {
        "variants": {
            "normal": [
                { "model": "dragon_egg" },
                { "model": "dragon_egg/dragon_egg2" }
            ]
        }
    }
    Posted in: Resource Pack Discussion
  • 3

    posted a message on redstone_wire.json blockstate help?

    Both of these are actually OR statements for multipart models. Let's look at the redstone_wire blockstate to see what's going on.


    {   "when": {
            "OR": [
                {"north": "none", "east": "none", "south": "none", "west": "none"},
                {"north": "side|up", "east": "side|up" },
                {"east": "side|up", "south": "side|up" },
                {"south": "side|up", "west": "side|up"},
                {"west": "side|up", "north": "side|up"}
            ]},
        "apply": { "model": "redstone_dot" }
    },

    This is in the redstone_wire blockstate, "when" defines a blockstate, or several states, which when true will apply a model, "OR" defines multiple blockstates when any of these are true the model defined in "apply" will be applied.


    Redstone has four states which can have one of three values, "north", "east", "south", "west" these can be:

    "side" - this is when a redstone component that redstone dust can be attached to is next to redstone dust in the specified direction

    "up" - this is when a redstone dust is up one block in the specified direction

    "none" - there is no redstone component in the specfied direction


    "north": "side|up" will be true when redstone dust has the blockstate "north": "side" OR "north": "up"


    I hope that makes sense. :)

    Posted in: Resource Pack Help
  • 3

    posted a message on Make SOME Blocks / Leaves Ignore the Colormap

    You can change the birch leaves model so that it doesn't turn green automatically.


    Simply change 'birch_leaves.json' to this


    birch_leaves.json:

    {
        "parent": "block/cube_all",
        "textures": {
            "all": "blocks/leaves_birch"
        }
    }

    Although there isn't a way to stop minecraft from tinting the breaking particles for birch leaves, so the particles that birch leaves give off will still be green.

    Posted in: Resource Pack Help
  • 1

    posted a message on block overlays

    I've updated the example resourcepack linked in my previous comment, it should work more how you want it to now.

    What you might want to change is the "weight" value for "grass_normal", in the grass bloackstate file, the higher the value the more likely plain grass will appear.

    Posted in: Resource Pack Help
  • To post a comment, please or register a new account.