Python - Add Objects Without Going to Scene List

Hey. So I was wondering what people thought about an ability to add objects via Python but not place them into the scene’s object list. What makes me ask this is that I’m doing work with voxels right now, and I’d rather not have a scene object list full of voxels and associated objects. So, I was wondering if there could be another function or argument added to the addObject function that would allow you to add objects but not place them into the scene’s object list. You would have to keep up with the object in this case, getting the object via the returned value and putting it into a list or organization of your own.

What does everyone think? How easy would it be to implement, and would it speed up the scenegraph / adding objects to the scene (I’m doubtful, but it’s a question)?

That’s all very well, but how would you maintain a reference to them?
From what i gather the addObject returns a GameObject reference, and i presume that this is relevant to the scene object list.
I personally agree with you’re idea, but i would not feel comfortable having objects that are not accessible!

Sorry, but I simply cannot resist the Offtopicness…

Voxels? In the Game Engine??
It is Possible? And what are the Possibilities?

Either I misunderstood something or my Day may be made! : D

Well, i beleive SolarLune is experimenting with physical voxels - 3D GameObjects, but he’s trying to avoid the clutter of a massive object list, though it may be that he is trying to extrapolate mesh data from physical gameObjects and draw them using post draw, but i doubt it.

@AGoose77 - Well, I would just stick the references in other places. Voxels aren’t very fast in the BGE, even after speed upgrades, but a simple game could theoretically be made. The main problem would be in drawing them all, rather than placing them. Here’s what I’ve got working so far:

I use ‘Voxel’ custom class objects in Python to manage the voxel objects in the BGE itself. Each class object has some properties like its neighbors (can be one on each side), as well as faces (again, can be one face on each side). The way it works is that this voxel object class creates actual Game Object in-game empties that are the real ‘voxels’, and these empties have six faces (cube sides) parented to them. The BGE adds the faces in when the empties are added in, and each face is named correctly (‘left’, ‘right’, ‘front’, etc).

Currently, I store the voxel class objects in a module list in bge.logic, so I don’t need to have the voxel empty objects and the faces all in the scene objects list - they’re not really ‘scene’ objects, you know? EDIT: They just sit there until I’m ready to deal with them, if at all.

And no, I’m not trying to draw them with post-draw, though that might be the better method…

@C.A. - Voxels are just cubes, so you can do them in the BGE, though it will be slower than a dedicated voxel engine. Still, it’s good enough for a simple proof of progress… I think.

EDIT: Here’s a quick look at performance:

Each Voxel is 1 BU
Camera is zoomed out and draw distance is set to view every Voxel spawned
Map size is 48x48x1

Number of voxel objects = 48x48x1 = 2304


Here are the stats.


Load time: A few seconds
Face Count: 13824
FPS - 14 FPS

After optimizing drawing by deleting interior faces in-game (which is why the faces are separate from the voxel):

Load time: ~12 seconds (extra time is deleting unnecessary faces)
Face Count: 4800
FPS - 41-42 FPS

EDIT: By the way, RAM is at ~112,000. Not bad when you consider the RAM is usually at 72,000 without spawning any Voxels in-game.

EDIT 2: And I just got through writing a class in my BGHelper module to enable getting ranges that adhere to a rule of a certain amount at a time - what I mean is that rather than looping through those 2304 voxels in-game, I would just loop through, say, 100 a game frame. This would mean that loading time would be drastically reduced, as the game could add voxels and delete unnecessary faces while drawing the game (something akin to streaming).

So, that’s pretty good. It’s unlikely you’ll need to see as many voxels as I had on-screen at a time (48x48 is pretty large, but MineCraft, for example, is a far larger game. However, those cubes are quite big to be voxels), so it’s definitely something to think about. The main slow-down with spawning objects is in creating the voxels themselves using the sce.addObject() function. Perhaps not placing them into the scene list would be quicker?

EDIT 3: AGoose’s method of drawing them via post_draw might be a good idea. There’s no way to know where they would be, depth-wise, though, utilizing the scene’s post_draw variable… I wonder, if there was a method to draw objects yourself using some sort of gl_draw variable, like the scene’s post_draw variable, would it render faster than usual?

So, would a developer know if there would be any speed increase for adding objects outside of a scene list? As far as I can tell, the main slow-down comes from adding (and deleting) objects in the spawning process. Would keeping them outside of this scene list be faster?

AFAIK scene.objects is there for our benefit, I don’t think you’ll find any optimization to not adding objects to it, and I don’t see any reason why you would want objects not to be included in it.

If addobject is slowing you down maybe try:

adding the objects in the beginning, and keeping them at some location well outside the view range. Manage them and move them to the correct positions rather than adding and deleting them.

Queuing the amount of added objects per frame.

Use an octree to manage the voxel array. Congruent areas can be displayed as scaled up cubes, helping to keep the overall amount of objects down. I’m pretty sure that’s what is going on inside of those minecraft type games.

http://code.google.com/p/projectstarfield/source/browse/trunk/starfield/Octree.py