Octree selector memory use
Octree selector memory use
I´ve noticed that on large meshes when the Octree triangle selector is created, a massive list of nodes is created, and up to 4 times more memory than needed for the nesh (vertices, indices etc), is used just for the triangle selector.
Is there any way to reduce that, or to make a hit selection system that is more memory efficient?
Is there any way to reduce that, or to make a hit selection system that is more memory efficient?
Re: Octree selector memory use
Many apps use color picking.
Re: Octree selector memory use
Yes but how does that determine which sub-mesh has been touched?
Re: Octree selector memory use
Google for color picking. You assign different colors for each part you want to recognize.
Re: Octree selector memory use
Not possible as the colors could be anything, and are related to the colors of the fish models, which I cannot reassign.
I´m looking for a more efficient way to detect hits... there must be a better way to do this.
I´m looking for a more efficient way to detect hits... there must be a better way to do this.
Re: Octree selector memory use
Just wondering - is this really a problem? Generally the texture memory blows away the amount of mesh-memory you need by far.
You can try tuning the octree parameters somewhat. But triangle-selectors will always be larger than the mesh as it keeps real triangles (so vertices are no longer shared like with vertex-arrays). The alternative would be to write a triangleselector which creates the triangles constantly at runtime when trying to select something (would use less memory, but I suppose it would be a lot slower).
I have used an own grid-selector in the past as alternative, but while that is better/worse in some situation it also works with triangles.
You can try tuning the octree parameters somewhat. But triangle-selectors will always be larger than the mesh as it keeps real triangles (so vertices are no longer shared like with vertex-arrays). The alternative would be to write a triangleselector which creates the triangles constantly at runtime when trying to select something (would use less memory, but I suppose it would be a lot slower).
I have used an own grid-selector in the past as alternative, but while that is better/worse in some situation it also works with triangles.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Octree selector memory use
The weak point of the system is the cpu, so trying to not have it process 10s thousands of triangles to find a hit match would be good.
This is from a paper on computing mesh collisions on the GPU : http://www8.cs.umu.se/education/examina ... eckman.pdf
"Implementing and evaluating triangle mesh collision detection on GPUs using OpenCL was another important aspect. As GPUs nowadays are getting more and more advanced, with better and better capabilities for performing general programming, evaluating whether the massively parallel architecture of GPUs could lead to speedups versus a CPU implementation was an important aspect."
Having the GPU to handle hits in scenes with bigger models would be ideal of course...
This is from a paper on computing mesh collisions on the GPU : http://www8.cs.umu.se/education/examina ... eckman.pdf
"Implementing and evaluating triangle mesh collision detection on GPUs using OpenCL was another important aspect. As GPUs nowadays are getting more and more advanced, with better and better capabilities for performing general programming, evaluating whether the massively parallel architecture of GPUs could lead to speedups versus a CPU implementation was an important aspect."
Having the GPU to handle hits in scenes with bigger models would be ideal of course...
Re: Octree selector memory use
You really should do your research. Color picking does not mean you change your normal mesh colors. You always ask for hand-holding...
Re: Octree selector memory use
True hendu,
Well, I still don´t think color picking will work where the textures can be any color due to reflections and lighting, unless this is some form of color picking that I´ve not heard of...
This paper I referenced upload the triangle data to the GPU, and I guess that´s the best way to crack this nut head on, or is there a better solution?
Well, I still don´t think color picking will work where the textures can be any color due to reflections and lighting, unless this is some form of color picking that I´ve not heard of...
This paper I referenced upload the triangle data to the GPU, and I guess that´s the best way to crack this nut head on, or is there a better solution?
Re: Octree selector memory use
Multiple render target + color picking problem solved
Re: Octree selector memory use
MRTs are not efficient in complex scenes though... or am I not understanding?
Re: Octree selector memory use
why wouldn't they? it really depends how you use them
Re: Octree selector memory use
Other than high rasterizing consumers, the MRT just serve for anything. the only drawback is to read the pixels, as that implies retrieving the rendertarget data, and reading it, whether directly by locking the texture or implicitly through a driver call.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt