I'm making a 3D game, and looking at the best method to have a floor plane as part of the 3D. If you imagine those games like TempleRun, but no turns, where you are moving forwards and the floor is scrolling backwards (towards the user) infinitely.
I already have my 3D object moving around X axis suitably (on a fixed Z plane), but now looking at adding a background, floor, etc.
I've been reading on Decal and Plane but uncertain as to which would be the best approach. I'd have the same floor structure on each level, but with different textures. Does one offer more expandability in the future? Eg, slopes, hills, etc. Each floor structure (whether Decal or Plane) would be repeating endlessly, and I'd see if I can create a fog effect which makes the floor fade with distance. Also it would have a tileable texture (eg grass, tarmac, dirt) which would be repeating backwards.
Perhaps even a static structure, and simply move the texture backwards?
Any thoughts would be great, thanks.
I would say don't go with decals, as these don't react to libgdx's environments (lights, shadow, an so on). And a Plane is just some class that represents plane and can't be rendered at all.
Simples solution: go to blender or any other 3d editing tool of your choice create a plane and apply your tillable texture to it.
Export it as .fbx and convert it to .g3db (libGDX's format).
Load it into your game and and make a couple of copies of it (ModelInstances).
Place those on the floor one after another so that no gap appears and they all form a nice repeating ground.
As your character moves forward check its position on X axis (or whatever axis you want to move on) and if the position is greater than position of your last plane on the floor - some distance than update floor as follows:
Remove the first plane from ground and add it after the last plane that you have.
(Render everything with ModelBatch)
If you have enough of these planes the player wont notice them appearing in the distance. Also use fog to completely hide this transitioning of planes.
The same can be applied not only to planes but repeating hill or any other tillable 3d object.
You could have some Planes made with meshpartbuilder (Like explained here) or even a Model made with an Application like Blender.
As you can create many ModelInstances out of one Model and give them different Materials, you can use the same Model over and over again. So you could create a 4x4 meter (for example) big Model (it will only be 1 face) on the XZ-Plane. Next you create, lets say 10, ModelInstances out of it and add them to each other:
first Plane: x = 0-4m, y = 0-0, z = 0-4m
second Plane: x= 4-8m, y = 0-0, z = 0-4m
And so on. As soon as your character is at a X Position > 4, you can translate the ModelInstance firstPlane foreward to the end of the 10th plane. So its new x would be 44-48 meters.
As soon as you reach a new level or another ground or whatever you can simply change the Material of the ModelInstance.
For the background i would suggest to read something about SkyBoxes.
Hope i could help
Related
I've recently been looking into LibGDX and seem to have hit a wall, seen in the picture, the blue dot represents the users finger, the map generation it self is where i seem to get stuck, does LibGDX provide a method of dynamically drawing curved objects? I could simply generate them myself as images but then the image is hugely stretched to the point of the gap for the finger can fit 3! But also would need to be 1000's of PX tall to accommodate the whole level design.
Is it such that i should be drawing hundreds of polygons close together to make a curved line?
On a side not i'll need a way of determining when the object has from bottom to top so i can generate another 'chunk' of map.
You don't need hundreds of polygons to make a curve like you drew. You could get away with 40 quads on the left, and 40 on the right, and it would look pretty smooth. Raise that to 100 on each side and it will look almost perfectly smooth, and no modern device is going to have any trouble running that at 60fps.
You could use the Mesh class to generate a procedural mesh for each side. You can make the mesh stay in one spot, locked to the camera, and modify it's vertices and UVs to make it look like you are panning down an infinitely long corridor. This will take a fair amount of math up front but should be smooth sailing once you have that down.
Basically, your level design could be based on some kind of equation that takes Y offset as an input. Or it could be a long array of offsets, and you could use a spline equation or linear equation to interpolate between them. The output would be the UV and X coordinates which can be used to update each of the vertices of your two meshes.
You can use the vertex shader to efficiently update the UV coordinates, using a constant offset uniform parameter that you update each frame. That way you don't have to move UV data to the GPU every frame.
For the vertex positions, use your Mesh's underlying float[] and call setVertices() each frame to update it. Info here.
Actually, it might look better if you leave the UV's and the X positions alone, and just scroll the Y positions up. Keep a couple quads of padding off top and bottom of screen, and just move the top quad to the bottom after it scrolls off screen.
How about creating a set of curved forms that can be put together variably. Like the gap in the middle will at the top and bottom of each image be in the middle (with the same curvature at end and beginning points)...
And inbetween the start and end points you can go crazy on the shape.
And finally, you can randomly put those images together and get an endless world.
If you don't want to stop in the middle each time, you could also have like three entry and exit points (left, middle, right)... and after an image that ends left, you of course need to add an image that starts left, but might end somewhere else...
I am programming a 2D, grid-based Pacman game. All the tiles are 8x8 in size. In-game, the map tiles are treated as 16x16, and the characters (Pacman and the ghosts) are treated as 32x32. In actuality, they are all pulled from a spritesheet of 8x8 tiles. I store positions as the center point of each character. Since the character tiles are bigger than the map tiles, the map is built in a way that requires the characters being able to "overlap" onto blocked tiles.
To deal with this set of problems, I created an invisible Rectangle and attached it to the character's position. Where the position is an (x,y) point, the Rectangle is a box surrounding that point. This rectangle is essentially 16x16 in-game, and is in the center of the character, which allows for the overlap necessary.
This works fine if you're working with 8px as the global movement speed, but I'd like to treat 8px as "100% speed" and have complete control over character speed with a double that is in the range [0,1). The positions are stored as double points, so on that level, this is fine. I read the positions back as integers, though, since I'm working with pixels.
So the question I ask is essentially "if this moves X amount of pixels to direction Y now, will my collision box be touching a blocked tile? But if you're moving 5px at a time, this eventually causes a very obvious issue. Say you're at x = 0, moving right. The tiles are 16x16 in-game, as stated before, and you have two of these open before the third, which is blocked. So you move, x = 5, x = 10, x = 15, x = 20, we just got to the 2nd tile, x = 25, x = 30, x = 35 now we're in the 3rd tile... but wait. We can't go there, because X = 35 collides. And unfortunately, we needed to turn and start moving down, but we can't, because now our Y-axis isn't aligned properly with the grid. Our X position needs to be 32, but can't.
My question for everyone here is, what are my options? What are some ideas or insights you have? I have a feeling I'm making it more difficult than I need to.
sounds like you have...
Why not give your "pac-man" sprite a velocity vector? The vector will describe not only the speed at which "pac-man" is traveling but in what direction, meaning you can see ahead.
"pac-man" should be calculating and ultimately making a decision based upon the following conversation..."hey, moving at this speed and in this direction..in so many seconds I'm going to hit a wall, when does that happen?". The seconds don't even have to be seconds...they could be "squares".
You would need a function which takes in the initial movement vector (direction and speed) which returns a coordinate of an X,Y point where "pac-man" must stop, where he cannot go further and must change direction (the center of a tile adjacent to a wall). Each time "pac-man" changes direction, run this calculation again...you do not need to keep checking if the next square is passable. If his direction hasn't changed and his speed is constant..you only need calculate once and let the coordinate system do the rest.
With this approach, square size and velocity is irrelevant...until "pac-man" hits or within his next movement exceeds the stopping point, continue to move along the vector.
At the moment I have a simple animation where a car (JPanel) approaches a junction where after it waits for traffic lights to turn green and continues straight on. However I'm going to the next step now where I want the car to turn 90 deg right in a smooth curve to turn onto the perpendicular road. I have sketched roughly how it looks and the curve represent the way I want the car to turn:
I'm not too sure how to do this. I suppose I would need to represent some sort of bezier curve? Or matrix transformation to rotate the car?
Can someone give advice on the best way to do this in Swing.
If you are new to graphics in Java, I recommend this tutorial. If I were to code what you are doing, I see two options.
First and easiest, you can model turning as "first driving straight, then turning 90º along the edge of a circle centred on the corner I am turning around, and then driving straight again". The easiest way to do this is to define a JPanel that draws your Image (yes, a JPanel; if you don't paint their background, you can layer JPanels on top of each other - and they will be painted in the correct order; make the background JPanel opaque so that it cleans up before drawing the next frame), and give it an AffineTransform that makes the image display in the position you want it to. You will need to adjust the increments in the transform so that the speed appears constant; trial and error, or a bit of geometry (90º of radius R implies R*pi/2.0 total travel along the curved path) , will help you out there.
The hard way is to consider the car's route to be an arbitrary Shape (which you can define using Bezier curves, for example), extract a flattened PathIterator from it, advance in equally-spaced jumps along that iterator, and calculate the rotation you need from the position along the curve and the heading at any given point (you can estimate the heading by taking 2 successive samples, and aligning the car according to these samples). This is harder than using the above method, but allows your car to follow arbitrarily complex paths.
I'm currently writing an application that actually acts as a "cut" tool for 3D meshes. Well, I had some problems with it now which I am clueless on how to solve, since it is my first application.
I have loaded a model from an object file onto the canvas, then on the same canvas, I use the mouse drag event to draw lines to define the cutting point.
Let us say I want to cut a ball into half and I draw the line in the middle. How do I detect the vertices of the ball under the line.
Secondly, if I rotate/translate the ball, would all the the vertices information change?
Think of what you'd do in the real world: You can't cut a ball with a line, you must use a knife (a line has no volume). To cut the ball, you must move the knife through the ball.
So what you're looking after is a plane, not a line. To get such a plane, you must use some 3D math. What you have is the canvas orientation and the "side view" of the plane (which looks like a line).
So the plane you're looking for is perpendicular to the canvas. A simple way to get such a plane is to take the canvas orientation and create a plane which has the same orientation and then rotate the plane around the line by 90°.
After that, you can visit all edges of your model and determine on which side of the plane they are. For this, determine on which side of the plane the end points of the edge are. Use the cross product. If they are on the same side (both results of the cross products will have the same sign), you can ignore the edge. Otherwise, you need to determine the intersection point of the edge and plane. Create new edges and connect them accordingly.
See this page for some background on the math. But you should find some helper methods for all this in your opengl library.
if I rotate / translate the ball, would all the the vertices information change
Of course.
It's not going to be that easy.
I assume the line you are drawing induces a plane which then cuts the sphere.
To do so, you have to calculate the intersecting area of the sphere and the plane.
This is not a trivial task and I suggest using an existing framework for this or if you really want to do this yourself, read about basic intersection problems to get a feeling for this kind of problem. This paper offers a good introduction to various intersection tests.
In general boundary represended volumes, as in your case, are difficult to handle when it comes to more advanced manipulations. Cutting a sphere in half is easy compared to burring a small hole into it. Sometimes it's better to use a volume representation, like tetrahedral meshes or CSG.
Regarding your second question, you shouldn't rotate or translate the sphere, rotate and translate the camera.
I'm building a pacman game. Basically, I want to have a map representation of this window consisting of blocks/tiles. Then as the pacman character/ghost moves i would change their position on the map to represent what's on the screen, and use that for collision detection etc.
How can I build this map, especially since the screen is made of x,y coordinates, so how can I correctly represent them in tiles/on this map?
I know it's tempting to start thinking of objects and interfaces but have you thought about a 2-dimensional array with each element representing 40 pixels or something? I don't remember pacman being pixel accurate when it came to collision, more a question of the direction each piece was moving in.
Generally you have an abstract representation that doesn't reference pixels as such (for example, maybe the Pac-Man maze is simply w units wide), and then you have a linear transformation (you know, y = mx + b) to carry the abstract representation to actual pixels.
To make it concrete, let's say that you want your abstract representation to be 100 units wide, and you want to render it as 400 pixels. Then the transformation is just scrn_x = 4 * x.
Kind of difficult to come up with this without writing it myself but.
First you'll need to create entity definitions that implement ICollidable. Entities would include ghosts, pacman, dots and powerups.
Each element in the map would contain, along with other information, a list of all present entities with a sort of "position" value for added precision. The ICollidable interface would include not only logic for determining which entities collide with one another (ghosts don't collide with dots for example.) but determining if they're in position to collide with one another. IE if pacman is entering a space from the right and a ghost is leaving that space from the left there's no collision. It will also help determine when exactly pacman has eaten a dot so that graphically it looks correct. IE if you destroy a dot right as pacman enters a space it's going to disappear before he even touches it graphically.
Your sprites such as pacman and the ghost are represented by positions (x,y). To determine if they collide with each other, use this psuedocode:
sprites = [ ... list of sprites ... ]
for i1=0 to len(sprites):
sprite1 = sprites[i1]
for i2 = i1+1 to len(sprites):
sprite2 = sprites[i2]
if (sprite1.x-sprite2.x)^2+(sprite1.y-sprite2.y)^2 < radius_of_sprites^2:
collide(sprite1, sprite2)
Note that this doesn't involve the map at all. We can check for collisions between pacman and the map separately. The key trick here is you divide the pixel coordinate of each of pacman's sides (top, bottom, left, right) and check for collisions. For example, if pacman is going to the right, we need to check the right edge for a collision:
pacman_tile_x = (pacman.x+tilesize/2)/tilesize # added tilesize/2 to check the middle of pacman
pacman_tile_y = pacman.y/tilesize + 1 # +1 because right edge is 1 tile to the right of the sprite's coordinate
if tile[pacman_tile_x][pacman_tile_y].is_a_wall:
... wall collide code ...
Now, if you have a huge number of sprites on the screen, you can optimize the sprite-to-sprite collision detection by storing which sprites exist on any particular tile in the map, and so you only have to check against sprites in adjacent tiles. But for a first pass and for this pacman game, it's probably not a necessary optimization.