Ugh, apologies for the great wall of text.
Okay, you seems to know you stuff and are just unfamiliar with this game engine.
Don’t give me too much credit. 
Honestly, seeing the level of your effort was very discouraging for me; I feel pretty outclassed.
Physics can be updated, but it is a hasle. I think it was something along the lines " edit the hidden layer object and then addObject/replacemesh_with that"
Makes sense.
If it matters, my geometry for physics and the graphical representation are one in the same. I don’t have a separate simplified collision mesh, as the graphical mesh is very modest.
Also note that my game is 2.5D. All the physics objects are constrained to the same ZY plane (soon to be XY plane for other reasons). So far this has simplified many things, and promises to keep good performance. The background mesh doesn’t even have physics applied for example.
If you need your map to be fully random, you would have to build it in game first which takes time.You could also premake your map and keep a dictionary file of the fake objects initially present.
My terrain is actually prebaked from a height map + displacement modifier on a highly subdivided plane. I also have a low-polly version with a baked normal map. The latter kinda looks like crap; I’m planing on reworking it. Pretty conventional stuff though.
This terrain is totally static, and only determines aesthetics, major paths, and major obstacles for the game. The physics layer is just in front of this, and is effectively two dimensional.
My map making process is simple enough that I’m sure it could be easily automated. Doing it in just BGE, placing enemies/assets, and placing a matching low poly physics layer are problems though.
As for dictionary files, I have yet to play with them. I’ve been putting it off to focus on other aspects. Though I definitely need to figure it out soon as I want some game save and inventory functionality, of course.
I’ll listen to recommendations regarding this. It’s probably the very next thing I’m going to do.
You probably could smooth the terrain as said with slope blocks or, more fancy marching cube algo.
Speaking of marching cube algo, I’m actually thinking that, if I went the voxel route, the marching square algo would be sufficient for my game.
The only environment the player object can interact with is confined to one plane. If the collision mesh for the plane were made voxel like, there would never be a change in the data above and below a certain depth, as nothing the player does would ever reach. Knowing this, the collision mesh reduces to 2D, so the marching square algo would apply.
This would make for a more simple implementation, and higher performance… I might play with this.
Good luck
Thanks, you to.
The donor mesh idea looks pretty good, but how would you handle making each one unique in cases where large numbers of them are needed,
If you check out one of VJ’s demos in post #14, there are a whole bunch of identical planes on the visible layer. Looks like thousands and thousands. Also looks like VJ is culling a lot that’s not being seen, greatly reducing the number of donors he needs at one time.
[W]hat about smooth shading and changing UV’s, different textures, conversion to a new physics object?
Indeed. These are difficult problems that arise doing this, and big concerns for me as well.
To be fair, I don’t think my idea (or any other for that matter) is in any batter standing.
Truth be told, the BGE may have (by a decent margin) the weakest API of any free or low cost engine that is out there in terms of direct mesh manipulation and the creation of entirely new data (bpy doesn’t count as it will not work in executables). You have to really hack things together to get something that even resembles true, procedural, creation.
I’m starting to see this, and it’s really unfortunate. The wave of the future for video games is dynamic “sand box” environments. IMHO that is the thing that really sold Mincraft, not it’s “goofy but endearing blockyness” like a lot of people believe. It’s the fact that you could build/destroy anything that made it an instant hit. I’m not a big fan of Minecraft, but I feel no shame promoting this aspect of the game.
I think BGE suffers greatly by not having tools for this.
The BGE may simply not be the right engine for this, because even if you hack the system together, you still have to find a way to make it run at 60 FPS (and Python’s not the fastest language around).
Agreed for the most part.
That being said, both of VJ’s blends ran on my lesser dev computer at full 60 frames when everything was eventually loaded. That’s on a 3Ghz Phenom II x2 555 BE + 4GB RAM + Radeon HD3800 series card. I presume it to be a pretty decent baseline.
Even so, I’m rapidly coming more inline with the quoted viewpoint as time goes on.
I think a voxel terrain using a marching squares/cubes algo is pretty workable. The mutating donor geometry is also plausible. But I’m also thinking about the work/effort necessary (including talking in this thread) and it’s looking pretty prohibitive.
Just note that; even if I do ultimately give up on having this in my game, it’s still something that BGE should strive to acquire.
That is what is great about the bge.Someone could possible come up with a new solution.I know you are going to say don’t hold my breath.But who knows i might be right.
From what I’ve read, development on BGE has more or less stagnated. There was a lot of talk about making it more an integrated visualizer for game prototyping than an independent engine. There was even scare that it BGE was getting dropped altogether. It turned out to be more about lack of enthusiasm for continued development, and that there are no plans to remove it.
For the record, the inbuilt game engine is my sole interest in blender. If it was gone, I would leave with it. I feel this is probably true for a lot of people.
