Collision Model issues

[New Horizon]

My understanding was that the Doom 3 physics engine is open sourced and could be replaced already. Pretty sure I read that.

[Springheel]

One idea I really like is having one chair + 4 legs bound to that chair. Then when the force on one joint (where leg and chair are joined) exceeds a certain value, the leg could break off. I think we could hack that in.

 

That sounds like a lot more work than I'm willing to put in to this. Writing new physics code and modifying assets so chairs break under stress in a vaguely realistic manner would be a lot of work for not much gain, IMO.

 

Adding separate cms is relatively painless and requires no new code (though it remains to be seen whether it's workable...I'll upload the prefabs this afternoon so people can test it).

[Baddcog]

Tels, I think you need to go back and read old threads as you keep bringing up points we've already mentioned.

 

Arguing back my original point is slightly annoying.

 

The team has already decided that everythings gonna be moveable, do we really need to discuss why some objects are moveables and others are not again? I was for non-moveable chairs so we didn't have this problem, but the team wants moveables so...

 

I spent at least a week trying to get a decent collision model and couldn't. IF you want to learn a modelling program and find a better solution fine with me. I certianly don't want to start remaking all collision models again just to test, nor would I want to remodel all the existing chairs so their legs can break off.

 

I also don't think having seperate chairs for an L shape that turns into a 3-5 combo would be a very good way to go. First, the proper collision wouldn't be detected becuase it would be the L shape that detected the collision. So waht, we'd have a chair that allowed arrows to stick in the air but then you could pick it up and set it on top of something properly?

 

And you're arguing that 300 entities of a hundred chairs isn't worse than 100, but trying to make it sound sweet by adding that there are another 2,000 entities in the map. Doesn't matter, the chairs are still 3x if we do it this way. And if we have 4 attached legs which is the best collision we could have then we are looking at 500 entities, that's not small difference.

I'd be more concerned building a mission that I had enough entities for sounds, trol points, all objects, arrows, flinders (things I can't count ahead of time) than whether or not the chairs collision is perfect.

 

To me it sounds like the entity limit most likely WON'T be raised so that extra 200 objects is a concern.

 

Just because we come full circle and 'comprimise' on the original L shape doesn't mean it isn't a comprimise. It is a comprimise because we'd be compirimising a better collision mesh for a better entity count. Doesn't matter if that's where we started or not, in fact we started with non-moveable chairs.

[Springheel]

The team has already decided that everythings gonna be moveable, do we really need to discuss why some objects are moveables and others are not again?

 

Actually, what we decided was that objects small enough to move will have movable entities. That doesn't stop a mapper from adding static objects if they want to.

 

I also don't think having seperate chairs for an L shape that turns into a 3-5 combo would be a very good way to go. First, the proper collision wouldn't be detected becuase it would be the L shape that detected the collision. So waht, we'd have a chair that allowed arrows to stick in the air but then you could pick it up and set it on top of something properly?

 

I have no idea what you mean here.

 

And you're arguing that 300 entities of a hundred chairs isn't worse than 100, but trying to make it sound sweet by adding that there are another 2,000 entities in the map. Doesn't matter, the chairs are still 3x if we do it this way. And if we have 4 attached legs which is the best collision we could have then we are looking at 500 entities, that's not small difference.

 

Yes, adding another 4 entities per chair is probably not a good idea. I don't see a huge problem adding an extra 2. How many missions are going to have more than 100 chairs? I'd wager Blackheart Manor has less than 50 chairs of this kind, and it's got one massive dining room.

 

Just because we come full circle and 'comprimise' on the original L shape doesn't mean it isn't a comprimise.

 

Of course it does. A compromise means you take a little from option A and a little from option B, not that you just stick with option A because it's easier. Option A may indeed turn out to be the best overall option, but that still won't make it a compromise.

[Springheel]

Well, as I said, this may all turn out to be moot anyway. For some reason, when I try to bind two sets of chairlegs to the chair, it no longer works. I can't pick up or otherwise move the chair, though it does fall to the ground if I mantle on top of it.

 

Going back to one leg I get a similar problem...the chair won't respond to being picked up initially, but once I mantle onto it, it falls to the ground and the behaves normally.

 

