So after generating the terrain model from the heightmap, all I have to do is pass it to those functions and I’ll have a collision solid that’ll prevent my world objects from falling through the ground?
Since most of my project is just procedurally generated boxes, would it be better to switch from panda’s collision handling system, as it requires a “from”-usually a sphere- object and an "into object, to ODE, where collisions can be tested against two boxes?
I ask this because I am yet to fully explore ODE, I hope to do it soon, but it will not be worth it if I cannot do those two things, better to stick with panda’s collision system in that case. I also cannot use bullet, since I have decided to finish this project using v1.7.2. [sound doesn’t work for me with v1.8.1 and v1.9.0 renders all the geometry as dark silhouettes in my computer].
You could collide with visible geometry, but it’s not very fast. There is currently no mechanism in Panda’s built-in collision system to collide with a heightfield.
However, for simple uses, like checking whether the player is above ground, and where to place an object, it is much easier and quicker to use terrain.getElevation() to determine the Z at a given X, Y position.
This actually covers most cases where collision with terrain is needed, since you can prevent objects from falling through the ground by checking that their z value isn’t lower than the terrain Z at that position, and you can derive information about which way objects should face using getNormal().
Hmm, true, we do not implement box-to-box collisions. If you feel you cannot adequately model your geometry with spheres and polygons (in many cases, a sphere is just a fine approximation for a box shape), you may indeed need to use Bullet or ODE as a collision system.
I’d really like more information about the issues you are describing with 1.8.1 and 1.9.0. Perhaps we can look into a workaround or fix, since 1.7 is no longer supported. What kind of graphics card do you have? Which driver? Which operating system?
Have you tried a development build of 1.10 to see if the issues also occur there?
Hi rdb, sorry it took a while for me to see this reply [I’ve been super busy].
That is exactly what I’m doing [using .getElevation()], it’s working fine except: when I animate my procedural geometry, for instance, changing it’s heading periodically, and it happens to be along a slope, then obviously, it will appear to “go through” the slope as it rotates [I haven’t tried getNormal() yet, so coming up with something to do with it may fix this]. It would seem that this will do the trick:
Right? Won’t that generate appropriate collision geometry from the terrain’s mesh? I’m soon finishing up some things and will be able to explore ODE fully this weekend, but won’t that do it?
Regarding the specs on both my computers, for my older computer:
System:
OS- Windows xp professional 32-bit (5.1, build 2600)
system model: dell optiplex 360
Processor: Pentium (R) Dual-Core CPU E5300 @ 2.60 GHz (2 cpus)
Memory: 1024 MB RAM
Directx version: 9.0c (4.09.0000.0904)
Display:
Intel(R) G33/G31 Express Chipset Family
Chip Type: Intel(R) GMA 3100
Total Memory: 384 MB
AGP Texture Acceleration: none
Drivers:
Main Driver: igxprd32.dll
Version: 6.14.0010.4957
Mini VDD: igxpmp32.sys
DDI version: 9(or higher)
For my newer computer:
System:
OS- Windows 8.1 Pro 64-bit(6.3 build 9600)
System model: HP 2000 Notebook PC
Processor: AMD E-350 Processor (2 CPUs), ~1.60 GHz
Memory: 3072MB RAM
DirectX version: DirectX 11
Display:
AMD Radeon HD 6310 Graphics
Chip Type: AMD Radeon HD 6310 Graphics (0x9802)
Memory: 1526MB
AGP Texture Acceleration: enabled
Drivers:
Main Driver: aticfx64.dll,aticfx64.dll,aticfx64.dll,a
Version: 13.251.9001.1001
Feature Levels: 11.0,10.1,10.0,9.3,9.2,9.1
Driver Model: WDDM 1.2
As for the collisions, I really cannot change the shape of the collision solids, what I presently do is: use collision polygons as “INTO” objects, and then wrap a sphere around the generated geometry for “FROM” objects. So a procedurally generated object has two collision solids: a cubic one for “INTO” and a spherical one for “FROM”; I use bitmasks to control which of those collision solids should be on at a certain time. [ODE does support box-box collisions right? Also, there are no “FROM”/“INTO” objects: all collision geometry collides with all other collision geometry, from my gleanings on this section of the manual, it appears to be the case. If so, that is very ideal for this particular project].
For both the newer and older computers, the sound issue occurs with v1.8.1. However there are no sound issues with v1.9.0 on either computer. By sound issues for v1.8.1 I mean: there is no sound at all that can be played, even default sounds for buttons for instance. Also, at times the crash that was documented regarding it occurs, but this happens infrequently. As for v1.9.0 as I said, on my older machine, everything is rendered as a dark silhouette, with or without light [however, when there is light, the silhouettes look like flat-shaded meshes]. There are no sound issues with v1.9.0 on either machine. Because I’m planning a commercial release once I’m done, I’d rather stick with 1.7.2 as it is the only one which works flawlessly in both machines, and I’d like the game to hopefully be played on computers that are as old as my old one. I have not yet tried 1.10 [but I may, though I’m kinda shifty playing with a build-release…]
To be more precise, this is the particular sound issue that causes the occasional crash with v1.8.1:
AL lib: MMDevApiOpenPlayback: Device init failed: 0x80004005
:audio(error): OpenALAudioManager: alcOpenDevice(NULL): ALC couldn't open device
:audio(error): OpenALAudioManager: No open device or context
But I know you’re already aware of this; when the crash doesn’t happen, no sound plays with v1.8.1 as I said before.
Yes, that sounds like that would be the right way to generate collision against visible geometry in ODE, but not in Panda’s built-in collision system. Yes, I believe ODE supports box-box collisions.
Is the sound issue the only problem with Panda 1.8.1? I suppose in theory we could make a 1.8.2 release, but it would take a significant amount of effort (that might best be spent on bug fixing the 1.9 branch instead) so I’d only do it if there is significant clamour for it.
Hmm, I don’t think I’m going to be able to get my hands on a G31 for testing the black silhouette issue. I know there were some graphics issues in 1.9.0 that were since resolved, so perhaps when the 1.9.1 release is out I’ll ask you to try again.
Yes, for me the sound is presently the only problem with 1.8.1 on both the older and newer machines. It doesn’t work at all on either of them, so if I’d opt to use 1.8.1 then I’d have to use some other sound library.
Good grief the graphics card on my old computer is that old huh? Alright when 1.9.1 comes out then I’ll be happy to give it a go on my apparently ancient machine.