Advertisement Jump to content
  • Advertisement

breakin

Member
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

158 Neutral

About breakin

  • Rank
    Member
  1. I'm going to suggest a book. http://realtimecollisiondetection.net/books/rtcd/ It deals with many structures that are needed in collision detection. It might be nice since it is written for people who wants to do collision detection (rather than say occlusion culling). After reading the book you might decide to use Octree, BVH or something other. Perhaps you decide not to do it yourself and use a existing library instead. There is also a list of all papers referenced from the book. If you don't want to borrow/buy it, perhaps you can find something in there! http://realtimecollisiondetection.net/books/rtcd/references/index.html
  2. BSP-trees are not used that much anymore due to the fact that they operate on triangles and not on objects. Today is often better to just draw an object, rather than to spend time on determining what triangles are visible are what are not. Z-buffer makes back-2-front-rendering obsolete. Ordering draws front-2-back is better with Z-buffer since then most pixels are only rendered once. For collision purposes I think that loose-octrees or octrees or any other structure than BSP-trees is the best! BSP-trees are hard to update when things move and it is hard to get rid of all numerical problems. That said, I think BSP-trees are really cool, they just don't make that much sense nymore.
  3. Hm one more point though. It is often true that TxB=N but in case the winding of the triangle in UV-space is different form the winding in worldspace, it should be TxB=-N You must calculate both tangent and bitangent. You could do calculate T,B calculate N calculate TxB calculate f=(TxB) dot N sign = f>0 and store N,T,f (just one bit!). Then you can flip the sign of B based on f. Where t store that one bit is another matter, not sure what is best ;)
  4. Hi! I think the main problem is that you don't calculate the tangent vector at all, but something else. I really like the derivation of how to calculate tangent/bitangent-vectors found at http://www.terathon.com/code/tangent.html . There is also source code for how to do it! Hope this helps!
  5. Hey. Let me answer another question instead. Easiest way to do picking is often this: * Render object-ID/triangle-ID in 16x16 pixels around the pixel where the mouse cursor is. You can do frustum culling vs this small rectangle so most objects are rejected. * Read back to CPU and check. Fairly fast for small framebuffers. Hard part is precision, but if you set up your ID's correctly you can obtain back the ID correctly on the CPU. If you don't have precision to have a unique ID for each triangle in the scene, consider: A) first determine object-ID and then polygon-ID within that object using two passes. B) write two integers (perhaps using multiple render targets). Object-ID in the first one and polygon-ID in the second one. Why is this easier? You can reuse your renderingversion of your object. No need for collision friendly versions at all. If you want to know where in the triangle you are picking, you have to do ray<>triangle-intersection, but that is easier than doing ray<>scene-intersection. I guess you could do the same thing to get a small zbuffer using shaders and storing depth encoded as colors somehow (just as you store int as colors in the approach outlined above), but then you still have to find where that point is in your scene (ie on what triangle).
  6. breakin

    Help on Exponents

    Is that (2*3)^n - ( 3^(n+2) / 3^(n+1) ) or ( (2*3)^n - 3^(n+2) ) / 3^(n+1) or something else ?
  7. Unless there is really really much content, perhaps XNA is a good platform. Since you've already mentioned DirectX and Visual Studio, I'm assuming that Windows only is fine with you. Using XNA you get access to Xbox 360 as well, and can use the digital distribution channel there. You could of course first make the game and try getting a publisher interested, might be easier to prove yourself by making one game yourself though and publish it yourself. Might make a buck or two that way as well...
  8. breakin

    About GLSL

    In the vertex shader, the coordinate that was set using glVertex3f (or perhaps put in some kind of buffer) can be found using gl_Vertex. I'm guessing you are using gl_Position = ftransform() but that functions is mostly equivalent to gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; (read more at http://www.lighthouse3d.com/opengl/glsl/index.php?minimal). If this is indeed what you do, that mean that (in the vertex shader) vec4 viewSpacePosition = gö_ModelViewMatrix * gl_Vertex; will give you the view space position of the vertex. To get the world space position, you have to work some more (then you can't use the MODELVIEW matrix alone). Hope this helps, feel free to post more questions on my confusing answer!
  9. breakin

    Lighting

    Quote:Original post by kaiser83 isn't per pixel lighting supposed to be a better solution to lightmaps? as far as i understand it was a technique used long ago and has been phased out? No. They just solve different problems. Quote:Original post by kaiser83 in any case my main problem is that the lighting is too dark in some areas and blindingly bright in others (depends on how the camera is facing) If you only use diffuse lighting then lighting shouldn't change as you move the camera. If it does, it's a bug. That is a good way to test that you do all your calculations in a good way.
  10. breakin

    Lighting

    Quote:Original post by kaiser83 Hi I need help with the lighting in my scene is there anyway to make things look somewhat realistic without having to resort to raytracing? Compared to per-pixel lighting raytracing will give you one thing; shadows. But this you can do in realtime as well using shadow mapping. (OK so it can give you transparent shadows etc as well...). It is not that easy to implement but I'd try some shadow mapping to improve the visual look. Especially if you find one with blurry edges. Variance shadow mapping can do this, as well as PCF-filtered shadow maps. As supagu said one can try lightmaps we well, to get the raytraced result in realtime. One could then also include expensive indirect effects that a simple raytracer won't give you, such as global illumination. I'd say this is somewhat harder if you are new to the game, unless you find a finished tool that does this. One example is Blender that can create unique UV-sets for your world and then bake direct illumination. To do all of this yourself is tedious and hard, compares to shadow mapping. Most new games uses lightmaps for static lights and shadow mapping for dynamic lights. Another option is to store the indirect effects from static lights in lightmaps and then add the direct contribution using shadow mapping since that gives better results.
  11. breakin

    Am I to old to start?

    Hi! I think the real question is if it's too late to start programming at 28. I think not. One does not have to be as hardcore as some years ago. Today it's easier than ever to make a game. Maybe start by hello world and then not too much later you're doing a XBLA-game (Xbox Live Arvade, xbox-360 distribution channels for homebrew games) using XNA. Then it's down to good ideas and your ability to work in a team. This you might already have experience with! To make a triple-A game in C++ is another matter but if you want to go there as well, you can. But just do whatever is fun and possible and work from there! Remember; Small teams means more fun. And that often means smaller games!
  12. I'm not sure about the exact timings, the recommandation seems to wait at least 2-3 frames for the results (depending on double or triple buffering). The card is supposed to buffer for the coming X frames but if you wait for results that goes out the window since the previous frames needs to be fully completed before you can start with the next one. They are mostly used conservatively to determine things for an time interval. Like is the (swept) bounding box of this object visible? Ie will it become visible in 2-3 frames or can I keep not drawing it, etc... On some consoles it can be much faster though (or so I've heard!)!
  13. breakin

    OpenGL3.0.. I mean 2.2

    Quote:Original post by V-man What "stability benchmarks"? Where are they? Oh forgot about the benchmark. ATM I guess there are none, but someone (this could be a guy/girl at Nvidia/ATI/Intel internally, or someone else for all to use) probably could do a better job testing the non-deprecated subset than all of OpenGL. For instance Khronos could create a test-suite with reference images. Or perhaps some reference rasterizer or something. Point is that the subset to test would be smaller, if they only wanted to please game developers and all of those could jump on the 3.0 train. Problem here is older card that now won't support OpenGL3 so I'm guessning not nearly as many as supposed to can jump.
  14. breakin

    OpenGL3.0.. I mean 2.2

    Quote:Original post by V-man Quote:Original post by breakin Many things that were extensions were hard to find information about and were poorly documented. They have now been merged into the GL3 specification (vertex buffer objects, fragmebuffer objects etc). Writing fast GL code now seems way more accessible for newcomers. The bar has been raised a bit with OpenGL3. A single document now includes all the extensions one need to write a program that adheres to the fast path (previously that was in extensions). Less features are non-depracated, limiting the tutorials that now need to be written. Visible fast path if someone does a clean GL3 specification document. And stability benchmarks that only tests the newer portions might be prioritized by driver developers, leading to more stable implmentation of those. Have you even looked at the spec once in your life? The spec isn't going to help a newb program. A spec is not an SDK. There are no code samples in it. What "stability benchmarks"? Where are they? "Writing fast GL code now seems way more accessible for newcomers." Are you sure about that? Sure I've looked at the spec. It hasn't always helped me out, but mostly so since it's missing what I need (that were in extension documents instead), and since it had too much (things that now have been depracated). And since there were so few tutorials around describing the non ARB-extensions (such as FBO) I had to rely on the extensions documents. And that sucked since they were written as diffs. I hate that. I'm nog saying that newcomers have it easy; immediate mode was quite nice for newbies. Fixed-function pipeline with light sources and materials was neat too. But what I mean is that if they produce specification and tutorials that only includes the non-deprecated stuff, I think the GL parts of what one has to learn is much less now. I mean stuff can only be done in one way now and that is the way that is fastest with OpenGL. Sure that way is not as efficient as D3D, but that is another story. I also think that tutorials must be created to complement the specification. Problem before was that tutorials started out in the wrong end with specifying the easy-to-teach but slow-to-use things (think NEHE tutorials). Now there is only one way so all GL3-tutorials will have to use Vertex Buffer Objects and Shaders. Let's hope that the opengl-site collect OpenGL3-tutorials and labels them as such. And then when the tutorial is not enough one might have to turn to the specification (I know I did). And if most of what is used is in that one document, that really helps. Needing the extension registry is not all that helpful (even though it does contain the occasional code example). I'm not saying that I like the new specification. I'd rather have an object-oriented framework that could be used in multi-threaded contexts. And I wouldn't mind to make it easy for the driver developers by validating at creation, as well as actually removing all the deprecated shit. What I'm saying is that the new leaner non-deprecated subset could have huge educational benfits ). Ah well.
  15. breakin

    OpenGL3.0.. I mean 2.2

    So I too think it is sad that GL3 is not all that it could have been. Especially I don't think they helped the people who write drivers to provide more reliable drivers, something I think is a major problem. Also they won't get much faster due to lack of the new object model. But there is a good thing in here for the hobby enthusiast. There is now actually a visible fast path. Ok sure you can't guess it from the API but now it will be possible for Khronos to publish a PDF with GL3 only.. with all the depracted stuff removed from the manual. This way it will be easy for newcomers who are yet to write that 5% code (which is 100% of the code since many starts with the OpenGL part anyway). Many things that were extensions were hard to find information about and were poorly documented. They have now been merged into the GL3 specification (vertex buffer objects, fragmebuffer objects etc). Writing fast GL code now seems way more accessible for newcomers. My major problem with OpenGL for newcomers who doesn't care about backwards compability (say they require OpenGL 2.1 with framebuffer objects) were these: * No single document to read. Had to diff specification vs extensions. * Hard to know what the fast path was * Poor tutorials on new features (such as FBO) * Poor driver support for new features (especially on my ATI laptop) The bar has been raised a bit with OpenGL3. A single document now includes all the extensions one need to write a program that adheres to the fast path (previously that was in extensions). Less features are non-depracated, limiting the tutorials that now need to be written. Visible fast path if someone does a clean GL3 specification document. And stability benchmarks that only tests the newer portions might be prioritized by driver developers, leading to more stable implmentation of those. So there sure is some good things is this incremental update of OpenGL! Not all is good, but some things are better. Expected a bit more though. But I think that things are great. Just hate to wait for drivers to catch up yet again ;)
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!