My interest in this task is quickly waning....

 

edit: I tried again, and this time it reacted immediately to me bumping into it, but the chair cms stopped functioning, and the chair simply fell into the floor. If anyone wants to test this out, I'll upload the files, but it seems pretty unstable to me. I think we may be back to square one.

[Nyarlathotep]

My understanding was that the Doom 3 physics engine is open sourced and could be replaced already. Pretty sure I read that.

Sure, if you don't intend to replace the collision code, which is behind the precompiled stuff.

[Ishtvan]

There's no shame in accepting that an L shaped chair is the best we can do for now. Yes it has problems, but is the cost of trying to get a perfect chair worth the time lost on other things? I'd rather have a functioning stealth game with chairs that things can't roll under than a perfect chair simulator that's lacking gameplay. Let me ask some rhetorical questions: How much time is the player going to spend sneaking around AI? How much time is the player going to spend rolling things under chairs? So what should we work on first?

 

So many new ideas have been put off until "post 1.0" release in the interest of releasing within the decade, and it really seems like "perfect concave moveable object physics" fits into that group. I'm glad we tried it, but again there's no shame accepting that it's more work than it's worth right now.

[New Horizon]

What options are left at this point to improve this system? It's really annoying that the system is so limited. If we could extract the pertinent sections of the Prey CM code and modify it to our needs, would it be possible to somehow ignore those parts of the D3 code and have the physics code that is exposed in the SDK reference our own customized cm code instead? There must be a way that wouldn't set us back for weeks.

[Ishtvan]

