Space Exploration Engine - Procedural Planets, Ring Worlds, Huge Seamless Environments

[experimentfailed]

I seem to have hit a bit of a snafu. Here is a screenshot:

[Album] imgur.com

As you can see, the speeds are wonky. At that time, I was still close to the red planet; just pitched up.The perceived speed seems normal, but the distance countdown for the main thrusters stays stuck at 50000, and the speeds increase indefinitely.

I have not yet had a chance to troubleshoot/investigate, but thought I would point this out, in case you need to make a bug fix and/or can give me a little insight on where to look.

This was built in Unity 5…Tried both x86 and x86_64

EDIT: Forgot to mention, it seems like the main thrusters were never going to kick on due to this glitch. I flew away from the red planet for quite a long time, and that message never went away, and my speed never increased (outside of the obviously wrong numbers on the GUI)

I’ll be able to have a closer look in an hour or two from this writing.

EDIT2: Hmm…seems to function normally in the game preview (running the project from within the editor). I am stumped now…I feel like I’m doing something wrong.

[DemianT]

@experimentfailed

I seem to have hit a bit of a snafu. Here is a screenshot:
http://imgur.com/a/zDgdi
As you can see, the speeds are wonky. At that time, I was still close to the red planet; just pitched up.The perceived speed seems normal, but the distance countdown for the main thrusters stays stuck at 50000, and the speeds increase indefinitely.

I have not yet had a chance to troubleshoot/investigate, but thought I would point this out, in case you need to make a bug fix and/or can give me a little insight on where to look.

This was built in Unity 5…Tried both x86 and x86_64

EDIT: Forgot to mention, it seems like the main thrusters were never going to kick on due to this glitch. I flew away from the red planet for quite a long time, and that message never went away, and my speed never increased (outside of the obviously wrong numbers on the GUI)

I’ll be able to have a closer look in an hour or two from this writing.

EDIT2: Hmm…seems to function normally in the game preview (running the project from within the editor). I am stumped now…I feel like I’m doing something wrong.

That sounds very strange. I’ve never heard anything like that before. Which version of Unity 5 are you using? Have you made any changes at all? Did you download it into an empty project?

[experimentfailed]

Unity version is 5.3.5f1

I just tried creating a fresh project to be sure that I hadn’t inadvertently changed anything, but still having the issue.

It doesn’t make any sense at all that it would work normally in the preview, but get weird after it’s built. Compiler issue? Unity bug? I have not changed anything there - running a completely stock install of Unity + VisualStudio.

EDIT: It is worth noting, that I am fairly new to Unity, so it very well could be something simple that I’m overlooking…

UPDATE: Realized I was quite a ways behind on Unity updates, so updated (had only just installed to this PC (Windows 10) a few weeks ago). No change in the condition… Works perfectly in editor preview, but once built, I get wonky speeds and my distance from the planet does not update. I don’t see anything obvious wrong in the code, so I remain stumped.

[DemianT]

I’ve just tested it with V5.3.6 and I’m getting the same problem. Additionally, the frame rate is very low. Sorry about that. I’ll look into it now.

UPDATE: it seems to be to do with tags not getting imported correctly, or rather, with imported tags getting messed up after building the project for the first time. Hopefully I’ll find a solution tomorrow.

[experimentfailed]

Thank you kind sir! I look forward to your findings. Now that I have some direction, I’ll have a look tonight as well.

Yea, I did notice a drop in frame rates on the very latest version of Unity. If push comes to shove, I can roll back to an older version of Unity. I’m really not bothred either way…I’m just grateful not to have to spend 1000 hours figuring out my own solution to landing on planets

[DemianT]

@experimentfailed

Thank you kind sir! I look forward to your findings. Now that I have some direction, I’ll have a look tonight as well.

Yea, I did notice a drop in frame rates on the very latest version of Unity. If push comes to shove, I can roll back to an older version of Unity. I’m really not bothred either way…I’m just grateful not to have to spend 1000 hours figuring out my own solution to landing on planets

