If your target hardware supports shader model 5, you can use a combination of a pre-tessellated cylinder and hardware tessellation to arrive at the needed resolution.
In the CPU side, you could divide the width and height resolutions by 64, and on the GPU tessellate the coarser geometry by factors of 64 to get the effective target resolution.
BUT consider this: do you actually need that kind of actual geometry resolution, or would a bump-map + displacement approximation be enough for the visual effect? The latter is a very common approach.
Regarding spatial partitioning, you could divide the cylinder surface to 4 separate sectors (and the possible cylinder caps as two more), and render only those that are within the view volume and that are actually facing the view. If you use more complex visibility culling logic, there is a greater chance that the visibility determination and increased device call count takes more time than just rendering the whole dataset at once. If you have heavy shaders, you can justify for heavier visibility determination too.
Show differencesHistory of post edits
#4Nik02
Posted 17 October 2012 - 10:12 AM
If your target hardware supports shader model 5, you can use a combination of a pre-tessellated cylinder and hardware tessellation to arrive at the needed resolution.
In the CPU side, you could divide the width and height resolutions by 64, and on the GPU tessellate the coarser geometry by factors of 64 to get the effective target resolution.
BUT consider this: do you actually need that kind of actual geometry resolution, or would a bump-map + displacement approximation be enough for the visual effect? The latter is a very common approach.
Regarding spatial partitioning, you could divide the cylinder surface to 4 separate sectors (and the possible cylinder caps as two more), and render only those that are within the view volume and that are actually facing the view. If you use more complex visibility culling logic, there is a greater chance that the visibility determination and increased device call count takes more time than just rendering the whole dataset at once.
In the CPU side, you could divide the width and height resolutions by 64, and on the GPU tessellate the coarser geometry by factors of 64 to get the effective target resolution.
BUT consider this: do you actually need that kind of actual geometry resolution, or would a bump-map + displacement approximation be enough for the visual effect? The latter is a very common approach.
Regarding spatial partitioning, you could divide the cylinder surface to 4 separate sectors (and the possible cylinder caps as two more), and render only those that are within the view volume and that are actually facing the view. If you use more complex visibility culling logic, there is a greater chance that the visibility determination and increased device call count takes more time than just rendering the whole dataset at once.
#3Nik02
Posted 17 October 2012 - 10:09 AM
If your target hardware supports shader model 5, you can use a combination of a pre-tessellated cylinder and hardware tessellation to arrive at the needed resolution.
In the CPU side, you could divide the width and height resolutions by 64, and on the GPU tessellate the coarser geometry by factors of 64 to get the effective target resolution.
BUT consider this: do you actually need that kind of actual geometry resolution, or would a bump-map + displacement approximation be enough for the visual effect? The latter is a very common approach.
Regarding spatial partitioning, you could divide the cylinder surface to 4 separate sectors (and the possible cylinder caps as two more), and render only those that are within the view volume and that are actually facing the view.
In the CPU side, you could divide the width and height resolutions by 64, and on the GPU tessellate the coarser geometry by factors of 64 to get the effective target resolution.
BUT consider this: do you actually need that kind of actual geometry resolution, or would a bump-map + displacement approximation be enough for the visual effect? The latter is a very common approach.
Regarding spatial partitioning, you could divide the cylinder surface to 4 separate sectors (and the possible cylinder caps as two more), and render only those that are within the view volume and that are actually facing the view.
#2Nik02
Posted 17 October 2012 - 10:08 AM
If your target hardware supports shader model 5, you can use a combination of a pre-tessellated cylinder and hardware tessellation to arrive at the needed resolution.
In the CPU side, you could divide the width and height resolutions by 64, and on the GPU tessellate the coarser geometry by factors of 64 to get the effective target resolution.
BUT consider this: do you actually need that kind of actual geometry resolution, or would a bump-map + displacement approximation be enough for the visual effect? The latter is a very common approach.
Regarding spatial partitioning, you could divide the cylinder surface to 4 separate sectors (and the possible cylinder caps as two more), and render only those that are within the view volume.
In the CPU side, you could divide the width and height resolutions by 64, and on the GPU tessellate the coarser geometry by factors of 64 to get the effective target resolution.
BUT consider this: do you actually need that kind of actual geometry resolution, or would a bump-map + displacement approximation be enough for the visual effect? The latter is a very common approach.
Regarding spatial partitioning, you could divide the cylinder surface to 4 separate sectors (and the possible cylinder caps as two more), and render only those that are within the view volume.
#1Nik02
Posted 17 October 2012 - 10:05 AM
If your target hardware supports shader model 5, you can use a combination of a pre-tessellated cylinder and hardware tessellation to arrive at the needed resolution.
In the CPU side, you could divide the width and height resolutions by 64, and on the GPU tessellate the coarser geometry by factors of 64 to get the effective target resolution.
BUT consider this: do you actually need that kind of actual geometry resolution, or would a bump-map + displacement approximation be enough for the visual effect? The latter is a very common approach.
In the CPU side, you could divide the width and height resolutions by 64, and on the GPU tessellate the coarser geometry by factors of 64 to get the effective target resolution.
BUT consider this: do you actually need that kind of actual geometry resolution, or would a bump-map + displacement approximation be enough for the visual effect? The latter is a very common approach.