Advertisement Jump to content
  • Advertisement

ak-73

Member
  • Content Count

    116
  • Joined

  • Last visited

Community Reputation

160 Neutral

About ak-73

  • Rank
    Member
  1. Would be Slick recommended for 2D? The nice thing about JME is that it offers the support of an entire engine. while slick is only a 2D library from what I gather. Since both are based on lwjgl - can the two be combined? Alex
  2. Sorry, I looked for a Java forum on the main forum page and must have overlooked it. My initial research made me stumble across the name jMonkey Engine - but before delving into it, I figured I'd ask some people who know the deal for their opinion. [EDIT] Bonus question: the features page of jMonkey doesn't mention 3D sound. True? What to use instead? JOAL? Alex
  3. Hi gamedev.net! Long time no see. Anyway, I have to code a small game (probably 3D) for a university project in Java and I would like to know if you can recommend any Java game engines to me. That's all, Alex PS If wrong forum, sorry, please move.
  4. ak-73

    Collision Handling

    Quote:Original post by oliii Could be, but the SAT is simple and already very efficient. I doubt it's a lot faster than the SAT, when fully optimised for triangle / triangle. I'd just run with it. Their method involves calculating the line of intersection between the planes of both triangles and then projecting the tris onto that axis only. Quote: It also depends what sort of information you are able to extract from it. The SAT can return you the MTD vector. I have been looking at the PolygonPolygon code and some questions remain: 1. The time of collision is calculated by measuring the deepest penetration of any axises, is that correct? Is that an *approximation* of collision time? 2. The normal of the collision is also derived from that? The axis of deepest penetration? 3. Why does t_exit < 0 mean objects behind each other? I'm not sure I get this quite right. Thanks, Alex
  5. ak-73

    Collision Handling

    Quote:Original post by oliii Pretty much the same, when you have two convex polytopes (box, pyramid, prism, even triangles and convex polygons). in 3D, what you need from both objects are a list of face normals, and edge directions. the axes to tests are face normals and cross products of edges. However for the 3D version, I would use the object's projected intervals though to calculate the intersection and collision data. Follow-up question: Möller/Haines claims their interval overlap method is faster than SAT for detecting tri-tri intersections. Can anyone confirm that? (Because SAT seems to be much better documented than their method.) Alex
  6. ak-73

    Collision Handling

    Thanks a lot I will have to dig into this. :-) Alex
  7. ak-73

    Collision Handling

    How does that translate (lol, no pun intended) into 3 dimensions though? Alex
  8. ak-73

    Collision Handling

    Quote:Original post by Buckeye It sounds like you're doing several physics timesteps for every collision detection call. If so, it won't be perfectly smooth, but that may be acceptable. When a collision is detected (don't know what line segments you may be determining), the bodies will have interpenetrated. Calculate the point of intersection, the depth of penetration and a normal vector at the collision point. That gives you the plane of collision. Between two arbitrarily intersecting triangles, I suppose I can take the middle of the intersection line segment as collision point. How do I derive the normal vector of the collision though? Quote: Only after all collisions have been detected, calculate the force on each body due to all collisions on that body that timestep. Use those forces to change the body's velocity and torque (if you use torque). So I am going to let the bodies interpenetrate in that timestep? Wouldn't I have to calculate the time of collision and integrate with the post-collision forces only for the remaining time interval within the the current timestep? Quote: You don't. You don't apply physics ("getting tossed back") until after all collisions have been detected. When you detect collisions, there's either a collision between two bodies or not in that timestep. If there's going to be a "secondary" collision, that will be detected during the next collision detection cycle. If the actions of your bodies seem too coarse for your taste (e.g., too much interpenetration), perform the collision detection more often. Oh, okay. thanks. Alex
  9. ak-73

    Collision Handling

    Hi! I am programming a 3D space shooter. I am at the point where I can do interscetion tests for my spaceships now and get reported back whether an intersection has taken place and what the line segments of intersection are. I also read a bit of Chris Hecker's articles and the wikipedia article on collision response and I am not sure if I get the next steps quite together. I guess I need to determine the exact time of collision, probaly using a binary search by adjusting the timestep. How do I deal with the line segments though? Is it possible to condense this to one central collisiob point? And how do I find the plane of collision given that I am colliding two arbitrary meshes? I'm trying to get the basics implemented without things getting too complicated here. (And: how do deal with a colliding spaceship possibly getting tossed back into *another* spaceship causing a *secondary* collision in the same timestep?) Plenty of questions, I know, but if you could lift my uncertainty about some of them, I'd be grateful. Alex
  10. ak-73

    Lasers and Lights

    I fear I am going to need to do it in the shader then... :-) Deferred lighting would be an option but I don't want to make such a significant change to the rendering pipeline at this point. As for line lighting, the question would be then to choose the angle at which the light should fall in. Orthogonal projection onto the beam doesn't strike me as right as the light would come from the side. I figure I would have to calculate the orthogonal projection point and then move a bit along the beam towards the camera for a point of origination in order to have some satisfying result. And fortunately I have no shadowing implemented... :-) thanks, Alex
  11. Hi! I'm coding my own 3D space shooter, I have laser fire set up, collision detection is also working. One thing I noticed though is that the laser fire *should* also illuminate the objects it hits or passes nearby. Any suggestions on how to handle that? Do I have to dynamically create a point light and place it somewhere on the beam's path for every object that the beam passes close enough? For every beam/nearby object in view? That sounds expensive... Alex
  12. ak-73

    Triangle-Triangle Intersections

    Quote:Original post by GMano Quote:Original post by ak-73 What's a manageable number though? Any rule of thumb? This really is dependent on your engine, application, target hardware, etc. What is often done pre-process is that some sort of bounding tree structure is generated (quad/oct tree, k-d,bsp, etc.) and you can specify how many polys to allow in the leaf nodes of the tree, then empirically determine how many polys per leaf gives you the best performance. In a usable engine, you will often find that you have to use several different techniques to do what you want. You may use raycasts for things like bullets, simple bounding proxies for objects like crates, barrells, rocks, etc., hierarchies of bounding proxies for characters, and some sort of space partitioning tree with sets of tris as leaves for the terrain. The right tool for the job to be done. It is up to you to determine what kind of accuracy you need for your collisions, and how much time/memory/cpu/gpu/etc. budget you have to do it. Preprocess seems a bit overkill. I am writing a simple 3D space-shooter and I'd just like to implement basic but efficiently enough working collision detection to pick up some basic understanding of that issue at hand. After all I have yet to implement an enemy ai which I'd like to pour more time and energy into. Right now I am planning to divide spaceship geometry into different vehicle parts first (these will be individually damageable, leading to a natural first division layer) and then, for the sake of simplicity to divide meshes with a too high polycount into submeshes by hand. Any thoughts on that? Sensible approach, given the game I am trying to code? Alex
  13. ak-73

    Triangle-Triangle Intersections

    Quote:Original post by GMano The way it is usually done in a game engine is that you do a broadphase collision tests first using bounding volumes of some sort, and only test tri/tri collisions when necessary, and when you do the tests you have (hopefully) narrowed it down to a manageable number of tris or convex polygons. Once it is known the bounding volumes collide, if more precise collision information is needed you do a narrowphase collision test using entire tris/polygons rather than vertices using various methods (separating axes, GJK, etc.) depending on the engines requirements. What's a manageable number though? Any rule of thumb? Quote:Original post by jyk Even then, I imagine the narrow-phase tests are often performed using simplified geometry, such as a simplified version of the mesh or a proxy object composed of simpler primitives such as spheres, boxes, and capsules. Okay, but do I have to experiment with a "target polycount" (whether original geometry or collision geometry) or can I assume that with a given algorithm I should aim at x polygon intersection test per narrow phase at most? Like 50 tris per colliding object? A good rule of thumb for the latter would simplify things for me a good deal for me, of course. Alex
  14. ak-73

    Triangle-Triangle Intersections

    Quote:Original post by RDragon1 Is it actually a bottleneck for you? How else are you going to compare these shapes if they aren't in a common coordinate space? No, no bottleneck because I haven't implemented it yet, partially because I would have liked the info whether my approach was in principle correct (no use in coding an inefficient solution when there was a different, much more efficient standard solution out there) and partially because other real world stuff has kept me from coding the past few days. Alex
  15. ak-73

    Triangle-Triangle Intersections

    Quote:Original post by jyk Quote:Even so, if I only have the vertex positions in the two different object spaces of two different meshes, I have to transform the vertices of one object into the space of the other. Or both into world space (which would be slower).Transforming the geometry of one object into the space of the other should be more efficient in the general case (since you only have to perform one transform per vertex, rather than two). And that's the way it's *usually* done in a game engine too? Vertex data kept in object space and only transformed into another geometry's object space when needed? I'm asking because I assume that this can become fairly costly quickly, as the polycount grows. Alex
  • 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!