Matrix math library that is good to use alongside OpenGL to keep track of primitive co-ordinates.
Does such a thing exist? Is this the best way to track my objects for use in collision detection?
You don't describe your situation very much but I'm assuming that you are making some game or simulation application?
I would suggest you use a physics engine, like Bullet or ODE, from the start. This way you will get a properly optimized matrix library plus well tested collision detection and handling. Using some other general-purpose matrix math library may seem easier at first glance. However it will probably be less adapted to your needs and will surely be a mess to replace with a physics engine if you decide to use one later on.
You don't have to use all the fancy features of the physics engine right away. In fact you could very well just use the matrix and vector implementation and skip the rest until later.
OpenGL is simply for rendering the objects from your data store, your physics/collision library will already have matrices for all the objects within it.
I dont think there is such thing. Maybe this helps to clarify a few things:
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=30
Related
I have been reading the documentation and playing with Eigen recently:
docs
and would like to build something that uses it extensively to learn it well. I looked on their website and they mention various projects that use it - like Google Ceres. Something like that might be too large for one or two people to undertake on the side as an Eigen learning experience so I'm looking for something simpler but not trivial that would use it extensively and is a real - useful - application..
Eigen is extensively used in computer vision, and if you are comfortable with linear algebra and matrix calculus (I assume you are, otherwise you wouldn't use Eigen), why not build a toy VSLAM (visual simultaneous localization and mapping) system? Those that are based on bundle adjustment (there's a whole chapter dedicated to that in zisserman's book on multipleview geometry, and it is also discussed in the open-source yet excellent book enter link description here) can be very tricky to implement efficiently, and will take a lot of time, but since your goal is to learn Eigen, performance shouldn't be that much of an issue. If that seems too hard/long for two people, and you think it demands too much energy for a side-project, I recommend that you select some computer-vision algorithms like those that compute the the essential matrix between two images, or are used in 3d pose estimation. Well, those are the only really fun things that come to mind right now, and they will force you to discover a lot of Eigen's functionalities (and gotchas!).
http://app.geokone.net/ is an open source javascript app for generating shapes (if you can look at it, it's really fast, for 5 seconds, I'm sure you'll get the idea).
It's hard for me to go through it because it's a lot of code, what is the general idea?
also, I need those shapes as GameObject with polygon collider around them (anything from 0 to 20 of them on the screen at the same time, could be different shapes also), is it even possible with GL?
would GL help me? I think GL would be fast for just 1 shape or something (as it's using recursion), but for what I want, I think drawing them in real time to a texture, then using the texture as a sprite would be faster (as I can save the sprite for shapes that are the same), or maybe I should use a shader? any other method that you can think of?
and for the algorithm itself, what is the general idea?
You don't want to use GL, look into custom mesh generation with MeshFilter. It is required for the colliders anyway.
Meshes have to be updated just once and probably will be faster than any optimisation you proposed. You might need a shader to draw it, though.
As for the algorithm, I'm afraid you have to look into it yourself or hire someone for it. StackOverflow is for helping with issues, not doing the work for you. If you need a hint, look into basic fractals
I am in the process of coding a level design tool in Qt with OpenGL (for a relevant example see Valve's Hammer, as Source games are what I'm primarily designing this for) and have currently written a few classes to represent 3D objects (vertices, edges, faces). I plan to implement an "object" class which ties the three together, keeps track of its own vertices, etc.
After having read up on rendering polygons on http://open.gl, I have a couple of questions regarding the most efficient way to render the content. Bear in mind that this is a level editor, so I am anticipating needing to render a large number of objects with arbitrary shapes and numbers of vertices/faces.
Edit: Updated to be less broad.
At what point would be the best point to create the VBO? The Qt OpenGL example creates a VBO when a viewport is initialized, but I'd expect it to be inefficient to create a close for each viewport.
Regarding the submitted answer, would it be a sensible idea to create one VBO for geometry, another for mesh models, etc? What happens if/when a VBO overflows?
VBOs should be re-/initialized whenever there's a need for it. Consider VBOs as memory pools. So you'd not allocate one VBO per object, but group similar objects into a single VBO. When you run out of space in one VBO you allocate a another one.
Today's GPUs are optimized for rendering indexed triangles. So GL_TRIANGLES will suffice in 90% of all cases.
Frankly modern OpenGL implementations completely ignore the buffer object access mode. So many programs did made ill use of that parameter, that it became more efficient to profile the usage pattern and adjust driver behavior toward that. However it's still a good idea to use the right mode. And in your case it's GL_STATIC_DRAW.
Is there a way to create and use a simple 3d model on the Unreal Engine?
Your best bet would be to create the initial 3D asset in a third party tool and import it into the IDE. From there you can change the texture map, and manipulate the aesthetics in one way or another, but the initial 3D model should be in an external 3D format, and then placed as a prefab into your world.
Creating an object dynamically in UDK is cumbersome and requires lots of tweaking, and won't save much in terms of cost of resources. Especially if you want it to look good and more than just 3D meshes thrown together rudimentarily. It is possible, but almost not worth it, especially if you have 3DSMax, Maya, Cinema4D, MotionBuilder, or one of the other hundred tools available to do the grunt work for you.
Most 3D Engines (IE Unity, UDK, Torque, Cry and now Havok) support many formats, and especially the unversal FBX. You could even use google sketchup and export to DAE or FBX format to get it into your Engine. Grant it you lose a lot of the elements, but the basic 3D mesh stays relatively in tact.
I have a simulation I am running where I would like to test for the collision of 2D objects. I am not interested in the physics simulation portion of Box2D but would like to leverage its collision detection features.
My initial thought was to make a bunch of static bodies but after reading the documentation I got the impression they were not included in collision testing and therefore don't make sense.
Is it worthwhile using Box2D to evaluate collision detection in my system, where the position of the elements is driven by a separate system, or does it make more sense to look elsewhere for a collision detection solution? If so, how would I start down that path with Box2D?
Although I have not tried it myself, I guess you could do it by using dynamic bodies, with the world gravity set to zero, and all bodies linear velocity set to zero (so they do not move in world Step call) and then position them using SetTransform. The regular BeginContact/EndContact events should still be sent to your contact listener.
Yes, use Box2D. Box2D has the best collision detection system I've used, compared to Chipmunk and Bullet.
I agree with iforce2d, you should use dynamic bodies with a world whose gravity is set to zero.
Good luck and happy coding.