Note: I posted this in Resource Pack Discussion because this thread is for resource pack artists, and what I'm doing has the most relevancy to them, not modders.
I'm developing a custom entity model system.
As you will know, entity models were hinted for 1.9, then (most likely) scrapped. So, I have taken it upon myself to create a working customizable entity model system as a mod. This topic is for you to post what you want in entity models, in order that it be the most relevant to the resource pack community. But first, here's what I have so far:
Entity JSON Files:
These JSON model files will contain model element definitions and animation declarations. A typical model file might look like this.
Imports: These are elements imported from other files. Each key is a resource location pointing to a .json file relative to the /models/entity directory. The one in the example points to assets/bunkernine/models/entity/entityImport.json. Each value in the array is the name of the element to import. A special value "*" can be used to import all the elements in a particular file. You can only import elements defined within the import file; imports will not be recursively imported.
Elements: This is similar to the elements used in block models, but with slightly different syntax.
name: The element name is mandatory and must be unique.
parent: (optional) In the code, elements can be grouped on the same rendering grid using a parent-child relation. Child element will share the same rotations as the parent element, although they can be rotated individual relative to the parent. The value of this tag is the name of the parent element, or "", null, or absent if there is no parent.
texcoords: The coordinates on the texture image. These are the upper-left corner of the rectangular region containing the texture. If the dimensions are [x, y, z], the region will have a height of z + y and a width of 2z + 2x.
from: The lowest vertex of the element. Analogous to from in block models.
to: The highest vertex of the element. Analogous to to in block models.
rotpoint: (optional) This is the origin of rotation for the element, relative to itself.
Animations: These are not texture animations! This is the place to animate the model under certain conditions, as follows.
idle: When the entity is not controlled by AI.
moving: When the entity is moving. The speed of this animation is modulated by the speed of the entity.
attack: When the entity is attacking.
defend (?): When the entity is being attacked.
damaged: When the entity is damaged.
swimming (?): When the entity is swimming.
flying (?): When the entity is flying.
interact: When a player interacts with the entity by right-clicking. This animation is played in reverse when the player finishes interaction (?).
Within each of these are these properties.
script: The animation script to use. This is a resource location pointing to a .enim file relative to /models/entity. See ENIM files below.
with: This connects the animation-defined elements with actual elements of the entity. The key is the animation-defined element, the value is the model-defined element.
Entity Animation (ENIM) Files:
These are where the entity animations are defined. A typical animation file might look like this.
#this is a comment
#they reach until the end of the line
#definition
define node
#frequency or "tick delay". freq 2 occurs every two ticks, freq 3 every three, etc.
freq 1
set node y 0.0
set node y 30.0
set node y 60.0
set node y 90.0
set node y 120.0
set node y 150.0
set node y 180.0
repeat 6 loop
rotate node y 30.0
end loop
#empty frames
pause 387
These are the commands so far.
define (name): This defines an element placeholder to be used in the animation. The actual elements are defined in the model file.
freq (unsigned_int): This is similar to frametime in block animations.
set (name) (axis) (floating_point): Sets the angle of a particular element along one axis.
rotate (name) (axis) (floating_point): Adds the specified angle to the element along one axis.
pause (unsigned_int): Does nothing for the specified number of frames.
repeat (unsigned_int) (name)...end (name): Defines a loop execute the given number of times. This is most useful for rotate commands.
#(text): This is a comment. Comments continue until the end of the line.
So, now that you've read on what I have so far, do you see anything missing (other than the lack of texture definitions)? Anything that's not needed? Post it below. For the programmatically inclined, the code behind this is on the GitHub repository.
There are a few things that I'd like to see (that may or may not be possible) in regards to animations.
The first one would be to define animation loops based on a pretty traditional keyframe system that the game interpolates in based on the usual types of curves (spline, ease in, ease out, stepped (also known as clamped), etc.) This would make the process more like "@ frame 1 spline to element rotation x=0.0; @ frame 5 ease-in to element rotation x=45. & ease-in to element rotation y=5.0; etc.". You'll have to figure out how to make that sound json-y but it makes more sense to define keyframes and curves. If you need a practical freeware example of this system, look up how Synfig does animation curves. It's pretty easy to figure out after watching a couple of tutorials.
Another thing would be to define an animation offset from an action. Take for example the zombie attack animation currently in the game. It starts the animation to attack the moment it hits rather than hitting at the logical end or middle point of the animation. Being able to say "start this loop 5 frames before event" would be extremely useful and make combat MUCH more intuitive with certain mobs. Not sure how possible that is, but it's a thing that should exist.
Ultimately I think that the thing that would make this system the most useful would be to have a solid editor program that's designed for it. Particularly because it's a mod, not a lot of people are going to want to learn to code entities and animations that realistically a very small portion of their user base will see. Consider coding a dedicated editor in Java as a parallel project to the mod itself. That would definitely help everyone out.
Thank you for making this mod. I hope that it goes well, and I hope that it's everything we all dream it will be! (Soon I will be able to simplify the darned over-designed horses. Sooooooon. Muhahah!)
I would love for the entity model system to be biome sensitive both "on spawn" and "on presence". I would use "on spawn" to assign a stripey texture for horses spawned in Savanna. The "on presence" I would want for environmental effects like icing in frozen biomes, mud in swamp biomes.
Thank you for listening
Rollback Post to RevisionRollBack
(koo-star-neek) The real numbers are countable and I CAN prove it. Cantor was wrong!
I would love for the entity model system to be biome sensitive both "on spawn" and "on presence". I would use "on spawn" to assign a stripey texture for horses spawned in Savanna. The "on presence" I would want for environmental effects like icing in frozen biomes, mud in swamp biomes.
Thank you for listening
Oooh. Hadn't considered that. So basically having the biome-specific skins from Random Mobs be added as part of this then? With some additions for being able to swap or add on the fly. That would be a lot of work, but would be amazing for any pack that could pull it off!
Actually, this brings to mind another suggestion: The ability to use texture animations for entity animations. For example, instea of having the Ghast pop back and forth between to frames I'd love to be able to use an animation strip that starts x frames before the fireball event and runs once rather than looping on its own. Likewise the ability to define a singe face to animate so that people could do blinking animations without resorting to moving geometry or having to have MCPatcher/Optifine installed would be pretty keen.
A bit of this does kind of step on the toes of other mods so I can see if you wouldn't want to do it. Still, it would be quite nice particularly if it were an easier system to use.
1. Simplicity. I DON'T GET IT. Is that a very early example? Seriously, how is the texture being defined? I would really prefer something that mimicked how vanilla models already worked with added support for bone/joints and animations. And y'know, without extremely heavy restrictions on rotations (it's extremely limiting what you can make for item models, let alone entities). (although a mod removing rotation restriction or even allowing element combination to create stuff like this or this would be really nice)
2. Texture atlases. I would like for mob atlases to no longer be needed, instead we could make our own atlases (for arms or heads as a good example) and then have them stitched onto an atlas (or multiple atlases). The big perk here is that if you wanted to, you could do each face as a perfect square texture (where applicable) and this texture could be animated (goes towards what Alvoria was saying about blinking animations)... this would also mean that mobs could have different resolution textures for different faces.
3. Multi-version support. I don't want to get stuck on forge, needing to wait on mods to update after the API updated ... that heavily defeats the point of using it in the first place. It's very early on and there's no documentation but I hope you could use Meddle, a mod loader/API that has dynamic mapping that need to be updated but not necessarily mods, which allows mods even on snapshots.
4. Early, 'stable' rolling releases. A large amounts of models can be done so far without animations or bone if the work is put into it... please consider giving us a version that allows models for minecarts+signs+worn armor.... as well as static inheriting of entity models to items (like giving boat+minecarts+signs+armor or even mob eggs the model of what they represent). After that, chests are one of the basic things that still needs fixing, that's fairly simple compared to something like skeletons. I think it'd be fair to see a new release once you have major functionality in certain areas completed... then you can get feedback on it. Although this would be more spaced out and deliberate than Minecraft's snapshots are.
5. Spawn/despawn/death animations. Did you forget about these? This should be a global thing with mesh/display settings, although you should be able to define it per-mob as well. I'd like to make mobs grow out of the ground (and fade from black) and the opposite when they despawn. Although I might want endermen just to fade in from completely transparent when they spawn. People will probably want to make animations where Zombies crawl out of the ground, but it'd be funny if they just easily floated out of it too, haha.
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
1. Simplicity. I DON'T GET IT. Is that a very early example? Seriously, how is the texture being defined? I would really prefer something that mimicked how vanilla models already worked with added support for bone/joints and animations. And y'know, without extremely heavy restrictions on rotations (it's extremely limiting what you can make for item models, let alone entities). (although a mod removing rotation restriction or even allowing element combination to create stuff like this or this would be really nice)
2. Texture atlases. I would like for mob atlases to no longer be needed, instead we could make our own atlases (for arms or heads as a good example) and then have them stitched onto an atlas (or multiple atlases). The big perk here is that if you wanted to, you could do each face as a perfect square texture (where applicable) and this texture could be animated (goes towards what Alvoria was saying about blinking animations)... this would also mean that mobs could have different resolution textures for different faces.
3. Multi-version support. I don't want to get stuck on forge, needing to wait on mods to update after the API updated ... that heavily defeats the point of using it in the first place. It's very early on and there's no documentation but I hope you could use Meddle, a mod loader/API that has dynamic mapping that need to be updated but not necessarily mods, which allows mods even on snapshots.
4. Early, 'stable' rolling releases. A large amounts of models can be done so far without animations or bone if the work is put into it... please consider giving us a version that allows models for minecarts+signs+worn armor.... as well as static inheriting of entity models to items (like giving boat+minecarts+signs+armor or even mob eggs the model of what they represent). After that, chests are one of the basic things that still needs fixing, that's fairly simple compared to something like skeletons. I think it'd be fair to see a new release once you have major functionality in certain areas completed... then you can get feedback on it. Although this would be more spaced out and deliberate than Minecraft's snapshots are.
5. Spawn/despawn/death animations. Did you forget about these? This should be a global thing with mesh/display settings, although you should be able to define it per-mob as well. I'd like to make mobs grow out of the ground (and fade from black) and the opposite when they despawn. Although I might want endermen just to fade in from completely transparent when they spawn. People will probably want to make animations where Zombies crawl out of the ground, but it'd be funny if they just easily floated out of it too, haha.
1) Yes, this is an early example, and I did base it on vanilla block models, with some modifications to work better with the present entity code (if you were looking at the "size/offset" business, that's how the code does it, but I'll probably change it to the "from/to" that blocks have). Vanilla models are great, but they have their downsides when applied to entities, namely, the lack of separation between the model and the texture and the overly restrictive "parent" relationship with the model files. The parenting problem is solved with unrestricted importing of individual elements, and the textures will be defined per entity in the equivalent of blockstate files (entitystate files?). I don't plan on having any restrictions on rotations whatsoever, but neither do I plan to support non-cuboid elements (mainly because the code doesn't support non-cuboid elements without manually setting the GL matrix).
2) Mob textures are coded to a single atlas by design -- it's not something I can change without a coremod. What I can change is the dimensions of the atlas and the position of the elements. It's probably perfectly possible to do entity texture animations exactly like vanilla block animations, MCMETA and all.
3) The current state of this mod has no dependency on Forge at all. Using Meddle's mappings should not be a problem unless it hides the necessary behavior.
4) This is like #3. There is no release yet because it's not connected to Minecraft yet. Certainly I can release a preliminary model-only version after that's finished. Though tile entities use a really hacky way to hijack the entity model system. For entity items I may have to intercept the "builtin/entity" property and allow users to specify a custom property in addition pointing to the actual entity model file.
5) Yes, I did forget about those, mainly because they do not exist in vanilla. To do those, I'll have to override the default death animation, which should be pretty straightforward. I'm not sure if I can detect spawning, though. Fancy GL tricks like fading are most likely outside the scope of this mod. Al well, the only way I have found to do translations is to manually translate the GL matrix, which is doable, but I'd prefer another way.
For entity items I may have to intercept the "builtin/entity" property and allow users to specify a custom property in addition pointing to the actual entity model file.
A pointer for a custom model might not even be needed. All of the default models inheriting from builtin/entity use a hardcoded value... and there certainly isn't much ambiguity here considering most of those would just be using the same model as their entity form. If you wanted any other model you could just inherit or specify it directly especially if the entity models were somewhat compatible with the rest of the models.
The only problem I can see coming up would be mob spawn eggs... specifically because each one would need to be a different mob that would require different display settings. I suppose predicates with the display settings in them to override specific settings for each mob egg would be really handy here.
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
Here's a very early version so you can play around with the model system. Most entities (mobs and projectiles) use rather complex rotation, and tile entities (like chests and banners) render completely differently from regular entities, so only the boat is modifiable as of now. The model tags are like their block model counterparts:
Entity models -- Block models
from -- from
to -- to
texcoords -- uv (only two coords, the upper-left corner of the "unused space" around the net)
rotpoint -- rotation origin
rotation -- rotation (supports multiple axes)
It requires Forge for 1.8.9, as Meddle doesn't have mappings or hooks for entity rendering yet. You can get it here.
Imports, model elements, and random textures are functional (but textures suffer from the radnomobs multiplayer problem). If the textures look garbled, reloading the resources may fix it.
That may be a little difficult, as entities are not persistent on the client (even their UUIDs change). I have an idea though.
edit: And that idea doesn't work. To do persistent random entities I'll probably have to modify the server-side, which won't work for multiplayer (and I don't want to modify the server anyway).
Note: I posted this in Resource Pack Discussion because this thread is for resource pack artists, and what I'm doing has the most relevancy to them, not modders.
I'm developing a custom entity model system.
As you will know, entity models were hinted for 1.9, then (most likely) scrapped. So, I have taken it upon myself to create a working customizable entity model system as a mod. This topic is for you to post what you want in entity models, in order that it be the most relevant to the resource pack community. But first, here's what I have so far:
Entity JSON Files:
These JSON model files will contain model element definitions and animation declarations. A typical model file might look like this.
Here's the breakdown:
Entity Animation (ENIM) Files:
These are where the entity animations are defined. A typical animation file might look like this.
These are the commands so far.
So, now that you've read on what I have so far, do you see anything missing (other than the lack of texture definitions)? Anything that's not needed? Post it below. For the programmatically inclined, the code behind this is on the GitHub repository.
Putting the CENDENT back in transcendent!
There are a few things that I'd like to see (that may or may not be possible) in regards to animations.
The first one would be to define animation loops based on a pretty traditional keyframe system that the game interpolates in based on the usual types of curves (spline, ease in, ease out, stepped (also known as clamped), etc.) This would make the process more like "@ frame 1 spline to element rotation x=0.0; @ frame 5 ease-in to element rotation x=45. & ease-in to element rotation y=5.0; etc.". You'll have to figure out how to make that sound json-y but it makes more sense to define keyframes and curves. If you need a practical freeware example of this system, look up how Synfig does animation curves. It's pretty easy to figure out after watching a couple of tutorials.
Another thing would be to define an animation offset from an action. Take for example the zombie attack animation currently in the game. It starts the animation to attack the moment it hits rather than hitting at the logical end or middle point of the animation. Being able to say "start this loop 5 frames before event" would be extremely useful and make combat MUCH more intuitive with certain mobs. Not sure how possible that is, but it's a thing that should exist.
Ultimately I think that the thing that would make this system the most useful would be to have a solid editor program that's designed for it. Particularly because it's a mod, not a lot of people are going to want to learn to code entities and animations that realistically a very small portion of their user base will see. Consider coding a dedicated editor in Java as a parallel project to the mod itself. That would definitely help everyone out.
Thank you for making this mod. I hope that it goes well, and I hope that it's everything we all dream it will be! (Soon I will be able to simplify the darned over-designed horses. Sooooooon. Muhahah!)
Hi Kwerti,
I am glad you are taking on this project.
I would love for the entity model system to be biome sensitive both "on spawn" and "on presence". I would use "on spawn" to assign a stripey texture for horses spawned in Savanna. The "on presence" I would want for environmental effects like icing in frozen biomes, mud in swamp biomes.
Thank you for listening
Oooh. Hadn't considered that. So basically having the biome-specific skins from Random Mobs be added as part of this then? With some additions for being able to swap or add on the fly. That would be a lot of work, but would be amazing for any pack that could pull it off!
Actually, this brings to mind another suggestion: The ability to use texture animations for entity animations. For example, instea of having the Ghast pop back and forth between to frames I'd love to be able to use an animation strip that starts x frames before the fireball event and runs once rather than looping on its own. Likewise the ability to define a singe face to animate so that people could do blinking animations without resorting to moving geometry or having to have MCPatcher/Optifine installed would be pretty keen.
A bit of this does kind of step on the toes of other mods so I can see if you wouldn't want to do it. Still, it would be quite nice particularly if it were an easier system to use.
1. Simplicity. I DON'T GET IT. Is that a very early example? Seriously, how is the texture being defined? I would really prefer something that mimicked how vanilla models already worked with added support for bone/joints and animations. And y'know, without extremely heavy restrictions on rotations (it's extremely limiting what you can make for item models, let alone entities). (although a mod removing rotation restriction or even allowing element combination to create stuff like this or this would be really nice)
2. Texture atlases. I would like for mob atlases to no longer be needed, instead we could make our own atlases (for arms or heads as a good example) and then have them stitched onto an atlas (or multiple atlases). The big perk here is that if you wanted to, you could do each face as a perfect square texture (where applicable) and this texture could be animated (goes towards what Alvoria was saying about blinking animations)... this would also mean that mobs could have different resolution textures for different faces.
3. Multi-version support. I don't want to get stuck on forge, needing to wait on mods to update after the API updated ... that heavily defeats the point of using it in the first place. It's very early on and there's no documentation but I hope you could use Meddle, a mod loader/API that has dynamic mapping that need to be updated but not necessarily mods, which allows mods even on snapshots.
4. Early, 'stable' rolling releases. A large amounts of models can be done so far without animations or bone if the work is put into it... please consider giving us a version that allows models for minecarts+signs+worn armor.... as well as static inheriting of entity models to items (like giving boat+minecarts+signs+armor or even mob eggs the model of what they represent). After that, chests are one of the basic things that still needs fixing, that's fairly simple compared to something like skeletons. I think it'd be fair to see a new release once you have major functionality in certain areas completed... then you can get feedback on it. Although this would be more spaced out and deliberate than Minecraft's snapshots are.
5. Spawn/despawn/death animations. Did you forget about these? This should be a global thing with mesh/display settings, although you should be able to define it per-mob as well. I'd like to make mobs grow out of the ground (and fade from black) and the opposite when they despawn. Although I might want endermen just to fade in from completely transparent when they spawn. People will probably want to make animations where Zombies crawl out of the ground, but it'd be funny if they just easily floated out of it too, haha.
"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
1) Yes, this is an early example, and I did base it on vanilla block models, with some modifications to work better with the present entity code (if you were looking at the "size/offset" business, that's how the code does it, but I'll probably change it to the "from/to" that blocks have). Vanilla models are great, but they have their downsides when applied to entities, namely, the lack of separation between the model and the texture and the overly restrictive "parent" relationship with the model files. The parenting problem is solved with unrestricted importing of individual elements, and the textures will be defined per entity in the equivalent of blockstate files (entitystate files?). I don't plan on having any restrictions on rotations whatsoever, but neither do I plan to support non-cuboid elements (mainly because the code doesn't support non-cuboid elements without manually setting the GL matrix).
2) Mob textures are coded to a single atlas by design -- it's not something I can change without a coremod. What I can change is the dimensions of the atlas and the position of the elements. It's probably perfectly possible to do entity texture animations exactly like vanilla block animations, MCMETA and all.
3) The current state of this mod has no dependency on Forge at all. Using Meddle's mappings should not be a problem unless it hides the necessary behavior.
4) This is like #3. There is no release yet because it's not connected to Minecraft yet. Certainly I can release a preliminary model-only version after that's finished. Though tile entities use a really hacky way to hijack the entity model system. For entity items I may have to intercept the "builtin/entity" property and allow users to specify a custom property in addition pointing to the actual entity model file.
5) Yes, I did forget about those, mainly because they do not exist in vanilla. To do those, I'll have to override the default death animation, which should be pretty straightforward. I'm not sure if I can detect spawning, though. Fancy GL tricks like fading are most likely outside the scope of this mod. Al well, the only way I have found to do translations is to manually translate the GL matrix, which is doable, but I'd prefer another way.
Putting the CENDENT back in transcendent!
A pointer for a custom model might not even be needed. All of the default models inheriting from builtin/entity use a hardcoded value... and there certainly isn't much ambiguity here considering most of those would just be using the same model as their entity form. If you wanted any other model you could just inherit or specify it directly especially if the entity models were somewhat compatible with the rest of the models.
The only problem I can see coming up would be mob spawn eggs... specifically because each one would need to be a different mob that would require different display settings. I suppose predicates with the display settings in them to override specific settings for each mob egg would be really handy here.
"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
Here's a very early version so you can play around with the model system. Most entities (mobs and projectiles) use rather complex rotation, and tile entities (like chests and banners) render completely differently from regular entities, so only the boat is modifiable as of now. The model tags are like their block model counterparts:
It requires Forge for 1.8.9, as Meddle doesn't have mappings or hooks for entity rendering yet. You can get it here.
Imports, model elements, and random textures are functional (but textures suffer from the radnomobs multiplayer problem). If the textures look garbled, reloading the resources may fix it.
Putting the CENDENT back in transcendent!
Random mob skins that persist over different logins.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
Yes please!
That may be a little difficult, as entities are not persistent on the client (even their UUIDs change). I have an idea though.
edit: And that idea doesn't work. To do persistent random entities I'll probably have to modify the server-side, which won't work for multiplayer (and I don't want to modify the server anyway).
Putting the CENDENT back in transcendent!
This is one huge sign. Nothing a little scaling won't fix, though.
You'll be able to do scaling per-element and as a model, as well as control rotation along all three axes.
Putting the CENDENT back in transcendent!