Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark Physics & Dark A.I. & Dark Dynamix / Dark Physics with Dark GDK

Author
Message
Tactics1
18
Years of Service
User Offline
Joined: 22nd Aug 2006
Location:
Posted: 22nd Jan 2008 13:35
I have heard about Dark Physics coming for Dark GDK. I have Dark Basic Pro but I have been recently looking into C++. Anyways, I am curious, are the Dark Physics for GDK going to be free like the GDK? Thanks

Oh, and any news concerning the status and estimated time when available is always appreciated
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 22nd Jan 2008 14:08
The plugins will need to be purchased. It's highly likely that if you own DP for DB Pro, then the GDK version will be simply added to your order history. But I am just speculating, I don't know for definite.
Mike Johnson
TGC Developer
22
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 22nd Jan 2008 14:29
Currently working on Dark Physics for Dark GDK. Expect some more news later this week. Anyone who owns the DB Pro version will find the GDK version in their download history when it is released.
pdq
18
Years of Service
User Offline
Joined: 20th Jul 2006
Location:
Posted: 22nd Jan 2008 21:41 Edited at: 22nd Jan 2008 21:43
Quote: "
Currently working on Dark Physics for Dark GDK.
"


I really hate to sound selfish...

...but I hope Dark Physics for DB is the real focus right now since it has been in need of much attention for such a long time. There are still many issues that need to be addressed that users have been requesting.
Tactics1
18
Years of Service
User Offline
Joined: 22nd Aug 2006
Location:
Posted: 22nd Jan 2008 22:42
Good to hear, then I can get Dark Physics Pro without worrying about wasting money on something I may not use later

Quote: "I really hate to sound selfish...

...but I hope Dark Physics for DB is the real focus right now since it has been in need of much attention for such a long time. There are still many issues that need to be addressed that users have been requesting."


Oh Im sure they are working hard on Dark Physics. It shows, just look at all the updates and fixes they have been doing! The game creators rock! Keep up the good work! BTW, the customer support is awsome! Keep up the good work there too ;p
wh1sp3r
21
Years of Service
User Offline
Joined: 28th Sep 2003
Location: Czech republic
Posted: 22nd Jan 2008 23:12
I hope so too. Iam waiting for "usable" character controller for a year ... Why developers have their diary closed. I think, its nice to see, what they are doing ..


PS: Real programmers aren't afraid of math!.
monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 27th Jan 2008 19:23
Quote: "Iam waiting for "usable" character controller for a year"


What problems are you having with Characer Controllers? I think they work prety well, if used correctly.

Who is your Daddy, and what does he do?
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 27th Jan 2008 22:07
Just tried the character controller having got Dark Physics for DGDK and initially was very impressed. Movement seemed rock solid and very smooth with good collision.

But then I realised there is no jump, crouch or strafe capability. Who in their right mind would design a game character controller without those!

Yes I'm sure I can code it but it begs the question why didn't they? Why do half the job!

Please tell me I'm wrong and the functionality is there.

No matter how good your code is, someone will improve on it
monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 27th Jan 2008 22:24
@Pixel Perfect

using this command phy set character controller extents ID, radius#, height# you can make the character controller crouch by setting the height# parameter to say half the original then to stand just set it back to the original height.

As for the jumping you can use the phy set character controller displacement command.

You could also use this command to perform strafing, but personally I just rotate the character controller to face the strafe direction then move it and rotate it back to the original direction.

e.g. PSEUDO Code


Then obviously you just control the forward/backward movement normally.

Who is your Daddy, and what does he do?
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 27th Jan 2008 22:49
Thanks monotonic, that's great news.

I've looked in the header file now and can see all these additional commands that YET AGAIN DO NOT APPEAR IN THE DOCUMENTATION!

No matter how good your code is, someone will improve on it
monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 27th Jan 2008 22:53
Yeah, the documentation is lacking a bit it could definitely do with updating.

Who is your Daddy, and what does he do?
wh1sp3r
21
Years of Service
User Offline
Joined: 28th Sep 2003
Location: Czech republic
Posted: 28th Jan 2008 19:03
monotonic: what about gravity ? Character is not accelerating. When I push upkey, gravity acceleration is faster heh


