Hands up if you love eye candy?

Can't see the link?
ONLY REGISTERED USERS CAN SEE LINKS
Posted on 2008-06-08 10:27:36 by Homer

Hands up if you love eye candy?

Can't see the link?
ONLY REGISTERED USERS CAN SEE LINKS



Are you talking about this forum? As far as I know (and from just checking), everyone can view links, regardless if they are registered.
Posted on 2008-06-08 12:43:24 by SpooK
Very nice! And yay - it's a day I've been waiting for - some eye-candy from Homer ^^.

As for checking for gravity causing microcollisions, maybe you can apply a different threshold on the Y axis (or whatever points Down).
Posted on 2008-06-08 13:25:59 by Ultrano
Yeah I'll have to do something like that - but I can't be sure the floor is flat, only that Gravity points downwards - so I need to find the component of the closing velocity that is acting along the collision normal, and determine how much of it is due to Gravity... or something.
I can't decide exactly how I wanna deal with this one yet, but I can't imagine it will be anything too difficult.
I'll probably spend some moments today implementing the FRICTIONAL collision response.
The code is there, it just needs to be enabled, and checked for bugs.
If everything goes well, I'll post another little movie today.
Posted on 2008-06-08 21:34:37 by Homer
Homer we need more cool stuff to spice up our lives!  ;)
Posted on 2008-06-09 07:15:18 by roticv
I've implemented the Frictional code, and it works wonderfully - the box hops all over the place :)

However there is a problem that occurs under specific circumstances... if the Body collides with the ground with a certain kind of glancing blow, it won't produce enough linear response to escape the clutches of Gravity, and we'll find the Body is now Penetrating the floor at the start of the next timestep - which is supposed to be impossible under this simulator, and isn't handled... it causes the simulator to enter into an infinite loop.
There's two ways I might go about dealing with this.
One is to treat it as a special case and add code to watch for and handle it, and the other is to implement a whole new chunk of code to resolve penetration within the collision detector.
Each has its pros and cons, so I'm taking a moment to think and choose.
Posted on 2008-06-09 20:21:09 by Homer
Having implemented code to correct Penetration when it occurs, I find a delightful new problem :)

When the special condition (mentioned previously) occurs, the Body appears to 'get stuck' for several timesteps, and then suddenly LAUNCHES INTO SPACE :D :D :D

Oh dear.
Oh my.

Looking closely at my debug spew, I can see the problem.
There is a single-point collision that is being resolved, the outcome of the resolution is not enough to escape gravity, but nonetheless is accumulated in the state of the body - the body's angular and linear momentum are changing, but its position and orientation are not because the amount of time we advanced by is very very small... then we detect and resolve the SAME collision a few MORE times, accumulating MORE momentum, but NOT MOVING MUCH.
Finally, we break free of the collision state, and jet off with our new momentum.
That aint right.

I'm going to need to make the Body a little more stateful in terms of remembering its current collision status, so that Point collisions are only resolved ONCE PER COLLISION.
This might also be good for some optimizing in the 'fine' collision testing methods.

Right now, the collision-checking code keeps a set of flags in its stackframe which tell us the collision-state of each point in the body's boundingbox... I'll probably move these into the CollisionHull class, and change the array into a 'bit-key' to save space.

We'd invent a new state for the body indicating that its not touching ANYTHING - its 'FALLING' (even if its not - it just means its not touching stuff).

IF FALLING
  Clear Body's collision state flags
  Perform collision testing, setting flags for colliding and penetrating points
ELSEIF TOUCHING
  Perform collision resolution, clearing flags for resolved points
ELSEIF PENETRATING
  Correct penetration
ENDIF

or something like that.


Posted on 2008-06-16 18:21:04 by Homer

Having implemented code to correct Penetration when it occurs, I find a delightful new problem :)

When the special condition (mentioned previously) occurs, the Body appears to 'get stuck' for several timesteps, and then suddenly LAUNCHES INTO SPACE :D :D :D

Oh dear.
Oh my.

"Oh deary deary tut tut" - I've seen it happen in a few games. It's pretty hilarious when it happens... bodies flying around in silly ways :D

Just wanted to let you know this happens even in commercial applications - and break the flow of monologue =)
Posted on 2008-06-16 19:48:38 by f0dder

I've been giving the problem some more thought.
What is happening is that a collision response is producing insufficient linear impulse to correct the velocity of the Body in the direction of the collision plane.

After we apply a collision response to a Body, we should recheck the relative velocity at the contact-point... if its still Negative (because it was a kind of glancing blow that produced more rotational response than linear response to the body as a whole) then we need to change the State of the body - it is now officially in RESTING CONTACT with that plane at one or more points, and really, any further motion in the direction of the plane should be CONSTRAINED.

Its worth noting that when this glancing-blow situation happens, we can be fairly certain(?) that this event will be soon followed by a substantial SMACK as 'the other side' of the Body comes crashing down.

So - what kind of constraint are we talking about?
Well, imagine if there was only one contact-point involved here (a corner of a box).. we'd want to 'pivot' freely ABOUT THAT POINT... we wish to move the rotational origin of the Body to that point for the purposes of rotating it - the body is still free to 'slide' along the plane in any direction (with friction) - we're only constraining its Rotation - and forcing change in its Position to suit the constraint.