I implemented the propagation of the collision impulse from the slave to the bind master (it's in idEntity::RunPhysics()), but it is invoked when the team chain gets stuck.

Would it be hard to invoke that every time an entity has ApplyImpulse called on it, rather than just when it gets stuck against something? One solution would be to take all impulses (angular and linear) applied to the bind child, shift them into the reference frame of the bindmaster and apply the shifted impulse to the bindmaster? To be really correct we'd also have to take into account the mass and moments of inertia of all the bind children, but we may be able to get away without that for starters.

[Ishtvan]

What options are left at this point to improve this system? It's really annoying that the system is so limited. If we could extract the pertinent sections of the Prey CM code and modify it to our needs, would it be possible to somehow ignore those parts of the D3 code and have the physics code that is exposed in the SDK reference our own customized cm code instead? There must be a way that wouldn't set us back for weeks.

I'm guessing the "tracemodels need to be convex to behave correctly" thing isn't just an arbitrary restriction. It's probably used in the collision detecton algorithm, and there are probably tradeoffs making things concave. So what you're saying is we have to write a collision algorithm that handles more than Id's and that runs at roughly the same speed. Plus there's the whole legality issue of using code that was accidentally released.

[greebo]

What options are left at this point to improve this system? It's really annoying that the system is so limited. If we could extract the pertinent sections of the Prey CM code and modify it to our needs, would it be possible to somehow ignore those parts of the D3 code and have the physics code that is exposed in the SDK reference our own customized cm code instead? There must be a way that wouldn't set us back for weeks.

The CM code is closed source, there is no way for us to modify it. The Prey CM is just for sneaking behind the scenes a tiny bit, but nothing more. We can't exchange code that's out of our control, and even if we could, it's out of our scope to implement a new collision code.

 

The little I saw from the Prey code was very specific and optimised the hell out of. Nobody on the team has the skills to rewrite that, I guess.

 

Would it be hard to invoke that every time an entity has ApplyImpulse called on it, rather than just when it gets stuck against something? One solution would be to take all impulses (angular and linear) applied to the bind child, shift them into the reference frame of the bindmaster and apply the shifted impulse to the bindmaster? To be really correct we'd also have to take into account the mass and moments of inertia of all the bind children, but we may be able to get away without that for starters.

I'd have to look into that, but I don't know if that's worth it. It seems like a special case to me (even if I bet that we can think of a thousand pathological cases that might be desired by FM makers), and I fully agree with your above post that we should just forget about this and get the important stuff working.

 

We can put that on the bugtracker, if you like, so that it won't be forgotten.

[New Horizon]

Damn, unfortunate.

[Springheel]

I'm glad we tried it, but again there's no shame accepting that it's more work than it's worth right now.

 

Agreed. I would never suggest we pull any coders into this, as there definitely is a lot more important stuff that needs to be done. I didn't mind spending a week or so on it, as I'm not feeling very motivated to do anything else atm.

 

We'll have to stick with fairly primitive cms for moveables for the time being.

[Ishtvan]

Re: Bindchildren propagating impulses

 

I'd have to look into that, but I don't know if that's worth it. It seems like a special case to me (even if I bet that we can think of a thousand pathological cases that might be desired by FM makers), and I fully agree with your above post that we should just forget about this and get the important stuff working.

I understand if it takes a lot of time, there are definitely more important things to work on. That being said, it doesn't seem that special a case to me. What we currently have now is: When two objects are bound together, you drop both to the ground, with the bind slave facing down and it doesn't push the it thru the floor. In an abstract physics sense, you are currently propagating the normal force of the floor from one object up to the other. One would think that other forces (impulses in D3) would also be propagated from the bind child to the bindmaster.

 

I wouldn't be very comfortable including an object ingame made of bound moveables if if it doesn't do anything when you hit the bind slaves, and moves only when you hit the bindmaster. It's completely arbitrary which one is the bindmaster. To represent something as one physical object and then have it take on momentum or not depending on which part of it you hit isn't very believable.

 

We can put that on the bugtracker, if you like, so that it won't be forgotten.

Sure, I would appreciate that.

[greebo]

Ok, it was actually a trivial change, the updated code is already in darkmod_src:

 

http://208.49.149.118/TheDarkMod/Videos/bindslave.wmv

[sparhawk]

My understanding was that the Doom 3 physics engine is open sourced and could be replaced already. Pretty sure I read that.

 

That's right. Of course you would have to find somebody who could add the new engine into the existing framework, so that it works as before without to much changes.

[Crispy]

* http://www.newtondynamics.com/

Newton is freeware, not open source. If the mod is going to be released under GPL, we wouldn't be able to use Newton. Sadly, because it's a good physics engine.

 

Replacing D3 physics with ODE or Bullet might be technically feasible, but it definitely wouldn't be easy.

[Tels]

Newton is freeware, not open source. If the mod is going to be released under GPL, we wouldn't be able to use Newton. Sadly, because it's a good physics engine.

 

Replacing D3 physics with ODE or Bullet might be technically feasible, but it definitely wouldn't be easy.

 

Yes and we don't have the time and manpower. I just wanted to say it *could* do it.

[Tels]

Ok, it was actually a trivial change, the updated code is already in darkmod_src:

 

http://208.49.149.118/TheDarkMod/Videos/bindslave.wmv

 

Very cool - and an allround useful change, regardless of whether we do chairs with bound legs, or not

[Ishtvan]

Yeah, thanks a lot for adding that Greebo! There should be nothing holding us back now from making more complicated moveables by binding a few together.

 

Re: Prefabs

I didn't realise prefabs were so much harder to place over regular entities. Is there any way we could make this more transparent in DR so that prefabs are placed the same as any other entity? I guess you can't include spawnargs to place them in a hierarchy because they're .map files, not entitydefs, but maybe we can work something out.

[Tels]

Yeah, thanks a lot for adding that Greebo! There should be nothing holding us back now from making more complicated moveables by binding a few together.

 

Re: Prefabs

I didn't realise prefabs were so much harder to place over regular entities. Is there any way we could make this more transparent in DR so that prefabs are placed the same as any other entity? I guess you can't include spawnargs to place them in a hierarchy because they're .map files, not entitydefs, but maybe we can work something out.

 

Hm, we can (ab)use the file system as storage. The prefabs are already in their own folder. It should also be already be implemented loading a prefab from a sub-folder.

 

So make subfolders like so:

 

  + prefabs
+ furniture
+ houses
+ etc. etc.

 

Then DR could read the contents of all these folders at startup and display them in a tree. Actually, the file selector dialog already offers this, so I am not sure how much we would gain.

[Springheel]

Yeah, thanks a lot for adding that Greebo! There should be nothing holding us back now from making more complicated moveables by binding a few together.

 

I'll check and see if it makes a difference with the chair.