I'm creating a side-scroller video game for my final project in my grade 12 programming class. Right now I have nice delta-timer my partner made for me, a flying ship, asteroids, and a scrolling background. I've added a few basic things such as collision detection between asteroids and the ship, and ship movement. Now, my next steps are implementing random enemy spawns, and projectiles (laser beams :D) from both ships. Implementing random enemy spawns should fun and relatively easy, however I'm struggling with figuring out how I will create so many bullets that will fit on the screen. I need bullets from the enemy, and the ship (player controlled).
How can I achieve this? I know there are probably many answers to this question, but I would really like to see the types of approaches people have to this problem.
So far I have thought that:
a) I could make the game have a (say) 200 bullets max on the screen
b) I could make a dynamic array (I believe this term means the array gets bigger or smaller), that way I don't limit the amount of possible projectiles
...and then I'm afraid that all these bullets will cause lag from all the collision processing that will happen.
Please shed some light on this, and help guide me along the path to an efficient; well executed; side-scroller game.
Thanks,
Guest dude
I'm new to x3d/vrml and I'm trying figure out how to punch a hole in a solid shape. For example, a 6x6x2 cube with a smaller 2x2x2 cube in the middle to create a hollow shape. I have tried extrusion and indexedFaceSet without success. I haven't found any tutorials that show me how to do this. Therefore, A working example would be useful to me as well as others .
Normally you don't create this kind of shapes manually. Of course it is possible to use the IndexedFaceSet node in order to achieve this but it's much better and easier to use a tool (e.g. 3D Studio Max) where you can create shapes using a graphical interface. Then you export the file to X3D or VRML or whatever and you'll see the IndexedFaceSet there and possibly the complexity of the node (I mean the node values which are nearly impossible to determine by yourself).
In your specific case you could use 4 cubes that are intersecting and leaving a hole in the middle...this would be just a tricky solution.
I have some code that draws a cube. I've managed to rotate the cube using glRotatef but I need to be able to rotate the cube using only matrix multiplication. I know what matrices to use but I'm not sure how to apply them to the vertices of the cube. Is there a way to pass a vector to glVertex3f? Or a way to pass an array of vertices?
I agree completely with Drew's answer. However, I figured I'd point you in the direction of a nicely-written tutorial series that shows these concepts in action:
http://en.wikibooks.org/wiki/OpenGL_Programming
Start with the first 3 tutorials to learn shader basics, and then the 4th and 5th tutorials dive into rotation with triangles and cubes. Also, the examples use FreeGLUT, which is a framework that allows you to easily interact with your code using key presses, mouse movements, mouse presses, and more.
The OpenGL functions you're using are for immediate-mode rendering, and the vertex transformations are done within OpenGL. If you want to manually transform the vertices outside of OpenGL, you'll have to either implement matrix * vector multiplication, or use a library that does this for you.
As a side note, if you're just interested in rotation, you may find Rodrigues' rotation formula easier to implement than general matrix transformation.
So, to start off, I'm not very good at computer graphics. I'm trying to implement a GUI toolkit where one of the features is being able to apply 3D transformations to 2D "layers". (a layer only has one Z coordinate, as pre-transform, it's a two dimensional axis aligned rectangle)
Now, this is pretty straightforward, until you come to 3D transformations that would push the layer back, requiring splitting the layer into several polygons in order to render it correctly, as illustrated here. And because we can have transparency, layers may not get completely occluded, while still requiring getting split.
So here is an illustration depicting the issue and the desired outcome. In this scenario, the blue layer (call it B) is on top of the red layer (R), while having the same Z position (but B was added after R). In this scenario, if we rotate B, its top two points will get a Z index lower than 0 while the bottom points will get an index higher than 0 (with the anchor point being the only point/line left as 0).
Can somebody suggest a good way of doing this on the CPU? I've struggled to find a suitable algorithm implementation (in C++ or C) that would be appropriate to this scenario.
Edit: To clarify myself, at this stage in the pipeline, there is no rendering yet. We just need to produce a set of polygons for each layer that would then represent the layer's transformed and occluded geometry. Then, if required, rendering (either software or hardware) is done if required, which is not always the case (for example, when doing hit testing).
Edit 2: I looked at binary space partitioning as an option of achieving this but I have only been able to find one implementation (in GL2PS), which I'm not sure how to use. I do have a vague understanding of how BSPs work, but I'm not sure how they can be used for occlusion culling.
Edit 3: I'm not trying to do colour and transparency blending at this stage. Just pure geometry. Transparency can be handled by the renderer, and overdraw is okay. In this case, the blue polygon can just be drawn under the red one, but with more complicated cases, depth sorting or even splitting up the polygons may be required (example of a scary case like that below). Although the viewport is fixed, because all layers can be transformed in 3D, creating a shape shown below is possible.
So what I'm really looking for is an algorithm that would geometrically split layer B into two blue shapes, one of which would be drawn "above" and one of which would be drawn below R. The part "below" would get overdraw, yes, but it's not a major issue. So B just need to be split into two polygons so it would appear to cut through R when those polygons are drawn in order. No need to worry about blending.
Edit 4: For the purpose of this, we cannot render anything at all. This all has to be done purely geometrically (producing 2D polygons). This is what I was originally getting at.
Edit 5: I should note that the overall number of quads per subscene is around 30 (average). Definitely won't go above 100. Unless the layers are 3D transformed (which is where this problem arises), they are just radix sorted by Z positions before being drawn. Layers with the same Z position are drawn in order in which they were added (first in, first out).
Sorry if I didn't make it clear in the original question.
If you "aren't good with computer graphics", Doing it on CPU (software rendering) will be extremely difficult for you, if polygons can be transparent.
The easiest way to do it is to use GPU rendering (OpenGL/Direct3D) with Depth Peeling technique.
Cpu solutions:
Soltuion #1 (extremely difficult):
(I forgot the name of this algorithm).
You need to split polygon B into two, - for example, using polygon A as clip plane, then render result using painter's algorithm.
To do that you'll need to change your rendering routines so they'll no longer use quads, but textured polygons, plus you'll have to write/debug clipping routines that'll split triangles present in scene in such way that they'll no longer break paitner's algorithm.
Big Problem: If you have many polygons, this solution can potentially split scene into infinite number of triangles. Also, writing texture rendering code yourself isn't much fun, so it is advised to use OpenGL/Direct3D.
This can be extremely difficult to get right. I think this method was discussed in "Computer Graphics Using OpenGL 2nd edition" by "Francis S. Hill" - somewhere in one of their excercises.
Also check wikipedia article on Hidden Surface Removal.
Solution #2 (simpler):
You need to implement multi-layered z-buffer that stores up to N transparent pixels and their depth.
Solution #3 (computationally expensive):
Just use ray-tracing. You'll get perfect rendering result (no limitations of depth peeling and cpu solution #2), but it'll be computationally expensive, so you'll need to optimize rendering routines a lot.
Bottom line:
If you're performing software rendering, use Solution #2 or #3. If you're rendering on hardware, use technique similar to depth-peeling, or implement raytracing on hardware.
--edit-1--
required knowledge for implementing #1 and #2 is "line-plane intersection". If you understand how to split line (in 3d space) into two using a plane, you can implement raytracing or clipping easily.
Required knowledge for #2 is "textured 3d triangle rendering" (algorithm). It is a fairly complex topic.
In order to implement GPU solution, you need to be able to find few OpenGL tutorials that deal with shaders.
--edit-2--
Transparency is relevant, because in order to get transparency right, you need to draw polygons from back to front (from farthest to closest) using painter's algorithms. Sorting polygons properly is impossible in certain situation, so they must be split, or you should use one of the listed techniques, otherwise in certain situations there will be artifacts/incorrectly rendered images.
If there's no transparency, you can implement standard zbuffer or draw using hardware OpenGL, which is a very trivial task.
--edit-3--
I should note that the overall number of quads per subscene is around 30 (average). Definitely won't go above 100.
If you will split polygons, it can easily go way above 100.
It might be possible to position polygons in such way that each polygon will split all others polygon.
Now, 2^29 is 536870912, however, it is not possible to split one surface with a plane in such way that during each split number of polygons would double. If one polygon is split 29 timse, you'll get 30 polygons in the best-case scenario, and probably several thousands in the worst case if splitting planes aren't parallel.
Here's rough algorithm outline that should work:
Prepare list of all triangles in scene.
Remove back-facing triangles.
Find all triangles that intersect each other in 3d space, and split them using line of intersection.
compute screen-space coordinates for all vertices of all triangles.
Sort by depth for painter's algorithm.
Prepare extra list for new primitives.
Find triangles that overlap in 2D (post projection) screen space.
For all overlapping triangles check their rendering order. Basically a triangle that is going to be rendered "below" another triangles should have no part that is above another triangle.
8.1. To do that, use camera origin point and triangle edges to split original triangles into several sub-regions, then check if regions conform to established sort order (prepared for painter's algorithm). Regions are created by splitting existing pair of triangles using 6 clip planes created by camera origin points and triangle edges.
8.2. If all regions conform to rendering order, leave triangles be. If they don't, remove triangles from list, and add them to the "new primitives" list.
IF there are any primitives in new primitives list, merge the list with triangle list, and go to #5.
By looking at that algorithm, you can easily understand why everybody uses Z-buffer nowadays.
Come to think about it, that's a good training exercise for universities that specialize in CG. The kind of exercise that might make your students hate you.
I am going to come out say give the simpler solution, which may not fit your problem. Why not just change your artwork to prevent this problem from occuring.
In problem 1, just divide the polys in Maya or whatever beforehand. For the 3 lines problem, again, divide your polys at the intersections to prevent fighting. Pre-computed solutions will always run faster than on the fly ones - especially on limited hardware. From profesional experience, I can say that it also does scale, well it scales ok. It just requires some tweaking from the art side and technical reviews to make sure nothing is created "ilegally." You may end up getting more polys doing it this way than rendering on the fly, but at least you won't have to do a ton of math on CPUs that may not be up to the task.
If you do not have control over the artwork pipeline, this won't work as writing some sort of a converter would take longer than getting a BSP sub-division routine up and running. Still, KISS is often the best solution.
I am new to stack overflow and new to 3D graphics programming. I have been given the task of creating an app that will read in data (currently I am reading from a delimited text file, but eventually will read from data arrays) and to graphically display the data in 3D. The data is x,y,z coordinates read from a 3D scanner which is scanning logs. I need to show the 3D representation of these logs on screen, from 4 different angles. I am reading the data into a 2-dimensional Point3D array and then using it to create 3D models in a HelixViewport3D. I use a nested for loop to check that the data points in the array are within certain x,Z bounds- and if they are I need to create a triangle out of that data. Once the entire array is passed through, I add the Model3DGroup to the children of my viewport:
topModel.Content = topGroup;
this.mainViewport.Children.Add(topModel);
It takes about 8 seconds for this to take place and zooming,panning, rotating are very very slow with all this data on the screen (around 500,000 triangles). Are there any ways to improve performance of WPF 3D graphics? I actually don't need to be able to zoom/pan/rotate in the finished app but it is helpful for debugging. The final app will simply be the same model shown statically 4 different ways, from different sides. However, I need to be able to read in the data and get the graphics to display in 1-5 seconds. Any help is greatly appreciated, and I hope my question is fairly clear!
EDIT: After doing some more digging into vertex buffering, this is what I need to do. I am using way too many points. If anyone can point me to some literature on doing vertex/index buffering in c#, it would be greatly appreciated!
I have solved this issue. Thanks for the input Capt Skyhawk! You saying that you doubted this was a WPF3D shortcoming helped me look in the right places. My problem was that the way I wrote this made every triangle it's own ModelVisual3D!! I re-wrote the code to contain only 3 GeometryModel3D (sp?) objects, and all the triangles are placed in a MeshGeometry3D and then the mesh is used to create a model. This made the models render in < 0.1 seconds. I now have a new issue- for some reason only about half of the triangles are showing up in the model in my viewports. I'm not sure why, though it may be that I have too many Point3D points or too many triangle indices in my mesh.
I doubt this is a shortcoming in WPF3D. It's more than likely the loading process. Parsing a text file with 500,000 triangles(even more points!) is where the bulk of the processing time is being spent.
If the loading of the text file is not being included in the 8 seconds, something is very wrong.
Are you using index buffers? If not, you're shooting yourself in the foot with that many vertices.