Link to my comment where this is described in detail: d04ce46#commitcomment-64690478

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I'm pretty sure the spawning of the particles is what causes the performance drop. If you can figure out how to make it multithreaded then that should solve that issue.

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I'm pretty sure the spawning of the particles is what causes the performance drop. If you can figure out how to make it multithreaded then that should solve that issue.

I had the idea of setting an entity to the particle, and having the particle follow the entity. It would work, IF there was a way to set which entity it's following.
I have no clue how to do entity model stuff, and my only experience with quaternions has been a pain- idk if I can do this, but feel free to start on the Firefly model up until the quaternion part and I'll see what I can do

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I'm pretty sure the spawning of the particles is what causes the performance drop. If you can figure out how to make it multithreaded then that should solve that issue.

I had the idea of setting an entity to the particle, and having the particle follow the entity. It would work, IF there was a way to set which entity it's following. I have no clue how to do entity model stuff, and my only experience with quaternions has been a pain- idk if I can do this, but feel free to start on the Firefly model up until the quaternion part and I'll see what I can do

it actually doesn't involve a model at all. the quaternion stuff is entirely done in the renderer

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I'm pretty sure the spawning of the particles is what causes the performance drop. If you can figure out how to make it multithreaded then that should solve that issue.

I had the idea of setting an entity to the particle, and having the particle follow the entity. It would work, IF there was a way to set which entity it's following. I have no clue how to do entity model stuff, and my only experience with quaternions has been a pain- idk if I can do this, but feel free to start on the Firefly model up until the quaternion part and I'll see what I can do

Also I don't think making particle spawning multithreaded is actually going to do anything, because regardless of what you do, I'm pretty sure Minecraft needs any changes to the world to be only on ONE thread.
The only reason my Catalyst Threader works is because Mojang has a method to send the Main Thread an explanation of what to do, (in this instance, only setting the blocks/blockstates,) but with particles, the method to create them would need to be sent. Therefore it wouldn't do much, and instead would probably make performance worse.
The Catalyst Threader's performance is better than non-threaded only because it lessens the load on the Main Thread by moving all the complex and looping calculations off to multiple other threads, but the performance drop of changing the blocks in the world is still present. May also be worth noting that I used thread.join();, which again, only works for Sculk Spreading- with particles, that would mean there'd be lots of visual gaps where the fireflies could possibly be invisible.

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I'm pretty sure the spawning of the particles is what causes the performance drop. If you can figure out how to make it multithreaded then that should solve that issue.

I had the idea of setting an entity to the particle, and having the particle follow the entity. It would work, IF there was a way to set which entity it's following. I have no clue how to do entity model stuff, and my only experience with quaternions has been a pain- idk if I can do this, but feel free to start on the Firefly model up until the quaternion part and I'll see what I can do

it actually doesn't involve a model at all. the quaternion stuff is entirely done in the renderer

oh
I don't know how to set that stuff up, so would you be able to get a simple and basic one set up for Fireflies? Thanks in advance if you get to

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I'm pretty sure the spawning of the particles is what causes the performance drop. If you can figure out how to make it multithreaded then that should solve that issue.

I had the idea of setting an entity to the particle, and having the particle follow the entity. It would work, IF there was a way to set which entity it's following. I have no clue how to do entity model stuff, and my only experience with quaternions has been a pain- idk if I can do this, but feel free to start on the Firefly model up until the quaternion part and I'll see what I can do

Also I don't think making particle spawning multithreaded is actually going to do anything, because regardless of what you do, I'm pretty sure Minecraft needs any changes to the world to be only on ONE thread. The only reason my Catalyst Threader works is because Mojang has a method to send the Main Thread an explanation of what to do, (in this instance, only setting the blocks/blockstates,) but with particles, the method to create them would need to be sent. Therefore it wouldn't do much, and instead would probably make performance worse. The Catalyst Threader's performance is better than non-threaded only because it lessens the load on the Main Thread by moving all the complex and looping calculations off to multiple other threads, but the performance drop of changing the blocks in the world is still present. May also be worth noting that I used thread.join();, which again, only works for Sculk Spreading- with particles, that would mean there'd be lots of visual gaps where the fireflies could possibly be invisible.

