6
lorentz
2d

I did a little bit of finger practice in Unity, nothing fancy just two spheres and a capsule-guy under Newtonian gravity and a force-driven player control script that works on spheres.

I will never understand how C# libraries spontaneously decide that some operations will be nonvirtual methods while others will be static methods. It is the exact same thing! You're just ruining intellisense for no conceivable reason!

Also, transform has a right but no left, the float return value of Vector3.SignedAngle is not the same unit as Transform.Rotate(Vector3, float), Transform has LookAt(Vector3 position) but not Look(Vector3 direction), to do that you need to

transform.rotation = Quaternion.LookRotation(Vector3.ProjectOnPlane(transform.up, direction).normalized(), direction)

you can't discover whether a collision encountered sticky or dynamic friction, you need to infer that by calling RigidBody.GetPointVelocity on both RB-s at the collision point, which has its own quirks. Apparently this is to keep the API engine agnostic, but any serious project will have its own physics materials which already specify the sticky friction coefficient. A simulation that works correctly with physics materials but doesn't discover the kind of friction as an intermediate result is not possible.

RigidBody's velocity isn't displayed in the GUI, so you can't give it an initial value without a dedicated script. I have a script on this fucking moon that does nothing but add a force in Start.

Is it just me or does Unity feel cheap somehow? Like a hastily written library for a research project that was never rounded out with the obvious features. I understand that it's a free product that catalyzed the golden age of indie game development, but I think it's seriously struggling to keep up, not with the showy investor bait stuff, but with the standard of comfort modern tooling provides.

Comments
  • 4
    I used to do motion tracking. The team I worked with was one of the smartest group I've ever worked with. One of the first bugs I found was a mistake they'd made converting between different coordinate systems. It wasn't a big thing and they made the same mistake somewhere else and it all balanced out. But as soon as I did extra stuff in between it all broke. And working it out/explaining it melted my brain, as well as theirs. Coordinate systems are hard. I added a load of unit tests (they were hardware people used to manual tests), and there were loads of simple little edge cases. We used FFTs and it's cyclical so 32 points in one direction was equivalent to 32 points in the other direction but they'd just said it was 32 points one way and 31 the other which is barely noticeable in most cases except for exactly what I was working on.
  • 5
    I think Unity is probably in the "good enough" stage. If people can ship products and make money its enough to get the job done.

    I remember years ago ID Software released Doom and Quake source code. Then the company who made Descent released their code. The Descent devs indicated that they wanted to show that good commercial code isn't always pretty. So I kinda assume lots of other software products are this way.
  • 1
    uhm.. "nonvirtual"? if by that you mean "lacking the virtual keyword", then it's just a method that's not supposed to be overriden in derived classes.

    which is VERY different from a static method.

    did you get your terminology mixed up?
  • 0
    @tosensei A nonvirtual method is a method that isn't marked virtual, abstract or override, and isn't implementing an interface, so it never appears in a vtable and never participates in dynamic dispatch. I borrowed the term from C++ where it makes sense to name these because they are isomorphic to a loose function with the first argument equated to "this", and as such can be safely cast to function pointer.
  • 0
    I'm pretty sure C# generates some glue to ensure that any method can be cast to predicate, but it makes sense to distinguish nonvirtual methods exactly because they are always convertible to static methods without removing previously valid use cases, since their only use case is to call them on a value of statically known type.
  • 0
    @lorentz technically, you can convert _any_ instance method to a static method with an object as parameter. if you prefix the parameter with "this", you even got an extension method, which _looks_ like an instance method (some syntactic sugar).

    does not change the fact that a non-virtual method, as you described, still is an instance-method, and not a static method.
  • 0
    @tosensei well no, if a method participates in dynamic dispatch then that means that the implementation can be modified by derived classes, so converting it to a static method without loss of functionality involves reimplementing a vtable.
  • 0
    @tosensei Extension methods are the perfect example; they read like an instance method, but there's no corresponding vtable entry in the original class so they can't implement interfaces and can't be overridden. The things you can do with an extension method are the same things you can do with a static method, because they're pure syntax sugar over a static method. For instance methods the same category is nonvirtual, which isn't explicit, you just have to not opt into any of the features that require virtual calls.
  • 0
    If you know what "virtual" means, then you shouldn't use unity in the first place 😂
  • 0
    @blindXfish it's what newbies use, so it's what you use if you want to deal with newbies.
  • 0
    @blindXfish but I also appreciate that everything, however simple or complex, has meaningful docs. Obvious is subjective.
Add Comment