fix issue with copy

This commit is contained in:
ZappoMan 2013-11-25 15:52:30 -08:00
parent 63a82af449
commit a60cf0f34e
3 changed files with 11 additions and 16 deletions

View file

@ -1524,7 +1524,6 @@ bool Application::sendVoxelsOperation(VoxelNode* node, void* extraData) {
SendVoxelsOperationArgs* args = (SendVoxelsOperationArgs*)extraData;
if (node->isColored()) {
const unsigned char* nodeOctalCode = node->getOctalCode();
unsigned char* codeColorBuffer = NULL;
int codeLength = 0;
int bytesInCode = 0;
@ -1545,10 +1544,9 @@ bool Application::sendVoxelsOperation(VoxelNode* node, void* extraData) {
}
// copy the colors over
codeColorBuffer[bytesInCode + RED_INDEX ] = node->getColor()[RED_INDEX ];
codeColorBuffer[bytesInCode + RED_INDEX] = node->getColor()[RED_INDEX];
codeColorBuffer[bytesInCode + GREEN_INDEX] = node->getColor()[GREEN_INDEX];
codeColorBuffer[bytesInCode + BLUE_INDEX ] = node->getColor()[BLUE_INDEX ];
codeColorBuffer[bytesInCode + BLUE_INDEX] = node->getColor()[BLUE_INDEX];
getInstance()->_voxelEditSender.queueVoxelEditMessage(PACKET_TYPE_SET_VOXEL_DESTRUCTIVE,
codeColorBuffer, codeAndColorLength);
@ -1612,7 +1610,6 @@ void Application::pasteVoxelsToOctalCode(const unsigned char* octalCodeDestinati
// the server as an set voxel message, this will also rebase the voxels to the new location
SendVoxelsOperationArgs args;
args.newBaseOctCode = octalCodeDestination;
_sharedVoxelSystem.getTree()->recurseTreeWithOperation(sendVoxelsOperation, &args);
if (_sharedVoxelSystem.getTree() != &_clipboard) {

View file

@ -9,8 +9,6 @@
// * add stats tracking for number of unique colors and consecutive identical colors.
// (as research for color dictionaries and RLE)
//
// * copy/paste broken?
//
// * further testing of compression to determine optimal configuration for performance and compression
//
// * improve semantics for "reshuffle" - current approach will work for now and with compression

View file

@ -1534,12 +1534,15 @@ int VoxelTree::encodeTreeBitstreamRecursion(VoxelNode* node,
int childTreeBytesOut = 0;
// XXXBHG - Note, this seems like the correct logic here, if we included the color in this packet, then
// the LOD logic determined that the child nodes do not need to be visible... and if so, we shouldn't recurse
// them further. But... this isn't how the code has been for a while... but it's a major savings (~30%) and
// it seems to work correctly. I'd like to discuss...
//
// only recurse if we DIDN'T include colore on this level
if (!oneAtBit(childrenColoredBits, originalIndex)) {
// the LOD logic determined that the child nodes would not be visible... and if so, we shouldn't recurse
// them further. But... for some time now the code has included and recursed into these child nodes, which
// would likely still send the child content, even though the client wouldn't render it. This change is
// a major savings (~30%) and it seems to work correctly. But I want us to discuss as a group when we do
// a voxel protocol review.
//
// This only applies in the view frustum case, in other cases, like file save and copy/past where
// no viewFrustum was requested, we still want to recurse the child tree.
if (!params.viewFrustum || !oneAtBit(childrenColoredBits, originalIndex)) {
childTreeBytesOut = encodeTreeBitstreamRecursion(childNode, packet, bag, params, thisLevel);
}
@ -1916,13 +1919,10 @@ void VoxelTree::copySubTreeIntoNewTree(VoxelNode* startNode, VoxelTree* destinat
while (!nodeBag.isEmpty()) {
VoxelNode* subTree = nodeBag.extract();
packet.reset(); // reset the packet between usage
// ask our tree to write a bitsteam
EncodeBitstreamParams params(INT_MAX, IGNORE_VIEW_FRUSTUM, WANT_COLOR, NO_EXISTS_BITS, chopLevels);
bytesWritten = encodeTreeBitstream(subTree, &packet, nodeBag, params);
// ask destination tree to read the bitstream
ReadBitstreamToTreeParams args(WANT_COLOR, NO_EXISTS_BITS);
destinationTree->readBitstreamToTree(packet.getUncompressedData(), packet.getUncompressedSize(), args);