Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Dwiel

do your objects draw theselvs?

This topic is 5813 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In most genras ?sp? for games, either the objects draw themselves or some ''mother'' draws them all. How does this norally work? How does yours work? How does this work in an RTS style game? What about a 3D shooter, kinda game? thanx for the coments/help in advance! tazzel3d ~ Dwiel

Share this post


Link to post
Share on other sites
Advertisement
Ususally its done with classes, and each object has a velocity, acceleration, etc. The objects are then put in a linked list or an array, and you have a loop that will draw each one, for every game frame.

- master_ball

----------------------------
We R 138

Share this post


Link to post
Share on other sites
If you have one centralized entity drawing your specialized objects sooner or later you''re going to run into problems. Rendering a billboard is different from rendering a static LOD model, which in turn is different from rendering terrain which is different from rendering indoor geometry. If you stick a lot of specialized code in one class in order to add a new object you''re going to have to modify this class which very soon will become very hard to maintain. Even more, if you decide to reuse your terrain code and use it in another engine you''re going to have to do a lot of cutting and pasting.

If you stick your specialized code into specialized classes, all the problems above disappear. Objects are responsible for rendering themselves and specialized code is located where it belongs. This makes your code a lot easier to maintain, understand, and reuse. A good idea is to create an interface (something like IRenderable) that defines general methods necessary to render an object. Then have all your specialized objects inherit this interface. This way you can stick all the specialized rendering code into your objects, but at the same time you can have a cetralized place (your scene graph) easily access all renderable objects without caring who/what they are.

Share this post


Link to post
Share on other sites
What if you set up any specialized renderor classes that rendered each of your objects. for exaple one for all your charactors, one for all of your walls/floors/etc one for all of your explotions, etc?

Is this equally not as good?

If all similar objects are rendered by one class, coul you not implement many more optimizations than if they all rew themselvs? For example, lets say that you are making an RTS and 30% of the tiles are tile A. When each object draws itself, each tile A might have a different kind of tile rendered before and after. This means that you will have to change the current texture many times. If one class draws them all for you, it can order them so that it draws all of the tile A''s at one time as to not have to re-set all of the textures/FVF modes/shaders. Would this not be much faster?

tazzel3d ~ dwiel

P.S. thanx for the quick help!

Share this post


Link to post
Share on other sites
quote:
Original post by Tazzel3D
If all similar objects are rendered by one class, coul you not implement many more optimizations than if they all rew themselvs? For example, lets say that you are making an RTS and 30% of the tiles are tile A. When each object draws itself, each tile A might have a different kind of tile rendered before and after. This means that you will have to change the current texture many times. If one class draws them all for you, it can order them so that it draws all of the tile A''s at one time as to not have to re-set all of the textures/FVF modes/shaders. Would this not be much faster?



Use some kind of tree to order all your objects by streamsource, vertex/pixelshader, texture, material, render/texturestagestates. Then move through the tree, setting all states for each node, and when you reach a leaf, you let all the objects draw themselves into their vertexbuffer. When you exit the leaf, you can draw the buffer (or do it each time its full, while looping through the objects). Similarly you could let the objects just fill an indexbuffer, or whatever.

Share this post


Link to post
Share on other sites
Wouldn''t the tree be inefficient, because it would need to be fully traversed to find all of the nodes, but only some of them would be rendered? And even if you make a tree of your potentially visible set, I don''t think that it would be very quick and would end up slowing down the prosess...

If we order the tree by position, we defeat the whole purpose...

I don''t really unerstand how this would be a good idea....

thanx for the quick response and I love bieng able to discus some of my funamental concepts...

tazzel3d ~ dwiel

Share this post


Link to post
Share on other sites
It''s a tree of states so that each object won''t need to switch the current state to what it needs and then render itself. This would cause a huge number of state changes, which is bad. So the tree optimizes this by grouping the objects according to the states that they require and draws them at the same time.

Share this post


Link to post
Share on other sites
So is this tree generated every frame or at the start up? what are soe ore of the details...

if A: you are loading at the start up, you''ll have a large tree with any objects in it and will need to traverse something mosterous just to render a couple of things (possibly)

or if B: you create the tree real time, isn''t this extremely time consuming? If not, how do you do it!?

Thanx for the quick responses again! and also thanx for your perseverience ?sp?

tazzel3d ~ dwiel

Share this post


Link to post
Share on other sites
It''s mostly personal preference. If doing it one way makes much more sense to you or fits into your overall design more elegantly, do it.

If you''re a big OO guy then having a mother class that draws the geometry of other objects could be seen as breaking encapsulation, complicating interface and increasing class interdependency.

One case where it definitely helps to have a mother class doing the drawing is when you have a very complex scene and state changes are affecting performance (state changes are things like turning lighting on/off, binding textures, etc - whatever changes the state of the rendering machine). In that case it''s probably better to have some mother class that arranges/draws all your geometry by render state (such as the tree that Dynaguy and MagicScript mentioned) to minimize state change overhead.

Share this post


Link to post
Share on other sites
Ok, thanx for all of the ideas, ill think about it at school today...

again thanx for all of the input!

tazzel3d ~ dwiel

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!