PS: Real programmers aren't afraid of math!.
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 29th Jan 2008 00:58
Having had more time to play with the character controller and play around with the commands monotonic pointed out it's clear that implementing strafe and crouch movement is easy. Jumping however is not nearly so straight forward but some experimentation has led me to believe that a reasonable jump model should be possible using functions that are called over time and modify the displacement values.

I had not realised initially just how divorced the character controller is from the physics, which has its pros and cons (does not respond to gravity at all, you need to implement that using the displacement command). However, having previously controlled my character using forces in my ODE physics implementation, I like the positive feel of the character controller and the fact that there is no jitter on sliding collision or slight movement of the character when it should be stationery.

I'm not sure quite how the character controller interacts with the real physics world yet and would welcome any insight from others more familiar with this. I believe that through collision detection call-backs it simulates the application of forces on other objects it interacts with, without being a dynamic object in that physical world itself. But, would it for instance, be affected by the forces generated by a near by explosion?

I'm still undecided on whether I will use this in the long term but will probably spend some more time seeing what it’s capable of.

The documentation is proving to be of the usual 'extremely poor quality' we have come to expect from TGC - very disappointing!

No matter how good your code is, someone will improve on it
theplake
16
Years of Service
User Offline
Joined: 30th Nov 2007
Location:
Posted: 29th Jan 2008 10:08
I have heard the dark physics for dark gdk is in history folder.

Where the HISTORY folder?????
wh1sp3r
21
Years of Service
User Offline
Joined: 28th Sep 2003
Location: Czech republic
Posted: 29th Jan 2008 10:12 Edited at: 29th Jan 2008 10:13
theplake : click on Profile button, which is on top side of this page and you can see "Order history"


PS: Real programmers aren't afraid of math!.
theplake
16
Years of Service
User Offline
Joined: 30th Nov 2007
Location:
Posted: 29th Jan 2008 11:16 Edited at: 29th Jan 2008 11:19
lol thx i am a noob

When i order dark physics can i use this for Visual c++ with dark gdk?
wh1sp3r
21
Years of Service
User Offline
Joined: 28th Sep 2003
Location: Czech republic
Posted: 29th Jan 2008 11:26
theplake : yes, you can


PS: Real programmers aren't afraid of math!.
monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 29th Jan 2008 13:56 Edited at: 29th Jan 2008 14:03
Pixel Perfect & wh1sp3r

Every cycle in your loop where you check for user input to move the character controller you need to call phy move character controller in order to update it. If you have no movement to make you must still call it using 0.0 as the movement speed. This will make the character controller respond to gravity.

From the documentation:

Quote: "

Syntax

phy move character controller ID, speed#


Parameters

ID

identification number of the character controller


speed#

speed at which the character controller is to move, when no movement is required pass in 0.0



Returns

This command does not return a value.

Description

When a character controller is being used it is important to update its movement each frame of the application and this is achieved by calling phy move character controller. Even if no movement is necessary at the time this command must still be called passing in 0.0. When movement is required simply pass in the speed at which you want the character controller to move and it will move in the direction it is facing.

"


The Sun is trying to kill me!
wh1sp3r
21
Years of Service
User Offline
Joined: 28th Sep 2003
Location: Czech republic
Posted: 29th Jan 2008 14:06
monotonic: I know about that. but when you press upkey for object walk forward, if the object is in air, it goes forward and more quickly to the ground. And gravity isnt accelerating, but constant. Only this is my problem and I dont know, how to solve it and some character commands are undocumented ...


PS: Real programmers aren't afraid of math!.
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 29th Jan 2008 14:28
@monotonic

Yep, I have all that in my code, I basically converted the DBPro Character Controller demo to DGDK.



Quote: "
If you have no movement to make you must still call it using 0.0 as the movement speed. This will make the character controller respond to gravity.
"


The character controller does not respond to gravity, at least not the gravity defined in the physics. That was the point I was trying to make in my last post, the physics is all being simulated. There is a small downward force simulation but it does not corresspond to the physics settings at all.

