Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 May 2009
Offline Last Active Jun 10 2016 08:38 PM

Posts I've Made

In Topic: Some programmers actually hate OOP languages? WHAT?!

27 January 2015 - 12:16 AM

Two main points:


#1:  OOP programming languages are a fad, and to many programmers, a religion.

#2:  A great many programs and applications can be written without objects of any kind.


Having said that, I'll make a couple personal comments.


#1:  I absolutely loathe OOP programming languages.

#2:  Most but not all the programs I write are chock full of object oriented aspects.


Are you shaking your head in disbelief yet?


Perhaps the best way to explain this [perhaps] seeming contradiction is the following.  I absolutely loathe other people telling me what to do, and how to do so.  I absolutely loathe other people forcing me to do things "their way".  I also absolutely loathe putting application-specific mechanisms in programming languages.  I also absolutely loathe "hiding", which is not absolutely necessary in an OOP programming language, but they all are (that I know of).  I also absolutely loathe staring at code that I can't understand without needing to read 65536 to 4-billion lines of header files and other code.  I also absolutely loathe completely bogus, unreadable, incomprehensible operators... instead of completely readable, comprehendable function names.  I also absolutely loathe having 50,000 code libraries that don't work together, and have 148,000 "approaches" (yes, sometimes several approaches per code library).


Shall I continue?  Because I could continue for hours!


Here is another very relevant way to express the above.  My programs are chock full of object-oriented aspects, and I have no trouble whatsoever implementing those aspects myself in conventional C code.  And when I do implement OOP aspects in my programs, my programs remain completely readable and easy to comprehend.  I also don't need to learn enormous quantities of obscure syntax and methodologies (that are often not applied uniformly by everyone).  I can implement OOP aspects in plain old C code quite happily, BTW.  And each is appropriate to what I need to accomplish, not some attempt to hyper-generalize until cows turn into leptons, making everything sooooo general that it is chock full of clutter (required to be ultra-general), chock full of hidden or difficult-to-learn assumptions (sometimes to make hyper-generality even possible or workable).


KISS.  Keep it simple, stupid!


I can do everything... EVERYTHING... with C that anyone else can do with C++, and my code will be simpler, faster, more readable, more reliable, easier to modify, easier to collaborate with others, easier to document, and just plain better.






The short answer is, I can do absolutely everything with:


#1:  statements
#2:  variables
#3:  operators
#4:  functions


Did I forget something?  Probably one or two.  Maybe you don't think of "structures" as being variables.  Maybe you don't think of "structure declarations" as being "types".  You can argue the C language contains a few more kinds of gizmos, but frankly, very few.


?????  WHAT DOES THIS MEAN  ?????


This means I only need to know (or remember) how statements work, how variables work, how operators work, how functions work... and THAT IS ALL.


Well, guess what, noobies?  If you do everything with only half a dozen very simple and fundamental mechanisms... ALL DAY, EVERY DAY... you not only learn them thoroughly... you habituate them very quickly and thoroughly, so they become like "how to breath".  You do not forget!  You do not get confused.  You don't need 37 ways to walk, you just freaking walk.


And how about interoperation?  How about implementing code libraries?


They are pretty much all exactly the same.  They are a huge pile of functions.  PERIOD.  Everything works the same, because they are all functions, just like the functions in your own programs, and just like the functions in other libraries.  And when you look at a function declaration, you understand it.  Some arguments are inputs, some arguments are outputs (the arguments passed by address without "const").  And you KNOW how every single one of them is passed... either the value of the variable is passed, or the address of the variable is passed.  Just look at the type of each argument.  The value of "int" or "double" or any other type argument is passed directly.  If you see one or more "*" as part of the typename in function declarations, you know the address (or the address of the address, etc) of the argument is passed.  So argument type "int*" means the argument is an address (pointer-to) an int.  And so forth.  You know what's happening.  With C++, you don't even know what a reference type is, because they reserve the right to hide and obscure that (and millions of other aspects of "what's going on" under the covers where you cannot see, or even if you can, it may change next Tuesday).


I'm gonna stop here, because I know there are already at least 256 hit men trying to figure out who I am, so I can be "taken out" for my atheistic views of the world, and especially for wanting my life to be simple, yet utterly flexible.  Religious freaks hate thinking like mine.


Just for the record, I learned C++ before C.  I just hated C++ so much, I decided to give C a try.  It was like removing 65536 scorpion stingers from my brain!  What a freaking relief!!!  You cannot even imagine.


