Octree selector memory use

[robmar]

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?

[hendu]

Many apps use color picking.

[robmar]

Yes but how does that determine which sub-mesh has been touched?

[hendu]

Google for color picking. You assign different colors for each part you want to recognize.

[robmar]

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.

[CuteAlien]

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.

[robmar]

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...

[hendu]

You really should do your research. Color picking does not mean you change your normal mesh colors. You always ask for hand-holding...

[robmar]

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?

[Granyte]

Multiple render target + color picking problem solved

[robmar]

MRTs are not efficient in complex scenes though... or am I not understanding?

[Granyte]

why wouldn't they? it really depends how you use them

[Mel]

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.