I have a code that changes the position of an object when grabbed to 100 units in front of the camera, this allows the player to stand on top of an object and pick it up causing him to fly towards wherever the camera is pointing.
Example: In this picture, I stood on top of a movable red rock. While on top I picked it up and moved my camera upwards which caused the rock to move to that position while carrying the actor. Because of this, I can quickly move to anywhere on the map by standing on top of an object and picking it up.
The skeletal mesh is unrelated to the grab function and the range of the grab is set to keep movable objects close to the skeletal mesh (like lifting this pebble) if that helps.
Any suggestions on how to fix this issue? Thanks in advance!
Assuming that your objects have some sort of toggle-able state that determines whether they can be picked up or not. One solution to the problem you are facing would be to cast a ray from the bottom of the player and if that ray hits an object that can be picked up, temporarily disable the ability to pick the object up. This introduces a new problem of stacking up two objects and moving the bottom object however. Alternatively you could also change objects so that when you are holding them, the collider is disabled on the object. There are many more ways you could go about solving this issue, but without knowing in detail what you are trying to accomplish by holding objects, it would be hard for anyone but yourself to choose the appropriate solution.
Related
I currently have an ray-tracer that can read .obj models and then render the objects described on them. Until now, I was basically working with .obj models where the vertices where around the origin, generally closer than 10 of distance, at maximum being around 100.
Now, I downloaded a different model, where the vertices are far away from the origin, Always at least at hundreds of units from the origin, some vertices being about 5000 away in some axis.
The problem is that now I cannot focus the entire car!
One of my tests was with the distance from camera to origin of -3639.
And the result was this:
Then I step the camera away at -4639 and what was produced was this:
Changing my approach, decided to approach it, placing the camera at -2639
The result:
So at -2639 a I am being able to visualize the entire car but it does not fit in my field of view. At -3669 the light is already fading away by some reason.
I imagine that might be possible to see the full car proper lightened using a intermediate distance between -2669 and -3669 and also experimenting with the filed of view value, but there is something odd about the Light not covering the entire car at -3669 and I would like to find out the reason.
So I would appreciate suggestions about the cause of this issue and how to proceed in this kind of situation, how to focus the entire car.
Your question mentions you are changing the camera position. However, the images show the lighting area changing between the various cases. Just a spotlight in one case, and more of the car being lit in the other.
Most likely, in the third case, nothing of the car is lit, hence everything comes up black. Start by fixing the light staying the same when the camera moves, and see if it fixes your issue.
If you move the camera: It could help looking into the settings for the front and back clipping planes.
If you don't move the camera: The FOV show be larger if the object is larger. I would avoid doing this as this likely will lead to more problems when you read more than one object that are different.
Personally I would scale the input from the file. Ideally to some SI-unit that makes sense.
I'm currently making a game in the DirectX engine in c++. I'm using path-finding to guide an army of soldiers to a specific location. the problem is that I use raycasts to see if there is nothing in the way of my path, and this slows down the speed of the game. Is there a better way to do pathfinding?
I also have a problem with the moving of my army. Right now i'm using the average of soldiers' positions as the start point, which means all the soldiers need to go there first before moving to the end point. Is there a way to make them go to the end point without going to the startpoint?
Thanks for the help.
Have you tried something like A-Star? to navigate via nodes, or some sort of 2d-array representation of your map? written good it could possible be faster aswell as easier to do with jobs ( multithreaded ).
if you have a solider, who is at postion A, and needs to get to B.
just calulate the path from C(the avrage position what ever) to B. get the direction from a to b and do some sort of interpolation. ( havent done this, or tried it, but it could probablt work out pretty well!)
Are you hit-testing every object when you are raycasting?
That can be very expensive when you have many objects and soldiers.
A common solution is to divide your world into square grid cells, and put each object in a list of objects for that grid.
Then you draw an imaginary line from the soldier to the destination and check each cell what objects you need to hit test against. This way you will evaluate only objects close to the straight path and ignore all others.
One of the powerups in my game is a vortex that attracts all coins. I know I have any cocos2d's moveto/bezierto methods available, but I don't know how to make them have tangential and radial speed.
The extra difficulty is that the vortex center can change in every step, so all movement has to be readjusted.
One way to achieve this without a physics engine is to use the rotation around point algorithm.
That covers the rotation around the vortex center. Once an object is rotation around the vortex, all you need to do is to reduce that object's distance from the center by a certain amount every frame. That way it will continue to move inwards.
The only tricky part then is to get the object from its initial position being "sucked into" the vortex. There's going to be a lot of tweaking needed. With a physics engine, that part would come natural from the physics itself and it would always look right.
This is not guaranteed for the manual solution and definitely not for actions, which aren't designed to track moving targets. For example, if you change a move action every frame by replacing the existing one with a new one, your object won't move at all. Every time you do that, there's a 1-frame delay before the new action does its work.
I have been experimenting with the box2D sample project within cocos2D for the iPhone and am wondering if box2D is the appropriate engine to use to make a moving object "stick" to a stationary object when the moving object is finished moving in a certain direction.
Here is a simplification of what I am trying to achieve: I have MovingObject, a dynamic rigid body, that moves vertically against gravity when enough force is applied to it. As MovingObject moves, it may overlap a static object, StationaryObject. When gravity diminishes MovingObject's velocity to zero such that it is no longer moving, I would like to have MovingObject remain where it is ONLY if it overlaps StationaryObject. If the object's do not overlap, MovingObject should start to move back down towards the ground per the force of gravity. During that descent, if MovingObject at any time overlaps StationaryObject, it should stop its descent and remain in that location as if it is stuck on StationaryObject.
I am able to get MovingObject to move per the forces I am applying to it, but not really sure how to make it stop and stay there once it reaches the top of its ascent, assuming it is overlapping StationaryObject.
Currently, I am experimenting with simple square/box objects but eventually both MovingObject StationaryObject will be defined as very different complex polygon shapes.
Thanks in advance for any insights and/or suggestions for achieving this.
Sounds like you'll want to change the type of fixture used for "MovingObject" while it "ascending" and then change it when it is "descending" so that it reacts differently (to overlaps).
by "overlap" it sounds like you want to achieve something similar to "one sided platforms" in a platform game (ie; Mario Bros.) - I would recommend looking into the solutions for one-sided platforms for starters.
For Operating Systems class I'm going to write a scheduling simulator entitled "Jurrasic Park".
The ultimate goal is for me to have a series of cars following a set path and passengers waiting in line at a set location for those cars to return to so they can be picked up and be taken on the tour. This will be a simple 2d, top-down view of the track and the cars moving along it.
While I can code this easily without having to visually display anything I'm not quite sure what the best way would be to implement a car moving along a fixed track.
To start out, I'm going to simply use OpenGL to draw my cars as rectangles but I'm still a little confused about how to approach updating the car's position and ensuring it is moving along the set path for the simulated theme park.
Should I store vertices of the track in a list and have each call to update() move the cars a step closer to the next vertex?
If you want curved track, you can use splines, which are mathematically defined curves specified by two vector endpoints. You plop down the endpoints, and then solve for a nice curve between them. A search should reveal source code or math that you can derive into source code. The nice thing about this is that you can solve for the heading of your vehicle exactly, as well as get the next location on your path by doing a percentage calculation. The difficult thing is that you have to do a curve length calculation if you don't want the same number of steps between each set of endpoints.
An alternate approach is to use a hidden bitmap with the path drawn on it as a single pixel wide curve. You can find the next location in the path by matching the pixels surrounding your current location to a direction-of-travel vector, and then updating the vector with a delta function at each step. We used this approach for a path traveling prototype where a "vehicle" was being "driven" along various paths using a joystick, and it works okay until you have some intersections that confuse your vector calculations. But if it's a unidirectional closed loop, this would work just fine, and it's dead simple to implement. You can smooth out the heading angle of your vehicle by averaging the last few deltas. Also, each pixel becomes one "step", so your velocity control is easy.
In the former case, you can have specially tagged endpoints for start/stop locations or points of interest. In the latter, just use a different color pixel on the path for special nodes. In either case, what you display will probably not be the underlying path data, but some prettied up representation of your "park".
Just pick whatever is easiest, and write a tick() function that steps to the next path location and updates your vehicle heading whenever the car is in motion. If you're really clever, you can do some radius based collision handling so that cars will automatically stop when a car in front of them on the track has halted.
I would keep it simple:
Run a timer (every 100msec), and on each timer draw each ones of the cars in the new location. The location is read from a file, which contains the 2D coordinates of the car (each car?).
If you design the road to be very long (lets say, 30 seconds) writing 30*10 points would be... hard. So how about storing at the file the location at every full second? Then between those 2 intervals you will have 9 blind spots, just move the car in constant speed (x += dx/9, y+= dy/9).
I would like to hear a better approach :)
Well you could use some path as you describe, ether a fixed point path or spline. Then move as a fixed 'velocity' on this path. This may look stiff, if the car moves at the same spend on the straight as cornering.
So you could then have speeds for each path section, but you would need many speed set points, or blend the speeds, otherwise you'll get jerky speed changes.
Or you could go for full car simulation, and use an A* to build the optimal path. That's over kill but very cool.
If there is only going forward and backward, and you know that you want to go forward, you could just look at the cells around you, find the ones that are the color of the road and move so you stay in the center of the road.
If you assume that you won't have abrupt curves then you can assume that the road is directly in front of you and just scan to the left and right to see if the road curves a bit, to stay in the center, to cut down on processing.
There are other approaches that could work, but this one is simple, IMO, and allows you to have gentle curves in your road.
Another approach is just to have it be tile-based, so you just look at the tile before you, and have different tiles for changes in road direction an so you know how to turn the car to stay on the tile.
This wouldn't be as smooth but is also easy to do.