I have been using Blendezos tutorial on vertex parenting and got it working quite satisfactorily in Blender 2.54. The problem is that I don’t think the technique is what I am looking for.
I want to align the camera with the fuselage of my “spaceship” thus giving a sort of pilots eye view. The idea being that the camera maintains its local alignment with the ship axis. [Eventually, I hope to be able to rotate the camera independently of the ship, this being equivalent to the pilot turning his head.]
When I use vertex parenting, (exactly as described in Blendezos tutorial,) the camera maintains its x,y,z position with respect to the ship but its orientation remains global. You can see the results in the two attached thumbnails. The first image being the start position where the camera is aligned with ships axis and the second image is the alignement of the camera after the ship has completed a turn.
I have tried parenting the camera in object mode and that is even worse.
Can anybody please offer any suggestions on how to lock the cameras orientation to the ships axis?
.
If you position the camera exactly where you want it, press ctrl+0 to set is as active so you can make sure you’ve got it in the right place, then parent it in object mode, it will copy the exact local orientation and position.
Can you explain what exactly wasn’t working when you did it in object mode?
Attached are screen-shots after turning with an “object parent”. The start position is the same as before: The first turn was a simple right/left local X-axis and the second was a combination of right/left and up/down
The camera was positioned directly above the ships center, (2.4 blender units,) and aligned along the direction of motion, (the local y-axis)
.
I have finally figured this out and since I have discovered that these posts are actually read by people looking for answers, here goes:
It is “object parenting” that I need to use, but the trick is not to parent the camera to the ship, but to parent the ship to the camera. You then have to put all the flight controls on the camera, not the ship!
That isn’t the best way of doing it though, I usually add slow-parent to the camera, where the camera lags behind the ship, so you can see it’s acceleration.
I have also had problems parenting some objects together, and would greatly like to know what causes this in-complete parenting. All I can say is that for some objects it works, and others it doesn’t.
If you want another way of doing it try adding an empty, and parenting the ship and camera to it. This normally works for me.
I tried so many different combinations of parenting with “empties”, “track to”, “camera actuator”, “slow parent” the list could fill pages… I think the effect of what I have done is actually what i had in mind.
I understand the problem about seeing the acceleration/movement: At the moment, I have some really nice scenery and I have set it far enough back from where I intend the game area to be that it maintains the illusion of depth and infinite space. The problem is that the play area is currently inhabited by one solitary asteroid and unless that asteroid happens to be in the current view-port, there is absolutely no sensation of movement,(from the pilots view.)
Oh, such a beautiful problem!
I have done a few test blends and have just started to work on populating my asteroid field, you may care to comment on my plan:1) I have one rotating asteroid of which I will make eight copies, (modifying each one slightly.) Then I intend to parent each asteroid to the vertices’s of a cube centered at the origin and give the cube a rotation.
2) Setting the material of the cube to “halo” and, (hopefully,) et voila I have band of orbiting rotating asteroids.
3) Duplicate the cube and scale it up to give as many bands of asteroids as is practical.
Like I say, this my first BGE project and I am playing it a bit by ear. But I think the basic idea is sound, it is very simple and suitable for a novice, it minimizes the amount of work and should avoid problems with unwanted collisions between asteroids.
The only real problem that I can see is that a discerning player may notice that the asteroids do not have a uniform (Brownian) direction which they would have in real asteroid belt.
This is a strange approach, though I can understand how you’ve came to this conclusion.
I would recommend the following:
Create a 3D asteroid
Make it dynamic
Give it an always sensor, an AND controller and a Simple Motion actuator with 0.1 Torque (on any axis for now)
Use alt+D to instance the asteroids until it looks like a nice field
Create an empty and center it in your asteroid field
Select all the asteroids, then finally the empty and press Ctrl+p to object parent
Make the empty dynamic
Give the empty an always sensor, an AND controller and a Simple Motion actuator with 0.1 Torque (on any axis for now)
When you parent an object to a vertice it only copies its location, not its rotation.
‘Halo’ is just a rendering trick to make the faces of an object always face the camera. It won’t give you the desired rotation (it may well have some ‘track to’ qualities if you vertex parent, though that’s not really how it’s supposed to be used)
Yes you re quite correct, “Halo” does not work, although it did seem promising in some test builds. I just implemented something similar using a cube and deleting only the faces, but it is less than satisfying.
I am going to try and implement your method: I now have basic collection of eight flavours of asteroid, (duplication and editing) and I keep switching gravity to zero at every iteration of the blend, but for some reason it keeps creeping back? (probably forgot to save)
Noting that my original asteroid has an image texture, a very light “subsurf”, (1 on view and render =0) and a light touch of “smoothing” have you any suggestions on a safe maximum number of asteroids that wont cause problems for future game development?
Subsurf will slow down game engine. Apply any modifiers before starting the game.
Use a low res texture (128*128) and keep it under 100 triangles and you could have dozens of them.
I have a 104 asteroids at the moment + 1 ship and that does not seem to noticeably affect the responsiveness of the ship. Eventually I hope to plant some missile launchers around the asteroid field and I suppose there radar, (and the radar of the ship,) will add an affect. But I need to spread things out a bit more.
Am I correct in thinking that it is only the objects that are in the current view frame that slow down the game response time? What I mean is that I could have a thousand asteroids, so long as there is only a few actually visible in the pilot-camera?
The asteroid texture I am using is 256*256 but I can scale that down easily. I am not sure what you mean by “applying the subsurf before the game starts” Before applying subsurf the asteroid was a distorted icosphere, and it really needs that 1 level of subsurf, (and smoothing,) to give it a more natural shape (see attached image.) I did read that modifiers were a problem and have tried to minimize them.
Looks good, you could probably get most of that detail with a baked texture (or baked normals if you are using the advanced texture settings). A rock like that only really needs to be a simple icosphere, unless you actually plan to land on it. Do you have a star background? If you use a sphere with a star texture that would realy add to the feeling of motion.
The icosphere on its own was too angular, I tried making asteroids using “vertex noise”, but that is mainly for rendering and no good in the BGE. Eventually, after much searching, I found a “Lunar Craters” texture on the “Blender 3D” site, with the result shown.
There is a couple of pictures of my star textures if you scroll up the post. I am using an “enclosed” or “six sided” star-box. I experimented with a sphere, and many different textures using “Hubble wallpaper”, but I found that the best results was to take one generic star-field wallpaper and use that on all six faces!
Using a base mat black layer, the generic star-filed layer and a couple of layers for the planets, I can move, replace or delete some of the larger more noticeable stars so that each face has the appearance of being different. Because it is the same image on each face, the textures match perfectly at the seams with just a little tweaking, (that was not the case when I tried to convert a star-field into polar projection for a star-dome.)
I have made the star-box twice the size of my intended playing area; this seems to keep it far enough away to maintain the illusion of infinite space, though I am still experimenting with this.
Using the tips that I have received in this post, I can see a definite improvement, though I think I need to make a fuller implementation of the pilot-HUD to give some basic positional telemetry which I heed for de-bugging/tweaking the play area. [At the moment, the HUD is just proof of concept.]
As far as the course of the game:1) Objective: Find/Destroy enemy/pirate base.
2) Hazards: The asteroids, a few of which will have missile/targeting launchers.
Pretty simple really, it is my first project.3) If I develop it further, I am thinking along the lines of having a friendly refueling base base that will have the exit/entry qualities of the “Oolite” game from the late 1980’s
I don’t know if you are old enough to remember “Oolite” but the very start of the game, and its main attraction, involved gaining entry to a rotating space station. I along with many other people never got beyond that point. (It was an amazingly popular game.)
