![[de]](/mwf/flags/de.png "Germany")
Here are a few idea I've had in mind for quite a while concerning object physics:- Limit the maximum speed of Objects. If a Object is faster, it decelerates to it's maximum which is calculated via mass
- Set the maximum limit depending to background type, e.g. Objects in Water (Stone) don't fall done, they are way slower then in free fall
- OnHit: Objects maybe could shake free a bit of earth, if the have reached a certain speed?
![[ca]](/mwf/flags/ca.png "Canada")
>If a Object is faster, it decelerates to it's maximum which is calculated via mass
I think terminal velocity would be much better defined by some 'drag' variable. One of the first things you'll learn in physics it that mass is not related to gravitational acceleration (though I believe it does affect momentum).
>Objects in Water (Stone) don't fall done, they are way slower then in free fall
This could also be defined by a drag variable.
>OnHit
There is already the Hit() callback, but you'd have to write a script for displacing terrain.
I'd like to say these are some nice ideas which really could have a beneficial impact on the game. :)
Exactly. Implementing engine support for simple drag is almost trivial - PXS (rain etc.) have this already. I think the only reason CR didn't have this was that nobody wanted to go over every object and figure out a suitable value.
![[ua]](/mwf/flags/ua.png "Ukraine")
I can tell that I like these ideas but I see a huge con - implementation difficulties. Does it really worth it? P.S. The only thing that made me complain is that I could not explode the "firestone" lying on the ground with a shot from a musket
![[pl]](/mwf/flags/pl.png "Poland")
Which brings us to another thing I tought of once. To be specific - that each object would have a 2d collision 'mesh', that is calculated into terrain collision map for collision checks. On other hand it would require some algorythm to make objects not self-collide. But that could be usefull for defining hitboxes for many objects, eventually clonks as well. Maybe we could use these for marking entrances as well. This way we would have few areas, that can not only be rectangular/anchor based as they are now, but:
Hitboxes - for checking collisions, two types of these - projecticle-only hitboxes and "fully material" ones.
Entrances - two types as well - one for clonks/etc. and second for objects flying in(like lorry)
Other - that for example execute script when something is inside, etc. could save up much work sometimes.
Hitboxes - for checking collisions, two types of these - projecticle-only hitboxes and "fully material" ones.
Entrances - two types as well - one for clonks/etc. and second for objects flying in(like lorry)
Other - that for example execute script when something is inside, etc. could save up much work sometimes.
There not really big - every tick already now the gravitational YDir is added. It shouldn't be hard to set a maximum speed and accelerate or decelerate there - and that maximum speed can already change if GBackLiquid().More or less the same applies to Objects - Hit() is already called b the engine, the same time when the engine decelerates the X/YDir - in this moment other actions can be possible.
That's just strange, you make it sound so easy... a balloon falling just as fast as a rock(@ maximum speed)? Or what do you even want to do in the engine?
In an environment without air we would actually have a balloon falling as fast as a rock. But we have to consider the air resistance and (in case of balloon) ejection force. Though I do not think that we should complicate ingame physics THAT much
> In an environment without air we would actually have a balloon falling as fast as a rock.
I am not stupid, you know? I am just saying that we either do it right, that means the whole concept: drag coefficients, object areas, which someone is going to solve for us in the 2D case (analytically prefered). Or we don't do it, cause this is not easy to implement.
> I am not stupid, you know?
Yes, I know. Sorry if my words looked like a doubt about your intelligence - I didn't mean it. Really.
> we either do it right ... Or we don't do it
My point is we should not. But if B_E thinks it is not that hard to implement we should consider his point as well.
He already stated this. The mass actually does not affect anything. At least not untill all those things Maikel mentioned are implemented
Of course - but why are those things so important if one can manage a kind of realistic way with the mass? You don't need Vectors, drag coefficients or anything else - why make things more complicated?
I do not know, really. If it happened for me to implement ingame physics I would do it another way. we have a lot of forces that affect the object:1) gravitational force;
2) friction force (air/water resistance included);
3) support reation force if object is lying on the ground;
4) liquid ejection force if object is emerged in water/lava/acid;
5) elasticihty force if object is hanging on a rope;
6) impact force if object was thrown/kicked/shot;
7) rotational force if we put it THAT far...
And a whole bunch of other forces.
So if I was implementing ingame physics I would consider all these forces in resulting acceleration calculation (and yeah, it can not be done without vectors, because every force has a direction aside from value). So maybe it is good that I do not actually implement anything.
Do not get me wrong: I like the ideas you've posted at the beginning of the topic. But I do not think that their implementation worth the efforts I've stated above (in that question I totally agree with Maikel). If you want to impelement it simple way (like you already said), I am not going to stop or criticise you (not a chance). And I am definitely not the person who should share his thoughts concerning the ingame physics. (In fact I think that it was completely wrong for me to write anything in this thread in the first place). Sorry.
Let me just give an example, not a complete derivation.
Let's consider a lorry and a balloon, both of equal mass, 250 kg. You'd want the balloon to accelerate slower than the lorry, that is: you want more drag for the balloon, so you'd need more parameters than just a mass, at least something like an area. And that is just the simple case. If you want it somewhat realistic, you'd have to introduce at least 2 parameters per object, which describe the drag of the object in the x and the y direction. There are just so many objects with equal mass, but which should behave differently under air friction.
Let's consider a lorry and a balloon, both of equal mass, 250 kg. You'd want the balloon to accelerate slower than the lorry, that is: you want more drag for the balloon, so you'd need more parameters than just a mass, at least something like an area. And that is just the simple case. If you want it somewhat realistic, you'd have to introduce at least 2 parameters per object, which describe the drag of the object in the x and the y direction. There are just so many objects with equal mass, but which should behave differently under air friction.
![[us]](/mwf/flags/us.png "United States")
I am just talking about free falling objects - at the moment they can gain any velocity the like - this should at least be limited by the objects mass. In this case everything concerning the balloon would be handled - like it is at the moment - via Float-procedure. The lorry counts as a normal object and should therefore not be able to reach the high speeds objects can reach, which fall into the game frome above the screen.
Do you think parachutes work because they are so light? Also: http://forum.openclonk.org/topic_show.pl?pid=7260#pid7260To say it clearly: Mass doesn't play any role in how fast an object accelerates towards the earth.
Yes. I do know that - I just thought it was the most simple way to implement it.
How? :S Would greater mass/lesser mass create more drag? That doesn't make sense.
I didn't say that, I just meant that it would be the simplest way to implement.Anyway, a maximum speed could depend on the material, rather than the object.
![[fi]](/mwf/flags/fi.png "Finland")
Dude, what happened to g=9,81 m/s^2 ? Even though I fail miserably at physics...
Dude, what happened to F = 1/2 *c * v^2 *a? a is a constant, v is a constant, the only think, you can change is c, which is the air resistance factor.
Like I stated before: I am aware of physical laws, I just derived the fact that the simplest implementation would be without concerning all factors.
I personally am against concept of doing everything via scripts - sure. It's way more flexible, but in the end it just slows the whole thing down...
By the way, an AirDrag value as a property imo completely makes sense - at least for balloons, airships. It's not that hard to implement and actually is already implemented for material pxs (snow falls slower than rain). Also it makes sense to apply a drag to falling objects when underwater (GBackSemiSolid)- if it implies performance issues if the background is checked for any object any frame is something that can be tested.So, I'd say go for it.
I'd say have a drag value per object and a drag value per material. The total drag is then calculated from the two.On that note, we might actually give some materials like sand a non-infinite drag value. Objects that impact sand very fast could move into it a few pixels and cause a splash (just like water does now).
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
