Since a terrain will also be needed, I implemented a simple perlin noise terrain generator today. It will need more work before its useable along with the voxel raycasting.
Dienstag, 10. Dezember 2013
Freitag, 6. Dezember 2013
Speed Crafting
I tried to see whats possible in a short amount of time. Creating the environment below took 2 hours to create (blocks and a very simple level)
Mittwoch, 4. Dezember 2013
Dienstag, 3. Dezember 2013
Montag, 2. Dezember 2013
Mittwoch, 27. November 2013
Color & Normal Compression Result
The screenshot below shows the result; includes specular lighting.
Octree: 115 MB , 2.88 bytes / voxel (including specular, glow, and more components),
Resolution : 4096x4096x4096 voxels
Using zip for storing the octree on disk reduces the size to ~1.44 bytes/voxel
( This includes color, normal, position and LOD data )
Comparison to common compression methods:
Color compression, DXT1: 0.5 byte / pixel
Normal compression, 3dc: 1 byte / pixel (only tangent space, no arbitrary normals!)
Linear octree: ~2.275 bit / voxel (for a surface, ~4 of 8 bit/node are used)
For CRUNCH, it provides ~1 bit/pixel for color and ~2 bit / pixel for normals.
https://www.youtube.com/watch?v=7bJ-D1xXEeg
https://code.google.com/p/crunch/
Example with 4 different specular power settings
Octree: 115 MB , 2.88 bytes / voxel (including specular, glow, and more components),
Resolution : 4096x4096x4096 voxels
Using zip for storing the octree on disk reduces the size to ~1.44 bytes/voxel
( This includes color, normal, position and LOD data )
Comparison to common compression methods:
Color compression, DXT1: 0.5 byte / pixel
Normal compression, 3dc: 1 byte / pixel (only tangent space, no arbitrary normals!)
Linear octree: ~2.275 bit / voxel (for a surface, ~4 of 8 bit/node are used)
For CRUNCH, it provides ~1 bit/pixel for color and ~2 bit / pixel for normals.
https://www.youtube.com/watch?v=7bJ-D1xXEeg
https://code.google.com/p/crunch/
Freitag, 22. November 2013
Color & Normal Compression
The new version uses 24 bit colors with color & normal compression. It achieves a 1:9 compression ratio compared to uncompressed storage. Speed impact is about 5-10%.
Montag, 4. November 2013
Mittwoch, 30. Oktober 2013
Dienstag, 22. Oktober 2013
Freitag, 9. August 2013
Mittwoch, 7. August 2013
Voxel Master - New functions
Today I added a smear function as well as grow/shrink.
As you can see in the image its easy to create organic stuff.
You can fetch the latest version here:
Samstag, 3. August 2013
Mittwoch, 31. Juli 2013
Voxel Editor Update: Higher Speed
The new version stores geometry on the GPU, so framerates are much higher. Also larger scenes can be created now
Freitag, 19. Juli 2013
Voxel Editor : New functions
Added a couple of functions & features like additional polygon functions, ssao, smoothing and others.
Donnerstag, 11. Juli 2013
Dienstag, 9. Juli 2013
Voxel Paint Tool
This is a first test of a Voxel Paint program. It supports a simple add/sub brush and also brush size and hardness.
Dienstag, 2. Juli 2013
Better memory compression
Montag, 17. Juni 2013
Titan benchmark
Yesterday I had the chance to run the raycaster on an NVidia TITAN.
The result for the tree-scene was
140 fps, 1920x1080
200-300 fps, 1280x720
The result for the tree-scene was
140 fps, 1920x1080
200-300 fps, 1280x720
Dienstag, 21. Mai 2013
Parallel all permutations - non-recursive - GPU optimal
This post is a general one - not voxel related.
Some time ago I developed a a simple, fast and yet non-recursive method to directly compute the n'th permutation. Thats useful especially when working on the graphics card with CUDA for parallel evaluations. (it might have been published somewhere already - so if you know the reference, you can post it as a comment)
The algorithm is based on the following property. Lets say there are 6 characters in the string to permute. Then the result is 6! = 720 combinations. In the first column of the results, we get 720/6=120 lines of each character. This means if the index counts from 0 to 719, then the first character to be removed is computed as remove_index = index/120.
For the next column, 5 numbers are left. This means, that 120 = 5 * 24 lines of the same character - and so on.
We the following list of removes:
column0: remove_index = (a/120)%5;
column1: remove_index = (a/24)%4;
column2: remove_index = (a/6)%3;
column3: remove_index = (a/2)%2;
column4: remove_index = (a/1)%1;
Code snipplet:
In the code, perm defines the Lehmer code (wiki)
Some time ago I developed a a simple, fast and yet non-recursive method to directly compute the n'th permutation. Thats useful especially when working on the graphics card with CUDA for parallel evaluations. (it might have been published somewhere already - so if you know the reference, you can post it as a comment)
The algorithm is based on the following property. Lets say there are 6 characters in the string to permute. Then the result is 6! = 720 combinations. In the first column of the results, we get 720/6=120 lines of each character. This means if the index counts from 0 to 719, then the first character to be removed is computed as remove_index = index/120.
For the next column, 5 numbers are left. This means, that 120 = 5 * 24 lines of the same character - and so on.
We the following list of removes:
column0: remove_index = (a/120)%5;
column1: remove_index = (a/24)%4;
column2: remove_index = (a/6)%3;
column3: remove_index = (a/2)%2;
column4: remove_index = (a/1)%1;
Code snipplet:
std::string default = "12345";
int perm=1, digits=default.size();
for (int i=1;i<=digits;perm*=i++);
for (int a=0;a<perm;a++)
{
std::string avail=default;
for (int b=digits,div=perm;b>0; b--)
{
div/=b;
int index = (a/div)%b;
printf("%c", avail[index] );
//avail[index]=avail[b-1]; // non-lexigraphic but fast
avail.erase(index,1) ; // lexigraphically correct
}
printf("\n");
}
printf("permutations:%d\n",perm);
In the code, perm defines the Lehmer code (wiki)
Dienstag, 19. Februar 2013
Samstag, 16. Februar 2013
Another speedup: now ~70fps@1920x1024
Mittwoch, 13. Februar 2013
OpenCL Happy Buddha Raycasting 1920x1024@50fps
Here a first glimpse of a new optimization. The good old Happy Buddha scene (1024^3) raycasted at 50 fps at almost HD resolution (1920x1024). Video below. For 960x512 it renders at 150 fps.
Donnerstag, 7. Februar 2013
Instancing: Combined AABB + Voxel raycasting
Here a first combined test by raycasting 10.000 to 100.000 models.
Abonnieren
Posts (Atom)