Hi everyone,
I feel like this is a common issue… And I’m kind of far from this stage in my game anyway but I just want to have an idea for it for when I get there. I heard that you don’t want the terrain to be its own collision mesh. What else would you use? And why is this a bad thing? Does it have to do with calculation or falling/sliding off slopes or both? And if you have a huge open world is it necessary to make the landscape work with LOD or can you just make the landscape really lowpoly and throw in some LOD trees/grass/etc with nice textures to make it not look bad?
Thanks
for a large open world, you will want seamless tiles, that load in and out, and suspend dynamics/engage dyanmics
oh I see ok thanks. What about the terrain collision is it ok to use the same object for terrain graphics and terrain collision?
Generally, making a lower-poly version of the terrain for physics may not be such a good idea as that could create a misalignment between the collision component and the graphics component. Usually, a separate physics mesh would make more sense for architectural or box-based components where there’s many co-planer faces that you can merge together.
Ok thanks, but what about all the sliding that occurs from the slightest of slopes?
Thanks but I don’t think I know how to do any of that. Would the player still slide down slopes?
Also on another note, if you use the visibility actuator, does it cause less lag by making the object not get rendered, or does it cause more lag?
if the item is no collision. then it will generate no lag while invisible other then adding to the size of scene.objects, (I think)
having the no collision add when near and changed it’s own physics might be a good idea
no collision GFX mesh
state 1 =On
always (level?)---------------and----------Visible
always (level?)-----------------sdd physics object
state 2 = 0ff
always(level)-------------and------------invisible
always(level)----------delete physics object
that had it’s states set by a manager seems like a damn good idea…
about the terrain, do you want them to go up hills?
HA Ha Ha Ha Ha Ha
“Loading Bubble”
uses .03 ms logic when not screencasting HD
Attachments
Eureka.blend (514 KB)
Side note, one could in theory have the “bubble” load in the physics objects, and the sensor could unload and return to “empty state”
with this setup, having 1000 tiles should in theory be the same as having 1 ?
If you don’t know how to code this, then you could learn it. Alternatively you should consider to design you game on the limitation of small area levels.
If you want to have control over that you also need to do some Python coding.
It will make a difference but not as much as you’d probably expect it to. I think it couldn’t hurt to have a triangle with an invisible material for example as a lowest level of detail for Static objects (when using the build-in LOD system).
in loading Bubble
Collision with ‘tile’----python
import bge
cont=bge.logic.getCurrentController()
sens=cont.sensors['Collision']
if sens.positive:
sens.hitObject.state=2 active(I don't know bitmask so a little help?)
sens.hitObject['time']=100
sens.hitObject['Visable']=True
scene=bge.logic.getCurrentScene()
physics=scene.addObject(sens.hitObject['Physics'],sens.hitObject,0)
sens.hitObject['Physics_object']=physics
in tile
if not colliding with bubble remove 1 from time
if time=0 delete physics mesh, set invisible, and return to “empty” off state,
There are various ways to do large worlds.
Breaking the visual mesh in to chunks can help because objects which are not visible to the camera are not rendered. That means all the chunks to the rear of your character won’t be rendered, making more than 50% not contribute to render time. If you have one big mesh all of it will be rendered, even though parts of it are outside the camera’s viewport.
However, having chunks of terrain is good but not needed unless you have a really huge world. I had a world several kilometers in size with just a simple mesh back in Blender 2.49, as long as the mesh is not too high poly it shouldn’t matter.
Just remember to set the origin of each chunk to match its geometry.
On the subject of sliding, if you use dynamic or character physics types for the agents in your world they shouldn’t slide or jam on slopes. If they do you can use the servo type movement actuator to eliminate sliding and jamming completely.
Ok I think I like the chunks idea the most. I’m planning to have a pretty massive world. I guess that’s more or less solved then. Also, I’ve been thinking about having a lot of ai interaction, like if an ai goes to another city or something. Since the player isn’t necessarily going to be around for this, could I basically put it in the ai’s routine to spawn in some other location at some time if the player’s not around, and otherwise if the player is around make him actually walk there?
Edit: So I guess I mean what if something happens in a non-loaded chunk?
have a “physical” copy that is spawned by a empty, if the player loads in the empty, add the physical copy
(the empty/static parents to the physics spawned?)
so move the static (in the air a ways?) and if the player gets near, have the empty/static cast a ray -Z to ground? place the “actor” at the edge of the bubble?
play around with the friction settings (at both objects indeed).
Ray(-z)--------python
Not walking—/
import bge
cont=bge.logcic.getCurrentController
own=cont.owner
own.localLinearVelocity.x*=.95
own.localLinearVelocity.y*=.95
Ok thanks but I feel like I did that at one point and it didn’t work. When I get there I’ll try it. That’s under the material right?
If you want a terrain like in Skyrim or Tom Raider you absolutly need LOD, if you want something like Spyro then you don’t. About the method to make the LOD terrain, the beast aprouch would be to make it inside the blender source code. One of this days, when I’ll finish my build game addon I’ll start working on that. About the LOD in objects, you can make the lowest have no mesh (deleting all the vertices in Edit Mode), in that case no render or physics will be used, so it will be practically as it were unexistent (but the object instance and logic still existent).
By the way, I remember your post about the RPG game, how is that going?
Thanks 
It’s going well! This question is concerning that actually. I’m currently working on getting combat down, then after that I’ll probably be working on some more assets.
I’m not sure it is true what you said about having no physics being used. The Physics mesh will always be the mesh of the original object, regardless of other levels of detail. Note that with LOD only Display mesh and Materials are updated, not the Physics mesh.
Also what purpose would logic be having if the object is not Dynamic and out of view? It wouldn’t be serving much then simulating static translation, which also could be calculated through Python. No need for the object to exist in the scene then.
I was also thinking about how to deal with Dynamic objects going from one point to the other, while not in view. For now I can only think of calculating an approximation of where the object should be under these or that circumstances. If it’s close to what physics would do, then the player won’t notice.