Jump to content

  • Log In with Google      Sign In   
  • Create Account

Is this a bad idea? A quadtree that uses a pointer to a render function


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Lil_Lloyd   Members   -  Reputation: 287

Like
0Likes
Like

Posted 13 January 2013 - 07:46 AM

Hi. At the moment I'm planning and writing some quad tree and quad tree nodes for rendering a terrain scene. I want to reuse these classes for many types of scenes, so I can have different terrain features rendered in each scene e.g

 

RenderGrass();

RenderGround();

RenderTrees();

 

in one and possibly 

 

RenderSnow();

RenderLake();

RenderTrees();

 

in another. As such I thought an abstract type of quadtree and quadtree node would be good (the example I'm basing my code on has the same render func passed through the chain). However when building the quadtree I need to call new QuadTreeNode(), the problem being that QuadTreeNode is an ADT, and as such cannot be instantiated. So....I thought of using pointers to a custom render function built for each scene.

Is this a crazy idea? Are there other alternatives?



Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 9304

Like
0Likes
Like

Posted 13 January 2013 - 08:06 AM

Surely the quad trees should contain references to abstract scene data (such as pointers/handles to models, which can provide their own spatial information to allow the quad-tree to be self-sufficient) rather than references to the engine itself?


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#3 JTippetts   Moderators   -  Reputation: 8662

Like
5Likes
Like

Posted 13 January 2013 - 09:37 AM

If you find yourself thinking of writing custom render functions specifically named like that (RenderSnow() as opposed to RenderGrass()) then you might want to re-think your abstraction. The engine shouldn't even have to know there is a difference between rendering snow and rendering grass. That distinction is purely the responsibility of the data you give it.

A renderer just has to be able to follow instructions: "Render this batch, using this material that includes these textures and shaders." That's pretty much it. Rendering dirt and rendering snow should all be handled through the exact same interface with the renderer; the difference being the shaders and textures.

#4 LorenzoGatti   Crossbones+   -  Reputation: 2779

Like
0Likes
Like

Posted 13 January 2013 - 01:35 PM

If you have tiles, you can probably batch together all of them, possibly with multiple layers.

For each layer, put all graphics in the same texture, then for each tile add to your vertex buffer a quad or two triangles with the appropriate texture coordinates for the part of the texture atlas that contains the tile's image. You can store in your map data structure the texture coordinates or a tile type code that you can use to look up the texture coordinates; try both and find which strategy (less work or less memory) performs better.


Produci, consuma, crepa

#5 KulSeran   Members   -  Reputation: 2587

Like
0Likes
Like

Posted 14 January 2013 - 03:52 AM

You should be thinking about abstracting your system into the functional parts. The quadtree part is just there to determine what you want to draw, it shouldn't be drawing anything. Walk the quad tree, build a list of renderables. Push that flat list into the rendering system where it can be sorted by material, draw layer and whatever other attributes make sense in your world.



#6 jmakitalo   Members   -  Reputation: 591

Like
0Likes
Like

Posted 14 January 2013 - 07:23 AM

To obtain a well isolated quadtree system, you could just let the quadtree deal with indices to you object instances. Then a frustum culling procedure would return a vector of indices to visible instances. You could then apply another routine that would sort this array in some way if required. When building the tree, bounding box data would be the only thing that the tree needs to know about the objects, in addition to the indices. I'm not sure that this is the most object oriented approach, but the indices do provide a nice decoupling interface.



#7 Lil_Lloyd   Members   -  Reputation: 287

Like
0Likes
Like

Posted 16 January 2013 - 08:27 AM

Very interesting and helpful feedback from all. Thank you very much! I think I'm getting my head around this malarky bit by bit ;)






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS