if you would like to maintain the absolute distance between cards being 4 at the bottom you can keep the angle equation you used initially and make preliminary transformations to the card geometry prior to making the mesh rotations…
Yes it looks like you’re creating a new mesh for every card, InstancedMesh will give you a lot better performance, one thing to note is that there will always be 3x the amount of cards for the “level” or “row” number so they can be procedurally stacked quite easily eg level 15 will have 15 triads (left, right, bottom) or 45 cards in total, level 16 = 48 cards, level 22 = 66 cards etc…
Do you plan to add physics to the resulting stack?
Yes, I’m thinking of adding physics and some animations.
When we click on the card house, it should fall naturally.
I have no idea how to do it. I think physics can be handled using cannon.js and for animation i guess no external library is needed.
And I feel, it will be hard to implement, since each card need its own physics, animation and interaction with other cards.
I’ve tried to put together a Rapier Physics example from the previous demo (as Rapier is pretty lightweight), however there seems to be a fundamental floor in the instanced body implementation of three’s Rapier Physics as the cards’ rotations are not being preserved…
@Mugen87 would you know the reason why the quaternion property of createBody within createInstancedBody is null in the RapierPhysics implementation? Is this an oversight or is there a technical reason an instances quaternion rotation can’t be derived to be used as the body’s rotation on initialization of physics?
@Mugen87 I managed to patch the Rapier Physics implementation to include quaternion calculations for instances by composing and decomposing a matrix from each instance, i did this in a separate repo but i can make an official PR if it helps…