WIP BSP Tree for 3D Layer Sorting

cc/output/bsp_tree.cc

+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "cc/output/bsp_tree.h"
+
+#include <list>
+#include <vector>
+
+#include "base/memory/scoped_ptr.h"
+#include "cc/base/scoped_ptr_deque.h"
+#include "cc/base/scoped_ptr_vector.h"
+#include "cc/output/bsp_compare_result.h"
+#include "cc/output/bsp_controller.h"
+#include "cc/quads/draw_polygon.h"
+
+namespace cc {
+
+BspNode::BspNode(scoped_ptr<DrawPolygon> data) {
+  node_data = data.Pass();
+}
+
+BspNode::~BspNode() {
+}
+
+BspTree::BspTree(BspController* bsp_controller,

[enne (OOO), 2014/07/28 21:38:20]

This is kind of an OO weirdness.  BspController isn't actually a polymorphic
class.  It has no data and only static functions, so it's not like they can be
overridden or changed in any way.

I think you should probably just remove controller and put those functions in
BspTree? Or, if you wanted to keep them separate, have a BspUtil namespace that
only has static functions in it and the BspTree can just call the static
functions directly rather than via this fake bsp_controller object which doesn't
serve any purpose.

[troyhildebrandt, 2014/07/29 00:04:33]

Removed the BspController, it's an artifact of an older design.

+                 ScopedPtrVector<DrawPolygon>* list)

[enne (OOO), 2014/07/28 21:38:20]

The BspTree takes ownership of this list, right? If so, just make it
ScopedPtrVector<DrawPolygon> list so that the caller has to Pass() it in.  Also,
FromList looks like a noop, so maybe this should be a ScopedPtrDeque to save a
copy.

[troyhildebrandt, 2014/07/29 00:04:33]

Now BspTree constructor takes a ScopedPtrDeque* instead, removed FromList.

[troyhildebrandt, 2014/07/29 00:04:33]

Removed FromList, made the constructor do minimal work by taking a
ScopedPtrDeque*.

+    : controller_(bsp_controller) {
+  FromList(list);
+}
+
+// FromList takes an input list and moves the better splitting polygons to the
+// front of the queue so when it comes time to build the tree, we already have
+// our splitting plane decided in the first element of the queue. BuildTree is
+// then called to perform the actual building of the tree using this list.
+void BspTree::FromList(ScopedPtrVector<DrawPolygon>* list) {
+  if (list->size() == 0)
+    return;
+
+  ScopedPtrDeque<DrawPolygon> list_data;
+  for (ScopedPtrVector<DrawPolygon>::iterator it = list->begin();
+       it != list->end();
+       ++it) {
+    list_data.push_back(list->take(it));
+  }
+
+  root_ = scoped_ptr<BspNode>(new BspNode(list_data.take_front()));
+  BuildTree(root_.get(), &list_data);
+}
+
+// The idea behind using a deque for BuildTree's input is that we want to be
+// able to place polygons that we've decided aren't splitting plane candidates
+// at the back of the queue while moving the candidate splitting planes to the
+// front when the heuristic decides that they're a better choice. This way we
+// can always simply just take from the front of the deque for our node's
+// data.
+void BspTree::BuildTree(BspNode* node, ScopedPtrDeque<DrawPolygon>* data) {

[enne (OOO), 2014/07/28 21:38:20]

Can you come up with a better name than "data"?

[troyhildebrandt, 2014/07/29 00:04:32]

Done.

+  ScopedPtrDeque<DrawPolygon> front_list;
+  ScopedPtrDeque<DrawPolygon> back_list;
+
+  // We take in a list of polygons at this level of the tree, and have to
+  // find a splitting plane, then classify polygons as either in front of
+  // or behind that splitting plane.
+  while (data->size() > 0) {
+    // Is this particular polygon in front of or behind our splitting polygon.
+    BspCompareResult comparer_result = controller_->GetNodePositionRelative(
+        *data->front(), *(node->node_data));
+
+    // If it's clearly behind or in front of the splitting plane, we use the
+    // heuristic to decide whether or not we should put it at the back
+    // or front of the list.
+    scoped_ptr<DrawPolygon> new_front;
+    scoped_ptr<DrawPolygon> new_back;
+    switch (comparer_result) {
+      case BSP_FRONT:
+        front_list.push_back(data->take_front().Pass());
+        break;
+      case BSP_BACK:
+        back_list.push_back(data->take_front().Pass());
+        break;
+      case BSP_SPLIT:
+        // Time to split this geometry, *it needs to be split by node_data.
+        if (controller_->SplitPolygon(data->take_front(),
+                                      *(node->node_data),
+                                      &new_front,
+                                      &new_back)) {
+          front_list.push_back(new_front.Pass());
+          back_list.push_back(new_back.Pass());
+        }
+        break;
+      case BSP_COPLANAR_FRONT:
+        node->coplanars_front.push_back(data->take_front());
+        break;
+      case BSP_COPLANAR_BACK:
+        node->coplanars_back.push_back(data->take_front());
+        break;
+      default:
+        NOTREACHED();
+        break;
+    }
+  }
+
+  // Build the back subtree using the front of the back_list as our splitter.
+  if (back_list.size() > 0) {
+    node->back_child = scoped_ptr<BspNode>(new BspNode(back_list.take_front()));
+    BuildTree(node->back_child.get(), &back_list);
+  }
+
+  // Build the front subtree using the front of the front_list as our splitter.
+  if (front_list.size() > 0) {
+    node->front_child =
+        scoped_ptr<BspNode>(new BspNode(front_list.take_front()));
+    BuildTree(node->front_child.get(), &front_list);
+  }
+}
+
+void BspTree::Clear() {
+  if (root_) {
+    root_.reset();
+  }
+}
+
+BspTree::~BspTree() {
+  Clear();

[enne (OOO), 2014/07/28 21:38:19]

Why does there need to be an explicit clear? Can this call (and the Clear
function) go away?

[troyhildebrandt, 2014/07/29 00:04:32]

Removed.

+}
+
+}  // namespace cc