Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draw node animation for items #15930

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open

Conversation

cx384
Copy link
Contributor

@cx384 cx384 commented Mar 22, 2025

(It does not work for the wield mesh without flickering) solved

Click me (Videos)
mtg.mp4
dev_animated.mp4

To do

Ready for Review.

Maybe some refactoring.

How to test

Enable the inventory_items_animations setting.
Start devtest and get some Animated Test Nodes.

@Zughy Zughy added @ Client / Audiovisuals Feature ✨ PRs that add or enhance a feature Roadmap: supported by core dev PR not adhering to the roadmap, yet some core dev decided to take care of it labels Mar 22, 2025
@DragonWrangler1
Copy link
Contributor

DragonWrangler1 commented Mar 22, 2025

So glad to see this finally getting implemented (even if only in part)

@sfan5 sfan5 changed the title Drawn node animation for items Draw node animation for items Mar 23, 2025
@DragonWrangler1
Copy link
Contributor

(It does not work for the wield mesh. I tried to implement it, but using the material type of the WieldMeshSceneNode caused some flickering, with other material types it looks fine, but the lighting does not update. So I leave this to someone else, since I'm not very familiar with the code, it probably involves some shader programming.)

Click me (Videos)

To do

Ready for Review.

Maybe some refactoring.

How to test

Enable the inventory_items_animations setting. Start devtest and get some Animated Test Nodes.

Disclaimer: I haven’t tested yet.

I see it’ behind the animated inventory items setting. Which also has the rotating items. Could this be changed to perhaps a new property that can be set per block that allows it to have the animation or not ?

@cx384
Copy link
Contributor Author

cx384 commented Mar 24, 2025

Could this be changed to perhaps a new property that can be set per block that allows it to have the animation or not ?

This will most likely be doable using (animated) mesh inventory images in the future.
(Currently, you can only override it by a flat (non-animated) inventory_image.)

I don't know about the rotating items. You should probably fill out a feature request issue in this regard.

@DragonWrangler1
Copy link
Contributor

DragonWrangler1 commented Mar 24, 2025

Could this be changed to perhaps a new property that can be set per block that allows it to have the animation or not ?

I don't know about the rotating items. You should probably fill out a feature request issue in this regard.

No i'm saying that you put it behind the same setting that has the item rotation.

@appgurueu
Copy link
Contributor

I think making this node-def-controlled is a good idea. Game developers should have fine-granular control over this; I don't see a priori why players should have much control here.

I agree that "reusing" the inventory_items_animations setting doesn't seem like the best idea for the reason DragonWrangler has pointed out already (it puts two somewhat different things, the spinning items and texture animations, behind the same setting).

@cx384
Copy link
Contributor Author

cx384 commented Mar 25, 2025

I think making this node-def-controlled is a good idea. Game developers should have fine-granular control over this; I don't see a priori why players should have much control here.

(I assume by "this" you mean the texture animation and not the rotation.)
As I already wrote, this will most likely be possible in the future by specifying a "mesh inventory image" in the item/node definition to override the mesh and (animated) textures of the inventory image (also see #3551).
Having a separate flag in the node definition which toggles whether the animated tiles of a node are also animated when it gets drawn in the inventory does not make much sense to me, if you can just replace the whole inventory image (mesh and its tiles). But item definitions also contain a color field, even though you can colorize the inventory image by using texture modifiers.
So, if you insist, I will add an animated_in_inventory flag to the node (not item) definition table. (I suspect you want this for the whole node and not for each tile separately as part of the tile animation definition.)
Would you prefer the flag to be true or false by default?

Allowing players to disable animations is beneficial for accessibility. People with vestibular disorder, epilepsy and similar may suffer from animated images, if I'm not wrong. So I guess it is good to have a global setting for this

I agree that "reusing" the inventory_items_animations setting doesn't seem like the best idea for the reason DragonWrangler has pointed out already (it puts two somewhat different things, the spinning items and texture animations, behind the same setting).

What do you suggest? Should it just ignore the inventory_items_animations setting, or should I add an additional disable_item_inventory_image_animations setting?
Personally, I don't care. I thought the inventory_items_animations setting is meant to enable any animation of items in inventories. If this is not the case, maybe it should be renamed to inventory_selected_item_rotation_animation, and maybe we want a rotate_on_selected flag in the item definition. But for those things, someone should open a feature request issue.

I thought it could even be considered a bug that animated nodes are not drawn animated in inventories, but if there is so much to discuss I should have opened an issue first. Note that this PR is closely related to #4758, but it does not solve it.

@@ -404,7 +411,7 @@ void WieldMeshSceneNode::setItem(const ItemStack &item, Client *client, bool che
setExtruded(tsrc->getTextureName(l0.texture_id),
"", wield_scale, tsrc,
l0.animation_frame_count);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note that setExtruded cuts the texture down to its first animation frame, so there's no point remembering animation info in this case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, setExtruded is only used for the wield mesh anyway, where the animation does not take effect (yet).
So I made it only remember the color there, like it was before, but for other draw types, both inventory items and the wield mesh uses createGenericNodeMesh which remembers the animation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed, animation for extruded meshes will be added in a follow up PR.

@cx384
Copy link
Contributor Author

cx384 commented Mar 27, 2025

Thanks for the review.
I hope I fixed everything.

@cx384
Copy link
Contributor Author

cx384 commented Mar 28, 2025

I finally solved the wield mesh flickering problem by updating the lighting and animation at the same time instead of doing it separately.
So wield item animation is now supported, too.

@cx384
Copy link
Contributor Author

cx384 commented Mar 28, 2025

I moved AnimationInfo somewhere else to avoid code duplication, and none of the extruded meshes stores the animation information anymore.

I suppose it would be too much for this PR if I change large parts of the code to make it work for drawtypes that use a flat inventory image that has no tile layer. I will probably fix this in a follow up PR which also adds an API to set the inventory image animation in the item definition table.

@@ -763,6 +761,12 @@ bool MapBlockMesh::animate(bool faraway, float time, int crack,
// Cracks
if (crack != m_last_crack) {
for (auto &crack_material : m_crack_materials) {

// TODO crack on animated tiles does not work
Copy link
Contributor Author

@cx384 cx384 Mar 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it never worked, so I just removed it. (because of the AnimationInfo change)
See #5317

@SmallJoker
Copy link
Member

SmallJoker commented Mar 30, 2025

I like this feature but would prefer to have it only apply to the hovered/selected ItemStack like the existing rotation animation.
(Answer based on the videos; didn't test the PR yet)

@DragonWrangler1
Copy link
Contributor

DragonWrangler1 commented Mar 30, 2025

I like this feature but would prefer to have it only apply to the hovered/selected ItemStack like the existing rotation animation. (Answer based on the videos; didn't test the PR yet)

I can’t say I’m for that. To help with game aesthetics I believe it would be better to define this per item.

@cx384
Copy link
Contributor Author

cx384 commented Mar 30, 2025

I prefer that by default nodes placed in the world and in inventories look the same, including the animation.
Such that you have to set the inventory image (including animation and mesh in the future) in the definition if you want to change it.

In my opinion, it would be better to turn the hovered/selected appearance into another feature, like wield_image, if we want such a feature.
And make it default to the inventory_image or in case it is empty, to the node image (including the animation).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@ Client / Audiovisuals Feature ✨ PRs that add or enhance a feature Roadmap: supported by core dev PR not adhering to the roadmap, yet some core dev decided to take care of it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants