-
Bug
-
Resolution: Won't Fix
-
P4
-
8
After the triangle mesh is filled with data (points, faces, texture coords, and material) and displayed in a mesh view, there is a first phase which is highly CPU and memory intensive.
I'm computing an elevation grid. The number of triangles is roughly twice the number of vertices (*). For a 512*512 grid, it takes about two seconds of compute time (**) and 280 megs of RAM!
Raw data sizes are (less than 20 megs total):
* Points: 3 145 728 bytes
* Faces: 12 533 808 bytes
* TexCoords: 2 097 152 bytes
* Material: ?
I would like this issue to cover three subjects:
* What is this computation about?
* How to improve the computation?
* Why the "extra" memory is not freed?
(*) triangleCount= (gridWidth-1)*(gridHeight-1)*2
(**) excluding points, faces, texture and material computation time AND with all the CPU cores used! - the CPU is an old Xeon 4 core
I'm computing an elevation grid. The number of triangles is roughly twice the number of vertices (*). For a 512*512 grid, it takes about two seconds of compute time (**) and 280 megs of RAM!
Raw data sizes are (less than 20 megs total):
* Points: 3 145 728 bytes
* Faces: 12 533 808 bytes
* TexCoords: 2 097 152 bytes
* Material: ?
I would like this issue to cover three subjects:
* What is this computation about?
* How to improve the computation?
* Why the "extra" memory is not freed?
(*) triangleCount= (gridWidth-1)*(gridHeight-1)*2
(**) excluding points, faces, texture and material computation time AND with all the CPU cores used! - the CPU is an old Xeon 4 core
- duplicates
-
JDK-8091319 The frame rate decreases by a factor of 4 when one point of a TriangleMesh is changed at every pulse
-
- Open
-
- is blocked by
-
-
- Open
-
-
-
- Open
-
-
-
- Resolved
-