I've added support for assymetric bows

[florinbaiduc]

[stfnp]

Wow, very cool!

How difficult was it? Did you have to change a lot of things? I have some questions about how you handled the details, but I saw that your fork is on GitHub, so I will check that out first.

[florinbaiduc]

I think that the support for asymmetric bows is the really big new feature, the rest are just nice to have :) . So if you see any issues blocking you from adding that in the mainstream, I'd like to focus my work at solving them. I've not tested with symmetrical bows at all, have you had issues in my fork with them?
PS: yes, there are still many small issues with the simulation - the yumi slow motion looks somewhat strange because indeed the grip is fixed - but we'll need it to rotate both along the Z and the X axis (so in the 3D domain) to actually approximate what's happening.
In case of a yumi, the tsunomi force (khatra or asymmetric pushing against the grip) and the gyroscopic induced rotation on the X axis (around the grip) are somewhat important for the final result and interesting to simulate.
Also, most yumi have composite I beam cores (so perpendicular to the back and belly), some even with asymmetric internal structures, that's also missing.
So there are many issues still left to solve for an accurate simulation of the dynamic phase. But to be honest, my main use case was actually the study of how a yumi's shape style (including various core tillering profiles) impact its efficiency and power, and that's solved, I think, even in the current version. One of my hobbies it is making yumi, so it's helpful to be able to play around with some of the parameters and see how the influence the final shapes.

[stfnp]

The way I see it, we would have to solve the following open questions for including asymmetry in VirtualBow. I don't expect you to solve them all by yourself, but maybe you also have some ideas:

• User Interface: Since symmetric bows are the more common use case, creating and editing them should be about as simple as before. Symmetric bows still work fine in your version, they are just more cumbersome because users would have to define the same limb twice and then keep both limbs in sync when making changes.

  • Solution idea: Maybe the items for the second limb (profile, width, layers), could each have a checkbox called "Symmetric". When this checkbox is selected, they are not editable and greyed out in the model tree. The simulation then assumes those as symmetric. Conversely, if the checkbox is unchecked, the properties can be edited to create an asymmetric bow.

• Performance: I haven't tested it yet, but I assume that an asymmetric bow adds some overhead to the simulation because it has essentially twice as many degrees of freedom. That can't be avoided, but it shouldn't affect the performance of symmetrical bow models. So the simulation should be smart enough to continue simulating only half of the bow, if symmetric, and the full bow only when it is actually asymmetric. (The reason I care about performance, even though the simulation only takes a few seconds, is that I eventually want to include some optimization features in VirtualBow where many simulations are run with varying parameters. And for that use case you can never have enough performance.)

  • Solution idea: This shouldn't be too difficult to do, it would only complicate the simulation code somewhat.

• Grip rotation: Interesting point about multiple rotation axis! Although I feel like this would be a bit too exotic for mainstream VirtualBow. But even just the in-plane rotation would create a new difficulty: VirtualBow also supports bows with risers, where the limbs are attached to a stiff middle section (think of an olympic style recurve bow, for example). In dynamics, the center of gravity and inertia of this middle section will probably have a big effect on how the grip rotates. But since the riser is not modelled directly in VirtualBow, we don't know its mass properties. Of course we could let users specify them, but they probably won't know either...

  • Solution idea: Can it be assumed that the grip, in a well made and tillered bow, does not rotate when the bow is being drawn? I honestly don't know. For most bows I would say probably yes. In that case we could just leave the grip clamped, as it is now, and add the torque it produces as an output. Low or zero torque -> the bow is tillered well and does not want to rotate when drawn. High torque -> the bow is not tillered well, grip would rotate in the real world.

• Motion of the arrow: In a similar way, if the two limbs do not work perfectly in sync, the string will not only accelerate the arrow in the forward direction, but also slightly in the transversal direction. But this is where the modelling of the arrow as a point mass in VirtualBow kinda breaks down. When a real bowstring creates some transversal motion, the arrow will probably flex instead of resisting this motion with its full inertia. But this is what a point mass does.

  • Solution idea: I have no good ideas for this yet. Modelling the arrow as elastic would go too far. Maybe the arrow should stay constrained to the forward direction. The transversal forces created by this constraint could be used to judge how much the arrow wants to go in the transversal direction, similar to the grip rotation...

[florinbaiduc]

Thank you, I basically agree to all your points, and see most of them as issues induced by the asymmetry variant. Let me see how much of these I can solve, especially in making the design and simulation as simple as before, for symmetric bows.

[florinbaiduc]

@stfnp I've added support for symmetrical editing. Please check.

[stfnp]

Haven't really looked at the code yet, but the result looks good to me!

It took me a moment before I realized that the symmetry can be changed under "Settings", but I think it's actually a good place to put this for now (I might move things around a bit anyway when implementing #291). I also like that there are three checkboxes. That way, some properties can stay symmetric while others are asymmetric.

I've realized another point that I missed in my list above: We need to also think about how we present some of the results. Stresses, for example, are only shown for one limb right now.