First off, I'd like to note that I've seen the other topic trying to explain this.
I've read over the topic and tried to implement the math, but it doesn't seem to work. I'm probably doing something wrong.
For reference, I'm using C# in the Unity engine. I'm working on a game simmilar to Miegakure, in the fact that you "turn" to face the fourth dimension, seeing it in slices. This means that projecting 4D objects to 3D doesn't work. I need to get 3D Cross-sections.
I already have this working for my actual terrain itself, since it's voxels which makes it easy to change how the mesh generator iterates through the 4D world.
My current problem is non-voxel meshes. I want to have them in my world, for things like the player, and dynamic blocks that move from dimension to dimension (Therefore giving the effect of hypercubes)
In that post, they use some complicated vector math, which I don't think I understand.
So long story short, I just need a slightly better explanation. Does anyone have a link I can steal of an example from 3D>2D slicing, so I can try and extend it to 4D>3D?
Literally any help, even just a re-explanation of that previous post, or someone translating it to actual script, would be nice.
Thanks in advance!
Related
I'm stuck on collision detection:
I've read about different ways of dealing with collisions, and choose to implement it with AABB. Problem appears right in the beginning: I have my test object - wood tower, and I'd like to enclose it with AABB object, I'm iterating through vertices to find min and max values for each axis, which works ok, but takes a lot time, even for single one object (It's quite big object I think ~8000 vertices).
What is proper way of doing it? Should data like this be in object files or I'm just doing it wrong way? Object may be big (I don't know if it is), but it's just one object, I'm afraid about what will happen when I set more of them
I'm writing with c# and OpenTK
Edit:
I know I should use the simplified collision model, I'm trying to find the boundaries over which I will build the AABB box (I had the screen hooked up, but it looks like mods didn't like it). Iterating over each vector seems somehow wrong (although it works, I have a nice box, fitted to the size of the model, but not in the effective processing time)
Yes, you should do that when creating the model resource file. I think your calculation method is fine as is.
And then if this model rotates or scales in your game, make a new AABB from the OBB(which was the AABB loaded from the file before transformation).
I am currently facing a problem I cannot wrap my head around. In my 2D game which in the end should become some kind of virtual model railway, I can create a path, consisting of different railtypes. Each rail has it's own waypoints. Now the issue is as follows:
Straight rails don't need many waypoints, since they only need two to be defined; The start and the end point. Curves on the other hand need a lot more waypoints, so the objects movement on them is not all jaggy and unsmooth. The problem I am facing is, that the waypoints then are so unevenly distributed on the whole railway, it makes the speed which the object moves along the path very uneven.
I also already know the issue: The points are so cramped in the curve sections that the distribution looks like this:
See this picture for an example with red Gizmo.Spheres as waypoints
Now when I move an object along that said path, I do it like this:
wagon.transform.position = Vector2.MoveTowards(wagon.transform.position, wagon.GetNextPosition(), wagon.GetSpeed());
The third parameter of the method Vector2.MoveTowards() is the maxDistanceDelta, so it can only move that amount into the direction of wagon.GetNextPosition(), which is constantly updated.
The twist is, that the densly packed points result in a way shorter distance than the maxDistanceDelta. So in those parts of the railway, the object moves way slower then wagon.GetSpeed() per frame.
I already have a solution to this, which sadly I cannot use: I took every waypoint and distributed them evenly on the path. I don't want that; I want the path to stay as is, but the speed to the eye to be uniform.
Thanks in advance for your help!
PS: I already looked in similar threads, but none of those solutions seems to work for me :( Namely:
This thread
And this one
I would comment this but unfortunately I don't have enough reputation, so here it is:
The best idea I can think of is to create 2 waypoints for your curve (at the start and finish) and use a parabolic function to define the movement between them. So in other words, your train follows a parabola instead of moving towards waypoints directly.
I found a useful answer on a unity forum about parabolic trajectories which you may find useful for your project (It is the first answer beneath the question at the time of writing).
How are you generating those waypoints?
Could you use bezier curves instead?
If yes, there it's typical to run into exactly this issue and solutions have been found. Not solutions with absolute accuracy, but usually sufficient for games (aka visualizations that in the end only need to be as accurate as the pixels you see).
There is this outstanding video about the topic: https://www.youtube.com/watch?v=aVwxzDHniEw
I'm trying to make a truncated icosahedron, though with more subdivision (so more hexagons)
In the game I use it, eacht pentagon and hexagon is a separate object. So after generating the icosahedron, I just use the generated points to place either a pentagon or a hexagon on it (instead of doing the find-middles-of-each-triangle-thing, I do this since I need them to be separate object anyway.) I have some questions about it though, and google doesn't really help, so I'm hoping there are some smart smath-knowing people here :D
Here we go:
Am I assured that the length of each sides is equal?
Since each hexa/petagon is a separate object, I need to rotate them to get them positioned properly, any help with this?
Assuming I have hexa/petagons with a radius of 1 (one), how far for the middle do I have to position them? (Basecly, whats the relationship between the radius of my hexa/pentagons and the radius of my truncated icosahedron.)
Here's my first test, I generated a icosahedron and then on each point put a pentagon model, which I rotate so it's pointing away from the middle. As you can see they still need to be rotated to fit together (question 2) and their distance to the middle has to the tweaked aswell (question 3).
I'll continue on working on this too, though all help will be appreciated! (I'm making this in Unity, using c#, so if you give sample code, it would be really really awesome if you use that.)
Thanks a lot!
Well, not the answer to your questions but maybe worth thinking about:
Wouldn't it be easier to start with a ready made Blender, Maya, ... model of a soccer ball like for example this one on Blend Swap, change it to fit your needs. Or do it on your own as there are a couple of YouTube tutorials. Then you will have far more options like LOD, materials. You can design it in Blender with each pentagon/hexagon as single object and so it will be imported in Unity.
i'm trying to develop Pentago-game in c#.
right now i'm having 2 players mode which working just fine.
the problem is, that i want One player mode (against computer), but unfortunately, all implements of minimax / negamax are for one thing calculated for each "Move" (placing marble, moving game-piece).
butin Pentago, every player need to do two things (place marble, and rotate one of the inner-boards)
I didn't figure out how to implement both rotate part & placing the marble, and i would love someone to guide me with this.
if you're not familiar with the game, here's a link to the game.
if anyone want's, i can upload my code somewhere if that's relevant.
thank you very much in advance
If a single legal moves consists of two sub-moves, then your "move" for game algorithm purposes is simply a tuple where the first item is the marble placement and the second item is the board rotation e.g.:
var marbleMove = new MarbleMove(fromRow, fromCol, toRow, toCol);
var boardRotation = new BoardRotation(subBoard, rotationDirection);
var move = new Tuple<MarblMove, BoardRotation>(marbleMove, boardRotation);
Typically a game playing algorithm will require you to enumerate all possible moves for a given position. In this case, you must enumerate all possible pairs of sub-moves. With this list in hand you can move on to using standing computer game playing approaches.
Rick suggested tuples above, but you might want to actually just have each player make two independent moves, so it remains their turn twice in a row. This can make move ordering easier, but may complicate your search algorithm, depending on which one you are using.
In an algorithm like UCT (which is likely to outperform minimax for simple implementations) breaking into two moves can be more efficient because the algorithm can first figure out what moves placements are good, and then figure out what rotation is best. (Googling UCT doesn't give much. The original research paper isn't very insightful, but this page might be better: http://senseis.xmp.net/?UCT)
Imagine the following scenario: I have a level whose physical structure is built up from a collection of bounding rectangles, combined with prerendered bitmap backgrounds. My actors, including the player character, all have their own bounding rectangle. If an actor manages to get stuck inside a level block, partially or otherwise, it'll need to be shifted out again, so that it is flush against the block.
The untested technique I thought up during bio break is as follows:
If an actor's box is found to intersect a level box, determine where the centerpoints of each rect are. If the actor's center is higher than the level box's, move the actor so that the bottom of the actor's rect is flush with the top of the level's rect, and vice versa if it's lower. Then do a similar thing horizontally.
Opinions on that? Suggestions on better methods?
Actually, the bounding rects are XNA BoundingBoxes with their Z spanning from -1 to 1, but it's still 2D gameplay.
Have you read the N Tutorials? They're a wonderful introduction, complete with little demos, of Separating Axis Theorem based collision detection and simple projection response. (They're actually used in the N game to great effect.) The tutorials cover more than you need, but they're very general (extensible to many other shapes), and start to touch on issues with fast-moving objects and other response techniques.
Even if you do decide to go with something simpler than a SAT implementation, this may give you a lot of good ideas.
(When you're done with that and if you want your mind blown, try looking into some of the presentations from the Game Developers Conference physics tutorial day, including realtimecollisiondetection.net publications, the essentialmath.com tutorial slides, both of those books, and/or other stuff linked from those sites. I'd highly recommend the GDC session itself, too. While we still don't need or particularly want fancy GJK on swept hulls on the handheld game platforms we work with, some of the simpler concepts such as "configuration spaces" and Minkowski sums and differences have greatly influenced how I think about physics and collision detection and how we implement it.)
What the "real" physics engines do is find the minimum penetration vector. That is - the smallest vector that represents how far inside each other the two objects penetrate.
For an AABB (axis-aligned bounding box) this is really easy to calculate.
(Consider making your own 2D AABB structure, it will be smaller and therefore better for performance.)
Once you have your minimum penetration vector, you can perform collision response. And the easiest response is to simply separate the two objects by that vector (or separate the one object if the other is static).
Here is a good reference, by the makers of N on how to do this for convex polygons and circles. You should be able to simplify this down for AABBs.
A lot depends on the details. A complete solution could take into account velocities or other issues. But treating this simply...
You don't want to always resolve vertically first. Imagine an actor nudges horizontally into a block. If you resolve vertically first then the actor will pop up above that block, when a small horizontal movement would have sufficed.
Find what the vertical and horizontal movements would need to be to "get out of collision", and then apply the one with the smallest absolute value.
Then repeat a few times, in case the movement puts the actor into another block. But don't repeat forever, because the actor could be wedged somewhere that never resolves.
Maybe if your last movement still leaves you in collision, you could just average the last two movements and leave it there.
Another possible approach is, rather than waiting for a collision and then shifting out, check for possible collisions before you move objects and, if there is going to be a collision, move the player only up to the edge of the block.
I.e., contrast how Adventure does collisions with walls: http://www.youtube.com/watch?v=I6-zN_eaRd8
to how most NES games do collisions with walls.