Dynamically Changing a Sprite?

[Raggar]

I'm in search for a way to dynamically change a sprite.

Let's say I have a spriteManager with spriteA.png. and a sprite called sprite linked to said manager. I want to change the sprite/spriteManager to spriteB.png. This might happen once every frame, so simply creating a new sprite won't quite cut it. I see the manager has a sprites array as well as a _spriteTexture, but I don't see any function that allows me to change these. Am I missing something that would allow me to do this, or are there issues I should be aware of?

[Christoph]

You could use a sprite sheet instead, so you can change to many different "sprites",  spriteA.png would be cell 1, spriteB.png would be cell 2.

[Raggar]

9 hours ago, Christoph said:

You could use a sprite sheet instead, so you can change to many different "sprites",  spriteA.png would be cell 1, spriteB.png would be cell 2.

I'm already using a sprite-sheet. I just thought it would be stupid to include some animation that might or might not be used. However, I realize now that loading them dynamically might result in added overhead(I think).

I saw an old review I made of the Doom movie some 12 years ago, and started thinking about the old games. I thought it would be fun to create some 2.5D-ish mechanics.

I read that some of the old games use rays to determine which angle the model is viewed from, and then apply the appropriate sprite based on that.

4 red planes make up the front, back and sides.

4 green planes make up the angles in between.

A ray is cast between the sphere in the middle and the main camera of the player. When a plane is hit, you'll know from which angle the player is viewing the model.

Take a look at this example: http://www.babylonjs-playground.com/#G8JR7V#7

Try moving the camera around the monster. The sprite-sheet consists of an animation of 8 angles, while 5 is enough as those can be inversed(they already are, just haven't made a new sheet). This decrease the size, but also decrease the realism a bit.

Here's an example of multiple monsters:

http://www.babylonjs-playground.com/#G8JR7V#9

I'll have to limit the rays to their only monsters, otherwise, as you can see, rays will catch the clipping planes from nearby monsters, and falsely use this data.

 

@Deltakosh

Any idea why Mr. GC is acting crazy in scene #9?

I'm reusing the rays, but I have no knowledge of the internal workings of sprites. When I play a new animation from the sprite-sheet, is the old ones somehow dereferenced and cleared from memory?

If I comment out the manageAnimations function, the load on the GC is drastically reduced, and the draw function takes the load instead. I'm not entirely sure whether or not disabling the rays have any major performance improvements.

 

 

 

[Raggar]

Using fastCheck and invisible meshes seems to boost performance a bit:

http://www.babylonjs-playground.com/#G8JR7V#11

 

[GameMonetize]

Hey, did you fix your issue?

[Raggar]

On 8/21/2017 at 7:55 PM, Deltakosh said:

Hey, did you fix your issue?

I'm not quite sure how I should approach this.

The fastCheck boolean needs to be set to false, otherwise only 4 angles will be used, instead of all 8.

The way sprites work, I think rays are the only way to go, but it seems the rays are pretty expensive when running 1x ray / monster object.

I don't dispose the rays, but they still turn up in the GC. I'm not sure how the internals work, and whether or not this is expected behavior.