Hey, yeah, it was the tags. Send me your email and I’ll send you a working version.

[experimentfailed]

@DemianT

Hey, yeah, it was the tags. Send me your email and I’ll send you a working version.

Sent you a PM yesterday…did yu get it?

[DemianT]

Ah, I didn’t get an email notification. I’ll send it to you now.

[experimentfailed]

Quick question - Do you have any advice about the Player object movement to make it come to a stop? Seems it’s always pulled down hill by gravity (also bounces off the surface, making it even worse), thus always moving. I’ve tried a handful of ideas to implement better behavior (including using SuperCharacterController, which had the same symptoms), to no avail.

That is way down the list of things for me to work on, so in the mean time, I’ve cooked up a script to deal with it temporarily. Had pasted it, but its got some bug I’ll have to work out before it’s fit for public consumption.

[DemianT]

@experimentfailed

Quick question - Do you have any advice about the Player object movement to make it come to a stop? Seems it’s always pulled down hill by gravity (also bounces off the surface, making it even worse), thus always moving. I’ve tried a handful of ideas to implement better behavior (including using SuperCharacterController, which had the same symptoms), to no avail.

That is way down the list of things for me to work on, so in the mean time, I’ve cooked up a script to deal with it temporarily. Had pasted it, but its got some bug I’ll have to work out before it’s fit for public consumption.

You might want to check out ‘NonPhysicsMove’, included in this asset. It is similar the script you posted earlier, but it has more movement options. It might be useful during development.

Regarding the rigidbody character controller, I tried fiddling around with frictions and forces but couldn’t find any simple way round the problem. If you turn up friction high enough that you don’t fall down slopes, then you also won’t be able to move up them (except by jumping/jetpacking). That is unless you turn up the movement force, but then you’ll move too fast when not walking against an incline. I suppose some complex solution might be possible, perhaps involving modifying the movement force based on the slope of the terrain.

For walking around on planets, you could use an ‘off-the-shelf’ character controller, providing it supports changing of its ‘up’ direction and teleporting while keeping its velocity. When it comes to using spacecraft, things can get more complicated depending on the requirements of the game. If the ships don’t have interiors, and the player just ‘teleports’ into controlling them, then it’s pretty straightforward. Otherwise, you need to decide how you’re going to deal with transitioning between inside and outside ships. In the demo, I’ve gone for a completely seamless approach, which relies on a rigidbody character controller in order to work.

If you want to use a different character controller, there are some difficulties. Unless you have an extremely sophisticated character controller, you probably won’t want the model the player is in to be moving and rotating while the player is trying to walk around. What you can do is move the outside world and keep the ship still. But then you’ll need to work out how to deal with potential collisions between the ship and the outside world. I’d recommend this approach providing gameplay requirements allow for it e.g. you can avoid collisions between the ship and the external world, or you don’t need the ship to behave like a rigidbody.

Alternatively, you could let the ship move, but teleport the player to a stationary model of the ship’s interior. Then you would need some sort of clever camera system to work out what the player should be able to see out of the windows.

[experimentfailed]

Thanks for the insights!

I did see the non-phyiscs controller, but didn’t mess with it too much and I don’t recall what turned me off to it now, so I’ll take a closer look. The reason my script failed was because I didn’t think about the fact that the gravity would be trying to keep the “feet” aimed at the planet. Huge derp on my part…I may just apply it to a raw camera, but I’ll have to tweak the OriginLeash to work with it.

For dealing with on-planet stopping, I do have an idea right now, which is when no movement buttons are being pressed, to forcibly decelerate the player and then forcibly keep their velocity at 0 until they press a movement button again. Basically, faked friction. Also, would have to forcibly limit their top speed, as I notice that not only are you continuously adding force to the rigid body (when a button is pressed), but it’s getting added to again by the gravity, so you end up skating/bouncing across the surface at crazy impossible speeds. Haven’t worked out a way to do this yet, probably due to my lack of experience with Unity, but I have no doubt there is some way to do it. Will let you know if/when we come up with something.

