Question about recursive class members
I apologize if this has been asked before but I'm actually really not even sure what keyword to search for that explains the question I have -- gotta love those kinds of questions lol Ok getting to my question:
Just a couple of really quick points:
1) My project is a graphics engine.
2) The export plugin I wrote for studio max exports models without hierarchy, For example if I modeled two cubes and exported it, it would have a listing for 2 meshes (With 1 set of vertices, faces, tverts, tfaces, and normals for each model that was in the scene (or selected) when it exported).
Point 1 was only important for those that might be curious for the usage of 3d terms.
Point 2 is important to establish an understanding (For anyone reading this) of the file layout and internal data management. More on this throughout the content of this post.
Unfortunately I can't explain the problem without digressing a bit into an explanation of the situation of both the code and the general file layout. Basically, I had a single model class, but am expanding it to support multiple submodels. So now I have a core model class and a model class. The classes have a dynamic container object for it's submodels. Basically it boils down to this:
Now the cModel class has no inheritance, I suppose I could make it inherit cCore_Model, but it kind've goes against a standard I've always tried to stick to, which is if needing a container: go with a struct, if needing an advanced struct that will have methods that modify those members go with a class. The cModel class while it will have -some- methods, like attaching to a bone point, etc, more or less it's being treated as a vertex/face data container, and so things like inheritance seem -way- overkill as the purpose just barely reaches class-need I feel and there's a problem with going with inheritance anyhow that I mention below.
Now onto the general file layout. I basically have a main file parser loop that is a do while loop and calls appropriate functions when it hits various chunks. If the loop determines it needs to spawn a submodel it does a:
SubModels = new cModel[NumberOfSubModels]
(I know, I still need to write a "new with preserve" type of function but for now my problem and focus is conceptual.)
The problem is this: In most programs you write down (broad to specific), classes are derived from base classes, classes have members that may be declared as a custom datatype that has elements inside of that. But how would one go "up"? For instance, let's say the model is a box with a hook and on that hook is a chain. The core model might be the box with the hook. The sub models might be the each of the links of the chain with various vertexes tagged with a name, creating an "AttachTo" point, with each of the submodels tagged as being attached to the appropriate vertexes of the other submodels.
Example pseudo-file layout:
CoreModel:
<materials>
*Mesh: (The box with the hooks -- Let's call this CoreMesh)
AttachedTo:
Number of Vertexes: 15
...
Vertex: 11: 11.0000,17.0000,9.0000,HookPoint_1
...
Number of Faces: ...
<faces>
*Mesh: (Chain 1, Link 1 -- Let's just call this Mesh 1)
AttachedTo: HookPoint_1
Number of Vertexes: 40
...
Vertex: 23: 43.0000, 24.0000, 11.000,Chain1_Link1_Point1
...
Number of Faces: ...
<faces>
(Mesh 1, will need to access CoreMesh's vertex list to see where the AttachPoint is)
both meshes are in the same file, however the 2nd mesh listing (Actually any mesh listing after the first) gets stored in a SubModel container (Which doesn't need to maintain any sort of model hierarchy coming from the file since the model files doesn't). I've thought about what possible benefits would be if I just had the exporter create the hierarchy as they are in the scene (Through maybe the use of { and }), but that would actually be limiting. The way I'm looking to go is to be able to allow adding an AttachPoint on the fly, which just tags/names a vertex in the specified model. I'm digressing big time though.
The problem occurs, because I have no way from methods inside of Model class, to access "up", at least that I know of. I thought about making a static variable inside of CoreModel, and passing it to to the submodel upon creation, but:
A) That conflicts with my array of dynamically created submodels since I'd have to create an "instance" function that simply returns the return of "new"'ing the class (Not exactly array friendly).
and B) That would make my engine only support one model since a static would be static across any instance of CoreModel.
Now inheritance seems overkill, as I'm sure I won't need all of the other stuff inside of CoreModel, do I just inherit anyhow? I was thinking of just biting the bullet and inheriting anyhow but I'm not sure inheritance will solve my problem ahoy as the SubModels member would not be the same instance as the one in the CoreModel, hence why I was thinking of using a static, but as I mentioned, there's a problem with using a static.
But in a recursive setting how does one traverse back up the creation stack? I guess my problem is similar to a "tree node problem", you may have many folders and under those many more folders all under let's say Folder_1 how do those sub folders traverse back up and then back down to get information about it's "relatives" for lack of a better word.
Really sorry for such a long post, the problem is kinda difficult to explain, but I tend to be really long winded, at least when it comes to typing, anyhow :/ Thanks in advance!
-- StakFallT
EDIT: I think I might have figured out a way to do it. Basically it looks like this now:
And upon each creation set the proper variable with the this pointer and set the newly created class instance's appropriate class member to the this pointer, maintaining the lifeline back up the chain. Then if I need to find the model's attach point names, just traverse up using the "safety-line" then back down using the dynamic arrays, or if it's too many deep to bother going up like instance->instance->instance->instance, just go straight to the core instance and work down. hmmm I think this seems like a really good plan; it's simple, yet still lends itself to be powerful and flexible. I'm SERIOUSLY glad I didn't just jump right into this and I stopped after realizing it was more complex than I thought, I could've really screwed some code up.
Just a couple of really quick points:
1) My project is a graphics engine.
2) The export plugin I wrote for studio max exports models without hierarchy, For example if I modeled two cubes and exported it, it would have a listing for 2 meshes (With 1 set of vertices, faces, tverts, tfaces, and normals for each model that was in the scene (or selected) when it exported).
Point 1 was only important for those that might be curious for the usage of 3d terms.
Point 2 is important to establish an understanding (For anyone reading this) of the file layout and internal data management. More on this throughout the content of this post.
Unfortunately I can't explain the problem without digressing a bit into an explanation of the situation of both the code and the general file layout. Basically, I had a single model class, but am expanding it to support multiple submodels. So now I have a core model class and a model class. The classes have a dynamic container object for it's submodels. Basically it boils down to this:
|
|
Now the cModel class has no inheritance, I suppose I could make it inherit cCore_Model, but it kind've goes against a standard I've always tried to stick to, which is if needing a container: go with a struct, if needing an advanced struct that will have methods that modify those members go with a class. The cModel class while it will have -some- methods, like attaching to a bone point, etc, more or less it's being treated as a vertex/face data container, and so things like inheritance seem -way- overkill as the purpose just barely reaches class-need I feel and there's a problem with going with inheritance anyhow that I mention below.
Now onto the general file layout. I basically have a main file parser loop that is a do while loop and calls appropriate functions when it hits various chunks. If the loop determines it needs to spawn a submodel it does a:
SubModels = new cModel[NumberOfSubModels]
(I know, I still need to write a "new with preserve" type of function but for now my problem and focus is conceptual.)
The problem is this: In most programs you write down (broad to specific), classes are derived from base classes, classes have members that may be declared as a custom datatype that has elements inside of that. But how would one go "up"? For instance, let's say the model is a box with a hook and on that hook is a chain. The core model might be the box with the hook. The sub models might be the each of the links of the chain with various vertexes tagged with a name, creating an "AttachTo" point, with each of the submodels tagged as being attached to the appropriate vertexes of the other submodels.
Example pseudo-file layout:
CoreModel:
<materials>
*Mesh: (The box with the hooks -- Let's call this CoreMesh)
AttachedTo:
Number of Vertexes: 15
...
Vertex: 11: 11.0000,17.0000,9.0000,HookPoint_1
...
Number of Faces: ...
<faces>
*Mesh: (Chain 1, Link 1 -- Let's just call this Mesh 1)
AttachedTo: HookPoint_1
Number of Vertexes: 40
...
Vertex: 23: 43.0000, 24.0000, 11.000,Chain1_Link1_Point1
...
Number of Faces: ...
<faces>
(Mesh 1, will need to access CoreMesh's vertex list to see where the AttachPoint is)
both meshes are in the same file, however the 2nd mesh listing (Actually any mesh listing after the first) gets stored in a SubModel container (Which doesn't need to maintain any sort of model hierarchy coming from the file since the model files doesn't). I've thought about what possible benefits would be if I just had the exporter create the hierarchy as they are in the scene (Through maybe the use of { and }), but that would actually be limiting. The way I'm looking to go is to be able to allow adding an AttachPoint on the fly, which just tags/names a vertex in the specified model. I'm digressing big time though.
The problem occurs, because I have no way from methods inside of Model class, to access "up", at least that I know of. I thought about making a static variable inside of CoreModel, and passing it to to the submodel upon creation, but:
A) That conflicts with my array of dynamically created submodels since I'd have to create an "instance" function that simply returns the return of "new"'ing the class (Not exactly array friendly).
and B) That would make my engine only support one model since a static would be static across any instance of CoreModel.
Now inheritance seems overkill, as I'm sure I won't need all of the other stuff inside of CoreModel, do I just inherit anyhow? I was thinking of just biting the bullet and inheriting anyhow but I'm not sure inheritance will solve my problem ahoy as the SubModels member would not be the same instance as the one in the CoreModel, hence why I was thinking of using a static, but as I mentioned, there's a problem with using a static.
But in a recursive setting how does one traverse back up the creation stack? I guess my problem is similar to a "tree node problem", you may have many folders and under those many more folders all under let's say Folder_1 how do those sub folders traverse back up and then back down to get information about it's "relatives" for lack of a better word.
Really sorry for such a long post, the problem is kinda difficult to explain, but I tend to be really long winded, at least when it comes to typing, anyhow :/ Thanks in advance!
-- StakFallT
EDIT: I think I might have figured out a way to do it. Basically it looks like this now:
|
|
And upon each creation set the proper variable with the this pointer and set the newly created class instance's appropriate class member to the this pointer, maintaining the lifeline back up the chain. Then if I need to find the model's attach point names, just traverse up using the "safety-line" then back down using the dynamic arrays, or if it's too many deep to bother going up like instance->instance->instance->instance, just go straight to the core instance and work down. hmmm I think this seems like a really good plan; it's simple, yet still lends itself to be powerful and flexible. I'm SERIOUSLY glad I didn't just jump right into this and I stopped after realizing it was more complex than I thought, I could've really screwed some code up.
Last edited on
Ok.
Inheritence is really easy to decide, it comes down to 1 simple question.
Ask youself. "Is CModel a Core_Model, or does CModel have a Core_Model. Is Core_Model a CModel, or does Core_Model have a CModel."
If it IS then it should inherit. If it HAS then it should have it as a member variable.
Your also going to have issues (if you don't already know) with cyclic-depenencies. So best you do a search on C++ forward declaration. This technique will help you solve it :)
Inheritence is really easy to decide, it comes down to 1 simple question.
Ask youself. "Is CModel a Core_Model, or does CModel have a Core_Model. Is Core_Model a CModel, or does Core_Model have a CModel."
If it IS then it should inherit. If it HAS then it should have it as a member variable.
Your also going to have issues (if you don't already know) with cyclic-depenencies. So best you do a search on C++ forward declaration. This technique will help you solve it :)
Topic archived. No new replies allowed.