Nonetheless, the fact of the matter is, humans can learn, habituate and even love just about anything, including horrific abuse.  So if you do learn to program in C++, you'll eventually habituate some way of doing things in C++ (there are about 143-million ways, and roughly 1 way to do things in C, not counting trivia like "which style comments do you prefer").


BTW, if there are any advantages to C++ (and I'm sure someone can concoct some convincing-on-the-surface examples), the totality is absolutely, definitely, certainly much more complex and problematic with C++.  Best things about C is... it works the same for 30 years, and it will work the same for another 30 years unless some C++ lover decides to "destroy C from within".


Perhaps the biggest lie of all is... C++ is better for "large programs" with "lots of contributors".  Boy is that the opposite of true!  Holy smokes!  You know how to know this is a total line of BS?  Easy.  Do you think a group of programmers who do everything with 6 simple mechanisms ALL THE TIME (with zero to nothing hidden away out of sight) can work together and understand each others code easier than a group of programmers who adopt varying subsets of 87 mechanisms and 93 non-compatible class libraries?  Hahaha.  You guess!  The additional proof is this.  The way to write good, solid, reliable C programs is the same today as 20 years ago.  The way to write good, solid, reliable C++ programs has not been invented yet, but thousands of people (who claim C++ is the greatest thing since sliced bread) will swear on a stack of bibles that THEIR WAY is the best way in the history of the universe.  Decide for yourself which you suspect is true.


And good luck!  You're gonna need it!


PS:  If you love to be loved, and hate to be laughed at... you must adopt C++.  That's for certain.  If you just want to write great code that works for years, and interoperates easily, well, prepare to be hated and vilified by the most vocal self-proclaimed programmers on planet earth.

In Topic: force and torque

22 January 2015 - 11:02 PM

Buckeye:  You apparently understood the rocket thruster configuration.  Great.  So, what series of steps (algebra equations or pseudo-code) compute the linear and angular acceleration, velocity, position and orientation for successive frames for that configuration given I know the object mass, thrust in grams, position of thrust in local-coordinates, direction of thrust in world-coordinates, object inverse inertia tensor, and duration of each frame?


Is that short enough?

In Topic: force and torque

20 January 2015 - 06:35 PM

Well, I'm almost afraid to ask the questions, because maybe the answers are even more basic and fundamental than any question like that (a specific scenario) implies.  What do I mean?  Well, for one thing, how does the duration argument/variable fit into these equations?  What I mean is this.  If we apply a force through the center of mass of an object, I get the impression these force -> acceleration -> velocity -> [delta]-position equations are reasonably precise and representative of what might happen in reality.  To be sure, I don't expect to be able to model the orbit of a planet around the sun, or a spacecraft around the earth with just four applications of force per orbit, but at least in free space (far from stars and planets), I would imagine that linear force, acceleration, velocity and change of position may be described reasonably well by the equations even if the duration is moderately large (every few seconds or perhaps even every few minutes given a long journey, with no need to recompute every 1/30 second or 1/1,000 second or 1/1,000,000 second to get fairly realistic results).


However, the situation doesn't "feel right" when it comes to torque, angular acceleration, angular velocity and angular change of orientation.  Why?  Well, partly because the object could be rotating several times during one "duration".  Now, in some very selective cases, perhaps including the one I mentioned in my last post, even angular quantities might be computed reasonably well.  That's because that case was contrived to put the rocket thruster exactly at the periphery of the sphere or disk shape spacecraft, and the thrust was precisely tangent to the outside surface of that sphere or disk.


In this specific very contrived and unusual situation, the rocket thrust at every moment remains AT the exact same point on the object in local-coordinates, and remains thrusting AT the exact same direction relative to the local-coordinates of the object.  And so, I infer that maybe if we compute everything in local-coordinates, we might get a reasonable result even if the "duration" is relatively long in relation to how long the object takes to rotate around the axis perpendicular to its thrust.


But even this highly contrived case (contrived to be easy to deal with) may be problematic, because I can imagine the trajectory of that flying sphere/disk spacecraft would be rather like a looping spiral in world-coordinates, and this is presumably different than a fully local-coordinates solution.  By definition, in local-coordinates, an object NEVER MOVES LINEARLY.  Why?  Because the center of mass is the origin of those local-coordinate system, and the center of mass will always remain the origin of that local-coordinate system, and so the object will NEVER MOVE in local-coordinates.


Unless what is meant by "local-coordinates" isn't actually the "local-coordinates" permanently attached to the object, but some kind of pseudo-imaginary inertial coordinate system that is, was, and forever shall-be the unaccelerated (but possibly moving) position the object was at when we turned on the rocket thruster, and not the local-coordinate system we think of in 3D graphics (the origin of which is always at the center of mass, and whose directions of the axes are fixed to certain fixed solid features on the rigid body (even if just little red, green, blue dots of paint on the surface so we can see and track them).


Frankly, I don't feel I should be telling you what frame of reference I want the equations to compute.  Why?  Because likely some frame of reference leads to vastly simpler equations, and that is likely the frame of reference I want.  And if I need to convert from one frame of reference to another, I'll just have to find a way to do so.  I already have matrices that convert from local-coordinates to world-coordinates and also the reverse, so depending on what is the most natural frame of reference to compute in, I will likely be able to accept that.  Though it could, I suppose, lead to a further question... how to convert from some new and very strange (to me) frame-of-reference to one I am familiar with.  We shall see.


So I'm tempted to say, how about that rocket thruster case for a starter?


I'm not concerned with gravity forces, I understand how to deal with them (and maybe all forces that always pass through the center-of-mass of all objects).


I was going to say "drag", but I'm guessing symmetric drag is easy, and asymmetric drag may be equivalent to attaching a few small rocket thrusters to various locations on an object and powering them up to whatever power-level generates a force equal to the drag.


So I'll stop here, except to add one more comment that also leads me to confusion.


In "game physics engine development" they have two functions to compute force, one that takes local-coordinates and other that takes world-coordinates.  In the one that takes local-coordinates, they simply transform to world-coordinates and continue.  Which implies, all this "frame-of-reference stuff" is merely a matter of multiplying a position or direction vector by a transformation matrix to get the force in the frame-of-reference you want, and then just procede as if the different frame has no other bearing.


However, think about what that means... or seems to mean to me... in the case of that simple example I started out with.  If that force applied to the periphery of the sphere or disk shape flying saucer is in local-coordinates, then presumably the force rotates around in circles (in terms of world-coordinates) even as the position and direction of that force stays fixed in local-coordinates!  However, if the force remained fixed in world-coordinates, well, the object would move away from the point where the force was applied (a fixed world-coordinate position)... AND... the direction of the force would not rotate with the object, but would remain pointing in the same direction (in world-coordinates) as it started.


Which means... no way could the result be the same, and this "easy technique" of transforming the force direction and position of application from one coordinate system to another could not possibly be as simple as this book implies.  This book (and the other books and slides on the same topic that I've encountered) simply never discuss the questions I am asking.  They just assume "everyone knows and understands the underlying assumptions we are making".  Well, no we don't, certainly not everyone!


And so, I'll leave you with this one example, but also a statement that "several paragraphs or pages are missing" in all these sources to help us understand exactly what is assumed, and how to deal with situations that do not fit the assumptions.  And I don't think it should be up to the "learner" to know what all the cases are... that should be explained by the authors who claim to understand the topic, or so I believe.


PS:  If you know some sources that are more practical, that explain (as much as practical) the whole range of possible physical situations and configurations and how to fiddle the equations to account for them, I'd appreciate the references.  I suppose I could ask questions one by one, but I don't even know yet whether that would require I ask questions about 5 situations and configurations, or 25, or 255.

In Topic: force and torque

20 January 2015 - 03:22 AM

Buckeye:  You have to decide where the force is applied.  If the source of the force is stationary in world space (gravity), then the force must be applied with respect to that reference frame.  If the source of the force travels with the object, then the force is applied locally.  Your general statement above assumes something about "the force" that's not general.


maxgpgpu:  Well, I don't want to be newton or euler (at least not in this field, and not now).  I'm just trying to figure out which equations to put into my engine to produce the correct result (objects do what they would do in reality, as close as possible).  And that's the problem.  What I read in the game physics books ("game physics engine development" and elsewhere), and in PDF slides downloaded from the internet, are the two simple equations in my original post.  They do say they can be applied in local-coordinates or global-coordinates, then procede to adopt global-coordinates.


However, they do not indicate what kind of physical systems and applications of force correspond to those equations, and which do not.  And so, I ask, what use are those equations if the authors has no idea what kind of physical contraption and configuration would satisfy those equations, and none of their readers (except me) bother to ask the question?


Do the equations only apply to some kind of fictitious idealized situations and contraptions, or to something useful (real life devices operating in real life ways)?  I can't tell.


The fact is, gravity is a bit of a cheat example.  First, it always (for practical purposes) applies its force through the center-of-mass of all objects, no matter where they are in the universe, and no matter how far.  Plus, unless we're discussing black-hole encounters of the third kind, the gravitation force doesn't change enough in any short time-frame (1/30 second or 1 second) to worry about changes in distance during the duration of the computation.


However, other real sources of force are not so obvious and not so uniform... to put it mildly.  But ALL authors I've read say NOTHING about the kind of real situations, real devices and real configurations we will encounter in real life (except maybe a simple spring example).


And so, I have to ask "what physical systems and configurations do those equations I wrote in my original post assume and work properly for?".


To take just the simplest example, how about a flying saucer in the shape of that idealized disk in my previous example.  Let's say that flying saucer disk has a rocket output nozzle on the exact periphery of the disk, pointing exactly tangent to the flying saucer disk.  Okay?


What equations apply to that case?


My first general, intuitive observation is the following.  This rocket thruster is indeed firmly and permanently attached to the exact same local-coordinates... forever (during force generation (thrust) and when shut down).  In my example, the local-coordinates of that thrust are <1, 0, 0>, and they STAY at <1, 0, 0> for all eternity.  Which makes this example vastly simpler than many other practical examples we (game developers) should discuss.


Also, in the local-coordinates of the object, the thrust vector (and therefore the applied force vector) is also constant at <0, 0, 1> (though the magnitude of that force might be anything (often a huge number)).


Now, since the force is applied at a single point at a single fixed coordinate <1, 0, 0>, I have to assume those equations I quoted should apply.  Also, since the force is eternally applied in a single direction, I have to further assume those equations I quoted should apply.  Of course, presumably they only apply in local-coordinates, so we still need to figure out how these local-coordinates related to world-coordinates at some point (namely, every frame time, so we can update the object orientation quaternion or matrix, and the object position in world-coordinates every frame (for many purposes, including collision-detection and collision-response)).  That's easy for orientation, since orientation is pretty much always help in local-coordinates (in a manner of speaking, that is, relative to the starting orientation which is co-aligned with world-coordinates).


But what about other physical configurations?  Say, the force of an air nozzle fixed in world-coordinates?  Or many other configurations where the quantity of force changes during the frame, the position the force is applied during the frame changes (as the object rotates and moves), and the direction of the force changes (at least relative to local-coordinates)?


All these source make it sound like there is one situation and one set of equations.  Obviously not so!  But nobody (I can see) talks about this, which sure makes my life difficult, and anyone else writing a game or physics engine.

In Topic: inverted GJK --- you're a genius if you can solve this

16 January 2015 - 10:34 PM

Sorry, I was away for a couple days.


I think both of the last two posts have merit, at different phases of the process.  The algorithm that is most efficient at a rough approximation stage will probably not be best at the precision stage.  Which is why we have SAP (sweep and prune) for broad phase and GJK for narrow-phase in the first place.  And at this point, frankly, we have about 5 phases (or sub-phases), from "swept bounding sphere SAP", to "compute earliest-possible TOI based on bounding spheres (or possibly realize they do not collide)", to "compute earliest-possible TOI based upon AABBs of rotating objects", to "enhanced GJK that reports distance and a separating axis and perpendicular plane" (which again lets us compute earliest-possible TOI based upon knowing vertex at maximum distance from center-of-mass and rotation axis ala erin catto), and continued "sorta" conservative advancement based upon our enhanced GJK routine.  BTW, though they probably don't arise very often in most games, we've identified a whole slew of cases that completely hose conventional conservative advancement techniques, so we found ourselves needing to be a little more "clever" and practical than their conservative advancement techniques.  Or so we hope.


All that's great (if not a bit exhausting to create) for conventional convex objects.  But when it comes to this fairly common case of intentionally flying objects into voids in other objects, some new problems pop up, which we'd like to solve efficiently if not simply.


I think the approach mentioned by Jtippetts looks good at broad phase or perhaps one small notch down from there.  Actually, I think two variants of that probably work fine - the first based upon the bounding-sphere of the landing spacecraft (which only requires transformation of one point to world coordinates (plus the fixed radius)), and another [perhaps] based upon the AABB of the landing spacecraft versus the real (arbitrarily rotated) planes of the 5 walls of the landing bay.


I'll have to think more about the techniques proposed by clb.  First I better go read about Dobkin-Kirkpatrick to gain some background.  As for that hill-climbing approach, that sounds quite a bit like that approach I mentioned in my original post.  Fortunately the fundamental 3D shapes that everything is created from in my engine contains "n sides" and "m levels", and the indices of those vertices are retained in arrays in objects for later applications like these.  Which means, walking the vertices in objects is very efficient, and can be done intelligently for most purposes.


So, I'll fiddle.