Blackvoxel > Programming with Blackvoxel
How hard could smoothing be?
d3x0r:
Well... it was a lot harder than I thought...
http://youtu.be/F4AUEHm7BAk
work in progress; maybe
inner corners are unsmoothed... just smooths the outer edges.
Have many corner cases that have multiple solution paths... light right now single blocks and single rows of blocks don't smooth either....
and I have a broken corner that could be better; not to mention all the directions that are yet missing.
was going to map textures on diagonals such that if it's a top & left visible, to show the top and left side of the texture, so the diagonals would get an extra line; right now all left & anything is left and any right & anthing is right and any forward & any is forward and same for back; sorta, top&((right/left)&(back/front)) is top....
olive:
--- Quote from: d3x0r on October 25, 2014, 02:20:50 pm ---Well... it was a lot harder than I thought...
http://youtu.be/F4AUEHm7BAk
work in progress; maybe
inner corners are unsmoothed... just smooths the outer edges.
Have many corner cases that have multiple solution paths... light right now single blocks and single rows of blocks don't smooth either....
and I have a broken corner that could be better; not to mention all the directions that are yet missing.
was going to map textures on diagonals such that if it's a top & left visible, to show the top and left side of the texture, so the diagonals would get an extra line; right now all left & anything is left and any right & anthing is right and any forward & any is forward and same for back; sorta, top&((right/left)&(back/front)) is top....
--- End quote ---
Amazing mod... :)
Nice marching cube smoothing.
It looks very good in the video.
We have seen in the video that you are using Visual Studio. We assume you are using Gcc/Gdb with it?
The Blackvoxel Team
d3x0r:
--- Quote from: olive on October 25, 2014, 11:08:10 pm ---
We have seen in the video that you are using Visual Studio. We assume you are using Gcc/Gdb with it?
The Blackvoxel Team
--- End quote ---
Nah, using cmake, which spits out makes appropraite for visual studio, I also use open watcom on the side... watcom, gcc and msvc all catch different errors; but cmake allows one make system to support them all...
SDL also uses cmake scripts...
It took a long while; but cmake 2.4 was actually usable.
--------
It's actually not marching cubes...
Was reverting it so I could sway between Render_Basic and Render_Smooth by making most of renderBasic be REnder_Interface, and a virtual 'render' function... but it's just based on existing culling flags
--- Code: ---if ( ( culling & (FACEDRAW_TOP|FACEDRAW_LEFT) ) == (FACEDRAW_TOP|FACEDRAW_LEFT) )
{
// example excpetion...
// if( ( culling & ( FACEDRAW_TOP_HAS_FORWARD| FACEDRAW_LEFT_HAS_FORWARD ) )
// == ( FACEDRAW_TOP_HAS_FORWARD| FACEDRAW_LEFT_HAS_FORWARD ) )
// // render more complex interpretations
// else
// //basic, draw diagonal slope.
}
--- End code ---
unfortunately because near sectors aren't always present, and i haven't fixed up the mating clipping updates, on sector boundaries I get false lacking cubes...
and I broke saves because I expended the clipping data from a byte to a long; needed 12 more bits in addition to the original 6 facedraw bits...
and I think I might need all 8 more for the corners ... 26 total... representing the cube of voxels around a center voxel
----------
re the floating land issue; it started showing up when I shrank the block size, so I figured it was just able to see so many more sectors above it that it actually ended up just treating every sector as 'need to fill' ... but it may be a cube that failed to be ejected properly... because again the scale of the world and that doesn't match what it was designed to be..
was just curious if it was something you had seen or something I had messed up... I'll revert some at some point and see what I did.
olive:
--- Quote from: d3x0r on October 26, 2014, 12:45:01 am ---...
re the floating land issue; it started showing up when I shrank the block size, so I figured it was just able to see so many more sectors above it that it actually ended up just treating every sector as 'need to fill' ... but it may be a cube that failed to be ejected properly... because again the scale of the world and that doesn't match what it was designed to be..
was just curious if it was something you had seen or something I had messed up... I'll revert some at some point and see what I did.
--- End quote ---
Hi,
Maybe something could help you :)
We just published on github some changes allowing to modify voxel size.
But we have taken a particular way to do it.
That's possible because in Blackvoxel, the voxel size is considered to be some kind of base unit.
The player coordinates are considered subdivision of the base voxel unit, something like centimetres. 256 was chosen because it's a power of two.
So, even if the voxel size are changing, the conversion between "voxel units" and "player units" can stay the same.
Look at this line ( in ZActor_Player.cpp), where is defined observer eye position relative to the voxel size.
EyesPosition.y = 256.0 * 1.75;
We changed it to :
EyesPosition.y = 256.0 * 1.75 / COMPILEOPTION_VOXELSIZEFACTOR;
There's also some other locations where some values had to be changed, we did it for selector distance. This remain to be done for player speed.
Of course, player collision should be fixed also with this. But it's "working" enough for testing.
You can change voxel size in ACompileSettings.h with the parameter COMPILEOPTION_VOXELSIZEFACTOR
Changing it from 1.0 to 0.5 will make the voxels smaller.
We hope this could help.
The Blackvoxel Team
d3x0r:
Ya but you're shrinking the character too; the point was to add more detail to the world... not just shrink the virtual render size :) increases the sector count visible though I suppose; but that's just extending the sphere selector thing
It's basically the same mod I did... as a const int variable it's gonna compile away anyway... but as a variable it's not been a huge performance hit.
eye position should be 256
---------
So the inner-sector culling routine is working.... I'm gonna have problems with the inter-sector culling though... the inner-sector had a nice 3x9 block of sectors it was working with... I'm thinking of redoing the seam culling with a 2x3x3 row of voxel references.... need to recover blocks that are near the blocks that are near also...
pretty sure I can do this without the 8 corner cubes in the 3x3x3 set around a point.
was also considering how to implement that culling data is 8 or 32 bits (save version?) but would like to retain so renderer could be applied per sector... but keep the optimal 6 bit culling for render basic...
--------
not sure that a reference looking for Xoffset Yoffset etc is any faster than doing the shifts... since the coorindate has to be shifted to index the array anyway...
Navigation
[0] Message Index
[#] Next page
Go to full version