Wayback Machinekoobas.hobune.stream
May JUN Jul
Previous capture 12 Next capture
2021 2022 2023
1 capture
12 Jun 22 - 12 Jun 22
sparklines
Close Help
  • 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 subcon · Aug 28, 2011 at 08:52 PM · loadlevel

Load-level in Space

OK, I'm near insanity here, I'll try to explain my FPS space-game problems.

I'm trying to create a virtually infinite space environment (limited only by how many scenes I create). I am of course, encountering floating-point inaccuracies. This is what I've come to realize:

  • Floating-point inaccuracy cannot be resolved by 'moving the universe, not the player' - this does not work in multiplayer contexts

  • Floating-point inaccuracy cannot be resolved by using the FloatingOrigin script found on UnifyCommunity wiki - 2D movement is fine, but once you throw vertical movement into the mix, floating-point numbers become inaccurate

  • Floating-point inaccuracy cannot be resolved by scaling objects up or down; I know this has worked for some people, but not for me

So I came to the conclusion that, perhaps, I need to just make smaller scenes and somehow link them together in a 3-dimensional grid of scenes (think rubix cube, just in virtually infinite size). This is fine, but I am totally lost as to how to implement this.

  • SetNeighbors would be nice, but I believe it only works with actual terrain - empty 'space' I dont believe will work

  • SetNeighbors also only works with 2 dimensional planes (e.g: left/right/forward/back, not including up/down)

  • Application.LoadLevel would theoretically work, but I do not understand how to keep the player facing the proper direction (orientation-wise) based on which direction from which they're entering a given scene. Also, keeping the skybox (same one used throughout all scenes)

I've gone over every thread I could find, I honestly have tried many solutions - I'm looking for something to save me from this seemingly impossible scenario.

Thanks

Comment
Add comment · Show 2
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 Waz · Aug 28, 2011 at 10:15 PM 0
Share

SetNeighbors is a red herring. It's just for terrains.

avatar image subcon · Aug 29, 2011 at 08:34 PM 0
Share

Thank you, this is what I suspected

2 Replies

· Add your reply
  • Sort: 
avatar image
0

Answer by Waz · Aug 28, 2011 at 10:14 PM

No matter what you do, you only get 6 or 7 digits of precision, regardless of scale. This is simply not sufficient to model space as a continuous area.

Yes, you will have to make smaller scenes. You can load them using LoadLevelAdditive and translate them to give an impression of continuity, but you will also need to translate everything to keep it near the floating point origin, and you will need to discard scene content that is too far away.

You may also need a second camera to draw more distant objects, since you probably can't have planets and people in the same floating point range.

Comment
Add comment · Show 1 · 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 subcon · Aug 29, 2011 at 08:30 PM 0
Share

"but you will also need to translate everything to keep it near the floating point origin, and you will need to discard scene content that is too far away"

Can you provide a rough example? I feel as though I am starting to get a vague sense of some of this, but an example would surely be a beneficial kick in the face =)

Thanks

avatar image
0

Answer by BerggreenDK · Aug 28, 2011 at 11:54 PM

I dont see how the multiplayer thing can be an issue. If you build your view as a viewport. Then you just have to use an offset value?

Your idea with the cubes (rubix) is great for this approach too. In 2D tilemapbased games to keep this simple, I usually make a buffer around the viewport. Same would apply for your idea I think. Or so I would do at least.

Once you get near a new zone, you have to start loading/spawning the next in that direction so you have enough.

When you cross a boundary, I think you can "easily" translate the whole "cube" in the oppersite direction.

For the rubix example:

Lets say you call center for (0,0,0). Around you, you have 26 other cubes. If you go right (1,0,0) you should now place this as your new center of your local viewport. Any player inside the other 26 cubes should be taken care of (shown).

Your universal position depends on where you place your universal 0,0,0 - but your own position is a local 0,0,0 with a cube-offset value to the real universe.

Now when you move to the right and the new offset is 1,0,0 then you can destroy/put away those in -1,y,z and add those in +2,y,z

Ofcause you can expand this cube system for a rubix of 5x5x5 or whatever matrix is best for your engine/idea. But I feel rather certain that this would do the trick and enable you to center your game around the precise 0,0,0 coords.

For every player you just need to know two coords: local (within a cube) and offset (which cube).

Does this make any sense?

Comment
Add comment · Show 3 · 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 subcon · Aug 29, 2011 at 08:33 PM 0
Share

Yes, its getting clearer, I'm still wrestling with the concept of making this a functional reality - any example data code-wise is appreciated in general, but lets see if I can digest this fully =)

Thanks for you help

avatar image BerggreenDK · Aug 29, 2011 at 09:54 PM 0
Share

If you have a commercial product, I can be hired for $$$ :o)

avatar image subcon · Aug 30, 2011 at 12:48 AM 0
Share

I see

Thanks

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.

Follow this Question

Answers Answers and Comments

4 People are following this question.

avatar image avatar image avatar image avatar image

Related Questions

Application.LoadLevel Error (Possible cause: URL request conditioning went wrong) 1 Answer

Static variable reset at LoadLevel 2 Answers

Scene switching not working? 2 Answers

Delays when move to another scene 1 Answer

Next lvl code help 1 Answer


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