Bug / Crash Pinhole inspector throw errors

[Qriva0]

Pinhole inspector uses rope as target instead of base class for rope and rod, so when used with rods it spams console with errors.

[josemendez]

Pinhole inspector uses rope as target instead of base class for rope and rod, so when used with rods it spams console with errors.

Hi!

Pinholes can only be used with ropes, so it should not be possible to add them to a rod. Thanks for reporting this! Will fix it in the next version.

[Qriva0]

Hi!

Pinholes can only be used with ropes, so it should not be possible to add them to a rod. Thanks for reporting this! Will fix it in the next version.

Actually why not? Except that inspector error it seems to work correctly with rods.
If pinholes are not compatible with rods, then I think there is big mistake in documentation here: https://obi.virtualmethodstudio.com/manu...nhole.html

"You can add ObiPinhole components to a ObiRope or ObiRod."

[josemendez]

Actually why not? Except that inspector error it seems to work correctly with rods.
If pinholes are not compatible with rods, then I think there is big mistake in documentation here: https://obi.virtualmethodstudio.com/manu...nhole.html

"You can add ObiPinhole components to a ObiRope or ObiRod."

You're right, they were supposed to be compatible with rods but this got postponed. The reason they're not fully compatible with rods is that rods cannot be torn, so a bit of extra logic needs to be added to the constraint projection to account for this.

Still, the fact they were originally planned for both slipped into the documentation.

If your use case involves using pinholes with rods, will see if I can do a quick fix to support them (even if it's not 100% accurate) and get back to you.

kind regards

[Qriva0]

You're right, they were supposed to be compatible with rods but this got postponed. The reason they're not fully compatible with rods is that rods cannot be torn, so a bit of extra logic needs to be added to the constraint projection to account for this.

Still, the fact they were originally planned for both slipped into the documentation.

If your use case involves using pinholes with rods, will see if I can do a quick fix to support them (even if it's not 100% accurate) and get back to you.

kind regards

It makes sense then!
Currently I consider to use them, but it's not the most critical feature.

Actually one more question - why pinhole requires target to be obi collider, while the field itself is of type transform?

[josemendez]

Actually one more question - why pinhole requires target to be obi collider, while the field itself is of type transform?

Futureproofing, making sure the API is similar to that attachments. In the future we may merge pinholes with attachments, making them a third attachment mode (static, dynamic, sliding).

Attachments support both static and dynamic modes: static mode accepts a transform and doesn't require a ObiCollider, dynamic mode does require one but warns you just like the Pinhole inspector does if your transform doesn't have one. It made sense to make the pinhole API follow a similar convention in order to make sure the amount of changes required in user code in the future are as few as possible.

kind regards,