Tremulous Forum
General => General Discussion => Topic started by: Zero Ame on January 28, 2009, 10:27:32 pm
-
Ok so as a former JKA player, I know of this mod a guy was working on to add physics into JKA. For anyone who doesnt know, JKA used the Q3 engine, same as Tremulous.
Well, this guy got pretty far with making it into a mod, heres 2 videos on it.
Sphere w/ physics (http://www.youtube.com/watch?v=TscOs75YdsQ&feature=channel)
physics stress test (http://www.youtube.com/watch?v=gA7M67q920Q&feature=channel)
Its a very awesome idea, opening MANY options for that game. SO.. I was hoping that maybe sometime in the future versions of Tremulous, Physics be added into the game. Would make some wicked awesome maps able to be made.
Please note that this mod for JKA made physics possible for both models and brushes in maps.
My next suggestion is another mod this same guy was working on. Take a look.
func_vehicle (http://www.youtube.com/watch?v=SN4WLMf6zIU&feature=channel)
Making it so we could make like bumper cars and stuff, pretty fun idea.
-
It's already sort of in the process. >_>
-
hmmm i don't know of any current efforts to put physics into trem... but a worthy endeavor for whoever wants.
-
Your best option (which probably would be your worst as well), would wait for Havok to go open source.
However, you would have to then wait for some community developer to fix it up, and find a way to get it into idTech3. That would take about a year.
-
What part of that being in the same game engine as the one trem uses dont you understand? Q3 Engine will support physics Kaleo, there doesnt need to be any waiting.
-
Q3 Engine will support physics Kaleo
It barely supports physics. You could get basic physics in, like bouncing objects, but you'll be spending a long time getting anything like ragdoll implemented. What I'm saying is that it probably isn't worth that much effort. By the time its worthy for major release, idTech4 will probably be in the public domain.
-
Q3 Engine will support physics Kaleo
It barely supports physics. You could get basic physics in, like bouncing objects, but you'll be spending a long time getting anything like ragdoll implemented. What I'm saying is that it probably isn't worth that much effort. By the time its worthy for major release, idTech4 will probably be in the public domain.
unless you're suggesting that it will take ~100 years, you should look up what public domain actually means
-
Fine, then replace "in the public domain" with "open source". I'm sure you understood what I meant and are just nitpicking.
-
And I'm sure this is an unnecessary conversation. Let's see just what physics can do in Q3, eh?
(Kaleo, wouldn't it be easier to go to souce? Make a Half Life mod.)
-
i'd much enjoy even simple physics, as well as the ability to bust shit up (beat brushes and other objects into smaller objects). it'd make me move my current sekrit project back from Source to ioq3.
-
Speaking of busting up, any word on breakables in 1.2?
In fact, wasn't someone working on third-party implementation of breakables?
-
sshhhhh
-
Yeah, they are, it's going good, but a little slowly and they a--
*silenced*
-
Urban Terror has breakables. Same engine. They were fun to play with... Worm maps...
-
and again, JKA has breakables, fun stuff, they have a limit of only 255 'func_destructable' brushes/entities per map.
-
and again, JKA has breakables, fun stuff, they have a limit of only 255 'func_destructable' brushes/entities per map.
thats better then trem we currently have 0 :(
-
Darkplaces has TWIG (http://urre.quakedev.com/), which being in QC may be portable to IOQ3?
-
Possibly, some coders would prolly have to take a look into it.
And since I know someone is going to say this sometime soon, maybe a team should get together and make a mod that alows physics and see how well it works, ect...
-
QC is a completely different language from C. It's going to be pretty hard to port.
-
I meant that TWIG is part of the QVM, so it's a matter of porting QC for the DarkPlaces engine to QC for the IOQ3 engine.
-
No. DarkPlaces uses QC. IOQ3 doesn't use QC at all. It uses plain C, for both engine and qvm.
-
Who said trem didn't have physics? There are accelerators and collisions all around. It's simple physics but it's still physics. :)
Do you want more realistic physics? That's a shame because I liked circle-jumping and air-control. :(
Is it just ragdolls you want? Movable objects? Then why didn't you say so? :P
-
Who said trem didn't have physics? There are accelerators and collisions all around. It's simple physics but it's still physics. :)
Do you want more realistic physics? That's a shame because I liked circle-jumping and air-control. :(
Is it just ragdolls you want? Movable objects? Then why didn't you say so? :P
what air control? :P
-
i think like the physics that allow planes to fly
-
I don't think we're in Kansas anymore.
-
I don't think we're in Kansas anymore.
I don't think we ever were.
-
since cactusfrog fixed his spelling the joke no longer exists. Was playing on how he said plains.
-
what air control? :P
In case you think I mean controlling the air -> :P
In case you don't that know you can push yourself around in midair -> :o
And yes you can do this by taking advantage of aerodynamics in real life.. so long as you have wings for arms and are made out of foam.
-
You just need to eat beans. A lot of beans.
-
what air control? :P
In case you think I mean controlling the air -> :P
In case you don't that know you can push yourself around in midair -> :o
And yes you can do this by taking advantage of aerodynamics in real life.. so long as you have wings for arms and are made out of foam.
there is almost no air control in vq3 physics (compared to say q1, which lets you make turns with a radius of ~30u with relatively little speed loss (check out the buttons on level 1 of qdq))
-
there is almost no air control in vq3 physics
Almost being the operative word. :P
It's smaller, yes, but's it's still there and is definately noticable (such as when pouncing high with a dragoon). To remove that ability would make it harder to land on the exact right spot (like a moving human's head).
-
Nux ninja-editted. >:(
-
I'm not sure I understand exactly how this physics thing would improve Trem. I've noted some ideas, such as vehicles (elevators, cablecars) but I believe those are already possible; breakable stuff, which would be cool but not essential; stuff like having dead bodies retain shape and being able to block paths or climb over them, which is also cool but again not quite essential for playability.
So... can anybody give me some cold hard features that make physics absolutely must-have? I mean stuff that would tremendously improve the game of Trem instead of just the cool factor. (Which is not a small feat either, don't get me wrong, I'm all for more wow, just please make it clear what the goal is here.)
-
Nux ninja-editted. >:(
Prove it! xP
I'd also like to point out that if you're annoyed by dretches at your feet then imagine what adding super realistic physically interactive junk to your walkway would be like.
-
I'm not sure I understand exactly how this physics thing would improve Trem. I've noted some ideas, such as vehicles (elevators, cablecars) but I believe those are already possible; breakable stuff, which would be cool but not essential; stuff like having dead bodies retain shape and being able to block paths or climb over them, which is also cool but again not quite essential for playability.
So... can anybody give me some cold hard features that make physics absolutely must-have? I mean stuff that would tremendously improve the game of Trem instead of just the cool factor. (Which is not a small feat either, don't get me wrong, I'm all for more wow, just please make it clear what the goal is here.)
The possiblities it would add is almost an endless list so I'm not going to go into THAT much detail, butit would be things like this:
You have a bunch of barrels and boxes all over the map, placers would be able to kick them around into a wall if they wanted to and funnel or block the enemy from getting to them temporarly until the enemy gets rid of the boxes and barrels(or destroys them if breakable stuff is added)
Which adds another point, you can't really have a breakable box unless there are physics to make it fall apart :/
Physics will not really improve or hinder gameplay really, its going to be more of a feature that will just be really awesome to have, thats basically all there is to it.
Maybe it will do something I'm not thinking of that would be really awesome, like maybe you could make rope ladders that actually sway back and forth when using them, or rope bridges that do the same thing, or hanging lights, ect, just think about it.
-
In the Quake 3 engine all "objects" (like players, potenitally movable boxes etc.) are represented by AABBs (Axis Aligned Bounding Boxes), which makes it basically impossible to put a box in a 45 degree angle on the map. You can test this and build an armoury (doesn't look square) at an 45 degree angle, yet the box will still block players out of a perfectly square area aligned to the map walls.
Before you implement any kind of believable object motion/rotation, you will need a better collision model, and this in itself requires a lot of work (and will cost CPU cycles too).
-
Actually it should be relatively easy to add support for non-axis-aligned bounding boxes and allowing a non-square base. But this would require changes in the netcode and in the collision model on both client and server side.
-
ya thats a good point the source engin is build off of q3 then we could code an engine a lot better.
-
You are clueless. The Source engine is closed source, so it won't help us. And it's based on q1, not q3.
-
You are clueless. The Source engine is closed source, so it won't help us. And it's based on q1, not q3.
I think you'll find that the Source engine is based of idTech2. Gold Source, the HL1 engine, is based of idTech1.
-
source has nearly none of the original code anymore, anyway.
-
(http://i115.photobucket.com/albums/n288/Mr-Mxyzptlk_2006/hitmode7/hitmode7-crouch-sten.png)
WolfET, jaymod.
-
UrT Has pretty good hitboxes.
-
Darkplaces engine, again (this time with Nexuiz): http://www.youtube.com/watch?v=kT4T0baxiu8&feature=related (http://www.youtube.com/watch?v=kT4T0baxiu8&feature=related)
-
We need at least breakable objects. =]
-
Tremulous Engine with New Physics = LAG!
Workaround=Limit servers up to 6 Players.
Result= :-(
-
wolfET, also doesnt have lame unlagged.
-
wolfET, also doesnt have lame unlagged.
WolfET has unlagged by default. You just dont notice it.
-
Tremulous Engine with New Physics = LAG!
Workaround=Limit servers up to 6 Players.
Result= :-(
Most calculations can be prepared on local pc. Tremulous have many 'objects' in game right now and i heard not so many 'tremulous laggy!' opinions. So i really dont think that breakable objects can be SO laggy. What you only need - send ONCE to client small info that 'obj' broken. May be a bit more, but not so much. So i think you wrong with such opinion.
-
wolfET, also doesnt have lame unlagged.
you don't notice it because it's real unlagged, not broken 1.1 unlagged.
-
wolfET, also doesnt have lame unlagged.
you don't notice it because it's real unlagged, not broken 1.1 unlagged.
Also the principles of unlagged work better when the opposing sides use the same types of weapons.
-
wolfET, also doesnt have lame unlagged.
you don't notice it because it's real unlagged, not broken 1.1 unlagged.
As time goes by more and more in 1.1 seems horribly broken :-/
-
wolfET, also doesnt have lame unlagged.
you don't notice it because it's real unlagged, not broken 1.1 unlagged.
As time goes by more and more in 1.1 seems horribly broken :-/
But we still love it. I will be hard to adjust to 1.2
-
Besides the obvious fun it would be to have physics in tremulous, lag would be a monumental problem and would probably take all the fun out of it. If a server is laggy enough, you will be able to walk right into the middle of an object, wait about half a second, and the object will then and only then react accordingly. This leads to a very boring or unsatisfactory performance of physics.
I am, however, all for breakables. Breakables look really nice (adding to the reputation of the game) ,they add to the strategy of the game, and also they perform according to each person's computer. The fragments of whatever object that is broken should not be user-interactive but rather they should "explode" in a random sequence. The parts should fly randomly.
-
I think some people mixing "lag" and "low fps" together.
-
I think physics would creat too much >:(LAG >:( for Windows nubs
I use XP cuz I'm not allowed to change any "major" settings on my family's computer.
Tryin to get laptop
a new OS isnt that "major" is it... ;)
-
Getting a new OS will have pretty much zero affect on tremulous' performance. Don't sound so stupid, it hurts.
-
But we still love it. I will be hard to adjust to 1.2
When I moved from 1.1 to TremFusion I didn't experience any bad stuff, only good things and none of them shocking. Is 1.2 supposed to be very different from Fusion?
-
You just tried the client part of tremfusion. The big difference in 1.2 is going to be game-side, such as the famous gameplay changes as well as some updated models, weapon animations, etc. You can try out the game part of Tremfusion on the Tremfusion test server.
-
Besides the obvious fun it would be to have physics in tremulous, lag would be a monumental problem and would probably take all the fun out of it. If a server is laggy enough, you will be able to walk right into the middle of an object, wait about half a second, and the object will then and only then react accordingly. This leads to a very boring or unsatisfactory performance of physics.
The game engine already has to do collision detection anyway so that isn't a problem. And the collision detection is by far the largest part of the work, the code that causes the reaction to a collision is run only once when something is actually hit.
I am, however, all for breakables. Breakables look really nice (adding to the reputation of the game) ,they add to the strategy of the game, and also they perform according to each person's computer. The fragments of whatever object that is broken should not be user-interactive but rather they should "explode" in a random sequence. The parts should fly randomly.
Well, the game has some breakables, but they also have other functions (turrets, arms, etc.). When you add a few generic "buildables" (wall/box/stairs/whatever) which can only be placed by the map builder, then you have your breakables mod.
-
Q3 uses AABB's for collision detection, which are really fast. To get physics, then you would need more accurate BB's, and that's going to slow things down, a lot. Trem is already CPU bound, so IMO that's a bad idea.
Breakables is kinda pointless without awesome physics, but as has already been mentioned, trem already has gibs, so someone go code it already.
-
2 things to do that shouldn't take up any more CPU than is currently used:
1 - Remove the restriction that the base of a BB must be square.
2 - Remove the restriction that BBs must be axis-aligned.
Breakables are easy to do, as David said, just do like buildables (and it has been done).
Bone-based hitboxes (used only for hit detection, movement is still done with a normal BB) can be implemented separately from the collision detection engine in the game.
What I would really want to see though is to have enough physics to have a barrel fall over, roll on a slope and fly through the air.
-
Making the bottom of a box not square shouldn't be hard. Making them not axis-aligned, will slow things down a lot.
-
Getting a new OS will have pretty much zero affect on tremulous' performance. Don't sound so stupid, it hurts.
Unless you're switching to or from Vista on an older machine.
-
All that is needed is to mod the animated door entity so that it creates a one-way animation triggered by a shot/chomp.
Nobody want's to animate their own boxes and crates, so an easier method must be developed. What method does the grenade use? Could we just put box.visible = false and create randomly textured shards that bounce using te grenade's physics.
I can tell by the looks on your face that that isn't going to work.
How would we do it then?
-
Making them not axis-aligned, will slow things down a lot.
Map brushes can be non axis-aligned. Just do the same thing for entity BBs.
-
Making them not axis-aligned, will slow things down a lot.
Map brushes can be non axis-aligned. Just do the same thing for entity BBs.
Q3 can only do AABB vs BSP collision tests, not BSP vs BSP. Even if it wants to check entity-entity collisions one of the entities is converted to a temporary BSP (see CM_TempBoxModel) and then the common AABB vs BSP test is used.
(In fact I think that a specialized AABB vs AABB trace could speed up Tremulous quite a bit, because the number of entities is relatively high in Trem, but this would require a new syscall and qvm changes etc.)
-
Just to note: Maps are just a set of entities, that are staticly placed, so you *can* destroy them
-
Just to note: Maps are just a set of entities, that are staticly placed, so you *can* destroy them
Can haz BLOWN UP train?