Ships will be an Everest for us…We’re generating them procedurally, so it remains to be seen if we’re going to bother with interiors or not, but I love that aspect in the demo so hopefully we can figure out a way to do it without adding 20 years development time!

Anyway, thanks again! Great food for thought. Having a blast working with this so far - money well spent!

EDIT: As far as forcibly stopping the player, I’m now finding a treasure trove of results on google that for some reason weren’t returning the other night when I looked, so the future is bright!

@DemianT

You might want to check out ‘NonPhysicsMove’, included in this asset. It is similar the script you posted earlier, but it has more movement options. It might be useful during development.

Regarding the rigidbody character controller, I tried fiddling around with frictions and forces but couldn’t find any simple way round the problem. If you turn up friction high enough that you don’t fall down slopes, then you also won’t be able to move up them (except by jumping/jetpacking). That is unless you turn up the movement force, but then you’ll move too fast when not walking against an incline. I suppose some complex solution might be possible, perhaps involving modifying the movement force based on the slope of the terrain.

For walking around on planets, you could use an ‘off-the-shelf’ character controller, providing it supports changing of its ‘up’ direction and teleporting while keeping its velocity. When it comes to using spacecraft, things can get more complicated depending on the requirements of the game. If the ships don’t have interiors, and the player just ‘teleports’ into controlling them, then it’s pretty straightforward. Otherwise, you need to decide how you’re going to deal with transitioning between inside and outside ships. In the demo, I’ve gone for a completely seamless approach, which relies on a rigidbody character controller in order to work.

If you want to use a different character controller, there are some difficulties. Unless you have an extremely sophisticated character controller, you probably won’t want the model the player is in to be moving and rotating while the player is trying to walk around. What you can do is move the outside world and keep the ship still. But then you’ll need to work out how to deal with potential collisions between the ship and the outside world. I’d recommend this approach providing gameplay requirements allow for it e.g. you can avoid collisions between the ship and the external world, or you don’t need the ship to behave like a rigidbody.

Alternatively, you could let the ship move, but teleport the player to a stationary model of the ship’s interior. Then you would need some sort of clever camera system to work out what the player should be able to see out of the windows.

[DemianT]

@experimentfailed

Thanks for the insights!

I did see the non-phyiscs controller, but didn’t mess with it too much and I don’t recall what turned me off to it now, so I’ll take a closer look. The reason my script failed was because I didn’t think about the fact that the gravity would be trying to keep the “feet” aimed at the planet. Huge derp on my part…I may just apply it to a raw camera, but I’ll have to tweak the OriginLeash to work with it.

For dealing with on-planet stopping, I do have an idea right now, which is when no movement buttons are being pressed, to forcibly decelerate the player and then forcibly keep their velocity at 0 until they press a movement button again. Basically, faked friction. Also, would have to forcibly limit their top speed, as I notice that not only are you continuously adding force to the rigid body (when a button is pressed), but it’s getting added to again by the gravity, so you end up skating/bouncing across the surface at crazy impossible speeds. Haven’t worked out a way to do this yet, probably due to my lack of experience with Unity, but I have no doubt there is some way to do it. Will let you know if/when we come up with something.

Ships will be an Everest for us…We’re generating them procedurally, so it remains to be seen if we’re going to bother with interiors or not, but I love that aspect in the demo so hopefully we can figure out a way to do it without adding 20 years development time!

Anyway, thanks again! Great food for thought. Having a blast working with this so far - money well spent!

EDIT: As far as forcibly stopping the player, I’m now finding a treasure trove of results on google that for some reason weren’t returning the other night when I looked, so the future is bright!

Actually it isn’t as simple as enabling nonPhysicsMove. Firstly, you’ll also need to disable velocityOriginLeash, gravityManager and LimitVelocityNearSurface. Those scripts were made with the demo in mind and need to be modified depending on the requirements of your game. For the purposes of simple free-flying, they aren’t needed at all.

