I am working on a terrain map in Blender that uses a Mesh Plane as the terrain/ground. Collisions are handled using a CollisionRay and that keeps the avatar positioned on the ground. This works.
I created a canyon in my terrain, and constructed a bridge using a Mesh Cube. I export the whole thing as an EGG file. When I load the terrain model, and try to walk my avatar across the bridge, the avatar falls through the bridge.
Is any anything special that needs to be done for bridges/rocks/any other type of object created as part of the terrain file? It appears that the only thing being recognized as a solid object is the terrain/plane itself.
I do have the { Polyset keep descend } statement in my model file. The bridge cube object has its own statement in the EGG file, but even is I place the tag there as well it doesn’t solve the issue.
Do I need to modify collision handling to work differently for objects included as part of the terrain? I assumed that the bridge, being imported with the terrain map, would simply be treated as part of the “ground”.
I think you need to sort the collisions, one closer to the player is used instead of something below it. That is if you got every thing colliding properly enable show collisions to see if that is true.
I believe I am sorting the collision entries. Here is the code snippet I’m using. Please let me know if you’d do this differently or if you see an issue:
if ( self.collQueue.getNumEntries() != 0 ):
self.collQueue.sortEntries()
for i in range( self.collQueue.getNumEntries() ):
entry = self.collQueue.getEntry(i)
print entry
point = entry.getSurfacePoint( self.terrain )
self.playerVirtualNode.setZ( point.getZ() )
print self.playerVirtualNode.getZ()
I have show collisions enabled, and I see the bridge object turn yellow when the avatar collides with it. I also see the entries in the collision queue. However, because I’ve already “fallen” through the bridge object (and have a negative Z position such as -2.345) the collision event returns a collision intersect with a negative Z value (such as -2.345), and the above code places the avatar at that location which is in/under the bridge object. Once that happens, no more floor and the avatar falls to the ground below the bridge.
[/code]
As a quick follow-up, I was just playing a bit with the bridge object which is a Blender Mesh Cube. I noticed that the collision always occurs in the center of the objects Z scale. for instance, my bridge has a Z “thickness” of 5, and the collisions always occur at 2.5. If I resize the bridge object to a Z of 3, the collisions always occur at 1.5.
Assuming this is normal, it throws a monkey wrench in my bridge object idea. Is there a way to set collisions to occur at the top of the object and not the center? I thought the CollisionRay intersected with the top-most area of an object, not the middle?
Because you loop through all detected collisions here:
for i in range( self.collQueue.getNumEntries() )
And, for each one, you reset the player’s Z value here:
self.playerVirtualNode.setZ( point.getZ() )
Doesn’t it follow that, at the end of the loop, your player will have the Z value associated with the last detected collision of the loop? And since you have sorted the entries, which puts them in order from nearest to furthest, it means you will always set your Z value to the bottommost object, not the topmost.
As to this:
I don’t understand what that could be about. The collision is detected with the surface, not with the interior. This is especially true if your bridge is made out of polygons, in which case there is not even an interior to talk about. Perhaps it is a coordinate-system confusion. If you are getting the surface point in a different coordinate system than the one you are interpreting it in, you can end up with weird misunderstandings like this. I see that you appear to be asking for the surface point in the coordinate system of the terrain. This means that the returned point will inherit any scales and translations on the terrain, so if the terrain is scaled or offset from render, so will be this point.
Thanks very much. I was looking at that iteration issue and not seeing it the whole time. You are completely correct. The bridge overlapped the terrain so that, as the terrain fell off in to the canyon, the avatar would be on the bridge. There were two collisions at that point–one for the bridge (closest) and one for the terrain. The iteration would set the Z to the bridge and then to the terrain, and the avatar would pass right through the bridge.
I load my models and set the scale to (1, 1, 1) which appears to be the same as not scaling them at all. For whatever reason, the collision entry always contains a Z entry that is in the middle of my bridge object. At this point, I worked around it in my code. I’m sure it is something I’m doing wrong, I just haven’t found what that is yet.
Thanks again for your help. The Panda community is really helping me get through my learning curve, and I appreciate it.
how you make collision ray work with the terrain? i exported my terrain from blender with chicken 1.0 but it didnt work… i searched a bit for this error and found something about collision meshes… how u did that in blender?
Make sure you have the following in your EGG file (you will have to manually insert it via text editor):
{ Polyset keep descend }
I also had an issue where my collision ray would “disappear” or stop working as I moved to the edges of my terrain. I found that using flattenlight() on the terrain node resolved that.
Let me know if either of those help. If not, post your collision code and I’ll compare it to mine.
Instead, first decide on whether you want to re-use your terrain mesh as your collision mesh, or create separate collision geometry; the former might be better in the case of a terrain, although I stand for correction on that.
Presuming the former, I think that the following should work (note that I haven’t tested this myself; I’m extrapolating from it working for normal collision geometry):
With your terrain mesh selected, in the Buttons Window go to the Logic Panel (you should be able to reach it via the “Panels” menu, the buttons to the right of that, or by pressing F4) and click on the “Add Property” button twice to add two properties, and set both of them to be String properties.
Name the first “ObjectType” and the second “Collide” (without the inverted commas, and noting the lack of an intervening space between the words in the former case).
In the text field to the right of the first, enter “barrier”, and in the text field to the right of the second enter “Polyset keep descend” (again without inverted commas).
This should, I think, result in the appropriate tags being placed in your egg file when you next export via Chicken - again, however, I stand for correction.
As to the version, I also use the R44 version, although it’s possible that it has issues that I’m not aware of.
thanks a lot!! sorry for the delay in the response… i’ve been busy…
i did Thaumaturge way and worked well but the model is not drawn… i have to export other egg without this options?
I dont use Chicken R44 because it doesnt work with my blender… i have blender 2.46 and when i start chicken gui this error message is shown on the console:
You must specify the egg file(s) to read on the command line.
Usage:
egg2bam [opts] input.egg output.bam
egg2bam [opts] -o output.bam input.egg
Traceback (most recent call last):
File "<string>", line 1279, in <module>
AttributeError: no such file or Blender text
You say that the object doesn’t appear - did you give it both of the properties that I mentioned (both ObjectType - barrier and Collide - Polyset keep descend)? If so, you might want to check your outputted egg file to be confident that the “Collide” tag is being placed properly. You may find that you’ll end up stuck with editing the egg file yourself (although it may be that if this is an issue, it’s one that is fixed in R44).
As to the error, aah yes, I remember that, I believe - I think that that was the glitch that I experienced (I was using 2.46 myself, as I recall, although I recently downloaded 2.47) - as I recall it’s just a matter of hacking around the problem in the .py file (I think that you’ll find that it’s a matter of having it pick up another exception type - presumably AttributeError - although I’m not sure that that was indeed the case for that error).
I seem to recall that I had a similar sort of issue with 1.0, so I prefer to use R44 - I think that it’s also the more recent version.
