You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched for duplicate or closed bug reports
I understand that I am supposed to provide my own legitimately obtained copy of the game
Describe the Bug
When assigning a collision primitive to a bone using it's bone index, the collision primitive will only be in the correct position if the base of the bone it's assigned to is located at 0,0,0 worldspace in Blender.
This means effectively, that only 1 bone in an armature can have collision meshes assigned to it.
If you set the primitive to a bone other than a bone at 0,0,0 worldspace, it will offset both the mesh collision location and it's collision sphere from it's typed coordinates, even though they are manually set. Manually balancing out the collision sphere location by typing the coordinates with the offset in mind, does not actually move the collision mesh back.
If you make your collision mesh visible, the visible mesh can be seen in the correct position, with its collision somewhere else separate from the visuals, which is interesting.
It's impossible to correct this without also breaking another one, since only one bone can be at 0,0,0 worldspace at a time.
How To Reproduce
Create an armature at a position other than 0,0,0 worldspace and assign a visual-only mesh to it with Automatic Weights.
Create a cube with collision and don't assign anything to it in Blender. Export GLB file with Custom Properties.
Set up a test actor with primitives and assign a primitive to one of the bone indexes on the armature.
Observe the offset in game (better to make the collision mesh visual as well)
Does this problem occur on original hardware or PCSX2?
Yes, it's unique to OpenGOAL
Expected Behavior
The offset is not minor and means only one bone in an armature can have a collision mesh on it
Environment Information
Using Blender 4.0
Game Version
NTSC 1.0 (black label)
Have you set the game to something other than 60fps?
No
The text was updated successfully, but these errors were encountered:
Acknowledgements
Describe the Bug
When assigning a collision primitive to a bone using it's bone index, the collision primitive will only be in the correct position if the base of the bone it's assigned to is located at 0,0,0 worldspace in Blender.
This means effectively, that only 1 bone in an armature can have collision meshes assigned to it.
If you set the primitive to a bone other than a bone at 0,0,0 worldspace, it will offset both the mesh collision location and it's collision sphere from it's typed coordinates, even though they are manually set. Manually balancing out the collision sphere location by typing the coordinates with the offset in mind, does not actually move the collision mesh back.
If you make your collision mesh visible, the visible mesh can be seen in the correct position, with its collision somewhere else separate from the visuals, which is interesting.
It's impossible to correct this without also breaking another one, since only one bone can be at 0,0,0 worldspace at a time.
How To Reproduce
Create an armature at a position other than 0,0,0 worldspace and assign a visual-only mesh to it with Automatic Weights.
Create a cube with collision and don't assign anything to it in Blender. Export GLB file with Custom Properties.
Set up a test actor with primitives and assign a primitive to one of the bone indexes on the armature.
Observe the offset in game (better to make the collision mesh visual as well)
Does this problem occur on original hardware or PCSX2?
Yes, it's unique to OpenGOAL
Expected Behavior
The offset is not minor and means only one bone in an armature can have a collision mesh on it
Environment Information
Using Blender 4.0
Game Version
NTSC 1.0 (black label)
Have you set the game to something other than
60fps
?No
The text was updated successfully, but these errors were encountered: