Offset between the physics and the visual of an entity.

#1
Hello,
I'm having a problem with the use of "parent" system coordinates.
I use a camera as a position reference as well as a simple box which is linked to the camera.
The camera is the parent and the box is the child.
I use the movement nodes "move entity to" and "rotateToEx" by configuring the system coordinates on "parent".
Everything works properly visually. The box moves and is oriented as indicated via the flowgraph with reference to the "parent".
The problem I meet is at the level of physics. Everything is going well visually.
But if I activate "P_Draw_Helpers" I notice that the physics of my box does not rotate on the same references.
The "moves" work correctly. Only the "Rotates" who have the worries.

I also noticed that the problem only appears if I rotate the camera.
-If my camera is at 0.0.0 there is no offset.
-If my camera is at 0.-30.0 There is an offset of 0. + 30.0 on my box (it remains at 0.0.0 (physics only))

To be as clear as possible. The box is supposed to always stay in front of the camera when it is rotating. Visually this is what is happening. But the physics of my box seems to remain at rotation 0.0.0

I want to clarify that my box is both visible mesh and physics. There is no proxy. it is a very simple box with a completely classic "physical" crytek shader.

Anyone know where it can come from and how can I fix it?

Re: Offset between the physics and the visual of an entity.

#4
..."known" doesn't mean "solved" (yet)...the kind of issue which makes things very complicated and almost impossible sometimes; and it's BASIC functionality, not a new, fancy feature; so my request to Crytek was/is this: take care of the basics, and after that dream about new features; without the basics you cannot build a game no matter how astonishing the new developments are !
Adrian Nen
visual artist
https://www.artstation.com/adriannen

Re: Offset between the physics and the visual of an entity.

#5
Hi there,

It appears you can reproduce this issue consistently, this sounds like a prefect candidate for a bug report.
It would be great if you can provide exact reproduction steps on our GitHub issues page, this is where we consolidate and track bugs in the engine directly with our internal teams.

Please make sure to include as much information as possible, and reproduce the problem on the latest engine version.
https://github.com/crytek/cryengine/issues
Uniflare
CRYENGINE Technical Community Manager
Here to help the community and social channels grow and thrive.

My personal belongings;
Beginner Guides | My GitHub | Splash Plugin

Re: Offset between the physics and the visual of an entity.

#6
While trying to reproduce the bug I realized an important detail.
The problem does not appear if I use a basic entity as a parent.
In my case I use a camera as a parent. With a camera as parent physics bug but not with a basic entity.

To reproduce this bug, all you need is a basic entity (primitive box / cube) and a camera.
- Make a link between the cube (child) and the camera (parent).
-Make a mini flowgraph to order a rotation to a given position (RotateEntityToEx) on the cube.
-If you come into play and try, the rotation should work properly both visually and physically. (P_draw_helpers 1 to see the physics)
-However, if we decide to change the angle of the camera to 45 ° and we repeat the test. this time, once the rotation is finished we can see that the physics is shifted.

I would find a time to report this bug on github.

Re: Offset between the physics and the visual of an entity.

#9
I could not reproduce this issue. I also responded in detail on what you may be experiencing on AnswerHub. I will copy the response here.

We do not recommend parenting physicalized objects, especially if they are to be moved dynamically. There are certain caveats to be aware of in doing so:

The physical entity (collision you see with p_draw_helpers) is not parented to the entity, the entity is parented to the physical entity. When the entity is a parented to another entity, this is overridden. This means that the physical entity will still move, but the entity itself will stay locked in its local position relative to the parent entity.

To get around this, you will want to set the physical type to Static, rather than Rigid. This will prevent the physical entity from moving due to collisions or physics. It will be a solid piece of physical geometry that will move in relation to the parent entity.

This however breeds another problem, if the physical entity is moved, depending on how it is moved, collision and other physical calculations are no longer natural. This means collisions can fail and the object can "break through" other physicalized geometry, causing errors in calculations such as objects becoming stuck to each other.

Perhaps you could explain your goal, then there might be a simpler or more robust solution for you.

Here is what I did to try to reproduce the issue:
  1. Create a Blank Project
  2. Open the example level
  3. Create a Camera from the current view (Essentially a basic entity with a Camera Component)
  4. Create a Physicalize Pyramid Object (Basic Entity + Mesh Component + RigidBody Component)
  5. Set the RigidBody Physical Type to Static
  6. Link the Pyramid to the Camera Entity
  7. Create a Flowgraph for each Camera and Pyramid with RotateEntityToEx on Game Start, Same for both. (As shown in attached image).
FG1.PNG
FG1.PNG (23 KiB) Viewed 273 times
Uniflare
CRYENGINE Technical Community Manager
Here to help the community and social channels grow and thrive.

My personal belongings;
Beginner Guides | My GitHub | Splash Plugin

Re: Offset between the physics and the visual of an entity.

#10
Please note that I'm using 5.3 and the problem may have been resolved in newer versions, but here you are the steps to replicate the issue:

1. create 2 basic entities: a box and a cube; the box is the base and the parent, the cube is the top and the child (fig 1 left);
2. create a simple flowgraph where both have a rotation movement which overlaps for a while (fig 1 right);
3. execute the fg; visually everything seems fine (fig 2 left), but when you hit F10 you'll notice that the physics of the top cube isn't in the right place (the parent rotation is not there); also, this happens right after the rotation movement has stopped, during the movement itself the physics moves well; also, if there's no overlapping for the 2 rotations everything is just fine.

parent_child_rotissue-1.jpg
parent_child_rotissue-1.jpg (1.05 MiB) Viewed 76 times
parent_child_rotissue-2.jpg
parent_child_rotissue-2.jpg (1.28 MiB) Viewed 76 times
Adrian Nen
visual artist
https://www.artstation.com/adriannen

Who is online

Users browsing this forum: No registered users and 0 guests