• Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
  • Asset Store
  • Get Unity

UNITY ACCOUNT

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account
  • Blog
  • Forums
  • Answers
  • Evangelists
  • User Groups
  • Beta Program
  • Advisory Panel

Navigation

  • Home
  • Products
  • Solutions
  • Made with Unity
  • Learning
  • Support & Services
  • Community
    • Blog
    • Forums
    • Answers
    • Evangelists
    • User Groups
    • Beta Program
    • Advisory Panel

Unity account

You need a Unity Account to shop in the Online and Asset Stores, participate in the Unity Community and manage your license portfolio. Login Create account

Language

  • Chinese
  • Spanish
  • Japanese
  • Korean
  • Portuguese
  • Ask a question
  • Spaces
    • Default
    • Help Room
    • META
    • Moderators
    • Topics
    • Questions
    • Users
    • Badges
  • Home /
avatar image
0
Question by kzaurckichz · Aug 07, 2015 at 12:10 PM · physicsfixedupdatelocalposition

Using custom physics engine - Is there a better way than setting localPosition

I am using my own Physics system as I needed a double precision physics, but I'm having performance issues with the way Unity deals with it.

It seams like the process is very slow when I have around 6000 objects within a parent object and I move Only the parent object.

I have no rigidbody in the scene.

When I want to move an object using my physics engine, I set the object's localPosition in FixedUpdate().

In the profiler I see that the most CPU is on Transform.INTERNAL_set_localPosition() and it's number of calls match the total number of child objects plus the parent object. And it becomes worst as I have more child objects in the object. Remember I am not moving the child objects here, only the parent, and it does that.

Looks like Unity calculates everything as absolute and when setting an object's position, all it's children are also "moved" even though their localPosition has not changed ?

Is there a way to optimize this ?

Also, I tried with and without the "Static" checkbox for all objects.. doesn't make any difference. What is the difference with or without Static in my case ?

Thank you.

Comment
Add comment · Show 4
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image Dave-Carlile · Aug 07, 2015 at 12:12 PM 0
Share

The position of child objects are always relative to the position of parent objects. When you move the parent, the children also move. 6,000+ children is a lot of objects.

avatar image kzaurckichz · Aug 07, 2015 at 01:11 PM 0
Share

I know that, what I mean is that the child objects don`t really need to "$$anonymous$$ove" in a way that needs any cpu resources, since only the parent moves, then the positions are calculated only for rendering, why need to recalculate all the children's positions when their local position stays the same ? I know Unity works with Absolute positions and velocities for physics, so I am asking if it's possible to disable unity physics so that child objects stay relative at all times and that their positions don't need to be recalculated each time the parent moves.

avatar image kzaurckichz · Aug 07, 2015 at 01:14 PM 0
Share

Anyways, it's something that is 100% doable and actually easier to do with low level OpenGL... Why does unity prevent us from doing it ? Seams like lots of overhead for nothing.. I only want to use Unity for the 3D engine and rendering.

avatar image _dns_ · Aug 07, 2015 at 02:39 PM 0
Share

Hi, are you accessing the local position or other element from the transform during (fixed)update ? I guess Unity uses some kind of "dirty" flags for transform so accessing it somewhere may force it to recompute some position or other elements.

Depending on what you want to do exactly, it might me better for you to manage your 6k objects in another way than using gameobjects. I mean, one manager gameobject can call a function on a list of sub non-gameobject objects that you manage and so replace the logic of (fixed)Update. For the rendering, using the new commandbuffers can be fast as well. If your 6k objects are very simple, you could also use mesh particles and modify their position/rotation each frame.

As for the "static" question: I guess if you have no physics/collision component on the objects, there is no reason that the physics system knows your objects. "Static" is mostly used for static batching & lighting I think.

1 Reply

· Add your reply
  • Sort: 
avatar image
0

Answer by dsmeathers · Aug 07, 2015 at 06:04 PM

Yeah, Unity has to update all of the transforms when you move the parent. At some point you're going to need the positions of the child objects so that calculation is inevitable.

However, its much faster if you add a rigid body to the parent (set it to kinematic, as you'll be controlling the movement with your own phsyics). Then use the rigidbody.MovePosition and rigidbody.MoveRotation to move it about.

Assuming you're only using the child objects for rendering you could avoid the cost completely by getting rid of them and rendering the meshes manually using Graphics.DrawMesh.

Comment
Add comment · Show 2 · Share
10 |3000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users
avatar image kzaurckichz · Aug 07, 2015 at 06:19 PM 0
Share

I can't have a rigidbody on the parent object since I need to use colliders on some child objects to capture raycasts for mouse point and click, and a rigidbody around them will capture the raycast first, and raycastAll is simply too heavy on resources.

avatar image dsmeathers · Aug 07, 2015 at 06:44 PM 0
Share

You don't need to add a collider to the rigid body. If the ray cast hits one of the children then raycasthit.collider will tell you which one it hit. You shouldn't need rigid bodies on the children just to check for ray casts.

Your answer

Hint: You can notify a user about this post by typing @username

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Welcome to Unity Answers

If you’re new to Unity Answers, please check our User Guide to help you navigate through our website and refer to our FAQ for more information.

Before posting, make sure to check out our Knowledge Base for commonly asked Unity questions.

Check our Moderator Guidelines if you’re a new moderator and want to work together in an effort to improve Unity Answers and support our users.

Follow this Question

Answers Answers and Comments

5 People are following this question.

avatar image avatar image avatar image avatar image avatar image

Related Questions

Are rigidbodies only moved in the physics-loop? 1 Answer

Physics + first person camera = jitter? 4 Answers

Game not running properly on slow machines (low fps) 1 Answer

Noticeable difference between full-screen / windowed physics behavior in standalone build 0 Answers

detection raycast too late 2 Answers


Enterprise
Social Q&A

Social
Subscribe on YouTube social-youtube Follow on LinkedIn social-linkedin Follow on Twitter social-twitter Follow on Facebook social-facebook Follow on Instagram social-instagram

Footer

  • Purchase
    • Products
    • Subscription
    • Asset Store
    • Unity Gear
    • Resellers
  • Education
    • Students
    • Educators
    • Certification
    • Learn
    • Center of Excellence
  • Download
    • Unity
    • Beta Program
  • Unity Labs
    • Labs
    • Publications
  • Resources
    • Learn platform
    • Community
    • Documentation
    • Unity QA
    • FAQ
    • Services Status
    • Connect
  • About Unity
    • About Us
    • Blog
    • Events
    • Careers
    • Contact
    • Press
    • Partners
    • Affiliates
    • Security
Copyright © 2020 Unity Technologies
  • Legal
  • Privacy Policy
  • Cookies
  • Do Not Sell My Personal Information
  • Cookies Settings
"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Spaces
  • Default
  • Help Room
  • META
  • Moderators
  • Explore
  • Topics
  • Questions
  • Users
  • Badges