Blackvoxel > Programming with Blackvoxel
How hard could smoothing be?
d3x0r:
I see what you did...
just moving the eye position can shrink the world... but then the player body doesn't match the eye .. and if I have a 2 block hole in a wall I can go through the wall even though my eyes are staring at blocks.
Detection distance.... should stay the same I guess... just has 64x the blocks in the same space...
like I should still be able to dig the same distance as 6 blocks from before... but now it's 24 blocks deep instead
d3x0r:
Is sector based PartialCulling really worth even having?
How often is an entire side of a thing opaque?
Culling needs to not be a world property; but really more something associated with the renderer; because only the renderer (and save file) is a consumer of cull data. It certainly makes sense how it currently is that nothing(except game container) knows about the renderer... I started passing the game environment as initializers so classes could get the renderer; and added some culling methods to renderer... but maybe ZVoxelCuller should be a utility class that's associated with/retrieved from the renderer, and then pass that. ZVoxelCuller would look more like an interface with
ZVoxelCuller( ZWorld &world );
InitFaceCullData( sector );
CullSector( sector, internal/edges);
-or-
CullSectorInternal( sector );
CullSectorEdges( sector );
and CullSingleVoxel( sector, (x,y,z/offset) );
----------------
started ending up with circular references, and things that had static members of thigns like SectorStreamLoader has a SectorCreator, which allocates sectors, and needs the culler (sounds like color)....
----------
I'm enjoying mangling your code :)
I'm going to make some other forks and clean up portions of this, like ZMatrix modification to Camera/PlayerPhysics
---------
also right now; draw_left actually draws the right side; and draw_right draws the right side...
this is a texture labeled according to clipping output...
the letters are oriented up on the sides... and the A for 'above' is up-right if looking from the back to the front. if you like bypass the 'DRAWFACE_LEFT' there will be a hole for the 'L' side... either that or forward/backward are reversed... or above/below... if any of these were wrong in the current... render matrix, then the RTFM cube would have backward text on some sides... and an original version does the same thing. (I'm pretty sure.... mine's totally broken right now, going forward with ZVoxelCuller utility class...)
-------------
Disrelated to the thread, but was thinking about other objects... I guess ZVoxelWorld is where I should add a ZMatrix for its current orientation, and give it a small sector size... was going to make ZVoxelSector instances that were standalone for large object models... (an airplane instead of a box with an airplane picture for instance), but maybe it makes more sense to instance worlds
d3x0r:
Neither of these routines use FaceCulling or 'data' variable associated with the face culling faces... so I think the faceculling save/load isn't working...
Compress_FaceCulling_RLE(UByte*data, void*stream)
{
... actual = OtherInfos[p];
}
Decompress_FaceCulling_RLE(UByte*data, void*stream)
{
OtherInfos[p] = read;
}
olive:
--- Quote from: d3x0r on October 26, 2014, 11:52:54 am ---I see what you did...
just moving the eye position can shrink the world... but then the player body doesn't match the eye .. and if I have a 2 block hole in a wall I can go through the wall even though my eyes are staring at blocks.
Detection distance.... should stay the same I guess... just has 64x the blocks in the same space...
like I should still be able to dig the same distance as 6 blocks from before... but now it's 24 blocks deep instead
--- End quote ---
The problem come from the collision detection system. That's what is making in fact the effectiveness of the body size.
Anyway, whatever the way, the collision detection must be redone if you want to change voxel size.
Increasing the detection distance appeared to be necessary because with some ratio, the player was unable to get voxels just at it's feet.
--- Quote ---...but as a variable it's not been a huge performance hit.
--- End quote ---
Not only a variable, but also using division/multiplication instead of shifting ... unless you would be limited to power of two ratio.
Sure, it's not huge, but it's always good to avoid when possible. :)
Yes, it's not always possible to avoid adding overhead when adding features.
Unfortunately, there is actually no way to make all voxel game possible features in one single engine. Some combinations would be technically impossible.
That's why, adding features will always be a matter of choice depending on what feature are wanted for a particular game.
The Blackvoxel Team
olive:
--- Quote from: d3x0r on October 26, 2014, 03:29:13 pm ---Is sector based PartialCulling really worth even having?
How often is an entire side of a thing opaque?
Culling needs to not be a world property; but really more something associated with the renderer; because only the renderer (and save file) is a consumer of cull data. It certainly makes sense how it currently is that nothing(except game container) knows about the renderer... I started passing the game environment as initializers so classes could get the renderer; and added some culling methods to renderer... but maybe ZVoxelCuller should be a utility class that's associated with/retrieved from the renderer, and then pass that. ZVoxelCuller would look more like an interface with
ZVoxelCuller( ZWorld &world );
InitFaceCullData( sector );
CullSector( sector, internal/edges);
-or-
CullSectorInternal( sector );
CullSectorEdges( sector );
and CullSingleVoxel( sector, (x,y,z/offset) );
...
-------------
--- End quote ---
Does culling must be done at world level ? In some parts, sectors need to be processed independently to the existence of a world. So, your proposition of an independent class is an efficient idea to clean the mess.
But we are tempted to say : don't mangle your head too much with that.
Because what is on our roadmap for future is making face culling completely integrated with rendering phase.
Yes, making that could be a very, very bad choice in some ways because it can add significant overhead to the main thread.
So, why we plan to do it ? Let's explain the actual system and why it could be better.
Keep in mind that Blackvoxel made very specific game choices. It's MVI engine cause massive load on rendering. Also, vehicles like airplane needs very quick refresh of sectors.
That's why avoiding bottleneck in rendering was vital for Blackvoxel. That's wasn't easy to make rendering fluid enough and balance rendering settings for getting fluid and quick.
To alleviate the task of rendering, work had been distributed on other threads. At sector loading/creation, main culling is done. It's completed on the MVI's thread for partial culling. Partial culling is also done on individual voxel refresh.
So you are asking, why partial culling ? Does it is really needed ?
Partial culling is not related to having an entire sector face culled, that's simply because voxels on the sides of a sectors needs to have culling like others. Unless that, it will make visible errors on side... or huge slowdowns if you make sides "all visibles".
The problem is simple : external faces of voxels on side can't be culled without data of the neighboring sectors.
At sector loading and creation, we can't rely on other sectors being in memory, so we made culling for all faces but the outside.
Further, MVI thread check if culling is needed on sectors and look if neighboring sectors are loaded. If so, culling is completed on the relevant side. Making these partial culling make less load on memory system than full culling.
All that stuff is complicated, but it's fast and working well.
So, why wanting to change that ?
In one word : because of MVI. What is optimized in one hand is bad on other.
The system rely on fact the faces are (nearly) always culled. So when MVI needs to move a voxel, it must redo culling on it's faces. Looking at the voxel changing routine will let you understand what we mean : it could be faster without need to keep faces culled.
Since the begining, we optimized rendering a lot with various stuff. It may compensate enough for what will be lost.
It will also be simpler, eliminate a lot of architectural complexity and make it more powerfull for future architectural change we are planing.
The Blackvoxel Team
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version