Jump to content
  • Advertisement

Defend

Member
  • Content Count

    225
  • Joined

  • Last visited

Community Reputation

316 Neutral

5 Followers

About Defend

  • Rank
    Member

Personal Information

  • Interests
    Programming

Recent Profile Visitors

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

  1. Found the other article that talks about robustness issues in Fauerby's paper. https://arxiv.org/ftp/arxiv/papers/1211/1211.0059.pdf
  2. Copying/pasting DarkS474's reply on Unreal's forums: https://answers.unrealengine.com/questions/465484/how-to-get-vertex-xyz-from-static-mesh-via-bluepri.html https://forums.unrealengine.com/development-discussion/c-gameplay-programming/7509-accessing-vertex-positions-of-static-mesh?8856-Accessing-Vertex-Positions-of-static-mesh= https://forums.unrealengine.com/development-discussion/c-gameplay-programming/113813-accessing-vertex-positions-of-animated-skeletal-mesh https://wiki.unrealengine.com/Accessing_mesh_triangles_and_vertex_positions_in_build Not sure why that last link doesn't work directly; you may need to copy & paste.
  3. ... Wait, can we not edit posts after a little time anymore? I guess I can only clarify the topic here then. Topic Clarification: I'm looking for something published that speaks from experience of dealing with the problems of using sweeps/raycasts (and not calculating the path across every tri on a mesh) to detect upcoming terrain, and knows which hiccups don't matter, which do, what to do about them, and what restrictions to work with. This assumes a physics engine is already available (Unreal's in this case) for doing the sweeps/rays/collision detection. It's advice on what to do with the results that I'm wondering about.
  4. Hi bmarci, the thought is appreciated but that's Fauerby's; one of the papers I wrote about above, recommending that people avoid it. Here's one link (I haven't read) looking at some problems it has. There's another rather academic paper out there that goes deeper into its numerical robustness, but I can't find a link anymore. Personally I didn't run into those particular issues; the problem I had with Fauerby's code is that it works thanks to 2 bugs that exist in the code - but not accounted for in the algorithm - actually cancelling each other out. I had unthinkingly not-implemented one of those 2 bugs and had to get real intimate with things to find the problem. After struggling with my OpenGL version I redid it in Unity for the sake of visual debugging, and could see that the sphere would periodically pass through a surface, yet also get the surface normal wrong and coincidentally push the sphere back out. It does achieve the result of not penetrating a flat surface, but adds jitter, but that's what kept it working. If I recall correctly this only affected the sliding, not colliding, part of the algorithm. I wrote a post about this maybe 4 (?) years ago, but I had a quick check of my post history yesterday and it seems it's not recorded. Since you've had long success with it you could say I'm being too harsh. It did work to a practical degree, with a little jitter, when following his code to the letter - bugs included. And I admit that's quite likely to be good enough for almost everything, but it was very frustrating for me before finding happiness with Ericson's book. So if it's still kind-of good enough for almost everything, why don't I go with it? Because it's actually a bit off topic, so I see I have to make the question a bit clearer after I submit this post. What I'm looking for is something that has demonstrated experience with the pitfalls of finding upcoming terrain when using sweeps/raycasts. Those pitfalls are pretty much about dealing with edge-case geometry, and I'm hoping to find something published where someone has really dealt with the problems and knows which hiccups don't matter, which do, what to do about them, and what restrictions to work with. The key difference is that Fauerby's article shows how to do sphere-mesh collision detection, while the thread's topic assumes that collision detection is already available (even if it's a posteriori), and is hoping for more expertise on what to do with the results when trying to track terrain. Thanks for the consideration nonetheless.
  5. Using Unreal 4.22 (C++) I'd like to be able to chuck all the vertices of a mesh into an array to work with. I'm interested in these different levels of complexity: a static mesh a mesh that is changing with simple T/R/S transformations a mesh that is deforming with animation (not necessarily with bones) Does anyone know what I should be looking into for these? Any answers to any of those 3 appreciated.
  6. Yep, it's cases like that (cliffs and such) that prevent me from just going at it. You're definitely anticipating the same kinds of problems I'm worried about, I'm just hoping there's something published/experienced that addresses them (and the ones we haven't thought of). I have Ericson's book buried somewhere; I was stuck puzzling over buggy ellipsoid-to-mesh collision detection guides for some months until finding his book and algorithm that actually works. (I am going to take this moment dive off-topic and warn any readers to NOT use Fauerby's or Nettle's guide to collision detection. Still bitter.) So thank you for the reminder about Ericson; I wouldn't have thought of checking it. I'll be using Unreal, so the physics engine behind the raycasting is already done for me, but I wouldn't be surprised if the book still has something on this thread's topic.
  7. That's an approach I took some time ago, for exactly the reasons you said; ie., it was less edge-case-prone than collision/raycast testing and the only noteworthy issue I had to work around was float inaccuracy on edges detecting wrong tris at times. I was happy with it, but it has a few of its own quirks like those you mentioned, as well as needing to predetermine every tri's neighbouring tris which leads to needing a bit more thought about what goes in a level, how interactions will work between two separate meshes, and the like. For now, I'm just interested in exploring the sweeping/raycasting approach. Not that it's necessarily the approach I'll take, but I believe it's fairly widely used so I'm hoping to find something that discusses its hidden pitfalls and what it needs to be made decently robust.
  8. I'd like to code something that lets a character move around any irregular mesh while always staying on the surface. This is regardless of orientation and without involving gravity. The common approach I know of to this is sweeping/raycasting ahead to find the next piece of ground they will hit or should be on. I could dive in but I'm also aware that there are a number of edge cases and pitfalls to be aware of. I've tried to find some tutorials that look into it but haven't been able to turn up anything at all. Does anyone know a good reference for this? Cheers
  9. Thanks all for your replies, especially those links you guys have thought of. _Silence_, I found that article in particle quite interesting. The pointers to simple engines should also be helpful, since while I've asked about guiding structures for writing I do indeed practise in merely recognising structures of other engines. Yep, exactly this is the kind of thing I'm wanting to be better at. I've had a glance all the articles & posts linked. They all get my interest but I'll prioritise those around engine structure advice. (Regarding the side topic of "Don't make an engine if you want to make a game", the disclaimer I wrote is just to keep such suggestions at bay. They're good suggestions but there's already a lot of internet covering it.)
  10. Obligatory disclaimer - Yes this is for academic purposes, not for making actual games. I've been employed as a Software Engineer for 2 years but still feel like a beginner when it comes to writing a game engine (and much of coding in general). What little experience I have with writing 3D software from scratch is from super rough university projects (which we called "engine" but that's definitely debatable). Meanwhile, my current job doesn't really take me down this line of learning. This thread is to ask for advice; mainly pointers to good guides, or comments on what structural approaches are considered to be good ones. I'm looking for something that teaches me about how to structure a game engine so that: it's good for learning about writing an engine it's not completely devoid of modern techniques it will be usable for later feature learning; networking, AI, unit testing, etc. (I imagine this criterion is typically a given anyway.) Some things I'm aware of so far (you may want to comment on any of these): https://www.gamasutra.com/blogs/MichaelKissner/20151027/257369/Writing_a_Game_Engine_from_Scratch__Part_1_Messaging.php I also have the book Kissner recommends: Game Engine Architecture by Jason Gregory. From what little I've read of it, it appears more advice than structural guide. ECS was a buzzword back when I was at uni, but the more I google it the more it appears to have become a dirty word. Unreal Engine's source Regarding ECS: For all the flak it appears to generate nowadays, it is at least a structure. If ECS isn't recommended I'm interested in what other general structural approaches there are. Regarding Unreal: I'd love to jump in and learn how Unreal Engine's structure works, but it might be biting off more than I can chew. Language of choice is C++. Thanks
  11. Frob, I too haven't heard an argument that the namespace approach is worse (or not) than the class approach, but that's because it is practically impossible to find discussion on that particular question at all. Any search (I can find anyway) related to 'how to singleton' and C++ produces the class approach. Any search with the word 'singleton' at all results in replies all too keen to launch into thoughts on the pattern and/or globals. I don't disagree with them at all, but they drown the focus on any related specific questions such as this one. Thank you all though for confirming for me that I'm not just missing something obvious in C++. I think Hodgman's suspicion is a good one. Seraph, your comment was something I hadn't thought of so that feels like I've finally I found some closure! Many thanks.
  12. Not asking about singletons here (nor advocating). With that clarified: If we assume someone wants a global + unique object, why isn't a namespace always the preferred approach in C++, over implementing a singleton class? I've only seen the namespace approach encouraged when there aren't statics being shared. Eg; from Google's style guidelines: But why not have non-member functions that share static data, declared in an unnamed namespace? And why isn't this generally suggested as a better alternative to writing a singleton class in C++?
  • 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!