Jump to content

Tuareg

Members
  • Posts

    370
  • Joined

  • Last visited

Posts posted by Tuareg

  1. You seem to be under a misconception, that your opinion of "best" and "worst" is fact.

    I prefer what I've seen of the scanning to Scansat. I prefer what I've seen of aerodynamics to FAR. I prefer what I've seen of re-entry and heat to DRE. I feel no need to mod these in. This makes it better than modding.

    For ME.

    Squad did not fail. They implemented a system that some people will like and some people won't. For those that like it, great. For those that don't, Squad thought ahead and left everything as open to modding as can be reasonably expected (and then some).

    5th is the ?paid? defender of the crown. first, he didnt say those are global facts, he dont even mention anything like that. he said "I'll", not "everybody will" so you seem to be under a misconception. also when nobody really likes it but you (this topic is 3 pages of complaints telling ppl accept it but dont like it), then you count as a minority and so your preference is the preference of the minority and other than you nobody cares. get yourself together before you go out to attack others. what squad does is covering up their inability with saying: but we made it moddable. all that is done by modders could be implemented with ease, the logics are there, even codes are there, they simply dont want to invest time and work. i've told right after the announcement how much they will fail and what they did is exactly as i've predicted it, just like in the case of science.

  2. I'm sure you believe that, but I'm also more than sure that there are those whose performance would be so impacted as to make it unplayable, because it's not something as simple as a slowly moving skybox...

    quite bad to be so sure of something you dont know about. games from the very beginning of 3d programming had clouds and didnt become unplayable on my 233 cyrix CPU and the TNT2 graphics card. all just depends on the implementation and clouds are not something could kill a 2x86 :)

  3. oh, the half informations again...

    lets start. FPUs had 80 bit precision to use it for INTERNAL calculations only, there was no processor or motherboard level support to FEED it.

    SSE had 128bit register which was able to work with 4 piece of SINGLE PRECISION NUMBERS IN PARALLEL doing the SAME operation on the 4 singles. NO HARDWARE SUPPORT for double precision.

    with SSE2 aka Athlon 64 came the hardware level support for double precision calculations. what it means:

    a single float in the memory looks like "1 bit minus sign""6 bit dot position" "the number"... with a 32bit register pushing it to the FPU means a simple step and the FPU can use it for calculations straight away

    a double float (or just double) looks like the same but the "dot position" is (i think) 8 bit and "the number" bit is far bigger. when you read it from the memory it already takes double the time to read it into the 32bit general registers but the problem comes when you push out the 2x 32bit data to the 32 bit arithmetic pipeline to build a freakin double from it... inside the FPU it takes actually a 32bit bitwise left (<<) and an other 32bit addition BEFORE the FPU can even start working with it. Yes, it supported double but it COULDNT RECEIVE the double. and when it has finished the calculations it had to cut the output into 2x 32 bit data and send it back and then took twice the steps (or even more) to write it back to the memory from the cpu registers.

    while with the appearance of the 64bit processors came the 64 bit arithmetic pipeline and the native 64bit registers so you can move and work with doubles everywhere with only 1 steps. its not twice faster just because it became 64bit, it became far far far quicker to work with 64bit floating point numbers

    Graphics cards can use single precision (well, actually nvidia cg has native support for doubles but just because it uses worldspace coordinates) because they are calculating only within a (-1) - (1) (called eye or clip coordinates /generally representing the space between the corners of the screen with a depth added/) sized standardized coordinate system which receives the coordinates from the DX or GL (so the single/double precision worldspace calcualtions are done on cpu level, thats why SSE2 was that big step in 3d graphics because it became able to actually use doubles on hardware level)... sad that most (yes, sadly unity developers too) dont get that they would have to separate the physics (in most cases its more than enough to have there singles, though bullet physics uses doubles) the hardware level graphics (like cg, hlsl) and their own internal coordinate system which actually could easily support doubles (cry engine actually works on it with RSI and i think i read somewhere that the new UR engine has an intelligent switch between the required precision) and they could actually use those doubles on DX and GL level too, and even (i dont know about amd graphics but im absolutely sure about nvidia) on low level cg programming. its just their laziness that stops them to do it

  4. I'd be fine with reducing them to 10% of current power and reducing RCS prices. The rest of it is just out of academic interest in how it works in real life.

    (Actually my KSP tests seem to imply that it doesn't matter where it's placed right now)

    there would be a simple way to make them somewhat realistic but in my guess it would be too much for squad based on how sas still works :)

    RW-s can have 2 effects, a weaker force what can only balance the craft in a stable state (but it actually works against controls too) and should be far weaker than the current effect (works like gyro) and one which is the same as current RW-s aka can make the craft rotate, can stop rotation and can keep balanced bigger crafts on the expense of rcs OR extra electricity /there are magnetic ways to desaturate RWs/. the programmatic problem with this is that squad would have to define a giro limit, continuously watch for the torques growing bigger than that and apply the rcs/electricity use based on that.

    (this is the system iss is using)

    it would make so you can balance a well built craft with very little to no expenses (with generally a continuously rolling gyro) while rotating a heavy craft or balancing a very off craft would cost a lot more (spinning up/down and desaturating the RW). i dont know for casuals how much would it be too complex

    but i think simply nerf them to 10% is not the solution

  5. If the objects have the same polar moment of inertia (i.e. same mass and mass distribution, to oversimplify) they will have the same angular momentum at the same angular velocity. The distinction matters because momentum is conserved but velocity is not.

    "The polar moment of inertia must not be confused with the moment of inertia, which characterizes an object's angular acceleration due to a torque." i start to feel uncomfortable.

    ugh, i just asked my gf about the situation (note she is a beautician) and though i had to explain some things she knew the answer. i think its time to quit for me now and let you keep thinking... but instead of high level principles try to apply common sense. and this time dont take it as personal attack, i said it seriously.

  6. And you, sir, are prime example of why 64bit windows are slow moving form "major pain in the ass" to "slight nuissance", never mind being actually useful. Even if your app has zero advantage in running 64bit (and actually slight penalty that comes with it), your users will have significant advantage of running native. Don't you find it strange that linux port of Unity, while getting much less attention then windows one, is just fine? Is linux Unity somehow magic? Let's see… On my linux box, 100% of installed packages is 64bit. And all of them work just fine. On win7 box, about half of system is 32bit, and anything 64bit exhibits all colours of trouble (still great compared to 64bit XP though). Doesn't look to me like it's just "some more virtual memory space". 32bit emulation need some complicated and error prone machinery, and geting rid of it is advatage for your users even if app itself does not change one bit.

    once this^^, on the other hand 64bit wouldn't just give 64bit memory addresses but native 64bit floating-point calculations and the entire spacegameprecision shakingfallingapart etc problem is because of precision. ksp already use a 3rd party 64bit lib but only for a couple of calculations and they are slow on 32bit. using all double precision calculations on native 64bit support would make the game having less precision issues running still smoother.

  7. Please share some of the calculations you refer to. Not a wiki page, a simple worked example for us. Show that, mathematically, a wheel spun up at the CoM of a larger object adds a differing amount of angular momentum than the same wheel spun up to the same speed some distance from the CoM.

    there is no simple calculation to it, it needs inertia matrix and integral calculations. as i've said its far more complex than what you think and there is an entire science dedicated to it. you would need to read about parallel axis theorem... (i didn't link its wiki page :) )

  8. You've just contradicted yourself, unless I'm misunderstanding you. First you say that a freefalling object will rotate about it's CoM, but then you say that the rotation centre is not the CoM but where you apply the torque?

    In which case, why do both of your cross shaped example craft rotate about their centres? For the first craft (reaction wheel in the centre) it should, but for the second one (reaction wheel at the end of one 'arm' of the cross) it should not - if what you've just said is correct. You are applying the torque at the end of one arm, therefore it should rotate about that arm.

    omg... i've explained it already a couple of times, the rotation center is not where it seems to rotate but where you rotate it aka where you apply the force/torque. there is no any contradiction. we don't use visualization in physical calculations.

    the 2 craft rotates around the same center because the objects have their kinetic energy, and that is balancing out the rotation forces of the second craft and thats why it rotates slower because those energies are taken from the torque...

  9. I don't understand this, it seems contradictory. It will rotate around its CoM but the rotation center is the location of the reaction wheel. How can it be both?

    The basic principle of physics is that we use for every calculations about forces the point where the forces are applied. every differentiation has to be calculated with derived forces applied on an arm equal with the distance. there is no such thing that you apply a torque at point A and you make calculations with the same torque at point B.

  10. Tuareg, surely you can explain your points without being condescending or dismissive about it. Phrases like "just read the sentences together with some common sense" or "not complicated... " add nothing to the conversation.

    I was attempting to differentiate between the wheel itself and the larger object to which the wheel is attached. So, why would the larger object to which it is attached rotate around a different axis depending on wheel placement (let's assume a simple vessel with one wheel at CoM and another at an extremity)?

    i might dont get your question...

    when you apply a torque, though a freefalling object will rotate around its com (its just because its kinetic energy balances its movement out) the rotation center is not the com but where you apply the torque

  11. Actually I strongly suspect in this situation, the 'missing' inertia does something weird like move the CoM or is dissipated as heat as the offset mounted RW flexes the craft. :P

    if you go back a couple of posts this is exactly what i wrote :) if you would apply torque to a mass-less object at the end of it it wouldn't rotate around its com but around the axis the torque applied. the object doesn't just change this behavior with having mass just cos why not or because "all our empirical observations". it has a reason, there is a force compensate for that change and that's where the missing torque is going

    - - - Updated - - -

    What is not clear to me is why the larger object would rotate around a different axis. Can you elaborate?

    what? we are talking about the SAME object rotating around different axes

  12. snip

    nicely ignored the second part of what i wrote. try to forget your formulas, just read the sentences together with some common sense:

    "Moment of inertia is the mass property of a rigid body that determines the torque needed for a desired angular acceleration about an axis of rotation."

    "Notice that rotation about different axes of the same body yield different moments of inertia."

    it means: rotating an object around different axes need more torque to reach the same angular velocity.

    not complicated...

  13. Just so I can get things straight in my head... (thinking of it as torque gets somewhat confusing)

    Units of angular momentum are: kg * m2 / s

    Rate of change of angular momentum is the derivative wrt time: kg * m2 / s2

    SI units for kg are: N * s2 / m

    Substituted: N * s2 * m2 * m-1 * s-2

    Simplifying: N * s(2 - 2) * m(2 - 1)

    Finally: N * m => Torque

    Rate of change of angular momentum of an object == torque applied to that object

    By conservation of angular momentum, the apparent torque on the parent body should not depend on the location in which the angular momentum is being stored or released

    That is exactly my question...

    - - - Updated - - -

    Can be defined at a lower level if required... (ie. here be two force vectors acting upon an object of mass m...)

    you really think physics is that simple you can just say "Rate of change of angular momentum of an object == torque applied to that object"?

    huhhh. its far more complex. im long years ago out of this kind of math, i've learnt these things about 20 years ago, but still, it's a shame to read something like this.

    "Moment of inertia is the mass property of a rigid body that determines the torque needed for a desired angular acceleration about an axis of rotation."

    "Notice that rotation about different axes of the same body yield different moments of inertia."

    at least read wiki pls.

    - - - Updated - - -

    You're applying a torque to change the angular momentum stored within the reaction wheel (motor torque driving the shaft). That torque itself doesn't effect the main body, the local change in angular momentum it produces does. Try to not think of it as forces and arms/levers :P

    thats entirely wrong, all the rules we are talking about are derived from simple forces and arms

  14. the problem is that you all take the laws like given things. it doesnt happen like that because it must, it has a reason behind. the law is there to be used on higher level without the need of deducing the entire low level problem again and again. saying it rotates around its com because it must is like saying there is a god because why not... :)

    The angular momentum of a closed system must remain 0. I can't see how, if the two 1-mass cubes have the same "spin" inside them in Unity (I'm assuming this is an abstraction), the two 5-mass conglomerations of 5 cubes can't also have the same spin.

    Are those sets of cubes nailed down? Or is the 1-mass spinning cube actually 1 mass unit and then you added a 1 mass unit spinny ball inside it, making it actually 2 mass units?

    Something is wrong with the simulation, I think. I'm no physicist and I'm not saying you're trying to trick us, but this seems impossible to me. I'd be much more comfortable with a real world test, though I'm having trouble coming up with one. The closest I can come up with is a free spinning wheel (like a bicycle tire) with something motorized attached to it, and a counterweight exactly equal to the motorized attachment so you can keep the mass of the system equal and the center of mass on the axle. Move the motorized part (and its counterweight) back and forth on a spoke of the wheel and record the rpm of the wheel as it's spinning up. Do it 3-5 times each way and compare the data.

    [/always preferred experiments to deduction]

    there is no mistake or cheat, not nailed down they are 2 copied "crafts" just the cubes are in different order. no other objects at all and it is right as it is, it SHOULD work like this. the law say only it will rotate around its com, not that it will rotate with the same speed...

  15. I see the effect, but I don't get why it's different.

    well, it will not be a scientific explanation just some common sense.

    explanation 1: when you apply torque off center (if are taking granted that the free-falling object will rotate around its com) the effect rotates the object is not the torque but the force created by the torque on an arm (im sure its not the perfect word but blame my English, sry :) )

    explanation 2: when you rotate something at its com, the centripetal forces are equal, they don't do work so they use no energy (i guess i don't have to explain the diff between force, work and energy), when you rotate around an off center axis, the centripetal forces are off and they make the object move along a spiral path (this is not modeled in unity, or at least i've never built anything big enough to make the effect visible). if you would stop applying torque after a quarter round the object would fly away. if you keep rotating and there would be no centripetal forces (mass-less object) the craft or object would rotate around the axis the torque is applied. now put the 2 effects together and you will see that when centripetal forces equal out that movement they do work and so use energy. but energy is not created or lost, that energy comes from the torque. (in reality a free falling object rotated off center does rotate perfectly around its com only when you stop applying the torque and its rotating free, until that its center moves on a tiny elliptical spiral based on the starting resultant force. im not sure if im clear.)

  16. Perhaps I misunderstand what you're trying to say. It seems to me that the angular momentum accumulated by the reaction wheel must be exactly offset by angular momentum of the craft, because of the conservation of angular momentum. Given that the wheel spun up to a defined RPM has a fixed angular momentum, how can the rotation applied to the craft be different if it's in a different spot?

    instead of trying to make a physics study i made a simulation in unity. 2 "crafts" behind each, each has 5 standard cube object with weight 1. the craft in front has the torque applied to the central (black) cube, the craft behind has the same torque applied on the last cube... watch them rotating. if you dont get it, watch it again :)

    (its still uploading, but i have to leave)

  17. Real life reaction wheels don't work any better at CoM, the torque they impart is the same regardless of location. KSP RWs apply their force at their location, build a flexy ship with wheels at the ends and you can see the effect clearly. And RCS does work best away from the CoM, due to leverage (it applies a force rather than a torque).

    lol. physics. The moment of inertial is minimum around an axis that passes through the CoM, so it's "harder" to get the object to rotate around an off-CoM axis. also, if there isnt a fixed axis (the center of rotation isnt pinned to an infinitely heavy object) the object u wanna rotate off-centre will move away on a spiral trajectory as the centripetal forces are off-centre too, aka its far better to place the RW into CM. its an other question that KSP (and unity) doesnt calculate these forces fight.

×
×
  • Create New...