radar1200gs
Regular
Ostsol said:
Well, you would only use vertex based collision where needed. If you can determine in advance that two objects won't collide, then there is no need for it.
Displacement mapping with shaders
- Thread starter Vadi
- Start date
Well, you would only use vertex based collision where needed. If you can determine in advance that two objects won't collide, then there is no need for it.
Well, whatever. To reiterate to my original point in reply to you: it doesn't matter whether pixel or vertex displacement mapping is used; it does not necessarily affect how collision is modeled. A ball rolling on a pixel displacement mapped surface can act the same was as on a vertex displacement mapped surface, or a pre-tesselated surface. All that matters is the collision model. How it's rendered is irrelevant.
radar1200gs
Regular
vertex collisions stop stupid rendering errors such as a human sticking his finger inside the ball he is supposed to be holding or walking straight through a rock or levitating a few pixels above the ground while walking.
That's the advantage of using vertexes and not relying on another collision model.
That's the advantage of using vertexes and not relying on another collision model.
Are you aware of how collision detetcion is generall achieved Radar?
radar1200gs
Regular
Usually with bounding boxes. Which is why you get lots of comical rendering errors in games.
If its done in a bounding box, how would vertex based displacement mapping change anything?
radar1200gs
Regular
You use the bounding box to see if you are about to touch something or not. If you are about to touch something, you switch to vertex collisions temporarily (and only for those bits of the scene that require it).
And if you do that, how is it going to interact with the rest of the physics calculation of the game to determine what action should be taken if a collision is detected?
radar1200gs
Regular
I think you need to learn how 3d games work dave.
But, in the case of the ball, you will be able to learn how much of the ball hit how much of the road and at what angle. This coupled with speed and direction gives you enough info to know where the ball should head next.
A bounding box only tells you there was a collision. Sometimes it will tell you there was a collision when there actually wasn't (bounding boxes surround an object at its extremities).
If there was a pothole in our road rendered with virtual displacement mapping the bounding box for the road would tell you nothing about it - the ball would bounce on top of the pothole, if you used vertex displacement mapping and vertex collisions when the ball is near the road surface the ball would bounce off the bottom of the pothole.
But, in the case of the ball, you will be able to learn how much of the ball hit how much of the road and at what angle. This coupled with speed and direction gives you enough info to know where the ball should head next.
A bounding box only tells you there was a collision. Sometimes it will tell you there was a collision when there actually wasn't (bounding boxes surround an object at its extremities).
If there was a pothole in our road rendered with virtual displacement mapping the bounding box for the road would tell you nothing about it - the ball would bounce on top of the pothole, if you used vertex displacement mapping and vertex collisions when the ball is near the road surface the ball would bounce off the bottom of the pothole.
That wasn't what I asked.
Again, once you have determined that there is going to be a collision, via whatever method you choose to do it, the game then has to determine the outcome of that collision - most of the time we are not dealing with something as simple as a ball, but usually fairly complex objects that have velocity, mass and potentially deformity values. When a collision is detected the physics engine will need to know that in order to determine the course of events that will occur next; which means that something needs to be passed back over the bus if you are doing the work via the vertex shaders.
And as a matte of fact, I've spent time talking to experience game developers about these types of things and I'm well aware of how they achieve things.
Again, once you have determined that there is going to be a collision, via whatever method you choose to do it, the game then has to determine the outcome of that collision - most of the time we are not dealing with something as simple as a ball, but usually fairly complex objects that have velocity, mass and potentially deformity values. When a collision is detected the physics engine will need to know that in order to determine the course of events that will occur next; which means that something needs to be passed back over the bus if you are doing the work via the vertex shaders.
And as a matte of fact, I've spent time talking to experience game developers about these types of things and I'm well aware of how they achieve things.
radar1200gs
Regular
the number of vertexes colliding and their position are the main things you would want returned.
With bounding boxes you only know something collided, not how much of something and not where on the object (yes, you can have lots of bounding boxes).
With bounding boxes you only know something collided, not how much of something and not where on the object (yes, you can have lots of bounding boxes).
Yes, but displacement mapping has nothing to do with collision. It is a rendering technique, but the physical geometry as is used by the physics engine is not affected by it unless the generated geometry is pulled across the bus to system memory -- which is pointless unless the surface is dynamic and the programmer simply does not want to duplicate the effect in software for the collision hull.
In the case of your road, the collision hull could have geometry to represent that pothole. Displacement mapping has nothing to do with this since the collision hull never gets rendered -- and displacement mapping is purely a rendering effect.
All bounding boxes are collision hulls, but not all collision hulls are bounding boxes. Collision hulls are used because in most cases it is not necessary to calculate collision with the smallest details of a mesh, but more precision is needed than simply bounding boxes. A basic case is a staircase where the back of the rise is inset from the forward point of the step. That lip is not necessary in the majority of the collision calculations, but the step is.
In the case of your road, the collision hull could have geometry to represent that pothole. Displacement mapping has nothing to do with this since the collision hull never gets rendered -- and displacement mapping is purely a rendering effect.
radar1200gs
Regular
A collision hull is just another hack, like bounding boxes that helps process scenes quickly.
It won't help you if a bomb were to drop on our road and rearrange the terrain. But vertex collisions would be unaffected.
It won't help you if a bomb were to drop on our road and rearrange the terrain. But vertex collisions would be unaffected.
radar1200gs
Regular
So, you are trying to tell me the trend in the future won't be towards dynamic worlds, geometry and more realism?
Why on earth are the IHV's working so hard to improve vertex and geometry performance in their next-gen gpu's then? Why is microsoft bothering with HOS's and geometry processors for DX next?
Why on earth are the IHV's working so hard to improve vertex and geometry performance in their next-gen gpu's then? Why is microsoft bothering with HOS's and geometry processors for DX next?
Heh. Yeah...radar1200gs said:
No, I'm just saying that physics is likely to remain entirely separate from rendering.
Take that road you're using in your example. The explosion causes a change to the terrain. In all current techniques, such deformation is calculated by the CPU. The new geometry is created then stored in system memory before being uploaded to video memory to replace the original terrain. The copy in system memory provides an updated collision hull.
Take that road you're using in your example. The explosion causes a change to the terrain. In all current techniques, such deformation is calculated by the CPU. The new geometry is created then stored in system memory before being uploaded to video memory to replace the original terrain. The copy in system memory provides an updated collision hull.
Well, the subject that radar raised was that pixel displacement mapping techniques such as relief mapping would produce incorrect collisions. However, the same is true for vertex displacement mapping. It all depends on the collision hull that is used. If the displacement is generated in software. . . well, I already covered that in my previous post. In that case it's perfectly viable to use the same data for rendering and physics.
Another matter to consider is for when the surface is out of view, but still colliding with objects. Would you really want to spend GPU cycles and bus bandwidth on tesselation for surfaces that won't even be seen?
Another matter to consider is for when the surface is out of view, but still colliding with objects. Would you really want to spend GPU cycles and bus bandwidth on tesselation for surfaces that won't even be seen?