ah.. in that case we're probably gonna have to use quaternions. if you need help, feel free to ask @magistermaks about it, since they're the one who directed us to reference their code. we're seeing if we can invite them so you can talk directly

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I'm pretty sure the spawning of the particles is what causes the performance drop. If you can figure out how to make it multithreaded then that should solve that issue.

I had the idea of setting an entity to the particle, and having the particle follow the entity. It would work, IF there was a way to set which entity it's following. I have no clue how to do entity model stuff, and my only experience with quaternions has been a pain- idk if I can do this, but feel free to start on the Firefly model up until the quaternion part and I'll see what I can do

Also I don't think making particle spawning multithreaded is actually going to do anything, because regardless of what you do, I'm pretty sure Minecraft needs any changes to the world to be only on ONE thread. The only reason my Catalyst Threader works is because Mojang has a method to send the Main Thread an explanation of what to do, (in this instance, only setting the blocks/blockstates,) but with particles, the method to create them would need to be sent. Therefore it wouldn't do much, and instead would probably make performance worse. The Catalyst Threader's performance is better than non-threaded only because it lessens the load on the Main Thread by moving all the complex and looping calculations off to multiple other threads, but the performance drop of changing the blocks in the world is still present. May also be worth noting that I used thread.join();, which again, only works for Sculk Spreading- with particles, that would mean there'd be lots of visual gaps where the fireflies could possibly be invisible.

ah.. in that case we're probably gonna have to use quaternions. if you need help, feel free to ask @magistermaks about it, since they're the one who directed us to reference their code. we're seeing if we can invite them so you can talk directly

I tested it on my PC, and particles have no effect on client-side performance- I'm 99% certain it's their pathfinding. I killed all the fireflies (and I removed their particle prior,) and behold, the performance got SIGNIFICANTLY better. Using the Alt+F3 menu, the lag is only server-side. Also, I don't think there's a way to get the CAMERA from the entity renderer, only the ENTITY that has the camera.

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I'm pretty sure the spawning of the particles is what causes the performance drop. If you can figure out how to make it multithreaded then that should solve that issue.

I had the idea of setting an entity to the particle, and having the particle follow the entity. It would work, IF there was a way to set which entity it's following. I have no clue how to do entity model stuff, and my only experience with quaternions has been a pain- idk if I can do this, but feel free to start on the Firefly model up until the quaternion part and I'll see what I can do

Also I don't think making particle spawning multithreaded is actually going to do anything, because regardless of what you do, I'm pretty sure Minecraft needs any changes to the world to be only on ONE thread. The only reason my Catalyst Threader works is because Mojang has a method to send the Main Thread an explanation of what to do, (in this instance, only setting the blocks/blockstates,) but with particles, the method to create them would need to be sent. Therefore it wouldn't do much, and instead would probably make performance worse. The Catalyst Threader's performance is better than non-threaded only because it lessens the load on the Main Thread by moving all the complex and looping calculations off to multiple other threads, but the performance drop of changing the blocks in the world is still present. May also be worth noting that I used thread.join();, which again, only works for Sculk Spreading- with particles, that would mean there'd be lots of visual gaps where the fireflies could possibly be invisible.

ah.. in that case we're probably gonna have to use quaternions. if you need help, feel free to ask @magistermaks about it, since they're the one who directed us to reference their code. we're seeing if we can invite them so you can talk directly

I tested it on my PC, and particles have no effect on client-side performance- I'm 99% certain it's their pathfinding. I killed all the fireflies (and I removed their particle,) and behold, the performance got SIGNIFICANTLY better. Using the Alt+F3 menu, the lag is only server-side. Also, I don't think there's a way to get the CAMERA from the entity renderer, only the ENTITY that has the camera.

hm, maybe. and yeah, have a look at the stuff i linked earlier, it should have info about the camera

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I'm pretty sure the spawning of the particles is what causes the performance drop. If you can figure out how to make it multithreaded then that should solve that issue.

