Search Results

Search found 5 results on 1 pages for 'identitycrisisuk'.

Page 1/1 | 1 

  • What has the most efficient intersection test against an AABB tree - OBB, Cylinder or Capsule?

    - by identitycrisisuk
    I'm currently trying to find collisions in 3D between a tighter volume than an AABB and a tree of AABB volumes. I just need to know whether they are intersecting, no closest distance or collision response. An OBB, Cylinder or Capsule would all roughly fit these purposes but Cylinder and Capsule were the first thing I thought of, which I have found little information about detecting intersections online. Am I right in thinking that they would always be more complex to perform Separating Axis Tests on even though they might seem like simpler shapes? I figure by the time I get my head around SAT for curved shapes I could have done the thing with OBBs but I wanted to find out for sure.

    Read the article

  • Is Ogre's use of Exceptions a good way of using them?

    - by identitycrisisuk
    I've managed to get through my C++ game programming career so far virtually never touching exceptions but recently I've been working on a project with the Ogre engine and I'm trying to learn properly. I've found a lot of good questions and answers here on the general usage of C++ exceptions but I'd like to get some outside opinions from here on whether Ogre's usage is good and how best to work with them. To start with, quoting from Ogre's documentation of it's own Exception class: OGRE never uses return values to indicate errors. Instead, if an error occurs, an exception is thrown, and this is the object that encapsulates the detail of the problem. The application using OGRE should always ensure that the exceptions are caught, so all OGRE engine functions should occur within a try{} catch(Ogre::Exception& e) {} block. Really? Every single Ogre function could throw an exception and be wrapped in a try/catch block? At present this is handled in our usage of it by a try/catch in main that will show a message box with the exception description before exiting. This can be a bit awkward for debugging though as you don't get a stack trace, just the function that threw the error - more important is the function from our code that called the Ogre function. If it was an assert in Ogre code then it would go straight to the code in the debugger and I'd be able to find out what's going on much easier - I don't know if I'm missing something that would allow me to debug exceptions already? I'm starting to add a few more try/catch blocks in our code now, generally thinking about whether it matters if the Ogre function throws an exception. If it's something that will stop everything working then let the main try/catch handle it and exit the program. If it's not of great importance then catch it just after the function call and let the program continue. One recent example of this was building up a vector of the vertex/fragment program parameters for materials applied to an entity - if a material didn't have any parameters then it would throw an exception, which I caught and then ignored as it didn't need to add to my list of parameters. Does this seem like a reasonable way of dealing with things? Any specific advice for working with Ogre is much appreciated.

    Read the article

  • How best to deal with warning c4305 when type could change?

    - by identitycrisisuk
    I'm using both Ogre and NxOgre, which both have a Real typedef that is either float or double depending on a compiler flag. This has resulted in most of our compiler warnings now being: warning C4305: 'argument' : truncation from 'double' to 'Ogre::Real' When initialising variables with 0.1 for example. Normally I would use 0.1f but then if you change the compiler flag to double precision then you would get the reverse warning. I guess it's probably best to pick one and stick with it but I'd like to write these in a way that would work for either configuration if possible. One fix would be to use #pragma warning (disable : 4305) in files where it occurs, I don't know if there are any other more complex problems that can be hidden by not having this warning. I understand I would push and pop these in header files too so that they don't end up spreading across code. Another is to create some macro based on the accuracy compiler flag like: #if OGRE_DOUBLE_PRECISION #define INIT_REAL(x) (x) #else #define INIT_REAL(x) static_cast<float>( x ) #endif which would require changing all the variable initialisation done so far but at least it would be future proof. Any preferences or something I haven't thought of?

    Read the article

  • Is the use of union in this matrix class completely safe?

    - by identitycrisisuk
    Unions aren't something I've used that often and after looking at a few other questions on them here it seems like there is almost always some kind of caveat where they might not work. Eg. structs possibly having unexpected padding or endian differences. Came across this in a math library I'm using though and I wondered if it is a totally safe usage. I assume that multidimensional arrays don't have any extra padding and since the type is the same for both definitions they are guaranteed to take up exactly the same amount of memory? template<typename T> class Matrix44T { ... union { T M[16]; T m[4][4]; } m; }; Are there any downsides to this setup? Would the order of definition make any difference to how this works?

    Read the article

  • Can Visual Studio exclude certain folders when searching for header files?

    - by identitycrisisuk
    I'm having trouble with a library that we are using, which has two copies of header files that are needed - one which we are modifying and building from and another which is automatically created during the build process. I don't fully know why or really want to change this but it can cause a bit of annoyance when on random occasions the go to definition function takes you to the auto created header instead of the one used to build. Usually you can spot it but sometimes you don't and make changes to the auto created one, which are then overwritten or sometimes stay around for a while so that something works on your machine but breaks on other peoples. I don't know if there is any way around this as the auto created folder is in the additional include directories of some of the projects in the solution but I just thought I would ask if there was any good way of reducing the chance of this annoying situation cropping up.

    Read the article

1