Falling though a terrain mesh
Blitz3D Forums/Blitz3D Programming/Falling though a terrain mesh
| ||
| I am experiencing a really bad problem falling through the terrain in a large mesh. The terrain is about 130,000x130,000 units, and each segment is 16,000 units wide, and about 1024 polys. This happens when I go up inclines, and it is in the middle of a single terrain mesh, not on the seams between meshes. |
| ||
| I've experienced this with Blitz terrains, my own terrain meshes, etc., I honestly haven't found a way to fix it. I guess you could always switch to using Coldet and write a bit of code for sliding and such. I intend to try that as a small project, since it seems to be fairly simple given you're using elias_t's wrapper. |
| ||
| Wow, at first I thought it was because the terrain was jagged, but I smoothed it out and I am falling through pretty much everything. Has anyone had success using Nuclear Glory with this? This is a terrible problem! |
| ||
| My first thought here is your scale is wrong, and you're at the low FPS your having, the floating point precision is causing problems. Ya might try scaling everythign down. If that's not it, then I'll keep braingstorming. |
| ||
| What does scale have to do with floating point precision? I reverted to my old method of line picking to avoid slope sliding, and I was able to travel even the most jagged terrain. It seems like I only solve problems once I post about them. It's weird, I am stuck on something, I post a thread, and then immediately solve it. This engine is going to rock. I have put so much work into figuring out all the little nuances of Blitz. |
| ||
| I've had similar. The only solution is to break your terrain up into smaller mesh chunks to avoid floating point errors - else institute a backup linepick routine. |
| ||
| Hmmm... strange problem. It's probably floating point precision but it could be that you have too much gravity and not enough normal force. I mean Blitz is supposed to stop object from moving through each other but it doesn't work very well with moving objects especially if the scale of the movement to the objects is a large ratio. |
| ||
| Halo check this : http://www.blitzbasic.com/Community/posts.php?topic=26738#279339 As you read this a massive land 524288x524288 units terrain. No linepick, just find what quad of the terran mesh is inside your position (if your mesh terran is formated in certain manner) and perform a pseudo linepick function just in the two triangles of this quad, returning the intersection point + angle of greater slope + sliding vector. Blitz collision detection is inacurate beyond 8000 units. It's why i use now the Nuclear Glory detection collision. |
| ||
| What does scale have to do with floating point precision? This engine is going to rock. These statements are in direct conflict with each other. :) |
| ||
| You idiot, scale is irrelevant to floating point precision if all objects use the same scale. |
| ||
| Shh, use your big boy voice. |
| ||
| I don't think that's true. Blitz will run out of precision regarding the global transforms of the characters thus making the collision detection less accurate. |
| ||
| >You idiot, scale is irrelevant... Stop namecalling or i'll strap you to a rock and let you roll down mount ego! Andy |
| ||
| If scale doesn't matter to precision, the physics programmer here will be thrilled! I'll go let him that he's been working under a misconception for years... |
| ||
| Scale doesn't matter if *everything* is scaled the same way. But that is almost certainly not the case. The entities may have similar scale, but what about movement? Does the player move ten times as fast when he is ten times as far from the origin? That's not likely. The problem almost certainly floating point precision. This would typically cause problems which get worse as you move farther away from (0,0,0). |
| ||
| You clearly have no concept of the subject. If I scaled everything down the same way, it would have no effect on floating point precision. I don't have the patience to explain why every reason you have offered is self-defeating, and have no hope in your ability to understand anyways. |
| ||
| Scale definitely has an affect vis a vis floating point precision. Are you high or sleep deprived or something? Because usually you're a pretty knowledgable programmer. Let's look at an example. If you use a scale of 1 unit=1 meter, then a millimeter (perfectly reasonable for, say, the amount an idling character has moved between frames) is 0.001 units. If you were to change the scale to 1 unit=1 kilometer (for example) the a millimeter would be 0.000001 units. Admittedly this is kind of a silly example (although even smaller changes are routine in a lot of calculations) but the point is that scale and floating point precision certainly are related. As for your specific problem however, I would guess that it's a scale problem in the other direction. 130,000x130,000 units is huge, much bigger than Blitz can comfortably handle. You might consider trying a larger scale for your game (ie. scale down all of the objects proportionally) so that the terrain won't be as large. |
| ||
I repeat, you clearly have no concept of the subject.a#=0.0000001 b#=0.0000003 Print (a+b);no imprecision Print (1.0+a);floating point imprecision, biatch WaitKey |
| ||
| Print (a+b);no imprecision Print (1.0+a);floating point imprecision That is exactly the point about the very large terrain. Your current position has a certain x value and you take step. The new x is x+xStep. The size of xStep would usually be roughly constant. But on your huge terrain x could be 1 or 100000. Assuming xStep is rather small the expression 1+xStep is done very accurately but 100000+xStep is not. |
| ||
Jesus, how simple do I have to make this? If your values are enough magnitudes different, scaling them down will make no difference.a#=0.0000001 b#=1.0 Print (a+b);floating point imprecision a=a/10000.0 b=b/10000.0 Print (a+b);still floating point imprecision WaitKey This is in response to the suggestion that I scale the entire world smaller: My first thought here is your scale is wrong, and you're at the low FPS your having, the floating point precision is causing problems. Ya might try scaling everythign down. |
| ||
| We can't say anything based solely on the scale of the terrain. The issue is the interaction of movement, usually small values, and position. The original problem was falling through the terrain. Where does this happen? If it is very far from (0,0,0) then you should suspect floating point accuracy as the reason. Similarly, there are issues with very steep terrain. Again, this is most likely a result of mixing large and small numbers. On steep terrain a small horizontal movement induces a large vertical movement. |
| ||
| Jesus, how simple do I have to make this? If your values are enough magnitudes different, scaling them down will make no difference. Sounds like someone needs a nap. |
| ||
| As a totally different approach: couldn't you implement a set of ghost triangles 'under your feet' that closely resembles the terrain, is not visible but does the collision detection? |
| ||
| If you look back at the posts, I solved this awhile back, but thanks. |
| ||
| ok, I see. This was just in case you wanted to return to the method you used before. I am looking forward to see a demo of that engine you're working on. |
| ||
| halo, have you even tried scaling everything down? It's a known fact that Blitz3D collision detection gets more inaccurate the further from 0,0,0 you get. Supposedly, collisions are only reliable up to about 10,000 units from the origin. I can't tell you if it's floating point inaccuracies, or some other bug causing this, but by scaling your world so everything is below 10,000 would help. I know you came up with your own solution which is great, but don't immediately disregard someone elses idea simply just because it doesn't make sense to you. On BlitzCoder.com, someone has come up with another method in which, when your character gets to be more than a certain number of units from 0,0,0, the whole world gets shifted over to put the character back at 0,0,0. If playerx > 5000 or playery > 5000 or playerx < -5000 or playery < -5000 terrainx = terrainx - playerx terrainy = terrainy - playery PositionEntity terrain, terrainx, terrainy, 0 PositionEntity player, 0, 0, EntityZ(player) playerx = 0 playery = 0 End If If your world contains many objects, such as trees and buildings, then you'd move only what was visible in the immediate area, then move the rest of the world little by little every few frames or so to prevent a sudden pause in the game. |
| ||
| I can't believe "halo" is questioning the mathematical judgement of the great "floyd". Wonders will never cease. |
| ||
| Big meshes -> blitz native collisions will fail intermittantly. Halo -> Derek Smart? |
| ||
| I don't have to explain myself now since everyone else already stated the facts. Yay! (Go study collision detection halo. It might have helped you avoid sounding like an idiot multiple times.) You idiot, scale is irrelevant to floating point precision if all objects use the same scale. Scale is irrelevant. Were talking about simple math imprecisions when the values stored in blitz's limited floating point mechanism are overrun by a lack of decimal point "locations" to store small values. |
| ||
| pwned |
| ||
| Might help, i had this before, i fixed it by toning down the floating numbers. I understand that blitz Can do floating numbers, but there not precice. make it about 1.00 two numbers after the point should fix things, it will do 3, but nyhight than 5 numbers after the point, things start falling through walls. |
   |