And if you point your character upwards and move forwards your character flys. Stop moving and it drops at a very slow rate. So to simulate real gravity (i.e where characters don't fly) you need to play with the displacement values as I did in the code above.

Out of interest have you implemented jumping?

No matter how good your code is, someone will improve on it
monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 29th Jan 2008 14:49
Pixel Perfect

I have not played with DarkPhysics in GDK yet, but in DBPro this should have sorted it out. Maybe, you could try altering the standard gravity, this may sort it out also add some dynamic boxes or something to see how they are affected by the new gravity settings.


I have implemented jumping before but I don't have the code at hand. If you go into the Physics and A.I thread there is some examples of implementing jumping.


wh1sp3r

Hmmmm strange, maybe you will have to use the displacement function to rectify this?

IIRC, the character controller if basically a kinematic object behind the scenes so you could create your own if worst-comes-worst. Or even better (but more coding) you could use a dynamic capsule or box and apply forces to control movement, this method would give you maximum flexibility.

But I have to say that whenever I've implemented the character controller it has served my needs spot-on.

The Sun is trying to kill me!
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 29th Jan 2008 20:26
Thanks for your input monotonic, it is appreciated, but I think you are still misunderstanding what both myself and wh1sp3r are trying to say.

You can alter the gravity setting all you like but it will never have any effect of the character controller because the character controller is not a dynamic player in the physics environment.

As you stated yourself the character controller if basically a kinematic object behind the scenes which I believe implies that it is not effected directly by the physical forces at work. This I'm sure is deliberate so as to avoid the typical pitfalls of having your character directly affected by the physics engine, but means that in order to make your character look like it's interacting in the physical world in a believable way you need to simulate the physical effects. TGC seem to have supplied some sort of downward movement by default to give you the impression of gravity but it appears to be a linear velocity, not an acceleration as wh1sp3r pointed out. Hence, if you really want to produce real physical type movement like falling or jumping you will need to implement a system that changes the displacement values over time giving the impression of acceleration. All of this is easy for dynamic objects as the physics engine does all this for you, but jumping in particular involves an initial acceleration followed by a de-acceleration followed by an acceleration again which outside of the physics engine takes a bit of doing.

To be fair to TGC, they state when referring to their implementation of the character controller:

Quote: "the goal is to give a default/sample implementation that people can use as a starting point."


This is the price we pay basically as designers. I have previously used a dynamic object to represent my character with ODE, so gravity comes by default as does jumping, you simply apply a force and the rest just happens. But I also saw the negative effects of lack of really precise movement control, the inability to stand completely still and the jittery effect of collisions. The character controller gives a much smoother character control but currently at the cost of a decent sensation of gravity and jump ability.

I am very impressed on the whole with it and am determined to produce a reasonable simulation of both jumping and gravity effects when falling. Maybe the best of both worlds could be obtained by forcing the kinematic object position to follow a real dynamic object which we can apply forces to when jumping or falling is required. I'm not sure currently if we can do this! If you can switch the dynamic interaction of objects on and off then this should be possible.

I have been able to simulate a simple jump movement by changing the displacement values within a loop to simulate acceleration upwards and downwards but it would need to be tied in to a time controlled movement system to really bring it to life!

No matter how good your code is, someone will improve on it
monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 29th Jan 2008 21:42 Edited at: 29th Jan 2008 21:46
This is an example of using a dynamic body as a kind of character controller, this was taken from the DBPro examples.



It works pretty well. With slight alteration you can make it respond to gravity, for instance if you change the phy set rigid body linear momentum 2, 0.0, 0.0, 0.0 to read phy set rigid body linear momentum 2, 0.0, phy get rigid body linear momentum y( 2 ), 0.0

The Sun is trying to kill me!
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 30th Jan 2008 00:09
Yes, this is essentially how I controlled my character using ODE Physics. In a really simple simulation this is fine, but it suffers from all the problems that the Character Controller was designed to alleviate. In a complex world you will find that its hard to control your character in some situations in a way that looks natural. Some of these problems are paraphrased in the following extract from the Dark Physics documentation:

Quote: "
In particular, here is a (non exhaustive) list of typical problems you run into when using a physics engine for character controllers:


(lack of) continuous collision detection: typical physics engines use discrete collision checks, leading to the famous “tunneling effect” that has plagued various commercial & non-commercial physics packages for years. This leads to 3 main problems:


the tunneling effect itself : if you character goes too fast it might tunnel through a wall

as a consequence, the maximum velocity of your character might be limited (hence also limiting the game play possibilities)

even if you don’t tunnel, the character might jitter when pushed forward in a corner for example, because the engine keeps moving it back and forth to slightly different positions


No direct control: a rigid body is typically controlled with impulses or forces. It is usually not possible to move it directly to its final position, you first have to convert the delta position vector to impulses/forces, apply them, and hope that the character will be where you wanted it to be as a result. Usually it doesn’t work too well, in particular when the physics engine uses an imperfect linear solver.


Trouble with friction: When the character is standing on a ramp, you don’t want it to slide. You want an infinite friction here. When the character is moving forward on that same ramp, you don’t want it to slow down. You want a null friction here. When the character is sliding against a wall, you don’t want it to slow down either. You want a null friction here. Usually it’s either 0 or infinite. However the friction model might not be perfect, and what you actually get is a very small friction (you can still feel the character slowing down) or a very-big-but-not-infinite one (the character slides very slowly on that ramp no matter how artificially big the friction parameters are). The conflicting requirements for ramps also mean that usually there’s simply no way to perfectly model desired behavior.


Trouble with restitution Basically you don’t want any restitution, ever. When the character moves fast and collides with a wall, you don’t want it to bump against it. When the character falls from a height and lands on the ground, flexing his legs, you definitely don’t want any bump to happen, which would visually look terrible. But once again even when the restitution is exactly zero, you sometimes get a small bump nonetheless. This is not only related to the non-perfect nature of the linear solver, it also has to do with how typical penetration-depth-based engines recover from overlap situations, sometimes applying too big forces that repel objects too much.


Undesired jumps You often want a character to stick to the ground, no matter what the physical behavior should be. For example characters in action games tend to move fast, at unrealistic speeds. When they reach the top of a ramp, the physics engine often makes them jump a bit, in the same way a fast car would jump in the streets of San Francisco. But that’s often not what you want: you want the character to stick to the ground regardless of its current velocity. This is sometimes implemented using fixed joints, which is really a terrible, terrible solution to a very simple problem that has been solved for years without requiring all the modern complexity of a physics engine.


Undesired rotations Finally, a character is always standing up and never rotating. However physics engine often have poor support for that kind of constraints, and a great deal of effort is often put into just preventing a capsule around the character from falling (it should always stands up on its tip). This is again often implemented using artificial joints, and the resulting system is neither very robust nor very fast.
"


Thats why I'm hinting that parhaps the best solution may be the ability to switch between the two when desirable.

No matter how good your code is, someone will improve on it
monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 30th Jan 2008 00:46 Edited at: 30th Jan 2008 00:49
Quote: "(lack of) continuous collision detection: typical physics engines use discrete collision checks, leading to the famous “tunneling effect” that has plagued various commercial & non-commercial physics packages for years. This leads to 3 main problems: "


DP has continuous collision detection.

Quote: "No direct control: a rigid body is typically controlled with impulses or forces. It is usually not possible to move it directly to its final position, you first have to convert the delta position vector to impulses/forces, apply them, and hope that the character will be where you wanted it to be as a result. Usually it doesn’t work too well, in particular when the physics engine uses an imperfect linear solver. "


You can apply forces locally so very little or indeed no mathematics is needed. Also, applying a force to an object and reseting its linear momentum is more-or-less the same as moving and object by a discrete value, just a little experimentation and all will be well.

Quote: "Trouble with friction: When the character is standing on a ramp, you don’t want it to slide."


You just reset the linear momentum, like in the example.

Quote: "Trouble with restitution Basically you don’t want any restitution, ever."


You just need to create a material and set the restitution to zero, then apply this to the body.

Quote: "Undesired jumps You often want a character to stick to the ground, no matter what the physical behavior should be. "


Again, just reseting the momentum every loop and applying only the desired movement will solve this.

Quote: "Undesired rotations Finally, a character is always standing up and never rotating."


Just reset the angular velocity or momentum, whichever one it is.


It wouldn't be as easy as implementing a character controller but can be done pretty easily and produce nice results. It just means that you will have to do some coding and experimentation to get it working how you want. All of the above problems can be dealt with using DP.

The Sun is trying to kill me!
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 30th Jan 2008 01:07
Well if its really true that DP suffers from non of these problems, or rather that they are countered as easily in code as you are suggesting, then no-one will be more happy than me. I saw all of these problems to one degree or another with ODE. I would far rather my character was a dynamic object directly controlled by the physics engine. I guess I'll drop the character controller for now and give this a go.

However, it does beg the question, if this is the case why did they bother to design a character controller which is not directly controlled by the physics engine and place all that justification for doing so in the documentation. Strange indeed!

Thanks for all the feedback monotonic.

No matter how good your code is, someone will improve on it
monotonic
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Nottinghamshire, England
Posted: 30th Jan 2008 01:15
I think the reason for the character controller is as you posted earlier, just a starting point.

Happy coding.

The Sun is trying to kill me!
Dewi Morgan
16
Years of Service
User Offline
Joined: 16th Jan 2008
Location: London, UK
Posted: 28th Feb 2008 07:45 Edited at: 29th Feb 2008 08:00
Has anyone had success using the "phy set character controller extents" command?

Looking at the dll in a text editor, there seem to be two forms, with the parameters "LFF" and "LFFF" (I assume "ID, Radius#, Height#" and "ID, X#, Y#, Z#" for the capsule and box forms of controllers).

[Edit: this now works, I was wrong about it being buggy: my code was buggy]

I am using:


Yet another game programmer
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 28th Feb 2008 19:00
You Could Have 3 or Controllers, and from the center of the smallest one's position ray cast up and down... and use the distance information to decide Which controller to use.

Dewi Morgan
16
Years of Service
User Offline
Joined: 16th Jan 2008
Location: London, UK
Posted: 29th Feb 2008 05:21 Edited at: 29th Feb 2008 08:01
Yes I could have that. It's what I'll do in the meantime.

But has anyone had success using "phy set character controller extents"? Am I using it wrong? Is there a way to use it without messing up all subsequent mesh collision?

[Edit: yes I was using it wrong, see above edited code.]

Yet another game programmer
Lover of games
19
Years of Service
User Offline
Joined: 17th Apr 2005
Location:
Posted: 29th Feb 2008 09:55 Edited at: 29th Feb 2008 09:56
For some reason, Character controllers don't work for me. what the heck, man? i'm using the 2.3.7.4 dlls. maybe that's the reason?

EDIT: 2.7.3.8 DLLs

"Originally I was going to have a BS on it but you know how that would be. I can't walk around with the letters BS on me." More or less a qoute by Syndrome from Jack, Jack, attack
Dewi Morgan
16
Years of Service
User Offline
Joined: 16th Jan 2008
Location: London, UK
Posted: 29th Feb 2008 10:23
I've been wrestling with them a *lot* lately. I have had an awful lot of things "not work for me" that in the end turned out to just be me doing it wrong.

What in particular has not been working for you?

The character controller got some coding love in the later versions of DP so yeah, making sure you're running that, plus the latest PhysX driver, would be a good idea.

Beyond that, what're you trying to do, how are you doing it, and what happens instead?

Yet another game programmer
Lover of games
19
Years of Service
User Offline
Joined: 17th Apr 2005
Location:
Posted: 29th Feb 2008 10:40
well, the character controller doesn't even seem to be created at all. i ran the debugger and the CC doesn't show up at all.



here is my code. when i run it, the CC doesn't move at all. and like i said, it doesn't seem to show up in the debugger.

"Originally I was going to have a BS on it but you know how that would be. I can't walk around with the letters BS on me." More or less a qoute by Syndrome from Jack, Jack, attack
Dewi Morgan
16
Years of Service
User Offline
Joined: 16th Jan 2008
Location: London, UK
Posted: 29th Feb 2008 11:48 Edited at: 29th Feb 2008 11:51
Yeah - mine shows up in the debugger, so it does sound like a bug.

Your code looks fine to me, though I've not compiled it. Make sure that:

1) collision with your "cube" mesh will prevent your character controller from zooming off within a couple of frames, since you are moving it 100 units per frame.