What if there was two points (an edge) involved?
Now the constraint has an axis of rotation as WELL as a shifted rotational origin... we can build up the similarity transform required to move into and out of 'constraint space' in much the same way as we dealt with 'contact space'... but our INTEGRATE method is where we should be applying the constraint... because thats who is responsible for the Penetration that is going to occur in the next timestep if we don't constrain something.
The Integrate method doesn't really care about the shape of the body that it is integrating right now, and observes no constraints whatsoever.
Bearing in mind that the ultimate goal is to support constraint-based articulated physical machines (such as ragdolls), it might be time to support constraints at the Integration level.
Its time to entertain the idea of supporting constraints at the Integration level.

Posted on 2008-06-18 02:04:59 by Homer
I'm ready to axe this project now.
This vehicle won't get me to where I want to be, and that sucks...But its not a total loss.
I (and perhaps we) have learned a lot of lessons on the way, and built up our math support macros and functions, and a lotta this stuff can be recycled.

I'm not giving up !!
This is NOT the end.

I am gonna redesign this thing to support the stuff I expect from it.
And I am gonna introduce you guys to a bunch more cooler and more modern maths !!
I guess this was bound to happen because I did not ever define the SCOPE of this project, in regards to my goals.. I wasn't exactly sure what I wanted, now I have a better idea.

We're not trying to implement a physics simulator that car companies could use to simulate crashes, we're trying to make an engine that produces results which are 'fast and believable', not necessarily accurate, but 'plausible', and suitable for use in GAMES !!!


Posted on 2008-06-21 11:08:48 by Homer

I've decided to borrow the framework of the Bullet physics library by Erwin Coumans.
I won't be implementing the whole thing, and I'll be making some big changes, but essentially the design of the thing will be based on his.

There are certain lessons and observations I've taken from my recent efforts which I believe are worth something, and I will review them in the context of the new engine framework.

Erwin's work is tremendous and is a credit to him, however the work labors under a mountain of OOP overhead
which, although acceptable and common in C++ sources, can be completely eliminated under OA32's programming model, making it smaller and faster before we've even started to look at the algorithms and structures and data accesses etc ect.

For me, the most ugly thing is all the Get and Set methods for reading and writing to variables in object instances... we can start by getting rid of almost all these as they are pointless, adding call overhead with zero benefit (theres no such thing as private variables when you're using OA32, you can break the rules of C++ when it suits you).

Anyway the work begins to slowly pool together the elements of the new engine - I'll keep you posted :)
Posted on 2008-06-24 00:13:40 by Homer

For me, the most ugly thing is all the Get and Set methods for reading and writing to variables in object instances... we can start by getting rid of almost all these as they are pointless, adding call overhead with zero benefit (theres no such thing as private variables when you're using OA32, you can break the rules of C++ when it suits you).

Get/Set methods are definitely inappropriate in assembly, because you don't have a compiler that optimizes them out. They can make sense in the HLL OOP case though, because the simplified forms will obviously end up as directly variable access, but they give you possibility to add caching, keeping invariants, doing debug-only sanity checks, etc. :)
Posted on 2008-06-24 07:33:19 by f0dder
Sure I agree - and the opportunity remains for data accesses to be vetted should we desire this... in fact OA32 does support resource leak detection etc should we require it - but private variables don't exist in OA32 - if you want them, you make sure that the methods that access them are private, and thats the best you can do - theres no actual security - attempting to cheat on private method access will throw an assembler error and cease the build process, but thats all.

My opinion is that the only excuse for having Get and Set methods is where they are dynamic (abstract) methods which we wish to override in some particular derivation of a class, so that code in the original class which calls these methods is marshalled to replacement methods in the subclass (ie - overridden through redefinition rather than explicitly).

Actually, your comment reminds me, I meant to speak to Biterider about supporting INLINE METHODS (with a view to eventually supporting SIMD inline optimizing).
Under OA32 these would be essentially nothing more than macros which are aware of the Object Instance whose context their execution belongs to.
Inline methods would be expressed inline within a regular method, rather than emitting a call to a method, and would not exist in the vtable at all... but unlike a method call, we dont have to pass a pointer to 'this' object, because we're already inside a class method ;)
Posted on 2008-06-24 08:09:13 by Homer
Biterider says that INLINE methods are on the TODO list - yay :)

Furthermore, we recently discussed an extension of OA32's typecasting of 'pointers to class object instances' - each class now emits a "ptr_ClassName typedef ptr ClassName"
This means that you can define class variables which are pointers to any known class, rather than simply "Pointer".

For example:

DefineVariable m_Pontiac,ptr_Automobile,NULL

This is I think a very nice thing because now we dont need to remember what class we are talking about here... and I think the next logical step would be to extend the calling methods to recognize this new type declaration, so we don't need to mention the classname when making calls via this pointer..
Posted on 2008-06-27 03:11:27 by Homer
I disagree, Erwins work might be good, but your work on bringing all these game C++/D3d game examples to a language like assembler and make your own  creations,is the excellent work not only once, but thru many years and inspiring others to implement d3d, OOP etc in their code
keep up the incredible work you do Homer

Posted on 2008-07-25 17:23:16 by daydreamer
Biterider has succeeded in implementing inline methods , and they emit inline code, inside the local procedural stackframe - perfect.
That places Get and Set methods back on the menu, because there IS no overhead anymore.
And that leads toward more faithful transliteration of the classes we import from other language bases, which means we don't lose speed at the cost of interoperability with external applications / binary objects :)

The next release of OA32 will break some backward compatibility with existing OA32 objects - but improves external interfacing while eliminating redundant call overhead.
Posted on 2008-07-26 08:42:49 by Homer