Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

136 Neutral

About kanageddaamen

  • Rank

Personal Information

  • Interests
  1. Actually, rather than spinning up a new VBO for each batch of the same state in a frame if one gets filled, would the following be a better approach: For batch size N MB Using a VBO allocated with N MB For each chunk of N MB data with the same state Fill VBO with chunk of data using glMapBufferRange with GL_MAP_INVALIDATE_BUFFER_BIT Make draw call From what I have read this should safely mitigate implicit synchronization while allowing for a single VBO handle to be used
  2. kanageddaamen

    Turret aim

    This is unrelated to your initial question about the turret rotation and just a suggestion. If you are going to have many active enemies and many active turrets, the complexity of finding all targets for all turrets will be O(T*E) where T is the number of turrets and E is the number of enemies. This may not be a problem for a low T and E, but as the numbers grow it could bog things down, especially if this is for mobile or some other limited environment. I would recommend some sort of spatial partitioning algorithm to quickly eliminate large chucks of enemies that aren't anywhere near the enemy. Also, if you know the turret range as well, I would store the range squared of the turrets, and compare that to the distance squared (x*x+y*y). This will save you a square root from every one of your range calculations
  3. Wouldn't you need to create an entire new VAO, otherwise the other VBOs in the VAO you are rendering will be passed by the draw call, thereby increasing the batch size which you are trying to keep constant? I must admit I am no expert on the various draw call options and their capabilities EDIT: I suppose you would just bind different VBOs and make some glVertexAttribPointer calls for the next batch call
  4. I think I figured part of this out myself. Between frames shouldn't be an issue since all of those draw calls will need to be completed for the frame anyway. Should you not reuse VAO for batching, if you need more space than a batch can handle, create a new VAO? This seems like the number of buffers can grow significantly though if you are sending a lot of data
  5. Indeed, another reason I would not like to go that route. Thanks for all the insights, they will be an immense help moving forward. I am currently passing in the bones as a uniform (actually as dual quaternions which I then convert to matrices in the shader) and the weights and indices as vert attributes for my skeletal animations, but I will look into trying it indexed to see if it fits my needs. One related question I had just cropped up as I was doing some more reading. Something I came across mentioned not to reuse buffers for write calls (e.g. a single fixed size VAO reused for batches) due to implicit synchronization killing performance, though some of what I have seen on batching does just that. How would you perform view frustum culling of objects each frame if modifying the data in buffers can be a killer on performance? I can't imagine you would want to submit/maintain a bunch of data to/on the GPU that isn't needed for rendering
  6. Hello all, I am currently working on a game engine for use with my game development that I would like to be as flexible as possible. As such the exact requirements for how things should work can't be nailed down to a specific implementation and I am looking for, at least now, a default good average case scenario design. Here is what I have implemented: Deferred rendering using OpenGL Arbitrary number of lights and shadow mapping Each rendered object, as defined by a set of geometry, textures, animation data, and a model matrix is rendered with its own draw call Skeletal animations implemented on the GPU. Model matrix transformation implemented on the GPU Frustum and octree culling for optimization Here are my questions and concerns: Doing the skeletal animation on the GPU, currently, requires doing the skinning for each object multiple times per frame: once for the initial geometry rendering and once for the shadow map rendering for each light for which it is not culled. This seems very inefficient. Is there a way to do skeletal animation on the GPU only once across these render calls? Without doing the model matrix transformation on the CPU, I fail to see how I can easily batch objects with the same textures and shaders in a single draw call without passing a ton of matrix data to the GPU (an array of model matrices then an index for each vertex into that array for transformation purposes?) If I do the matrix transformations on the CPU, It seems I can't really do the skinning on the GPU as the pre-transformed vertexes will wreck havoc with the calculations, so this seems not viable unless I am missing something Overall it seems like simplest solution is to just do all of the vertex manipulation on the CPU and pass the pre-transformed data to the GPU, using vertex shaders that do basically nothing. This doesn't seem the most efficient use of the graphics hardware, but could potentially reduce the number of draw calls needed. Really, I am looking for some advice on how to proceed with this, how something like this is typically handled. Are the multiple draw calls and skinning calculations not a huge deal? I would LIKE to save as much of the CPU's time per frame so it can be tasked with other things, as to keep CPU resources open to the implementation of the engine. However, that becomes a moot point if the GPU becomes a bottleneck.
  7. Hello all,   I am looking for some resources or information for developing a complex collision detection\response system.  I have a swept-ellipsoid system up and running for player-world collisions but where I am running into issues is combining object-object and object world collisions.     The real issue I am trying to resolve in the design phase is when looking at objects that could potentially stop or alter another object's motion (say some crates that can be moved, but act as "walls" when the player runs up against them.) I imagine that I would have to do something similar to the following: Find the displacement of the object Find the earliest time that the object collides with the world (a) Find the earliest time that the object collides with ANY other object (culled in the broad phase, of course) Move the object along the displacement by the less of (a) or (b) and perform response Iterate until the displacement is entirely used Is this correct? This seems like it will be very expensive as I will have to check each possible colliding object every iteration of the check. Another issue: What about objects that push other objects: Example, say a crate falls and pushes a player. I would need to move the crate until it hits the player, then do an entire collision detection run for the player as it is pushed before finishing the crate's movement. That also seems like it could get prohibitively expensive as a push may cause another push, and so on. Most of the information I have found is to determine whether 2 object collide, which I already have a firm grasp of.  I need to expand that into a collision system with multiple objects. Any guidance is much appreciated.
  8. kanageddaamen

    DirectX 11 depth buffer problem

    I had a similar problem which was caused by my perspective projection calculation being done with a 0 for the near clipping plane distance. Check to see if this is the same case for you, and if so set it to a small value like .1 or so.
  • 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!