3D Radar/Space Explorer: Encore

[torakunsama]

WARNING: Words wall!
Hello every one! I hope I can get your scripting skills help on this one.

Problem:
I need to fly from a planet to another. In my previous demo that was a bit possible, but it was from the same planet’s moon to another. For the game, there’s a need to explore a star system, if not many of them, in an almost seamless way. I know you might at first think it’s impossible, but I not the kind of guy who shows up and asks for impossible stuff to the other, such a fake up system is being hold for my lack of experience in python-fu.

So how so I go about it?
In my ideal setup, I’d have a star system with it’s planets in a background scene. there I have a camera flying about in space.Each planet has the same orbital space, which is determined by the biggest planet.
Then on the main scene I have another camera and a ship. There’s a planet spawner in the middle of the scene and a position controller.
When the camera approaches the planet, a position controller object is added, and it tracks to the camera, this object orientation is then linked to the main scene’s posController, since the camera is parented to that controller, both cameras will have the same relative angle to the planet. In which case the planet seems to spawn on the right side. As for the distance, the cameras need to have a relative position script that calculates the vector length from the controller to the camera and set’s it to the other camera X 1000.

So far, the first part works, but because there’s no distance calculation, landing on the planet is very awkward (not impossible) I provide a simple blend example without landing nor approaching planets. I was incapable of making it work from background to foreground. Therefore the main scene runs in overlay.
The script I’m using, courtesy of Raiderium, uses a position line, but since it takes the world position, I can’t use that!
The current setup has got precision problems. I figured it was because of the lack of distance to target calculation/attribution.
Precision problem.

This image shows what happens after orbiting the planet a few times

Although it’s fine when the planet is spawned

Solution:

A more sophisticated script.
Containing a linking list of objects in the scenes, a 1 pivot point (reference object) per scene and vector lenght calculation to the object in the scene. Attribution of this length to the corresponding object in the main scene [ the main scene being 1000X bigger than the background’s, the length is mult by 1000). Also their orientations must be copied. This has to work from the background to the main scene. Meaning that the background is the source of information.

BTW, the same principle is applicable for a 3D radar!

If you read this far, means that you are patient and might be willing to help a distressful fellow. Please help!

Attachments

player pos rev.blend (322 KB)

[torakunsama]

Once again, I’ve been ignored! My bad, I should have cut to the chase!
What I’m asking is a way to calculate a vector length from A to B, then give a distance to object D from C equal to that vector! I believe is quite simple, I’d have done it myself if I could, but I still can’t, so pliz help me out!

[Monster]

If I understand right, you want
A) the overlay scene with the player camera + player model + models of the near object and a corresponding camera in the background scene with the far distance (large) objects?

Or
B) the camera (player) in the overlay scene travelling with lets say 10 BU/s through the main scene space, while the camera (player as well) travels with 0.01BU/s through the background scene, while objects at the background scene are scaled down by 0.001?

Now you ask how to get distances from an point in the overlay scene to a point in the background scene and vice versa?

In that case I would think about having empties at the overlay scene at there expected location. Then you can calculate everything in its original size.
If that is not an option, you could scale up the distances from the overlay scene to the background scene by multiplying with 1000. But you could loose precision in short distances.

But I’m nor sure if I understand what you need.

[Edit]
If you want to land on a planet, I would let the near objects of the planets surface appear in the main scene rather than the overlay scene. (something like a LOD).
They would hide part of the planet of the background scene.
[/Edit]

[torakunsama]

It’s rather A. I’m using overlay coz the script I’m using prevents me to copy orientation from the background to the main scene! And it seems to work with 2 scenes only.
The idea is :
C: A background scene with a camera flying free in space. The planets are scaled 1/10000. Each explorable object spawns a ref object when the camera approaches it. From this empty, the relative position is calculated. This position is then copied to a corresponding cam in the main scene. Orientation must work in reverse. The main camera’s orientation is copied to the background’s!
The main scen spawns the planets and moons, so it stays the same.
As for LOD, I intend to use it on the main, I want to use the overlay for HUD…

Thank you for replying Sensei!

[torakunsama]

But I’m nor sure if I understand what you need.

Hmm, I see! My “eloquence” is faulty.

Illustration: I have a star system with 3 planets. Because it’s impossible to have big objects with big distances between them, they are scaled down /1000. I use a camera to fly from planet to planet. The planets have a bounding space, that on approach allow a signal to be sent to the main scene, spawning the appropriate planet in the main scene. From the center of the planet the camera position and orientation is calculated. This way, the same will be reproduced in the main scene, where ships and vehicles allow player to move about the planets.
This is an attempt to make space travel look seamless. Therefore, the position of the player in the background will be relative to an empty added to the planet’s center he’s visiting.
…ah, here I go again, I tend to make long speeches to explain a simple thing…

