Jump to content
  • Advertisement

MonterMan

Member
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

1 Neutral

About MonterMan

  • Rank
    Member

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Raylib seems solid. My suggestion is to use an composite of small libraries that deal with different stuff. For example, you can use bullet for physics and collision, cute_sound for audio stuff; that way, if you feel like rolling out your own renderer, nothing is holding you back since all your game engine components are separated libs. You aren't tied down by a heavy lib that does it all, because a heavy lib that does it all tend to be more of a "control freak" than lightweight libs. This way, you have retained the "control" in your own hands. Just make sure you are in control of your code, and not the other way around. I am not sure if Raylib is one of those, but better make sure it isn't before you've decided to use it (EDIT: I was simply enumerating the possible library you can use, I wasn't actually recommending them (namely bullet and cute_sound). Not saying they are bad or anything; I haven't used them so I can't speak for them.)
  2. I've used SDL and I would recommend it. As to your question: If you intend to use OpenGL and not use any pre-built graphics library (which is what I'm assuming here since you mentioned OpenGL), then you need to know that SDL and other similar low-level libraries simply provide you easy access to OpenGL API on your platform. so writing such a simple renderer would take roughly an equal amount of time no matter which library you choose in the end. And to your other question: What is your priority? Is it shipping the game or learning how a game actually works? If your priority is to ship a game, don't watch Handmade Hero and look for pre-built tools instead, there are plenty c++ game libraries out there. If your priority is to learn, watch Handmade Hero, and I can tell you that it's worth it.
  3. MonterMan

    Tetrahedron's face voronoi region testing

    I've never thought about taking the barycentric coordinates of the point against the tetrahedron, good point! That seems like an elegant way to do the voronoi regions check for a tetrahedron, thanks a lot!
  4. MonterMan

    Tetrahedron's face voronoi region testing

    Hi swiftcoder. If that's the case then it makes some sense now. I can see how these are intended to be just helpful facts for optimization. Also Eberly's approach is simple and correct, I like it. All in all, thank you for clearing it up for me! This was confusing me big time and now it finally makes some sense!
  5. MonterMan

    Tetrahedron's face voronoi region testing

    Hi swiftcoder. Sorry I didn't mention the section that I am referring to. I am talking about what's written in section 9.5.2 in the book, page 404. The author explicitly states that, if the point is not in any vertex or edge regions, then "P lies in the Voronoi region of Q1Q2Q3 if and only if the following inequality holds: ((P - Q) . n123)((Q4 - Q1) . n123) < 0, where again n123 = (Q2 - Q1) x (Q3 - Q1)" And that other face regions can be tested the same way. I don't see additional halfspace tests in this particular section.
  6. MonterMan

    Tetrahedron's face voronoi region testing

    Here are two cents from me on the issue: My temporary solution is to check all four faces and keep the possible candidates (accept the fact that there might be multiple triangle faces that pass the test). Recall that the test is consist of two dot products. Let's use the example above: one of the dot product, dot(P - Q1, N), can be used to calculate (P - Q1)'s projection onto N, the triangle normal. Then I take the absolute value of this projection value. This projected value tells us the absolute distance between the origin and the triangle face plane. Then we can choose the candidate with the highest projected length as the face whose voronoi region contains the origin. I haven't proved this to be absolutely correct, although I do have some intuitions to why it should work. I added it to my game and it works reasonably well. But again, I doubt that this is the best solution. Putting the questionable correctness aside, this will cost an extra division and sqrt for each candidate triangle face. Quite expensive.
  7. I've been reading up Christer Ericson's Real-Time Collision Detection to implement GJK in my game (namely section 9.5.2), but I have some questions regarding how Ericson picks the correct face voronoi region that contains the origin. In the book, he states that if the origin is not within any vertex or edge voronoi regions, then testing whether or not the origin is within any face voronoi regions simply becomes checking whether or not the origin and the last point from the tetrahedron are on the same side of the face plane. Let me elaborate: Let's define the tetrahedron Q as a set of four points, Q = {Q1, Q2, Q3, Q4}. Say we are currently testing face Q1Q2Q3, and we define origin as point P. We can obtain the normal of face Q1Q2Q3 by cross producting two edges, I will denote the normal as N now. The plane that contains Q1Q2Q3 divides the 3D space into two halfspaces. Ericson's face region test is to check if Q4, the only other point from the tetrahedron, and P, the point we are checking against, reside in two different halfspaces. Since the plane is defined by its normal N, we can do dot(P - Q1, N) and dot(Q4 - Q1, N) and check if they have different signs (that means they are in two different halfspaces). Here's the face region check written out in code: if (dot(P - Q1, N) * dot(Q4 - Q1, N) < 0) PIsInFaceRegionQ1Q2Q3(); However, I have an issue with this approach. Consider this tetrahedron: It is obvious that the origin is contained by the face voronoi region made up by red vertex, yellow vertex, and green vertex. However, if I take a picture of it from the side, we can see that this tetrahedron is nearly coplanar: ' If we do Ericson's test for face made up by red, yellow, and green vertex, then the test tells us that, yes, origin is inside RYG's voronoi region. However, if we do the same test on the face made up by green, yellow, and blue vertex, the test tells us that the origin is ALSO in GYB's region. The test result becomes ambiguous. The origin can be simultaneously in different halfspaces for two different triangle faces of the same tetrahedron while the origin is not in any vertex region or edge region. Therefore, I think either this technique is wrong or I am not understanding it correctly. Am I correct on saying that this way of testing face voronoi regions is wrong? If so, what is the best way to do it then? Thanks a lot!
  8. MonterMan

    Ellipsoid vs Convex shape GJK collision response

    Hi Randy. That makes a lot of sense. Thanks for the help!
  9. Hi all. I am trying to write a collision detection & response routine for my 3d game. I am approximating my player's geometry with an ellipsoid, and I am detecting the swept ellipsoid's collision with convex shapes. If there is an intersection, I do bisection test to get the time of impact. However, now I want to get the contact normal, but I'm not sure how to do that. I tried using the last search direction as the separating vector, which turns out to be inaccurate. Most people suggest EPA, but I don't know if it works with quadric surfaces. Since one of the objects is an analytical shape on my case, is there any simpler way to get the contact normal or is EPA the way to go? Thanks a lot!
  10. MonterMan

    retopology help

    I know cgcookie offers a retopology course, but you have to pay them monthly for their courses.
  11. Got it. I was initially looking for a real-time GI algorithm because I didn't want do a separate preprocess step. But now it seems like baking is the way to go to achieve the highest quality, so it's worth it. Thank you for the awesome resources. That's indeed some work, but it's going to be worth it in the end :). I actually looked into baking lightmaps before, one that caught my attention is the light precomputation in The Witness: https://web.archive.org/web/20170227054745/http://the-witness.net/news/2010/09/hemicube-rendering-and-integration/ that is based on a radiosity algorithm: https://web.archive.org/web/20120324095518/http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm. But I gave up on the above methods because they require a ton of tweaking to get the result just right, so I looked into real-time stuff instead. Again thanks for the help guys, now it's pretty clear to me what to do.
  12. Lighting is completely static. Sun never moves and it's always the same time of day. Mainly outdoor scenes with small buildings that have interior. Thanks for the additional info on voxel cone tracing's shortcomings.
  13. Thank you for your insight. It seems like I have to reconsider what GI algorithm to use. This is the constraints in my game: . Single directional light source. It never changes. . Mesh is mostly static except for characters that run around. . I want one bounce of diffuse indirect light. I'd appreciate it if you can suggest the GI algorithm that fits my criteria. Thank you for your answers.
  14. Hi all. I have been looking for a real-time global illumination algorithm to use in my game. I've found voxel cone tracing and I'm debating whether or not it's an algorithm worth investing my time researching and implementing. I have this doubt due to the following reasons: . I see a lot of people say it's really hard to implement. . Apparently this algorithm requires some Nvidia extension to work efficiently according to the original paper (I highly doubt it though) . Barely real-time performance, meaning it's too slow to be implemented in a game So in order to determine if I should invest time in voxel cone tracing, I want to ask the following questions: . Is the algorithm itself flexible enough so that I can increase the performance by tweaking it (probably lowering the GI quality at the same time, but I don't care) . Can I implement it without any driver requirement or special extensions, like the paper claims?
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!