Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 May 2004
Offline Last Active Aug 28 2014 05:53 AM

Posts I've Made

In Topic: glDrawElements invalid operation

07 June 2014 - 08:00 AM

Try adding an assert(vao && numIndices >= 0 && numIndices % 3 == 0);  in 'void Mesh::Draw()'. If everything is drawing ok, but the error is being spammed, I assume it's something like you have one or two Meshes in the scene for which vao is null or similar.


If that doesn't help, I'd spin up AMD CodeXL (works on all GPUs, not just AMD) and take a trace of the GL calls with that. It will show the stream clearly and the state of the GL context at the time of the error.

In Topic: glFlush/Finish Uses

07 June 2014 - 07:02 AM

The short answer is: never.


A bit longer answer: All GL functions are properly guarded to ensure that if you e.g. glReadPixels or swap buffers similar, you will always get the data back after all previous operations are finished. Instead, In some environments, you have access to companion APIs (e.g. with EGL) that integrate OpenGL with some other environment, which could be a very low-level compositing library provided by the platform, or some other GPU-accelerated API. While the built-in synchronization primitives in GL properly guard all access to the data via the GL functions themselves, they often are unable to do so across different APIs or when low-level system access is performed. That is the reason why the GL specification added glFlush() and glFinish() commands to be able to synchronize across APIs. It is quite rare that game developers would be using either, so the normal operation in a game is to avoid flushing or finishing at all, they just stall the CPU for nothing.


Now, sometimes there are arguments of people saying that it improves performance if you flush right after you have finished the last rendering command of the frame. That sounds like bs, or a bad driver in action. Neither glFlush or glFinish are performance primitives.


Also, sometimes people do a glFinish() right before starting a gpu micro-benchmark, to guarantee that the GPU would be idle when the benchmark starts. That's probably the only semi-decent use of a finish that I've heard of.

In Topic: Determining if a 3D point is in a 3D polygon

05 June 2014 - 06:11 PM

I have a destination 'box' in 3D and I'm trying to determine which (if any) 3D navigation mesh points are inside of it.


This sounds like completely something different than a point-in-polygon or a point-in-polyhedron test. If by "3D navigation mesh points" you mean the corner vertices of the navigation mesh, then what I'd do is populate a spatial subdivision acceleration structure (quadtree, octree, bsptree, kdtree, regular grid, etc. there's plenty to choose from) with the vertices and then do a box query into the structure ("find all the vertices inside this box").


If instead by "3D navigation mesh points" you meant the set intersection of the space taken up by the 3D navigation mesh and a given box, then I'd populate a spatial subdivision acceleration structure with the face polygons of the navigation mesh, and do a box clip operation into the structure ("find all polygons inside or intersecting the box, and clip each intersecting one to fit inside the contents of the box").



Perhaps one of those methods could help. If the navigation mesh has relatively few faces, then instead of using a spatial subdivision acceleration structure, you can try just using a flat list of faces as the structure, and linearly iterate over them while processing. "Upgrading" to a spatial subdivision structure can then be done optionally when necessary, it's more just an optimization for large data sets.

In Topic: Determining if a 3D point is in a 3D polygon

05 June 2014 - 01:01 PM

One needs to be very careful with the definitions. Usually a polyhedron is a closed volume of space defined by polygonal faces, which subdivides a space into two disjoint regions ("inside" and "outside"). Navigation meshes aren't usually like this - they don't form a closed volume, but instead they are just a connected set of planar polygon faces in a 3D space.


For keeping a point-polygon containment test numerically robust, one usual solution is to compute the closest point on such a polygon list to the target point, and the compare the distance of the closest point to the target point, and use that a threshold value. Another way is to imagine the polygons have a "thickness" and they get extruded in both positive and negative direction by this thickness amount by the purposes of the test. This is what MathGeoLib does in the link I posted above.

In Topic: Why do large engines use their own string class

05 June 2014 - 12:53 PM

In addition to the points mentioned above, I develop my own string class mostly because the std:: api is just plain stupid. I don't want to write over-verbose iterator madness or things like std::string::npos for operating the api. You can get a very good feeling of how obtuse it is to work with it when you search for most voted questions in StackOverflow related to std::string work: http://stackoverflow.com/questions/tagged/stdstring?sort=votes&pageSize=15 . With my own string class, I can make the functionality work as comfortably as I like. Compared to C#, JavaScript or Python, C++ has probably the weakest string api in existence.


C++11 improves handling of different unicode formats, but working with utf8/utf16/utf32 sources with just the std::string and std::wstring is a pain (see -fshort-wchar et al.). Having my own with explicit awareness for different encodings helps in my case.


Of course when you work on something like this, it should be associated with a good unit testing battery, and development will invariably take up time. It's not a "I'll just get it done in a weekend" type of project.