[Monster]

Thanks for the explaination. This makes it very clear to me.

I think you have to take care where you measure. That means if you use a distance in one scene you need to convert (scale) it, when using in the other scene. The orientation should be used as it is. But I think you know that already.

If you have (1,1) -> (5,2) in one scene you get (1000,1000) -> (5000,2000) in the other scene. Just multiplying each term with the scale factor (1000). And divide by 1000 the other way around.

BTW: you should have a shared (0,0) point in each scene. Or you need an (scaled) offset.

I hope it helps

[torakunsama]

Yes, I mentioned all this in the words wall I wrote above! I figured it would be lost in the amount of info. In my previous demo, I used such a script, courtesy of Raiderium. This time I need to go to other planets and and use their center as a new (0,0,0).
If you see the script in the provided blend, you’ll realise that it already does the job, only for one planet.

[Monster]

ok, so you have it that the player at the Front scene stands still, while you move the camera of the Back scene.

So your problem is that the spawn planet and the player stand still, isn’t it?

I would move the player at the Front scene as well. But not with the full scale.
That would mean you need a smaller copy of the Back scene (to match the positions of the planets).

I like your idea. It would enable you to build up multiple scenes for different planet surfaces. That might be loaded from different files during runtime as you just need one planet at the time.

I will came back later when I have more time for you.

[torakunsama]

Once again, thank you. The player stays still at the very limit of planetary orbit, so he wont spawn inside a planet (planets have different sizes). In the example I took the screenies from, landing is possible, but it lacks a some accuracy. The player is spawned when I change to fps camera, then he walks to a shuttle that takes him to the planet. I’ll make a video to show it, later on!
The ship moves after the planet has been spawned, but it goes back to it’s default place as the planet is ended!

[Monster]

I think if the player remains on its position that could be a problem. But not a big one.

The problem is, if the planet spawns, the camera will see it always from/at the same position.

What you can do is at the moment of spawning the planet, move the spawned planet to its expected position, or move the player to the opposite position.

After that you should move the player to make him land on the planet. But I think, you need to move the back scene camera as well, but not that far.

You can do that, by converting the position list to a vector:

from Mathutils import Vector

vector = Vector(obj.worldPosition)
otherObj.worldPosition = vector * scale

I hope it helps

[torakunsama]

Wait, there’s a misunderstanding! The player moves ‘only’ when the background object enters a planet’s space [when the script is activated], otherwise, when moving to another planet in the system, it wont have a position relative to the planet, resulting in having a planet spawning in the wrong place. Besides, that will imply that the player has to start from the centre of the scene, making planet spawning a problem.
Also the other object is in another scene. Converting the position list into vector is the only way to go.
Now I don’t understand the scale part, since is ideal to get a vector for the planet to the background player and transfer it to the one in the main scene, adding that same vector from the planet to the player X scale.

Have a look at the scrip I use:

#Simple inter-scene object transform linker
# By raider

#Useful for radars and suchlike. Should work okay with
#lots of objects.


#Set up object links by name, in a dictionary.

#The first object is the one being copied from, in the main scene.
#The second is the one being copied to, in the overlay.

link = {}

link["controller"] = "fps_camera"
#link["ob2"] = "ob2_copy"


sce_list = GameLogic.getSceneList()
cont = GameLogic.getCurrentController()
own = cont.owner

#This checks if the overlay has been added.
if len(sce_list) == 2: 
    
    Overlay = sce_list[1]
    Main = GameLogic.getCurrentScene()
    
    for source in link:
        
        #Grab the source and destination objects from each scene (note 'OB' prepended)
        source_ob = Main.objects["OB"+source]
        dest_ob = Overlay.objects["OB"+link[source]]
        
        dest_ob.WorldOrientation = source_ob.WorldlOrientation
        #dest_ob.LocalPosition = source_ob.LocaldPosition

[Monster]

I was assuming your back scene is a scaled down version of your “universe”, that the distances between the planets are not that huge.
If that scene has the same dimensions as the front scene you do not need to scale (sclae factor 1.0).

But than I can’t see the point of having two scenes.

[torakunsama]

Yes that’s exactly the idea. Only I have 3 scenes. Let me put things clear here.

1. Back scene: Galaxy mock up, each star takes 100 units of space in a , planets have 1-8 units of size… the camera take Orientation from the main scene.

2. Main scene: active objects, ships, player, building, planets etc, they are spawned according to the data received from the back. Planets range from 10000-80000 units. Player has 0.18 units of height (problematic) the player/ships take their position from the background camera.

3. Radar scene Overlay: Takes orientation and position from the back and main scene, contains cubes, arrows, spheres to represent elements in the scene, scale similar to the back ground scene.