I had the idea of setting an entity to the particle, and having the particle follow the entity. It would work, IF there was a way to set which entity it's following. I have no clue how to do entity model stuff, and my only experience with quaternions has been a pain- idk if I can do this, but feel free to start on the Firefly model up until the quaternion part and I'll see what I can do

Also I don't think making particle spawning multithreaded is actually going to do anything, because regardless of what you do, I'm pretty sure Minecraft needs any changes to the world to be only on ONE thread. The only reason my Catalyst Threader works is because Mojang has a method to send the Main Thread an explanation of what to do, (in this instance, only setting the blocks/blockstates,) but with particles, the method to create them would need to be sent. Therefore it wouldn't do much, and instead would probably make performance worse. The Catalyst Threader's performance is better than non-threaded only because it lessens the load on the Main Thread by moving all the complex and looping calculations off to multiple other threads, but the performance drop of changing the blocks in the world is still present. May also be worth noting that I used thread.join();, which again, only works for Sculk Spreading- with particles, that would mean there'd be lots of visual gaps where the fireflies could possibly be invisible.

ah.. in that case we're probably gonna have to use quaternions. if you need help, feel free to ask @magistermaks about it, since they're the one who directed us to reference their code. we're seeing if we can invite them so you can talk directly

I tested it on my PC, and particles have no effect on client-side performance- I'm 99% certain it's their pathfinding. I killed all the fireflies (and I removed their particle,) and behold, the performance got SIGNIFICANTLY better. Using the Alt+F3 menu, the lag is only server-side. Also, I don't think there's a way to get the CAMERA from the entity renderer, only the ENTITY that has the camera.

hm, maybe. and yeah, have a look at the stuff i linked earlier, it should have info about the camera

I did, and that's why I said there's no way to actually get the camera- the provided code simply doesn't let you get the camera itself, and the camera parameter is absent from the render() method as well
Honestly I think the best idea is to stick with what we have (unless someone can find a way to render fireflies like particles) and work on server-side performance

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I'm pretty sure the spawning of the particles is what causes the performance drop. If you can figure out how to make it multithreaded then that should solve that issue.

I had the idea of setting an entity to the particle, and having the particle follow the entity. It would work, IF there was a way to set which entity it's following. I have no clue how to do entity model stuff, and my only experience with quaternions has been a pain- idk if I can do this, but feel free to start on the Firefly model up until the quaternion part and I'll see what I can do

Also I don't think making particle spawning multithreaded is actually going to do anything, because regardless of what you do, I'm pretty sure Minecraft needs any changes to the world to be only on ONE thread. The only reason my Catalyst Threader works is because Mojang has a method to send the Main Thread an explanation of what to do, (in this instance, only setting the blocks/blockstates,) but with particles, the method to create them would need to be sent. Therefore it wouldn't do much, and instead would probably make performance worse. The Catalyst Threader's performance is better than non-threaded only because it lessens the load on the Main Thread by moving all the complex and looping calculations off to multiple other threads, but the performance drop of changing the blocks in the world is still present. May also be worth noting that I used thread.join();, which again, only works for Sculk Spreading- with particles, that would mean there'd be lots of visual gaps where the fireflies could possibly be invisible.

ah.. in that case we're probably gonna have to use quaternions. if you need help, feel free to ask @magistermaks about it, since they're the one who directed us to reference their code. we're seeing if we can invite them so you can talk directly

I tested it on my PC, and particles have no effect on client-side performance- I'm 99% certain it's their pathfinding. I killed all the fireflies (and I removed their particle,) and behold, the performance got SIGNIFICANTLY better. Using the Alt+F3 menu, the lag is only server-side. Also, I don't think there's a way to get the CAMERA from the entity renderer, only the ENTITY that has the camera.

hm, maybe. and yeah, have a look at the stuff i linked earlier, it should have info about the camera

I did, and that's why I said there's no way to actually get the camera- the provided code simply doesn't let you get the camera itself, and the camera parameter is absent from the render() method as well Honestly I think the best idea is to stick with what we have (unless someone can find a way to render fireflies like particles) and work on server-side performance

WAIT. Just found this: MinecraftClient.getInstance().gameRenderer.getCamera();

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I'm pretty sure the spawning of the particles is what causes the performance drop. If you can figure out how to make it multithreaded then that should solve that issue.

I had the idea of setting an entity to the particle, and having the particle follow the entity. It would work, IF there was a way to set which entity it's following. I have no clue how to do entity model stuff, and my only experience with quaternions has been a pain- idk if I can do this, but feel free to start on the Firefly model up until the quaternion part and I'll see what I can do

Also I don't think making particle spawning multithreaded is actually going to do anything, because regardless of what you do, I'm pretty sure Minecraft needs any changes to the world to be only on ONE thread. The only reason my Catalyst Threader works is because Mojang has a method to send the Main Thread an explanation of what to do, (in this instance, only setting the blocks/blockstates,) but with particles, the method to create them would need to be sent. Therefore it wouldn't do much, and instead would probably make performance worse. The Catalyst Threader's performance is better than non-threaded only because it lessens the load on the Main Thread by moving all the complex and looping calculations off to multiple other threads, but the performance drop of changing the blocks in the world is still present. May also be worth noting that I used thread.join();, which again, only works for Sculk Spreading- with particles, that would mean there'd be lots of visual gaps where the fireflies could possibly be invisible.

ah.. in that case we're probably gonna have to use quaternions. if you need help, feel free to ask @magistermaks about it, since they're the one who directed us to reference their code. we're seeing if we can invite them so you can talk directly

I tested it on my PC, and particles have no effect on client-side performance- I'm 99% certain it's their pathfinding. I killed all the fireflies (and I removed their particle,) and behold, the performance got SIGNIFICANTLY better. Using the Alt+F3 menu, the lag is only server-side. Also, I don't think there's a way to get the CAMERA from the entity renderer, only the ENTITY that has the camera.

hm, maybe. and yeah, have a look at the stuff i linked earlier, it should have info about the camera

I did, and that's why I said there's no way to actually get the camera- the provided code simply doesn't let you get the camera itself, and the camera parameter is absent from the render() method as well Honestly I think the best idea is to stick with what we have (unless someone can find a way to render fireflies like particles) and work on server-side performance

alright, that's fine. we could have @magistermaks work on that in that case since they're gonna help out a bit

I will say, the current firefly iteration is the best it's ever been, but it's still worryingly quite laggy. I'm a bit afraid of how it'll perform on lower end devices, considering it lags my relatively beefy PC. This could also be solved by threading the particle spawning if possible.

Quick question, since I'm testing Warden pathfinding at the moment. Does removing the particle altogether make it less laggy?

Definitely. In the few commits I pushed testing the firefly without particles, it was way smoother than with

I'm pretty sure the spawning of the particles is what causes the performance drop. If you can figure out how to make it multithreaded then that should solve that issue.

I had the idea of setting an entity to the particle, and having the particle follow the entity. It would work, IF there was a way to set which entity it's following. I have no clue how to do entity model stuff, and my only experience with quaternions has been a pain- idk if I can do this, but feel free to start on the Firefly model up until the quaternion part and I'll see what I can do

Also I don't think making particle spawning multithreaded is actually going to do anything, because regardless of what you do, I'm pretty sure Minecraft needs any changes to the world to be only on ONE thread. The only reason my Catalyst Threader works is because Mojang has a method to send the Main Thread an explanation of what to do, (in this instance, only setting the blocks/blockstates,) but with particles, the method to create them would need to be sent. Therefore it wouldn't do much, and instead would probably make performance worse. The Catalyst Threader's performance is better than non-threaded only because it lessens the load on the Main Thread by moving all the complex and looping calculations off to multiple other threads, but the performance drop of changing the blocks in the world is still present. May also be worth noting that I used thread.join();, which again, only works for Sculk Spreading- with particles, that would mean there'd be lots of visual gaps where the fireflies could possibly be invisible.

