From what I can tell based on the Manual, instancing creates copies of the original instance, but that’s it…they are not objects that can be moved and animated sepparately. Is this correct? If so, very different from any other Engine I’ve used. Real Instancing usually involves creating a whole new object using the same graphic data and attributes of that object class, and you should be able to control that instance apart from all other instances of the same class. Not being able to do that is new to me. Also, I haven’t been able to make an instance even show up.
that sorta sounds like it would do the very opposide of instancing. it’s very purpose is to re-use existing stuff instead of creating new stuff.
what you may refer to is hardware geometry instancing.
as explained here: panda3d.org/blog/?p=44
the “instancing” you’r currently looking at serves pretty much one single purpose: spare the CPU from calculating redundant animations.
if you have multiple actors all performing the same animation syncronously, then you can use instancing to calculate the animation one. and send the resulting geometry to the gpu multiple times.
each single actor can, of course, have individual position,rotation, and scale.
btw “;” are not neccessary in python.no need to add them.
for pasting code please used the [ code] tags , it makes sure indentation is not lost.
your code itself looks quite ok. altho there is no need for the last line. placeholder is already a child of render. (you did render.arrachNewNode)
so it should show up. maybe it’s simply off-screen and you dont see it.
The word “instancing” has a lot of different meanings in different contexts. The context you’re referring to sounds like class instancing, in which you create many instances of a particular class, which then have independent existence and may be assigned different properties.
This is a different use of the word “instancing” than is commonly used in 3-D engines. You can do that kind of thing in Panda, of course; it’s just called copying, or it’s not called anything at all (just re-load the same model file repeatedly for this effect).
The word “instancing” in 3-D engines most frequently refers to hardware instancing, as Thomas references above. This is very different from what you describe. Sometimes, in engines with a heritage such as Panda’s that predates hardware instancing, the word is used to refer to a model appearing in multiple points within a scene graph, which is the sense that Panda uses. This is also, of course, different from what you describe.
Yeah, I know…I just do it for clarity sake. The “;” just means there’s more code on the same line and if you have no other code on that line, you really don’t need it.
I pretty much knew I would have to create more instances of a class for more of the same; that’s why I’ve constructed everthing in a class. I was hoping there was a way to avoid re-loading the same geometry, but I guess not. Oh well.
ahm… at this point i want to point out that a class’s instance is something else than actor instancing which is something else than geometry instancing.
When defining a Class, from within the Class, you create the Actor instance with any other attributes the Class will have. Therefore creating an instance of a defined object class will init any other instances within the Class.
Where I was going with the Topic relates to creating an instance of a defined Class. I’ve used Engines that did not have to create additional Geometry instances to associate with a newly created object instance. Panda’s Manual states that the Engine will create multiple Geometry instances, per object instance created.
If this does not effect the Engine’s performance or greatly raise memory allocated, then it’s no big deal to me. I’m sure the Engine was designed to handle the occasion. (hopefully)
Got one for ya. I could look into it, but might as well ask here (since I’m new to Panda).
If I destroy an instance of an object, will data associated with that instance dump or would I have to dump everything manually?
In other Engines I’ve used, destroying an instance would dump all memory used for it, but I want to be sure on how Panda will handle that so I don’t leave things in memory that shouldn’t be there.
In other words: If I have a monster called Monster1 from Class MyMosters; If I were to unload this instance from render and dump it, would that be enough?
Would the code be
def destroy(self):
self.ignoreAll()
Monser1.destroy(); del Monster1
Just guessing. I saw this nodepath.detachNode() while reading also. Oh, oh! I think it’s removeNode()!
I doubt that any 3D engine would be so terrible inefficient. For example, think about a scene with, say, 100 wooden crates. Every single crate would have to keep a copy of all the data used by it in memory. This is 100 times the mesh and 100 times the texture!
Is it possible that you perhaps didn’t understand how these engines have been working beneath the hood?
Just for the record: In Python (and many other languages, for example Java) you can not destroy an object. Only Pathon itself can destroy an object, and Python decides if and when it destroys the object. The only thing you can do is to drop a reference to an object.
Wether or not data “used” by an object is freed when the objects get destroyed depends on the specific case. If the object “owns” the data then this object should release the data. If not then it better not releases the data, or terrible things happen.
For example David told you about Panda3D’s caching mechanism for loaded geometry. If two nodes use the same geometry, say the nice crate from above, and one node gets removed from the scene graph, then it would be terrible if the other node gets removed too, or even worse, this node tries to render with invalid data (since released).
Therefor most of the data used by the nodes is not owned by the nodes, for example geometry or textures. The nodes just keep a reference to such shared data. And Panda3D does a good job on counting the references. The shared data is released only if no more objects use this data.
Other data, like the transform of a node or it’s render state, is owned by a node, thus thus released when a node gets destroyed.
Thanks, but I actually read that in the manual and already realized the dangers of dumping instances with shared data and was developing in a way to avoid the conflict (every obj owns its own). I was actually asking about the codes involved in deleting, but I found them. I’m currently working on the lacking in lighting with panda. There’s an error in its calculation, but I can get around it.
And yes…there are open source Engines that do not create new geometry for every new instance created. Other data is stored anew like local variables, xy positon, scale, rot, etc. What happens is…those Engines take the one geometry data in memory and apply it to every instance by frame. Obj1 may have Geometry1 Frame1 drawn, while Obj2 has Geometry1 Frame2 drawn. Yes, the data was shared in this case, but only one data set in memory.
This method makes loading in the same geometry over for every instance look redundant. I normally dump data when it is not need by any instance and only load in when needed (usually at the start of a level). “Load on the fly” you may call it.
I made a Casual Commercial title with an Engine source that was constructed in that way. In fact, the only thing I lost was render time, because more instances of an object took longer to Render (common). That’s the reason I decided to dump the old out-dated Engine files and look for an Engine that had speed. So far, Panda is holding up and if it continues to hold up, I will continue to study and work with it.
I’m currently working on the lacking in lighting with panda. There’s an error in its calculation, but I can get around it.