Jump to content

  • Log In with Google      Sign In   
  • Create Account


Rendering Implementation Question


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
2 replies to this topic

#1 EarthBanana   Members   -  Reputation: 786

Like
0Likes
Like

Posted 06 December 2013 - 10:17 PM

I can have a potentially very large number of mesh instances (the mesh being a 3d hex tile) in my viewport at one time - potentially 64 by 64 by 64...

 

As it turns out, when there is that many instances (I'm always trying to test for worst case) one of the biggest bottlenecks was actually going through and extracting the transform for 200,000 tiles - what I was doing at first was building a std::vector of transforms every frame and using glBufferData passing a pointer to that std::vector - this was terribly slow and did not work at all

 

So then I changed it and made a std::vector of transforms where each hex tile instance contained a reference to a transform in the std::vector - when a tile was moved it would change its transform directly through the reference - I then used a dirty flag and only rebuilt the transformBuffer when a tile was added or deleted from the map

 

This worked fairly well but was messy and made it hard for me to implement any kind of culling - I'm okay with only rebuilding the transform buffer when a new tile is added or one is deleted from the map, but I don't like it that when the user is moving a tile around they are directly manipulating the tile's transform... which leads me to my question

 

Is it really feasible to run through 200,000 tile instances (considering a tile instance is basically a small struct containing a pointer to a HexTile and some other things like a 4dmatrix reference), check if the tile needs to be updated, and if it does then update the transform as needed?

 

The main problem I have with the user directly manipulating the tile's transform is that it puts the Input System in charge of things it seems like it shouldn't be in charge of... IE the input system is calling tileInstance.move(x,y,z) which directly changes the tileInstance's transform.. I don't really know why but that seems bad



Sponsor:

#2 Krohm   Crossbones+   -  Reputation: 2920

Like
0Likes
Like

Posted 09 December 2013 - 01:32 AM


Is it really feasible to run through 200,000 tile instances, check if the tile needs to be updated, and if it does then update the transform as needed?
No. I want you to read again what you have written.


The main problem I have with the user directly manipulating the tile's transform is that it puts the Input System in charge of things it seems like it shouldn't be in charge of... IE the input system is calling tileInstance.move(x,y,z) which directly changes the tileInstance's transform.. I don't really know why but that seems bad
So you know the solution already. This is an event-based action and needs to handled at need. What you need is to batch as much as you can. With no user interaction, the obtained structure is guaranteed to be correct. When an user moves a tile (or whatever), you trigger some special refresh... as you're doing already?

Not at all!

What your input system is doing is to have an explicit semantic binding: this action corresponds to a specific tile, at a specific action on that tile. You are correct in feeling uncomfortable about that! The solution is to have an intermediate layer. The input system could for example dispatch (call a function) to a set of generic objects. If one of those objects is the "tile manager", then its specific implementation will be in charge of computing which tile is being manipulated. This way preserves separation of concerns, and will make you feel better.



#3 haegarr   Crossbones+   -  Reputation: 3669

Like
0Likes
Like

Posted 09 December 2013 - 03:13 AM

Due to the lack of information, I wonder what you are doing exactly. Many things come to my mind, but they are all vague until further knowledge:

 

* Do you really need a 4D matrix for transformation? Individual scaling and rotation (more than ever with 3 axes) seems me strange, because we are speaking of tiles. Reducing the memory footprint of the transforms may help in cache hits and transfer bandwidth reduction.

 

* Are the tiles itself stored in the same order in which the transformations are stored? When you process it, e.g. during culling, do you do this in linear order? Is it really necessary to have so many pointers all over the place? Would parallel indexing be an option?

 

* You said that the total layout may show up to 64 x 64 x 64 tiles … what does the 3rd dimension mean here? Does it allow for a "natural" division into sections?

 

* How big is the std::vector initialized? AFAIK a std::vector doubles its capacity each time when it becomes full, but with 2^18 entries this may happen often enough, and each capacity increase causes a memory copy. You know the maximum amount of tiles, so a full sized pre-allocation is possible.

 

* Have you taken steps to reduce the count of buffer copies?

 

* Is grouping of tiles an option?

 


Is it really feasible to run through 200,000 tile instances (considering a tile instance is basically a small struct containing a pointer to a HexTile and some other things like a 4dmatrix reference), check if the tile needs to be updated, and if it does then update the transform as needed?

If this is for updating only, my question is how many tiles not being in a continuous range are expected to be updated at a time and frequently. Wouldn't a container memorizing just dirty tiles be more sufficient?






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