ah.. in that case we're probably gonna have to use quaternions. if you need help, feel free to ask @magistermaks about it, since they're the one who directed us to reference their code. we're seeing if we can invite them so you can talk directly

I tested it on my PC, and particles have no effect on client-side performance- I'm 99% certain it's their pathfinding. I killed all the fireflies (and I removed their particle,) and behold, the performance got SIGNIFICANTLY better. Using the Alt+F3 menu, the lag is only server-side. Also, I don't think there's a way to get the CAMERA from the entity renderer, only the ENTITY that has the camera.

hm, maybe. and yeah, have a look at the stuff i linked earlier, it should have info about the camera

I did, and that's why I said there's no way to actually get the camera- the provided code simply doesn't let you get the camera itself, and the camera parameter is absent from the render() method as well Honestly I think the best idea is to stick with what we have (unless someone can find a way to render fireflies like particles) and work on server-side performance

alright, that's fine. we could have @magistermaks work on that in that case since they're gonna help out a bit

NONONO READ MY COMMENT ABOVE I FOUND A METHOD THAT LETS YOU GET THE CAMERA

ok i written this for you guys

public class FireflyRenderer extends EntityRenderer<FireflyEntity> {

	public TestRenderer(EntityRendererFactory.Context ctx) {
		super(ctx);
	}

	private final Identifier TEXTURE = new Identifier("YOUR_MODID:textures/particle/firefly.png");
	private final RenderLayer LAYER = RenderLayer.getEntityCutout(TEXTURE);

	@Override
	public void render(FireflyEntity entity, float f, float g, MatrixStack matrixStack, VertexConsumerProvider vertexConsumerProvider, int i) {
		matrixStack.push();
		matrixStack.scale(1, 1, 1); // you may need to adjust this
		matrixStack.translate(0, 0.3, 0);
		matrixStack.multiply(this.dispatcher.getRotation());
		matrixStack.multiply(Vec3f.POSITIVE_Y.getDegreesQuaternion(180.0F));

		MatrixStack.Entry entry = matrixStack.peek();
		Matrix4f matrix4f = entry.getPositionMatrix();
		Matrix3f matrix3f = entry.getNormalMatrix();
		VertexConsumer vertexConsumer = vertexConsumerProvider.getBuffer(LAYER);

		int j = getLight(i);

		vertex(vertexConsumer, matrix4f, matrix3f, j, 0.0F, 0, 0, 1);
		vertex(vertexConsumer, matrix4f, matrix3f, j, 1.0F, 0, 1, 1);
		vertex(vertexConsumer, matrix4f, matrix3f, j, 1.0F, 1, 1, 0);
		vertex(vertexConsumer, matrix4f, matrix3f, j, 0.0F, 1, 0, 0);

		matrixStack.pop();
		super.render(entity, f, g, matrixStack, vertexConsumerProvider, i);
	}

	private static void vertex(VertexConsumer vertexConsumer, Matrix4f matrix4f, Matrix3f matrix3f, int i, float f, int j, int k, int l) {
		vertexConsumer
				.vertex(matrix4f, f - 0.5F, j - 0.5F, 0.0F)
				.color(255, 255, 255, 255)
				.texture(k, l)
				.overlay(OverlayTexture.DEFAULT_UV)
				.light(i)
				.normal(matrix3f, 0.0F, 1.0F, 0.0F)
				.next();
	}

	/**
	 * @see EntityRenderDispatcher drawFireVertex, for the origin of the '240' magic light value.
	 */
	protected int getLight(int i) {
		// return 'i' if you want the entity to be the same brightness as it's surroundings
		// leave it at 240 to make the entity always full-bright
		return 240;
	}

	@Override
	public Identifier getTexture(FireflyEntity entity) {
		return TEXTURE;
	}

}

register it like this:

EntityRendererRegistry.register(YOUR_ENTITY_TYPE, FireflyRenderer::new);

that should work on 1.18, but it's untested so if something breaks let me know i can help

You will also need to manually load the texture i use this method for this: (it uses super outdated fabric apis but still works)