2) your character controller fits fully within the "cube" mesh. Beware that the character controller may be 20x20x20, going from 0,0,0 to 20,20,20. At least, this is what I have found. The sizes in the "PhyMakeBoxCharacterController" command seem to get doubled, possibly they distances from the object origin rather than dimensions.

3) DP doesn't (in my experience) prevent objects colliding in the direction opposite the normals. If your "cube" mesh is "outward facing", that could cause the character controller to fall through.

Since you're not hiding the box (object 2) that you make the character controller around, you should at least be able to see that - can you?

Try setting the camera to follow the coordinates of the character controller each time round the loop.

Yet another game programmer
Lover of games
19
Years of Service
User Offline
Joined: 17th Apr 2005
Location:
Posted: 29th Feb 2008 15:36
The Thing is that the character controller doesn't show up in the debugger. I tried setting the size to something smaller like maybe 5x5x5 but.....no luck. Dang it. also seems that DarkPhysics for DBPro doesn't seem to work good with CCs. might be 1.03 beta? I'm stuck.....I suppose i could just use PhysX but that'll be a bitch to set up

"Originally I was going to have a BS on it but you know how that would be. I can't walk around with the letters BS on me." More or less a qoute by Syndrome from Jack, Jack, attack
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 29th Feb 2008 15:48
I've been hitting this DarkPhysics Stuff Hard - and it seems maybe - JUST MAYBE - we write our own Literally - just use Ageia directly. A friend of mine on here has 100% integrated to Ageia straight to DirectX - and he told me EVERY SINGLE MESH (referring to my inability to have EVER seen a Dynamic Rigid Body Mesh work in DarkGDK! - Only Boxes and cubes seem to work) works and the character controllers in Ageia are fine.