So the scenes have different scales, the vector scaling happens indeed, but for the back scene it’s localposition and for the main is world position!

[torakunsama]

I tried to toy a bit with the script, by modifying it a bit I got the script to work as I wanted. Now I need to get a relative position (using an empty as origin) for the objects in the main and overlay. So the main scene is not scaled up!
The ouline cubes represent the background objects, the smaller dots are the radar…

Remember I’m a Python noob and can’t actually write a script that works, so the maths part of it is certainly not working, maybe you might get what I’m trying to do…

Attachments

3D Radar_Planet Explorer.blend (199 KB)

[Monster]

Hi torakunsama,

I was thinking a lot about your aproach to desing this scenario. I think you could have the main movement of the player in the main (the small) scene. Then assign the down scaled position to the universe (large) scene with an (scaled) offset that is the determines the difference in the zero position.

If you change this offset with every frame it looks like the player is not moving in his scene.

I suggest to perform the offset movement only under certain conditions e.g. if the player leaves a specifc area around its original zero position. Lets say the new player’s position leaves an area of 100 units along Y from 0,0 (Y>100). Then move the player back by 100 Units along Y in the small scene and add 100*0.001= 0.1 units along Y to the offset in the large scene.

So you get:
largePosition = (smallPosition * scale) + smallSceneOffset

the other way around is:
smallPosition = (largePosition - smallOffset) / scale

If you look at this you see when moving in the large scene is not that accurate as you might want to have. So it is very difficult to move with slow speed. I think that is where your problems are coming from.

When you entering planetary space you can increase the limits when you change the offset. E.g. you do not change unless you leave the orbit around the planet.

I hope that makes any sense to you.

[torakunsama]

I don’t think I follow, I’ll read once again and edit this post, in the mid time, I made an update.

Edit>
Well before I analyse what seems to be what I’m trying to get at, here is the scene orders:

Background: Galaxy scene> scaled down mock-up galaxy model.
Main scene: Planetary scene> normal sized scene, where different planets are spawned, along with players and active objects.
Overlay: 3D Radar scene> self explanatory

In the galaxy scene, all star systems and planets have their orbital space, which corresponds to the planetary scene space.
As the camera enters the orbital space, its relative position (relative to the orbital space), is calculated (offseted) to the camera in the planetary scene, as you tried to explain I guess.
But on exit, the planetary camera must be reseted to it’s default position, at the border of the planetary space, and not move from there, till the other camera has entered a planet!
Does it make sense now?

Attachments

3D Radar_Planet Explorer.blend (205 KB)

[Monster]

Here is a demo.

you can move the camera wit hthe arrow keys.

in the middle of both scenes is a cube. A double wall cube in the Large scene a normal cube in the Small scene.
The objects in the Large scene are 10x smaller than in the Small scene.
The camera in the Large scene can look much further than the camera in the Small scene.
The Small scene contains a more detailed Sphere mesh than the one from the Large Scene.
The Small scene contains a border mesh with a scale of 20.

What it does:
If you move over the border with the camera (detected by the Border.detector) the player camera is set to the opposite end of the space (within the border). This is like moving the whole scene foward by (in this case 40 BUs).
The disadvantage is the with that method, you have like an endless universe with replicated space (the center model is visible each 40 BUs (also the detailed Sphere). You could load onother small Scene showing a different area e.g. planet space.

If you want to see how it works, switch the small scene (its the start scene) to top-down view <num 7>. Then you see the sensor object representing the cameras position.

Attachments

scaleDemo.blend (181 KB)

[torakunsama]

Hmm, very nice Monster Sensei! It could be used for long space trips or in corridors, like faked hyper space(thought I don’t believe in such things).
It seems to be linear though, does it work on all axis or just on one?

[Monster]

all axis. It compares the limits. If one or more are exceeded in any direction, it moves the synchronized object to its new location. The size is detemined by the size of the border cube. Make sure the border cube is a 2x2x2 cube scaled in object mode (not edit mode).

There is a little mistake - the sensor object parented to the camera should be a 2x2x2 cube rather than a 2x2 Plane. But it is not that bad.

I haven’t implemented a nice method to select the object to be synchronized. It is just hardcoded. I started but it ended in a complex function which is difficult to document.

[torakunsama]

Monster Sensei, I am very grateful for this demo, however, it seems quite complex for what it does. It could be used as overlay to add little objects like dust, little meteorite in between spaces. But being that complex, it gets hard to use. I’ll learn from it though it’s very hard core.
I still believe my solution to be to most quasi-seamless, using simple code, and giving the impression of continuous flight [which is a primary requirement for me].
What I need is partially achieved in the demo provided, just need a solution to turn a relative position into an absolute one. like in the illustration…

Attachments