Background:
So I am currently making a little game that uses a Minecraft-esque (voxel) system to generate terrain. It runs using a compressed matrix that tracks where all of the pieces of the map are. (simplified explanation) So each cell says if a building, road, river, or ground is at that point, along with the z position. This gives me amazing control over terrain and allows me to generate random terrain with code.
Question:
So with large towering mountains I find myself having to render objects that lay behind the mountain where the player can obviously not see, so I am trying to write code that makes all the objects that can’t be seen invisible using obj.visible = False . I have done test and it does reduce the rasterizing calculations dramatically. I am having trouble with figuring out what is seen by the player and what is not seen. I was thinking of using a ray trace, but the amount of ray traces I would have to do would be outrageous and slow the game down. I have also been trying to utilize my point cloud matrix (which is what the world is spawned on) to ray trace per object in a simpler matrix (as opposed to using the blender engine), little success there too. So I am wondering if there is something I missed where the engine can detect which objects are “hit” by a light. I could put a light where the camera is, make it invisible to the player, and whatever it hits I would tell to be visible, and anything not hit would be invisible. That would be the ideal situation, but I have no idea if that can even be done in the engine. I know the engine already “skips” over rendering the objects behind the camera, but that only goes so far.
I would really like to utilize my point cloud matrix to do the calculations because it would be faster to calculate scanning a matrix than it would be scanning in the the engine. So if you can think there is a way to do it like that, that would also be useful.
If you would like me to go into further detail on something just ask and I will do my best to clear it up.
Okay, I have looked into occlusion but it doesn’t seem to increase frame-rate, also I get this flashing of objects as I move the camera which I know is from it determining those things unseen. I am going to keep playing with it though. I will update in about an hour.
Edit: Still having flashing problem but I think this is definitely the right path to go down so I will keep at it.
There’s no way to tell if an object is being lit or not. You would have to program that kind of functionality in yourself.
It might be best to go for a cruder approach:
Each section of the world would get its own node object, and you can use ray casts from your position to the nodes to see if you can ‘see’ that section of the world. Parent the voxels in that section to the node when they’re created, and if you can’t see the node, you can just use
obj.setVisible(0, 1)
on the node to turn it invisible as well as all blocks parented to it. That might be faster than performing occlusion testing on each block.
Collision with a vision cone? have the cone go past the clip?
so things load before they are visible?
vision Collision--------and---------Visible -rasteriser
anti cone Collision------and--------Occlude - eraser
and some how only have it run during collisions on each object/vertex?
@SolarLune, I might just end up doing that if I cannot find a more elegant solution. The thing I don’t like about that is it would still end up rendering “excess” objects. Though it might be the best option.
EDIT: Never mind. @drfrev - Yeah, you would end up rendering extra objects that way, but I’m not sure how helpful occlusion culling can be since (I’d assume) it steps through each object to add it as an ‘occlusion mesh’ and checks it for blocking rendering with the BGE.
Hey BluePrint, it’d be great if you edited your posts; I haven’t seen any edits on any of your posts. It would condense five of your posts into one. You’re treating the forum like a chat, it’s not a chat. Every time I see an update on the post count for this thread I assume there are new contributions to solving the problem, but it’s just you posting updates on the same idea you could have just edited into an earlier post.
So please… Edit your posts.
In the first image you can see a small wall behind a bigger wall. The green arrow is the player. In occlusion no matter how close you get to the small wall, if you can’t see it, it won’t render. In the second image the same principle is added to a mountain, with the red blocks being invisible and the blue being visible. Your method doesn’t work as occlusion because it will render the blocks behind other blocks. You can see this by taking the three test cubes you have and making a 3x3 cube out of them. If you get the character close to the 3x3 the center cube will become visible, even-though it is not rendered on screen.
I am going to sleep on this. I believe I am on to a algorithm that would allow me to use my point cloud to tell if a item is visible. I will post the answer if I can sort it out.
@BluePrintRandom - Linkxgl is by no means trolling. He’s simply commenting on your posting method, and doing so in a respectful and nice way. It’s no big deal - please just try to compress your posts together. If you’re the last person to have commented on a thread and it was a fairly short time ago (i.e. less than a day), it would probably be a good idea to edit it and add the information you want, rather than add a whole new post.
About your blend file, it’s effective, but I don’t think it would be fast enough for what drfrev wants to do with his voxel-ish technique. I think a collision sensor mechanic would be slower than his current setup, especially since each block needs to check to see if it’s colliding with the collision mesh.
@drfrev - I’m not sure about your point cloud method, since I’ve never used point clouds in Python, but I would imagine that if you have a three dimensional array, you could check the blocks beyond the one closest to the player in a certain direction (i.e. the ones behind the one straight ahead). That’s pretty simple, though, so your method’s probably more fitting for what you need.
this will not help, for anything under a certain level of complexity, as it would take as much cpu to do the collision I assume, I may be wrong 