Secondly, you also need to disable the ‘Demo’ game object, as that enables the jetpack controller even after you disable it in the inspector.

Thirdly, (and I’ll include this in an update, but you can do it now if you want), in the script ‘PW_ManageTerrainCollider.cs’, you need to add a static class variable to control whether or not terrain colliders should be used. Add the following line:

‘public static bool MeshCollidersEnabled = ;’

And change the Update() function to:

void Update () {
        if (MeshCollidersEnabled) {
            Transform ship = objectListManager.getShip ().transform;
            Vector3 shipPositionIn1Sec = ship.position + ship.GetComponent<Rigidbody> ().velocity;
            bool colliderActive = UpdateCollider (ship.position, shipBoundingRadius, shipPositionIn1Sec);
            if (!colliderActive) {
                GameObject playerAvatar = objectListManager.getMainPlayerAvatar ();
                if (playerAvatar) {
                    Transform playerAvatarT = playerAvatar.transform;
                    Vector3 playerPositionIn1Sec = playerAvatarT.position + playerAvatarT.GetComponent<Rigidbody> ().velocity;
                    UpdateCollider (playerAvatarT.position, playerBoundingRadius, playerPositionIn1Sec);
                }
            }
        } else if(meshCollider.enabled) {
            meshCollider.enabled = false;
        }
    }

For the flying controller, you want mesh colliders to be disabled.

Note that, with regards to my previous post, this toggle could be used by a script to disable mesh colliders when the player starts moving inside a ship with a walkable interior. That way, the ship can be kept stationary while the external world moves without expensive mesh collider moving.

[experimentfailed]

Awesome, thanks a million!

[experimentfailed]

To anybody who may be stuck, it appears that

GetComponent<Rigidbody>().velocity = Vector3.zero;

Appears to be the magic seasoning to make my above idea work (fake friction).

For now, I’ve just bound that to a key, so we can move around on planets more easily for development use (while still having the full physics of the rigid body working), but in the future, I’ll expand it to smoothly bring it to a stop, and hold it still until a movement key is pressed again. Oh, and also that alone will negate falling (y axis) as well - you just completely stop, but I believe that should be easy to overcome.

EDIT: I just double checked the user guide to make sure I didn’t overlook anything related to the non physics move script, and i see there’s no mention, so if I may humbly suggest, you should probably add your above instructions

EDIT2:
In Update() I added:

if(!Input.GetKey("w") && !Input.GetKey("s") && !Input.GetKey("a") && !Input.GetKey("d") && isGrounded) GetComponent<Rigidbody>().velocity = Vector3.zero;

I moved isGrounded to a private class variable.

That makes you stop as soon as you hit the ground, but allows normal falling/jumping. That’s all I want (for now), mainly lacking nice deceleration. As it is now, it’s a hard stop.

[DemianT]

@experimentfailed

To anybody who may be stuck, it appears that

GetComponent<Rigidbody>().velocity = Vector3.zero;

Appears to be the magic seasoning to make my above idea work (fake friction).

For now, I’ve just bound that to a key, so we can move around on planets more easily for development use (while still having the full physics of the rigid body working), but in the future, I’ll expand it to smoothly bring it to a stop, and hold it still until a movement key is pressed again. Oh, and also that alone will negate falling (y axis) as well - you just completely stop, but I believe that should be easy to overcome.

EDIT: I just double checked the user guide to make sure I didn’t overlook anything related to the non physics move script, and i see there’s no mention, so if I may humbly suggest, you should probably add your above instructions

EDIT2:
In Update() I added:

if(!Input.GetKey("w") && !Input.GetKey("s") && !Input.GetKey("a") && !Input.GetKey("d") && isGrounded) GetComponent<Rigidbody>().velocity = Vector3.zero;

I moved isGrounded to a private class variable.