Case and point: I model and egg and set it on end - it should roll to its side right? I shouldn't have to choose between a BOX or a Sphere....

I can live with scaling issues - (Where scaling a object in DarkGDK will not be reflected in DarkPhysics if you then (after scaling) try to make a rigid anything ... it will be original size. (There is a workaround for this though)

Also - I hear Ageia Vehicle has no limits on the wheels or something for vehicles. I think 4 is fine usually - but... It seems maybe to get the 100% Mesh Dynamic Bodies and Character controllers - ....

I dunno - I don't wish to be the bad mouth rebel here - I would actually be quite content with a couple "patches" and fixes or something. And I think dropping support for dynamic rigid mesh bodies (as Dark Physics Help Elludes to) is awful.

Dewi Morgan
16
Years of Service
User Offline
Joined: 16th Jan 2008
Location: London, UK
Posted: 29th Feb 2008 21:52
From their page, their "SDK is available for all users who register at http://devsupport.ageia.com. Registration is free and includes access to AGEIA developer discussions and support."

I think it will be a whole lot harder than you envisage, however. I suspect that DBP stores stuff one way, and Ageia will store it another. So you'll need to somehow tell the Ageia drivers every time an object gets created or moved or in some way affected by DBP, and vice versa. That, I think, will be the hard part, and it's critically important. If you don't tell DBP where stuff has been moved to by the physics engine, then it won't get drawn.

So personally, I'd argue for making "add-on DLLs" for the DP module, rather than writing our own. I might be wrong, this might not be easier, but I suspect it will. It will also be likely to receive more support from TGC than a full rewrite. However, I do not know how hard it would be to access the DP and DBP data structures.

I think either way we should split it over multiple DLLs, though: one of the things that DP does "wrong" as far as I am concerned is to add 3M of functions just by enabling it, almost none of which I am using.

So I'd put separate DLLs for joints, vehicles, character controllers, cloths, emitters, rigid bodies, etc.

It'd also mean that different people could focus their development on a single part at a time: someone making a FPS might want to work on the character controller and cloth, while someone making a racing game or milsim might want to work on the vehicles and joints.

I do have Visual Studio, so could help with this project, but I'm hardly close to expert with C/C++, so wouldn't feel at all confident working on the core "hard" part where it interfaces to Ageia or DarkPhysics. I'd be interested in working on the character controller parts in particular: I feel that with work, they could be made to be fully-WASD/Jump/Crouch-aware, and this is something well worth doing.

Yet another game programmer
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 1st Mar 2008 00:26
Ageia is where the overhead is you cant just seperate it all. Sorry.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 1st Mar 2008 00:33
Good thoughts though Dewi - Complementing DP might be a great idea. I'm waiting in hopes that TGC will have an upgrade for us soon after the DarkGDK.Net.... I Wish they would publish their development Schedules - I know dev schedules are always moving targets - but then we could maybe kinda help the development by having focused feedback for the "product da jour" to help get stuff in that we (customers) all want!

david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 1st Mar 2008 00:52
@jason good thoughts, but a update isnt going to happen anytime soon. You just had one. If more people would have helped on the beta testing then you could have more fixes as it is. I got mike to fix raycasting. Mikes good if you can provide a snippent with the problem at hand, and a descripton as to how you believe it should work. DP basically is PhysX straight up. Just the commands are made easy to use and understand. So its really not that hard for Mike to make a change. He just needs the time given to him by TGC.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 1st Mar 2008 01:00
Thanx David, didn;t think they were that approachable. I mean - Once I was having an issue - and he said he would look into it - and never responded again - eventually things got sorted out - but no responses back from Mike either way - not even a better late than never "Glad its working" or something.

I Figured they get slammed with so many people wanting their time - I just backed off... figured they (TGC Developers) are to busy to engage us to much.

I wish they would engage me a little - I mean - like them, I'm a paid professional - I program every single day of my life - get paid for it - and there is a long queue of companies waiting for me to integrate business systems, write importing apps to work with various CRM systems, write custom applications....

I make mistakes - "Not a Bug Dude!" - but most of the time - I'm pretty spot on.

game coding is for fun and what got me started in this career ... so I return to games - because coding is an art form and business systems... well - there is no time to get creative usually - but here - I can strive to make code purr.

VRMan3D
19
Years of Service
User Offline
Joined: 3rd Apr 2005
Location: New England
Posted: 27th Apr 2008 22:21
Hey just read this excellent thread - and I thought for sure in the past like was said above, if you made an EGG shaped object and made it a dynamic mesh it worked and rolled to it's 'side' just fine. But I've been banging my head against the wall trying to figure out why that doesn't work now (after taking a while off from dbpro/gdk/dp). Did they really just remove dynamic mesh!?! Convex sounds like it would work for that and it doesn't scale properly (the scaled up 'egg' will be half-way underground). I had created a big world editor (it's actually very polished and has the exact same user interface as SecondLife to make it super easy to use - primatives, grab and stretch, etc.), and then I added physX when I got an Ageia card, and was reallllly disappointed when I noticed so many issues.

It brought my projects to a halt basically. What's the deal with DP? I'm (trying) to use it in gdk and so much seems broken lately....
Can someone please list out all the latest DarkPhysics 'limitations'/bugs for me? Are there differences between the gdk and dbpro versions as well?
Thanks... -=VRMan=-

World Famous 3D Screensavers
-- http://www.vrman3d.com --
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 27th Apr 2008 23:01
No - But We're in this together at least at the moment! I like this thread too... and the EGG problem is still bothering me. The reasons I'm going to HOPE for a fix and or make due is the intergration to DarkGDK is sweet versus integrating my own ... plus we don't have the internal mesh structures, so that makes it even more complex.

A buddy of mine did it directly to DirectX and Ageia and he told me recently he got dynamic mesh working, so its evidently a DarkPhysics issue more than an Ageia one. What's the point of physics without dynamic mesh.. unless your world is BALLS and BOXES.


Good luck and please post any developments! We're here... watching, waiting... We have a wonderful Engine, Car Body, Wheels, but we are missing 1st gear in the transmission!!!! (It's a standard...this isn't good)

Login to post a reply

Server time is: 2024-11-24 23:09:48
Your offset time is: 2024-11-24 23:09:48