Lots of words? About the same as your very excellent webpage about "speculative contacts". :-)
I guess my response to your suggestion is this. I'm trying to figure things out before I implement. The reason I wrote lots of words, and often write lots of words, is because I prefer to spend a LOT of time thinking and brainstorming before I try to implement anything complex or important. I'm not inclined to just dive in willy nilly and implement whatever I hear about, whatever happens to be popular, etc. I want to understand the issues involved well enough to identify and evaluate tradeoffs, and spot new approaches.
Why? Because, as you correctly stated, these subsystems are tons of work, and I prefer not to perform "tons of work" on several approaches that don't pan out. At least those I could have avoided in the first place if I had thought enough about it.
After reading your "speculative contacts" webpage, I must say, I was very impressed by what I see. Your examples are extremely compelling. Your technique "sounds almost absurd", but the visual examples you provide certainly make one consider whether the seeming "gross hack" of moving objects into contact and completely ignoring TOI and "lost time" is in fact a great idea. Your examples sure make it seem that way. However, I am a bit concerned by the fact that your visualizations are pretty much all "pile of balls/boxes" type examples. How "speculative contacts" work (visually) on other kinds of collision scenarios is not obvious, and that makes me worry.
The other problem, that is unique to me and a small minority, is that I'm not just making a "game engine". My engine is just as much a "simulation engine" as a "game engine", and simulations are mostly about "being accurate", not "being visually plausible". So I'm still scratching my head. Yes, I could implement a "speculative contacts" scheme AND some more accurate kind of scheme, and let the application choose which scheme to execute. Maybe I'll end up there, but I always prefer to find a technique that works for everything... if I can. Of course, I'm not entirely sure I can.
This topic might be one of those topics where I just need to turn my gaze away from "what others do", and tackle it more-or-less from scratch myself. Good chance I'll get into difficult situations that others already found ways to deal with, and that's what I was hoping to find out now, before hand.
I also have the feeling this whole area of study is too greatly influenced by the specific way game physics is generally implemented. There is something quite wacko about objects jiggling all over the place when they should be just sitting still. I ran into something like this a long time ago on a project that was somewhat similar (but just physics, not graphical)... but I found quite simple, accurate ways to eliminate all this silly jiggling. Just because gravity keeps pulling an object downward (against another object) is no reason to move the upper object inside the body of the object below, and start/continue some kind of undamped oscillations. So I have a feeling that whole problem will not exist for me, and leave me free to ignore all sorts of funky games others seem to play to deal with those situations. Maybe my scheme will be lots simpler because I don't need to worry about those problems, because I fixed them where the fix belongs (physics), not in a different subsystem (collision-detection). We shall see.
I'll just keep struggling with the problem. I almost have enough context built up in my mind to have a chance to find or develop a good approach. Hopefully a better approach. Hopefully something fairly accurate, fairly fast, and inherently stable.
I expect "tons of work" to implement TOI and physics. So be it. I just don't want to flail around wildly because I was too lazy to take the time to wrap my head around every consideration I could identify before I started designing and coding.
Show differencesHistory of post edits
#1maxgpgpu
Posted 06 March 2012 - 10:27 AM
Lots of words? About the same as your very excellent webpage about "speculative contacts". :-)
I guess my response to your suggestion is this. I'm trying to figure things out before I implement. The reason I wrote lots of words, and often write lots of words, is because I prefer to spend a LOT of time thinking and brainstorming before I try to implement anything complex or important. I'm not inclined to just dive in willy nilly and implement whatever I hear about, whatever happens to be popular, etc. I want to understand the issues involved well enough to identify and evaluate tradeoffs, and spot new approaches.
Why? Because, as you correctly stated, these subsystems are tons of work, and I prefer not to perform "tons of work" on several approaches that don't pan out. At least those I could have avoided in the first place if I had thought enough about it.
After reading your "speculative contacts" webpage, I must say, I was very impressed by what I see. Your examples are extremely compelling. Your technique "sounds almost absurd", but the visual examples you provide certainly make one consider whether the seeming "gross hack" of moving objects into contact and completely ignoring TOI and "lost time" is in fact a great idea. Your examples sure make it seem that way. However, I am a bit concerned by the fact that your visualizations are pretty much all "pile of balls/boxes" type examples. How "speculative contacts" work (visually) on other kinds of collision scenarios is not obvious, and that makes me worry.
The other problem, that is unique to me and a small minority, is that I'm not just making a "game engine". My engine is just as much a "simulation engine" as a "game engine", and simulations are mostly about "being accurate", not "being visually plausible". So I'm still scratching my head. Yes, I could implement a "speculative contacts" scheme AND some more accurate kind of scheme, and let the application choose which scheme to execute. Maybe I'll end up there, but I always prefer to find a technique that works for everything... if I can. Of course, I'm not entirely sure I can.
This topic might be one of those topics where I just need to turn my gaze away from "what others do", and tackle it more-or-less from scratch myself. Good chance I'll get into difficult situations that others already found ways to deal with, and that's what I was hoping to find out now, before hand.
I also have the feeling this whole area of study is too greatly influenced by the specific way game physics is generally implemented. There is something quite wacko about objects jiggling all over the place when they should be just sitting still. I ran into something like this a long time ago on a project that was somewhat similar (but just physics, not graphical)... but I found quite simple, accurate ways to eliminate all this silly jiggling. Just because gravity keeps pulling an object downward (against another object) is no reason to move the upper object inside the body of the object below, and start/continue some kind of undamped oscillations. So I have a feeling that whole problem will not exist for me, and leave me free to ignore all sorts of funky games others seem to play to deal with those situations. Maybe my scheme will be lots simpler because I don't need to worry about those problems, because I fixed them where the fix belongs (physics), not in a different subsystem (collision-detection). We shall see.
I'll just keep struggling with the problem. I almost have enough context built up in my mind to have a chance to find or develop a good approach. Hopefully a better approach. Hopefully something fairly accurate, fairly fast, and inherently stable.
I expect "tons of work" to implement TOI and physics. So be it. I just don't want to flail around wildly because I was too lazy to take the time to wrap my head around every consideration I could before I started coding.
I guess my response to your suggestion is this. I'm trying to figure things out before I implement. The reason I wrote lots of words, and often write lots of words, is because I prefer to spend a LOT of time thinking and brainstorming before I try to implement anything complex or important. I'm not inclined to just dive in willy nilly and implement whatever I hear about, whatever happens to be popular, etc. I want to understand the issues involved well enough to identify and evaluate tradeoffs, and spot new approaches.
Why? Because, as you correctly stated, these subsystems are tons of work, and I prefer not to perform "tons of work" on several approaches that don't pan out. At least those I could have avoided in the first place if I had thought enough about it.
After reading your "speculative contacts" webpage, I must say, I was very impressed by what I see. Your examples are extremely compelling. Your technique "sounds almost absurd", but the visual examples you provide certainly make one consider whether the seeming "gross hack" of moving objects into contact and completely ignoring TOI and "lost time" is in fact a great idea. Your examples sure make it seem that way. However, I am a bit concerned by the fact that your visualizations are pretty much all "pile of balls/boxes" type examples. How "speculative contacts" work (visually) on other kinds of collision scenarios is not obvious, and that makes me worry.
The other problem, that is unique to me and a small minority, is that I'm not just making a "game engine". My engine is just as much a "simulation engine" as a "game engine", and simulations are mostly about "being accurate", not "being visually plausible". So I'm still scratching my head. Yes, I could implement a "speculative contacts" scheme AND some more accurate kind of scheme, and let the application choose which scheme to execute. Maybe I'll end up there, but I always prefer to find a technique that works for everything... if I can. Of course, I'm not entirely sure I can.
This topic might be one of those topics where I just need to turn my gaze away from "what others do", and tackle it more-or-less from scratch myself. Good chance I'll get into difficult situations that others already found ways to deal with, and that's what I was hoping to find out now, before hand.
I also have the feeling this whole area of study is too greatly influenced by the specific way game physics is generally implemented. There is something quite wacko about objects jiggling all over the place when they should be just sitting still. I ran into something like this a long time ago on a project that was somewhat similar (but just physics, not graphical)... but I found quite simple, accurate ways to eliminate all this silly jiggling. Just because gravity keeps pulling an object downward (against another object) is no reason to move the upper object inside the body of the object below, and start/continue some kind of undamped oscillations. So I have a feeling that whole problem will not exist for me, and leave me free to ignore all sorts of funky games others seem to play to deal with those situations. Maybe my scheme will be lots simpler because I don't need to worry about those problems, because I fixed them where the fix belongs (physics), not in a different subsystem (collision-detection). We shall see.
I'll just keep struggling with the problem. I almost have enough context built up in my mind to have a chance to find or develop a good approach. Hopefully a better approach. Hopefully something fairly accurate, fairly fast, and inherently stable.
I expect "tons of work" to implement TOI and physics. So be it. I just don't want to flail around wildly because I was too lazy to take the time to wrap my head around every consideration I could before I started coding.