That makes you stop as soon as you hit the ground, but allows normal falling/jumping. That’s all I want (for now), mainly lacking nice deceleration. As it is now, it’s a hard stop.

Thanks, yeah, I’ll add that to the user guide.

Regarding your ‘fake friction’ idea, I tried something similar in the past but couldn’t get it to work. Unfortunately I can’t remember why. I may have just been being a bit stupid. Hopefully you will fare better!

[experimentfailed]

So, I’m making some progress on the rest of my universe generator… Just went to drop a planet prefab into my scene (which is basically a stripped down demo scene with some extras & cameras reconfigured a bit) and well, you’ll see by the screenshot that it hardly went swimmingly.

Any advice would be appreciated…I can’t tell for sure, but it seems like the chunks are not always moving when the planet is shifted by the origin leash. It’s kind of hard to see but those panels are actually floating above the planet - they are not simply misaligned.

It’s also worth noting, that the demo scenes are working fine, and I am still using the same version of Unity I was before when you made that bug fix. So guessing something is wrong with my setup. Note there are 3 cameras now, and I hijacked the one you were using for the skybox (the stars you see under the planet are procedurally placed now & are real geometry you could fly to). Anyway, so maybe I screwed something up there w/ the cameras?

Also, I notice the planet does not shift properly sometimes, as in it moves away from me a bit when the origin leash does its magic.

EDIT: Forgot to mention, I’m also seeing crazy amounts of depth errors (I don’t recall the correct technical term, but it most commonly happens if you put two surfaces too close together, so you’ll see both of them glitching and fighting for the foreground - that’s what it looks like to me).

[DemianT]

@experimentfailed

So, I’m making some progress on the rest of my universe generator… Just went to drop a planet prefab into my scene (which is basically a stripped down demo scene with some extras & cameras reconfigured a bit) and well, you’ll see by the screenshot that it hardly went swimmingly.

I see you have a null reference exception. Could you check the details of that? Perhaps you’ve made a new project and the tags have been messed up again. Take a look at the ‘taglet’ objects. Do they have the right tags?

What are the functions of your 3 cameras? I can only see one in your scene heirachy.

[experimentfailed]

Of course, now I can’t reproduce the panels getting placed above the planet issue - no idea what I did to fix that.

Still getting mad depth issues, but I am thinking it may be related to the modified clipping planes of my new camera setup. I’m exploring that now. My hypothesis is that it’s losing too much precision past a certain distance, and the way you have the cameras’ clipping planes set up in the demo worked around it.

The new cameras basically just provide two additional frames of reference (FORs) to represent interstellar and intergalactic scales of the universe. This is needed mainly because an origin leash alone cannot quite compensate for both the extreme distances and speeds required to traverse true sizes/scales of the universe. At least I couldn’t find any way to make it work, and it seemed like speed was the major issue. Doing it this way means I can put galaxies only a few units away from the camera and define 1 unity unit = 1mly (or whatever), then render that into the background; do the same for stars. Then whatever you’re actually close to (and going slow enough to see) will get moved to the local FOR. This way, the biggest scales I ever have to worry about are solar systems, which the origin leash seems to have no problem with. EDIT: of course, I will still need to origin leash the other FORs.

Tags all look OK to my eyes. This scene is basically a copy of demogoodquality from the latest update you sent me. Then I just stripped out what I didn’t need (namely the demo gameobject, ship, and all the text objects). Incidentally, the null reference exception was related to the ship (or lack thereof), but fixing that did not improve the situation.

But again: now it seems the planet panels are suddenly working fine (lining up correctly), and the planet is shifting with the origin leash normally, now so…shrugs i don’t even know…

[experimentfailed]

Ok, yea, my hypothesis was correct on the depth issue, so now it seems like all is solved. Thanks for listening, I guess? lol!

Will let you know if I run into the weird floating planet panels thing again, because I’m still not sure what happened.

[HonoraryBob]

The Windows Standalone link is broken.