Identifier id = new Identifier("YOUR_MODID:particle/firefly");
ClientSpriteRegistryCallback.event(SpriteAtlasTexture.PARTICLE_ATLAS_TEXTURE).register(((texture, registry) -> registry.register( id )));

ofc client side

You will also need to manually load the texture i use this method for this: (it uses super outdated fabric apis but still works)

Identifier id = new Identifier("YOUR_MODID:particle/firefly");
ClientSpriteRegistryCallback.event(SpriteAtlasTexture.PARTICLE_ATLAS_TEXTURE).register(((texture, registry) -> registry.register( id )));

ofc client side

you're awesome, thank you so much

You will also need to manually load the texture i use this method for this: (it uses super outdated fabric apis but still works)

Identifier id = new Identifier("YOUR_MODID:particle/firefly");
ClientSpriteRegistryCallback.event(SpriteAtlasTexture.PARTICLE_ATLAS_TEXTURE).register(((texture, registry) -> registry.register( id )));

ofc client side

oh, hey, would you happen to know how we can make the warden's soul overlay pulse? that is, it fades in and out between either normal brightness and zero brightness, or full opacity and zero opacity. we've been trying to figure it out but have no clue as to how.
we also know it's possible since mods like sculk worm do it just fine. the issue is that we can't really reference the code legally because it's closed source.

RTICLE_ATLA

YOU ARE A FREAKING LEGEND. THANK YOU, I JUST GOT IT WORKING! (although I think i put the wrong texture for them)
If I may ask, where did you learn all this about rendering? Or Minecraft's rendering, specifically?

RTICLE_ATLA

YOU ARE A FREAKING LEGEND. THANK YOU, I JUST GOT IT WORKING! (although I think i put the wrong texture for them) If I may ask, where did you learn all this about rendering? Or Minecraft's rendering, specifically?

Ooh, two things:

1. They're vanishing once you walk a short distance away from them
2. I don't think the texture part works actually, there's a good chance I'll be able to find a fix on my own though since it's just simple registry stuff on that part

oh, hey, would you happen to know how we can make the warden's soul overlay pulse? that is, it fades in and out between either normal brightness and zero brightness, or full opacity and zero opacity. we've been trying to figure it out but have no clue as to how. we also know it's possible since mods like sculk worm do it just fine. the issue is that we can't really reference the code legally because it's closed source.

how to change the brightness i do not know, that would require some reverse engineering of the magic light values something i never did, but i know how to change the opacity.

the 4th parameter to .color() in vertex() method is alpha ;) You can simply make it go between 0 and 255 over time, one thing though - you will need to change the render layer to one that supports transparency e.g.

private final RenderLayer LAYER = RenderLayer.getEntityTranslucent(TEXTURE);

tip: to get the alpha value to fade between 0 - 255 you can use the entity's age and tickDelta - fraction of time between ticks - to make it smoother (g in my code)

int alpha = Math.sin(entity.age / 20.0f + g) * 255;

RTICLE_ATLA

YOU ARE A FREAKING LEGEND. THANK YOU, I JUST GOT IT WORKING! (although I think i put the wrong texture for them) If I may ask, where did you learn all this about rendering? Or Minecraft's rendering, specifically?

Ooh, two things:

1. They're vanishing once you walk a short distance away from them
2. I don't think the texture part works actually, there's a good chance I'll be able to find a fix on my own though since it's just simple registry stuff on that part
   
   I got textures working!
   Sadly they still vanish when they're four blocks away, I'm not sure if that's anything with the renderer itself or if it's something to do with the entity class

Sadly they still vanish when they're four blocks away, I'm not sure if that's anything with the renderer itself or if it's something to do with the entity class

strange, idk what can be causing that

If I may ask, where did you learn all this about rendering? Or Minecraft's rendering, specifically?

mostly from minecraft's internals and other mods, when you want to do something first try to think of something similar in vanilla, then try copying that if it's not a complete mess. if that fails try looking for mods that add similar stuff. and the general idea about render i have mostly from playing with opengl