Class structure for an Octree [closed]A parent class needs to know his child classesOctree raycasting/raytracing - best ray/leaf intersection without recursionHow to find adjacent / neighbor cubes using octree datastructure?Generalized (non-slicing) pointer to templated tree nodes? (C++)C++ Branching recursive struct?Minimizing overhead for large trees in javaDoes an object of a subclass also allocate an object of the parent class?Dual Contouring: Refactoring a complex head-recursion octree dual traversal algorithm to be iterativeStoring data in an octree nodeHow to store data in an octree
Showing mass murder in a kid's book
Center page as a whole without centering each element individually
Error in master's thesis, I do not know what to do
What is the tangent at a sharp point on a curve?
Do I have to take mana from my deck or hand when tapping this card?
What (if any) is the reason to buy in small local stores?
If the Dominion rule using their Jem'Hadar troops, why is their life expectancy so low?
Hashing password to increase entropy
Is there any common country to visit for persons holding UK and Schengen visas?
Travelling in US for more than 90 days
What is this high flying aircraft over Pennsylvania?
1 John in Luther’s Bibel
Does capillary rise violate hydrostatic paradox?
"Oh no!" in Latin
Relations between homogeneous polynomials
What is the purpose of using a decision tree?
Is there a POSIX way to shutdown a UNIX machine?
Do people actually use the word "kaputt" in conversation?
Can you describe someone as luxurious? As in someone who likes luxurious things?
What do the positive and negative (+/-) transmit and receive pins mean on Ethernet cables?
Why does the frost depth increase when the surface temperature warms up?
How do I prevent inappropriate ads from appearing in my game?
Capacitor electron flow
Trouble reading roman numeral notation with flats
Class structure for an Octree [closed]
A parent class needs to know his child classesOctree raycasting/raytracing - best ray/leaf intersection without recursionHow to find adjacent / neighbor cubes using octree datastructure?Generalized (non-slicing) pointer to templated tree nodes? (C++)C++ Branching recursive struct?Minimizing overhead for large trees in javaDoes an object of a subclass also allocate an object of the parent class?Dual Contouring: Refactoring a complex head-recursion octree dual traversal algorithm to be iterativeStoring data in an octree nodeHow to store data in an octree
Edit: (Question has been reworded)
Background:
I am using an octree to store terrain data as part of an algorithm called Dual Contouring (https://www.cse.wustl.edu/~taoju/research/dualContour.pdf). The purpose of the algorithm is to store voxel surface data in the leaf nodes of an octree, create the dual graph of that data using a Quadratic Error/Least Squares Function and to then construct a mesh from it. The author's suggest using three types of nodes:
All three types of nodes store the depth of the node in the octree.
Interior nodes store 8 pointers to the children (32 bytes), a QEF (68 bytes), and the signs at the corners of the cube (8 bytes). The QEF of an internal node stores the aggregate QEF for all of the node’s children.
Homogeneous nodes are leaves in the octree that are either completely empty or completely full and have been collapsed maximally. These nodes only store a single number (1 byte) representing the sign at all eight corners of the node.
Heterogeneous nodes are leaves of the octree that contain a sign change and, therefore, a portion of the surface being generated. These leaves store the signs at the corners of the cube (8 bytes), the QEF (68 bytes), and twelve pointers to the hermite data on the edges (48 bytes). The edge pointers are all set to NULL unless there is a sign change on that edge, in which case the hermite data (16 bytes) populates that pointer.
Additionally all leaf nodes will store an index into the vertex buffer.
Problem:
I don't want to dump every possible property and method in a base Octree class, as I want to keep the memory footprint of nodes small. However, I need to perform recursive functions on the octree. These functions take an Octree object but internally need to know specifics about the node they are dealing with.
Approaches I have tried:
1) Have an abstract Octree class which represents a node. Create three subclasses, one for each of the three types of node.
2) Have an Octree class which includes a NodeData object (to hold the specialised data). Make NodeData abstract and subclass it for each of the three types of node data that I need.
3) Have an Octree class and use a struct with fields for all the specialised node data.
4) Have an Octree class and use an interface to implement the collective functionality of the three node types.
5) Downcasting/instanceOf.
The question:
What design would work for these requirements?
c# octree
asked Mar 7 at 20:33
MasterReDWinDMasterReDWinD
44
closed as primarily opinion-based by LarsTech, dbc, Michał Ziober, aaaaaa123456789, Billal Begueradj Mar 8 at 6:09
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
|
show 4 more comments
Edit: (Question has been reworded)
Background:
I am using an octree to store terrain data as part of an algorithm called Dual Contouring (https://www.cse.wustl.edu/~taoju/research/dualContour.pdf). The purpose of the algorithm is to store voxel surface data in the leaf nodes of an octree, create the dual graph of that data using a Quadratic Error/Least Squares Function and to then construct a mesh from it. The author's suggest using three types of nodes:
All three types of nodes store the depth of the node in the octree.
Interior nodes store 8 pointers to the children (32 bytes), a QEF (68 bytes), and the signs at the corners of the cube (8 bytes). The QEF of an internal node stores the aggregate QEF for all of the node’s children.
Homogeneous nodes are leaves in the octree that are either completely empty or completely full and have been collapsed maximally. These nodes only store a single number (1 byte) representing the sign at all eight corners of the node.
Heterogeneous nodes are leaves of the octree that contain a sign change and, therefore, a portion of the surface being generated. These leaves store the signs at the corners of the cube (8 bytes), the QEF (68 bytes), and twelve pointers to the hermite data on the edges (48 bytes). The edge pointers are all set to NULL unless there is a sign change on that edge, in which case the hermite data (16 bytes) populates that pointer.
Additionally all leaf nodes will store an index into the vertex buffer.
Problem:
I don't want to dump every possible property and method in a base Octree class, as I want to keep the memory footprint of nodes small. However, I need to perform recursive functions on the octree. These functions take an Octree object but internally need to know specifics about the node they are dealing with.
Approaches I have tried:
1) Have an abstract Octree class which represents a node. Create three subclasses, one for each of the three types of node.
2) Have an Octree class which includes a NodeData object (to hold the specialised data). Make NodeData abstract and subclass it for each of the three types of node data that I need.
3) Have an Octree class and use a struct with fields for all the specialised node data.
4) Have an Octree class and use an interface to implement the collective functionality of the three node types.
5) Downcasting/instanceOf.
The question:
What design would work for these requirements?
c# octree
asked Mar 7 at 20:33
MasterReDWinDMasterReDWinD
44
closed as primarily opinion-based by LarsTech, dbc, Michał Ziober, aaaaaa123456789, Billal Begueradj Mar 8 at 6:09
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
1
First you say you have some common members such as position and size and later you claim that you don't have anything useful you can put in a base class - that sounds contradictory
– UnholySheep
Mar 7 at 20:38
1
Design it exactly the way basically all other data structures are designed, i.e.List<T>,Hashset<T>,SortedSet<T>, and all the others. The code that handles the data structure itself doesn't need to know anything about the objects within it.
– Servy
Mar 7 at 21:30
@UnholySheep I see what you're saying. Do you think that the common members from the Octree class should be moved to the NodeData base class instead?
– MasterReDWinD
Mar 7 at 21:44
@Servy I understand that a generic approach would let me create an octree for each different type of node independently, but how would I apply this to an octree that is composed of a mix of different node types?
– MasterReDWinD
Mar 7 at 22:13
1
I think something that is confusing about this question is that we do not understand the relationship between the data in the node and its position in the octree. The reason that we can makeList<T>extremely generic is because it's not like there is one kind ofTat index zero and another kind ofTat index 1 and yet another at index 2, but it sounds like you want to have different node behaviours based not just on the contents of the node, but where in the octree they appear: at the root, or the interior, or the leaves.
– Eric Lippert
Mar 7 at 23:30
|
show 4 more comments
Edit: (Question has been reworded)
Background:
I am using an octree to store terrain data as part of an algorithm called Dual Contouring (https://www.cse.wustl.edu/~taoju/research/dualContour.pdf). The purpose of the algorithm is to store voxel surface data in the leaf nodes of an octree, create the dual graph of that data using a Quadratic Error/Least Squares Function and to then construct a mesh from it. The author's suggest using three types of nodes:
All three types of nodes store the depth of the node in the octree.
Interior nodes store 8 pointers to the children (32 bytes), a QEF (68 bytes), and the signs at the corners of the cube (8 bytes). The QEF of an internal node stores the aggregate QEF for all of the node’s children.
Homogeneous nodes are leaves in the octree that are either completely empty or completely full and have been collapsed maximally. These nodes only store a single number (1 byte) representing the sign at all eight corners of the node.
Heterogeneous nodes are leaves of the octree that contain a sign change and, therefore, a portion of the surface being generated. These leaves store the signs at the corners of the cube (8 bytes), the QEF (68 bytes), and twelve pointers to the hermite data on the edges (48 bytes). The edge pointers are all set to NULL unless there is a sign change on that edge, in which case the hermite data (16 bytes) populates that pointer.
Additionally all leaf nodes will store an index into the vertex buffer.
Problem:
I don't want to dump every possible property and method in a base Octree class, as I want to keep the memory footprint of nodes small. However, I need to perform recursive functions on the octree. These functions take an Octree object but internally need to know specifics about the node they are dealing with.
Approaches I have tried:
1) Have an abstract Octree class which represents a node. Create three subclasses, one for each of the three types of node.
2) Have an Octree class which includes a NodeData object (to hold the specialised data). Make NodeData abstract and subclass it for each of the three types of node data that I need.
3) Have an Octree class and use a struct with fields for all the specialised node data.
4) Have an Octree class and use an interface to implement the collective functionality of the three node types.
5) Downcasting/instanceOf.
The question:
What design would work for these requirements?
c# octree
asked Mar 7 at 20:33
MasterReDWinDMasterReDWinD
44
Edit: (Question has been reworded)
Background:
I am using an octree to store terrain data as part of an algorithm called Dual Contouring (https://www.cse.wustl.edu/~taoju/research/dualContour.pdf). The purpose of the algorithm is to store voxel surface data in the leaf nodes of an octree, create the dual graph of that data using a Quadratic Error/Least Squares Function and to then construct a mesh from it. The author's suggest using three types of nodes:
All three types of nodes store the depth of the node in the octree.
Interior nodes store 8 pointers to the children (32 bytes), a QEF (68 bytes), and the signs at the corners of the cube (8 bytes). The QEF of an internal node stores the aggregate QEF for all of the node’s children.
Homogeneous nodes are leaves in the octree that are either completely empty or completely full and have been collapsed maximally. These nodes only store a single number (1 byte) representing the sign at all eight corners of the node.
Heterogeneous nodes are leaves of the octree that contain a sign change and, therefore, a portion of the surface being generated. These leaves store the signs at the corners of the cube (8 bytes), the QEF (68 bytes), and twelve pointers to the hermite data on the edges (48 bytes). The edge pointers are all set to NULL unless there is a sign change on that edge, in which case the hermite data (16 bytes) populates that pointer.
Additionally all leaf nodes will store an index into the vertex buffer.
Problem:
I don't want to dump every possible property and method in a base Octree class, as I want to keep the memory footprint of nodes small. However, I need to perform recursive functions on the octree. These functions take an Octree object but internally need to know specifics about the node they are dealing with.
Approaches I have tried:
1) Have an abstract Octree class which represents a node. Create three subclasses, one for each of the three types of node.
2) Have an Octree class which includes a NodeData object (to hold the specialised data). Make NodeData abstract and subclass it for each of the three types of node data that I need.
3) Have an Octree class and use a struct with fields for all the specialised node data.
4) Have an Octree class and use an interface to implement the collective functionality of the three node types.
5) Downcasting/instanceOf.
The question:
What design would work for these requirements?
c# octree
c# octree
asked Mar 7 at 20:33
MasterReDWinDMasterReDWinD
44
asked Mar 7 at 20:33
MasterReDWinDMasterReDWinD
44
edited Mar 14 at 13:32
MasterReDWinD
asked Mar 7 at 20:33
MasterReDWinDMasterReDWinD
44
asked Mar 7 at 20:33
MasterReDWinDMasterReDWinD
44
asked Mar 7 at 20:33
MasterReDWinDMasterReDWinD
44
44
closed as primarily opinion-based by LarsTech, dbc, Michał Ziober, aaaaaa123456789, Billal Begueradj Mar 8 at 6:09
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by LarsTech, dbc, Michał Ziober, aaaaaa123456789, Billal Begueradj Mar 8 at 6:09
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
1
First you say you have some common members such as position and size and later you claim that you don't have anything useful you can put in a base class - that sounds contradictory
– UnholySheep
Mar 7 at 20:38
1
Design it exactly the way basically all other data structures are designed, i.e.List<T>,Hashset<T>,SortedSet<T>, and all the others. The code that handles the data structure itself doesn't need to know anything about the objects within it.
– Servy
Mar 7 at 21:30
@UnholySheep I see what you're saying. Do you think that the common members from the Octree class should be moved to the NodeData base class instead?
– MasterReDWinD
Mar 7 at 21:44
@Servy I understand that a generic approach would let me create an octree for each different type of node independently, but how would I apply this to an octree that is composed of a mix of different node types?
– MasterReDWinD
Mar 7 at 22:13
1
I think something that is confusing about this question is that we do not understand the relationship between the data in the node and its position in the octree. The reason that we can makeList<T>extremely generic is because it's not like there is one kind ofTat index zero and another kind ofTat index 1 and yet another at index 2, but it sounds like you want to have different node behaviours based not just on the contents of the node, but where in the octree they appear: at the root, or the interior, or the leaves.
– Eric Lippert
Mar 7 at 23:30
|
show 4 more comments
1
First you say you have some common members such as position and size and later you claim that you don't have anything useful you can put in a base class - that sounds contradictory
– UnholySheep
Mar 7 at 20:38
1
Design it exactly the way basically all other data structures are designed, i.e.List<T>,Hashset<T>,SortedSet<T>, and all the others. The code that handles the data structure itself doesn't need to know anything about the objects within it.
– Servy
Mar 7 at 21:30
@UnholySheep I see what you're saying. Do you think that the common members from the Octree class should be moved to the NodeData base class instead?
– MasterReDWinD
Mar 7 at 21:44
@Servy I understand that a generic approach would let me create an octree for each different type of node independently, but how would I apply this to an octree that is composed of a mix of different node types?
– MasterReDWinD
Mar 7 at 22:13
1
I think something that is confusing about this question is that we do not understand the relationship between the data in the node and its position in the octree. The reason that we can makeList<T>extremely generic is because it's not like there is one kind ofTat index zero and another kind ofTat index 1 and yet another at index 2, but it sounds like you want to have different node behaviours based not just on the contents of the node, but where in the octree they appear: at the root, or the interior, or the leaves.
– Eric Lippert
Mar 7 at 23:30
1
1
First you say you have some common members such as position and size and later you claim that you don't have anything useful you can put in a base class - that sounds contradictory
– UnholySheep
Mar 7 at 20:38
First you say you have some common members such as position and size and later you claim that you don't have anything useful you can put in a base class - that sounds contradictory
– UnholySheep
Mar 7 at 20:38
1
1
Design it exactly the way basically all other data structures are designed, i.e.
List<T>, Hashset<T>, SortedSet<T>, and all the others. The code that handles the data structure itself doesn't need to know anything about the objects within it.– Servy
Mar 7 at 21:30
Design it exactly the way basically all other data structures are designed, i.e.
List<T>, Hashset<T>, SortedSet<T>, and all the others. The code that handles the data structure itself doesn't need to know anything about the objects within it.– Servy
Mar 7 at 21:30
@UnholySheep I see what you're saying. Do you think that the common members from the Octree class should be moved to the NodeData base class instead?
– MasterReDWinD
Mar 7 at 21:44
@UnholySheep I see what you're saying. Do you think that the common members from the Octree class should be moved to the NodeData base class instead?
– MasterReDWinD
Mar 7 at 21:44
@Servy I understand that a generic approach would let me create an octree for each different type of node independently, but how would I apply this to an octree that is composed of a mix of different node types?
– MasterReDWinD
Mar 7 at 22:13
@Servy I understand that a generic approach would let me create an octree for each different type of node independently, but how would I apply this to an octree that is composed of a mix of different node types?
– MasterReDWinD
Mar 7 at 22:13
1
1
I think something that is confusing about this question is that we do not understand the relationship between the data in the node and its position in the octree. The reason that we can make
List<T> extremely generic is because it's not like there is one kind of T at index zero and another kind of T at index 1 and yet another at index 2, but it sounds like you want to have different node behaviours based not just on the contents of the node, but where in the octree they appear: at the root, or the interior, or the leaves.– Eric Lippert
Mar 7 at 23:30
I think something that is confusing about this question is that we do not understand the relationship between the data in the node and its position in the octree. The reason that we can make
List<T> extremely generic is because it's not like there is one kind of T at index zero and another kind of T at index 1 and yet another at index 2, but it sounds like you want to have different node behaviours based not just on the contents of the node, but where in the octree they appear: at the root, or the interior, or the leaves.– Eric Lippert
Mar 7 at 23:30
|
show 4 more comments
0
active
oldest
votes
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
1
First you say you have some common members such as position and size and later you claim that you don't have anything useful you can put in a base class - that sounds contradictory
– UnholySheep
Mar 7 at 20:38
1
Design it exactly the way basically all other data structures are designed, i.e.
List<T>,Hashset<T>,SortedSet<T>, and all the others. The code that handles the data structure itself doesn't need to know anything about the objects within it.– Servy
Mar 7 at 21:30
@UnholySheep I see what you're saying. Do you think that the common members from the Octree class should be moved to the NodeData base class instead?
– MasterReDWinD
Mar 7 at 21:44
@Servy I understand that a generic approach would let me create an octree for each different type of node independently, but how would I apply this to an octree that is composed of a mix of different node types?
– MasterReDWinD
Mar 7 at 22:13
1
I think something that is confusing about this question is that we do not understand the relationship between the data in the node and its position in the octree. The reason that we can make
List<T>extremely generic is because it's not like there is one kind ofTat index zero and another kind ofTat index 1 and yet another at index 2, but it sounds like you want to have different node behaviours based not just on the contents of the node, but where in the octree they appear: at the root, or the interior, or the leaves.– Eric Lippert
Mar 7 at 23:30