It's a 360 Video application on Unity 3D.
I want to place several objects around the camera (which has a fixed position), but I need this objects to have the same distance (same radius) from the Camera (which is the center). How can I do this? Either on Editor or by code.
I have been manually displacing objects around the camera, by dragging them by arrow tool. But it's as inaccurate as a pain to do. :)
Any light on this would help me a lot! Not only me, but anyone working with 360 videos in Unity.
Thank you all in advance!
To solve your problem, an easy solution would be to add a child "child_of_camera" to your camera and then add a child "child_of_child" to the "child_of_camera".
Now that you've done this, move the "child_of_child" away to however far from the camera you'd like it to be. After this, apply the random rotation you'd like to "child_of_camera".
Duplicate "child_of_camera" to however many objects you'd like on screen and then rotate them all to your preference.
Now, when you're moving around the camera, these children will follow along with the camera.
If you're looking so that the rotation of the camera doesn't affect the objects there are two ways you can handle this:
Place camera and "child_of_camera" (this name would now be misleading and should be renamed) under an empty GameObject and move "empty_GO" on the X,Y,Z axis instead of the camera.
or
Create a quick script to attach onto "child_of_camera" so that it always sets the "child_of_camera"s world space rotation to Vector3.zero.
As I stated in the comments, this solution is most likely not the optimal way to fix your problem but it is definitely a very simple solution that is easy to understand and implement. I hope it helps.
Related
For more than two days now I am struggling with this seemingly impossible problem: I have a composite GameObject (one parent, 10 children), each one hinged to at least another with angle limits and player-controlled motors. Moves perfectly as I wish.
Now I want to be able to flip it. After a while and many trials,rotation seems the best way in order to keep the angles (inverting localSpace does not respect them):
Vector3 rotPoint = new Vector3 (ParentGameObject.transform.position.x, myY, myZ);
ParentGameObject.transform.rotateAround (rotPoint, Vector3.up, 180.0f);
BUT, if the parent rotates as asked (180 degrees around its Y axis), every child flips but not around the same axis, rather around their own rotation center. This gives ridiculous results as hinges try to get back to the desired position. How could I fix this?
Many many thanks in advance...
In the end I figured out the problem. My problem had no valuable solution.
We can rotate the transform around the Y axis even in 2D, but NOT the rigidbody2D, which in the same object will invariably cause serious problems.
This is maybe one remaining inconsistency into Unity5's implementation of 2D.
I had to flip using localScale inversion and programmatically updated positions and rotations.
It sounds like the child GameObjects are rotating around their own pivots instead of the parents. I haven't got Unity installed at the moment to test this, but if you add an empty GameObject as a child of your parent (and with the same pivot point), then make all your other GameObjects a child of this, it should work.
You should not move or rotate a rigidbody if you don't have to. That will mess up the underlying physics calculations and physics engines won't be happy about it. Instead, you have other ways to interact with them
Apply force, torque
Apply acceleration, angular acceleration
Change speed, angular speed
If you have to move/rotate the object, you should also update positions, rotations, speeds, angular speeds of all of your hinged objects. That would not be easy. Give some more details if you unable to solve.
I'm making a zelda-like 2D Role-Playing-Game with XNA and wanted to implement a camera which follows the player today. Soo... I didn't really understand how it's working, but I found a nice code-example here: http://www.david-amador.com/2009/10/xna-camera-2d-with-zoom-and-rotation/
I implemented it and changed the spritebatch.Begin(); to what the guy in the thread said. Now it is working ... well. The collisions are alright and the player is centered (since I set the position of the camera to the position of the player once a frame) but: The textures don't get drawed the way they did before. So for example the shadow is drawn under the grass (=you can't see the shadows) the player is sometimes drawn over the NPCs and sometimes under them and the wall-tiles disappear and reappear like they want :(
Do I have to change the drawing-code or the order they get drawn?
Hope somebody know what I am doing wrong...
In your Spritebatch.Draw call you can specify the layer depth. When specifying the layer depth, you will need to use the proper Sprite Sort Mode when initializing your SpriteBatch.
I had an idea in my game of having 3 layers to the map, the first being the ground, the second being the roads/grass/etc, and the third being impassable objects such as walls/buildings/lakes/rivers/trees. I have it so the player is centered at the middle of the screen and the layers of the map move in the inverse direction that the player wants to go. I was thinking I would have the different layers that way if the playerModel overlaps whereever something is drawn on the impassableLayer, then the playerModel would shift back. However, as I am new to xna, I don't know how to get the game to recognize that the playerModel is overlapping the impassable objects on the impassableLayer. The impassableLayer obviously only has objects drawn on it, and is empty anywhere there isn't an object. Therefore I can't just say:
if (playerModel.X > impassableLayer.X)
{
impassableLayer.X++;
}
As this would always be true.
Is there a way to tell if an object is overlapping a layer?
What you are looking for is collision detection I belive. You want to keep objects from passing through each other. It isnt as simple as the idea you had. True collision detection will take alot of work, but their are tons of tutorials for it.
Youtube tutorial on per pixel collision
Per-pixel collision on MSDN
Bounding Box Collision
You can always to a search here on the site or google, there are lots of resources for this out there.
Im not intrested in the code for this problem i just want to be pointed in the right direction.
Im using C# XNA if that helps.
Basicaly for my game i am adding collisions for example the player can't walk or fall through stones.. I have the rectangle and i know i use the .intersects comand but would i need to check collision depending on the side of the rectangle here?
I know if the player is falling i can make if playerRectangle intersects stoneRectangle playerY = stopFalling..
But if the rectangle is coliding on the side of the player.. That would be different wouldn't it ?
One simple way of dealing with this is to work out the main axis of penetration, i.e. is the player further into the rectangle horizontally, or vertically. Then, using this information, you'd move the player so they were just touching the rectangle.
i.e. Player bumps into a wall on his right.
Main axis is Horizontal, and he's to the left of the centre of the rectangle, so we know to move him left.
Searching on gamedev.stackexchange.com will give you lots of different collision detection/response options.
If your game is 2D I would recommend using something like FarSeer Physics rather than implementing yourself.
If you are interested in the algorithms it is open source and you can poke around the code to see how they implemented collision detection.
I'm designing a 3D game with a camera not entirely unlike that in The Sims and I want to prevent the player character from being hidden behind objects, including walls, pillars and other objects.
One easy way to handle the walls case is to have them face inwards and not have an other side, but that won't cover the other cases at all.
What I had planned is to somehow check for objects that are "in front" of the player, relative to the camera, and hide them - be it by alpha blending or not rendering at all.
One probably not so good idea I had in mind is to scan from the camera to the player in a straight line and see if you hit a non-hidden object, continuing until you reach the player. Unfortunately, I am an almost complete newbie on 3D programming.
Demonstration SVG illustration < that wall panel obscures the player, so it must be hidden. Another unrelated and pretty much already solved problem is removing all three wall panels on that side, which is irrelevant to this question and only caused by the mapping system I came up with.
What I had planned is to somehow check for objects that are "in front" of the player, relative to the camera, and hide them - be it by alpha blending or not rendering at all.
This is a good plan. You'll want to incorporate some kind of bounding volume onto the player, so the entire player (plus a little extra) is visible at all times. Then, simply run the intersection algorithm for each corner of the bounding volume.
Finding which object is at a given point on screen is called picking. Here's an XNA link for you which should direct you to an example. The idea is that you retrieve the 3D point in the game from the 2D point, and then can use standard collision detection methods to work out which object is occupying that space. Then you can elect to render that object differently.
One hack which might suffice if you have trouble with the picking approach is to render the character once as part of the scene, and then render it again at the end at half-alpha on top of everything. That way you can see the whole character and the wall, though you won't see through the wall as such.
One easy way, at least for prototyping, would be to always draw the player after you draw the rest of the scene. This would ensure that the player is rendered on top of anything else in the scene. Crude but effective.
Create a bounding volume from the camera to the extents of the player, determine what objects intersect that volume, and then render them in whatever alternate style you want?
There might be some ultra-clever way to do this, but this seems like the pretty straightforward version, and shouldn't be too much of a perf hit (you're probably doing collision every frame anyway....)
The simplest thing I can think of that should work relatively well is to model all obstacles by a plane perpendicular to your ground (assuming you have a ground.) Roughly assuming everything that is an obstacle is a wall with some height.
Model your player as a point somewhere, and model your camera as another point. The line in 3d that connects these two points lies in a plane that is particularly interesting to you, because if this plane intersects an "obstacle plane" below the height of the obstacle, that means that that obstacle is blocking your view of the player point.
I hope thats somewhat clear. To make this into an algorithm you'd have to implement a general method for determining where two planes intersect (to determine if the obstacle is tall enough to block view.)