|
|
Post by Kjelle69 on Aug 4, 2004 10:47:04 GMT 1
I've come to understand that the advanced terrain bug (you can't make TreeCollision unless the terrain is very small) is a result of a limitation to the size of memblocks in DBPro.
luckily, a post on Apollo seems to have proposed a solution.
I will be adding a flag to the CreateTreeCollision command, that will build the collision one limb at a time (instead of using the whole object at once). this should allow very complex objects to be used with Newton!
basically, you will call the NDB_NewtonCreateTreeCollision with an extra ",1" at the end to specify the limb method. as long as each limb itself is under 20,000 polys, it should work!
I'll post again when I get it working.
|
|
|
|
Post by Kjelle69 on Aug 5, 2004 17:32:16 GMT 1
wo-hoo! I got it working!! you can now make TreeCollision out of VERY large objects! ;D ;D here`s a screenshot:  |
|
|
|
Post by zircher on Aug 6, 2004 22:02:57 GMT 1
Very nice! I have a certain snake I'd love to test drive over terrain like that. Any idea when a demo will become available?
--
TAZ
|
|
|
|
Post by Kjelle69 on Aug 6, 2004 22:22:16 GMT 1
sure. it's only a slight change to one command, so I'll re-upload the current NDB download with the updated version this weekend (probably on Sunday). I'll post here when it's uploaded.  |
|
|
|
Post by X3N0Wolf on Sept 6, 2004 15:49:20 GMT 1
Hey all OK, got a problem with Newton and Advanced Terrain. I've noticed that the collision object generated doesn't seem to be quite accurate compared to the visible terrain. Specifically, I was rolling some balls down hills to test it out when some of them sank partially into the terrain, then came back up again further down the hill, as if there was a dip in the collision data that wasn't in the terrain mesh. I've also fallen through a hole in the collision mesh where there was perfectly solid terrain. You can download a zip file with the stuff I'm using at www.feralmetal.co.uk/wolfland.zip The location of the hole is around X = 2295, Z = 3850 (player coordinates are displayed upper-left of screen), that's the only one I know of, could be more... I thought about changing the Terrain Split value, but my machine doesn't seem to like it if I set the value to anything other than 8... 16 makes it freak out and reset, 4 just seems to hang the program, or reset the machine. Anyone got any ideas? P.S> I know this isn't strictly to do with the terrain, because it's happened in another program using a .X file as the world geometry, but I thought I'd mention it since you can see the problem in this program quite clearly too. Once I take my finger off a movement button, if I'm moving in a certain direction, I slide in another direction as I slow down. Sometimes it's not really noticeable but sometimes it's entirely obvious. I thought perhaps Newton is decreasing the object speed in each direction by the same rate, which means if one speed is significantly greater than the others, the object will still be moving along that axis alone when the other speeds have been zeroed... again, anyone got any thoughts? Is there a better way to move a player around? Thanks! X3N0 |
|
|
|
Post by zircher on Sept 7, 2004 14:31:13 GMT 1
I've seen that glitch before. Every now and then I'll have my player fall through an .X mesh.
What's really surprising is that with my snake sim I have 20+ models linked together. The resulting drop is not like a hole in the floor, but a massive negative offset. I can not reproduce the bug reliably, but I'll add some diagnostic displays to my program so that when it does happen again, I can offer some harder data.
--
TAZ
[edit for typos]
|
|
|
|
Post by X3N0Wolf on Sept 8, 2004 19:58:08 GMT 1
Cool Zircher thanks. I think the 'hole' in mine is at the same place, I've only noticed it twice and the second time I was deliberately looking for it. When you say a 'massive negative offset', do you mean the ground is a lot lower that it should be, or your objects instantly jump to a lower height, or what? My 'hole' could be where the ground is stupidly lower than it should be, but my Newton world is set with the bottom at global Y 0 and as the camera and guide object get there the program aborts as the guide object is deleted and it no longer has an object to position the camera with  Then again shouldn't 100% black on a heightmap represent a height of 0 if the terrain object is at it's default position? Or is that part of the bug, that it goes way below what it normally should...? |
|
|
|
Post by zircher on Sept 9, 2004 0:46:44 GMT 1
I'm guessing right now it sets the Y height to a massive negative value since I can't even see the level any more. More info when I can get it.
--
TAZ
|
|
|
|
Post by zircher on Sept 11, 2004 7:58:38 GMT 1
Bam! I caught that baby. Doesn't mean I know how to fix it just yet, but when my snake goes down the rabbit hole its XYZ values all change to 1.#QNAN. I don't know if this is a Newton bug, a wrapper glitch, or a problem with DBP.
Any ideas Walaber?
--
TAZ
|
|
|
|
Post by Kjelle69 on Sept 12, 2004 1:26:44 GMT 1
hmmmm, sounds like a Newton bug. when I get back in town I'll add the "un-optimized tree collision" function, so you can test that. if it fixes the problem (the holes), then we know it's a bug in the tree collision optimizer (which has had a few bugs in the past). one known issue is if you pass it a mesh that is completely flat (all on the same plane), it won't generate any collision data. apparently this will be fixed in the future, but it's not a big issue as most meshes have some shape to them. however there could still be some bugs int he optimizer, so I'll try to get an interim release out soon so we can try and find an immediate solution for our compo entries |
|
|
|
Post by zircher on Sept 16, 2004 15:46:31 GMT 1
Just a bump since this might be a make or break feature for my game.
Welcome back, I hope that your trip was safe and productive.
--
TAZ
|
|
|
|
Post by X3N0Wolf on Sept 20, 2004 8:05:42 GMT 1
Hey Walaber welcome back thanks for the info there, hopefully we can nail this sucker dead soon That issue with the totally flat meshes, any idea if it applies to the sub-meshes that Advanced Terrain creates when it splits a Terrain Object? 'Cuz my holes (I'm now thinking there's more than one...) seem to be in areas where the ground looks completely flat, so maybe when Newton's getting a sub-mesh with no height changes it's tripping up on the same bug? |
|
|
|
Post by zircher on Sept 22, 2004 1:49:37 GMT 1
I'm starting to reach a panic state on this bug. Optimized/unoptimized trees don't matter. Impulse or gravity movement does not matter.
Will I be forced to build my terrain out of primitives?
--
TAZ
|
|
|
|
Post by Kjelle69 on Sept 22, 2004 3:26:17 GMT 1
If you can make a simple demo that ALWAYS breaks, at a specific point, EVERY TIME, then I'll send it to the Newton author(s) for checking...
Zircher, from what you've described of your problem, I highly doubt it's caused by the Tree Collision objects. I think it's more likely because you have a very complex object, with limited joints. I had a similar problem when developing Ragdoll Monkey Bowling, with the rope physics... basically when you get a lot of joints you have a very complex system, and it's possible for it to become unstable (I think joints with limits are also more apt to instability)... You might want to try adjusting your mass and gravity values, to see if you can remedy the problem. unfortunately, I have yet to see your demo actually "freak out", so I can't give a more educated guess on the cause...
Again, anyone experiencing problems, please let me know... most problems I've seen before in my own tests, and a lot of them are user errors...
|
|
|
|
Post by zircher on Sept 22, 2004 3:32:34 GMT 1
Aye, it's aggravating that I can't make this bug roll over on demand and die for you. I know it would help. I'm going to add some more debugging options and see if I can trap this thing at the moment of chaos.
I still have time, I might build a level using primitives and see if that has the same bug as the terrain mesh.
--
TAZ
|
|
Then again shouldn't 100% black on a heightmap represent a height of 0 if the terrain object is at it's default position? Or is that part of the bug, that it goes way below what it normally should...?