[Achilles4689]

Hey all,

I'll try to keep the example simple. Say you have a certain type of object in your game that is a static object that users can interact with (say maybe a turret). You want the object to be pickable and thus you need either a bounding box or its actual vertex data. However you have 250 of these objects in your game (ignore spatial performance enhancements for the sake of the example).

Isn't there a large performance hit if you have to do 250 seperate VBO binds, and 250 seperate draw calls VS being able to have all of the objects in one buffer in order to have one set of binds and one draw call?

However if all of their data is in a single buffer how do you access it for intersection tests with a pick ray?

The general problem I have is:

What is a good method to have many objects in the game that are either dynamic (thus needing their own model matrix) or pickable, without having the performance hit of having seperate VBO binds/draws for each object? Or is the performance hit not that big of a deal? What is the cost of binding and drawing 5 seperate VBOs of 10bytes each VS binding and drawing 1 VBO with 50bytes?

Thanks guys!

[stayscrisp]

You have two other threads open in this forum that have had answers posted yet you have not replied at all. Why should anyone reply to your threads when you never return to them?

We have a policy here at DIC where we like to see some effort on your part before we give out code or tips. What have you tried so far? Do you have en example of the code you are using and whether it is taking a performance hit from the amount of objects?

[Achilles4689]

You are the only one to respond to two of my other topics and I appreciate it. I did give you +points for you're reponses. The reason I didn't reply was because neither of the posts said anything worth replying to. One was just a comment that you had nothing more to add than what was already in my post. The other was a one line reply that stated that skin-and-bone animation and keyframes are both used together, in which you are correct.

I'm sorry for whatever harsh feelings you have.

[Achilles4689]

To explain more, I already have an engine that breaks up objects into their own thing, having their own model matrix etc. In order to truly test the cost of doing seperate binds on VBOs VS one large VBO I would have to be cpu bound, on a computer with 2.0ghz x4 cores.

So sorry if I was hoping to find someone with a bit of opengl experience that could take 30seconds out of their day to make a quick useful post.

[ButchDean]

To be honest your original proposal of 250 of the same object in a game world is either terrible game or engine design. I actually cannot think of one game that renders anywhere near 250 objects in a game work at any one time.

If you must have 250 of one object in your world, due to the view volume never being able to view then all you can actually have 'place holders' that only render your turret either when in view or you are suitably near enough. This is the only real solution that comes to mind.

[Achilles4689]

Thanks Butch. It was actually a hypothetical scenario that could easily be solved with culling techniques, that's why I said to ignore spatial performance enhancements.

I think I am explaining it horribly. Let me try again.

Say you have a building in your game with 50 rooms. (Once again please ignore any culling or spatial performance solutions, it's a silly example I know). So this entire building could be defined as one single VBO (vertex buffer object) and drawn with a single bind and draw call. However say you want users to be able to click on any wall in this building and move it around. This means each wall needs to have a model matrix as well as have its vertex data stored in a seperate buffer. If you have 250 walls in this building you have now taken a single VBO and broken it up into 250 VBOs in which you now have to bind different model matrices and make 250 seperare draw calls. This would result in a serious performance penalty right? They seem like two extremes. Is there a solution to this scenario?

Thanks in advance.

[ButchDean]

This is a scenario that wouldn't exist in any sensibly written game! The very techniques that you are saying should be ignored are the very solutions to such a problem. Why? Not only will there be a very serious performance hit, but the renderer itself may fail to initialize in the first place because of potential memory constraints.

[hype261]

Achilles4689, on 14 June 2011 - 11:17 AM, said:

Thanks Butch. It was actually a hypothetical scenario that could easily be solved with culling techniques, that's why I said to ignore spatial performance enhancements.

I think I am explaining it horribly. Let me try again.

Say you have a building in your game with 50 rooms. (Once again please ignore any culling or spatial performance solutions, it's a silly example I know). So this entire building could be defined as one single VBO (vertex buffer object) and drawn with a single bind and draw call. However say you want users to be able to click on any wall in this building and move it around. This means each wall needs to have a model matrix as well as have its vertex data stored in a seperate buffer. If you have 250 walls in this building you have now taken a single VBO and broken it up into 250 VBOs in which you now have to bind different model matrices and make 250 seperare draw calls. This would result in a serious performance penalty right? They seem like two extremes. Is there a solution to this scenario?

Thanks in advance.

I don't know about OpenGL, but DirectX 9 and 10 have a drawing ability called instancing. With instancing you only have 1 vertex buffer, but you keep a seperate world matrix for each instance. A special draw call is called that tells the hardware to render this vertex buffer with different world matrices. With DirectX you can animation also. I would seriously doubt if OpenGL doesn't have the same capability.

Secondly why are you doing your picking against the vertex buffers? Do you actually require this? Do your picking against an AABB instead of the vertex buffer. The good thing about the AABB is that it can be stored as 6 floats. 3 for world position in the center of the AABB, 1 height radius, 1 width radius, 1 depth radius.

The other method I have seen done to solve this problem was the use of billboards. The AI and mesh really didn't exist until the player came close to the AI until that point all that was rendered was a billboard of 4 floats aligned to the camera with an animated texture on it. The effect was very good considering they had huge armies being rendered on screen.

[Achilles4689]

Haha, you have a good point. I suppose I used an extreme and unrealistic scenario to try to get the point across. Say on a smaller scale you are in a single room with 4 walls and you want to be able to move the walls around. Is it necessary to split the walls up into seperate objects in order to do this? Is there no way to avoid a performance hit if one wants to have dynamic objects (and not just dynamic, say you have a static object and want to change its color at run-time, it's the same problem basically).

So basically, if you want to be able to change any attributes or interact with an object it needs to be seperated?

My problem is that I want to have an interactive environment but without having to pay a huge cost of seperating out all of the data. It would seem this may be impossible?

Thanks for the replies Butch!

Thanks hype. I'll check out instancing, it definitely sounds like a possible solution.

[ButchDean]

No problem, Archilles. Instancing will still cause you to have to overcome the original performance issues though.

[stayscrisp]

Achilles4689, on 14 June 2011 - 06:30 PM, said:

I'm sorry for whatever harsh feelings you have.

No harsh feelings, a small reply is common courtesy though, no?

Anyway, forget that. It seems you have a few techniques to bear in mind

This post has been edited by stayscrisp: 14 June 2011 - 12:17 PM

[Achilles4689]

Agreed. It would seem that my dreams of having an interactive environment were a noobie game designers wild dreams. I think I will have to seperate what objects are interactable and what is the static environment (buildings, trees and what not). The static environment can be a single object and rendered in a single pass. The objects that are interactable will have to be seperated.

[Kilorn]

We all fall into the same patterns when we first get into game development. Keeping grounded can become quite difficult as the mind tends to come up with these grand ideas that we're nowhere near ready or able to tackle.

This post has been edited by Kilorn: 14 June 2011 - 01:03 PM

[stayscrisp]

Quote

The static environment can be a single object and rendered in a single pass. The objects that are interactable will have to be seperated.

Well that's not entirely true. At the top level of abstraction your game objects can all be accessed via a single interface and rendered in one loop. That is if I understand you correctly.

For example you could have a generic game object class

class GameObject
{
   public:

       void Render() = 0;

       // other stuff
}

And then inherit from it

class Immovable : public GameObject
{
     public:

     void Render(); // implement this for immovable objects
}

class Moving : public GameObject
{
     public:

     void Render(); // implement this for moving objects
}

Then you can add them to a data structure (as pointers to game objects) such as a vector and loop through them. It will call the individual methods for inherited classes.

for(int i = 0; i < gameObjects.size(); i++)
{
     gameObjects[i]->Render();
}

I hope that helps somewhat

This post has been edited by stayscrisp: 14 June 2011 - 01:21 PM

[Achilles4689]

Interesting. I may have to consider redesigning a few things.

Thanks!