Is rendercam outdated/deprecated?

Questions
6

Oh yes, only the “top” camera was active. Wasn’t that in the manuals?

Did you know that the different types of mouse/screen coordinates are all wrong…in different ways? (and possibly different between platforms?) :sweat_smile:

I’m sure there are plenty of shocking issues that are 5+ years old, many may not even be reported (but that’s true of any software, isn’t it? :laughing:)

I think I have a list around here somewhere, hang on…

OK, this was my list, but after a few hours of digging through release notes, a few of these are pretty much solved now:

  • The easiest way to do camera shake is with a child object, but this can’t be done with an extension in a user-friendly way, since you can’t put a collection on a game object in the editor.
  • There’s no late_update/post_update callback after physics, so it’s impossible to update a custom camera matrix correctly (without a native extension or the raycast-every-frame workaround).
    • Side note - the camera component works—it sends an updated matrix to the render script—but you can’t use more than one at once and can’t change their properties, so it’s useless.
  • You can’t add user-friendly game.project settings - all custom ones show up as text input boxes, regardless of value type.
  • No enum script properties—no multiple-choice properties in editor.
  • Can’t update world transforms during a frame - camera transforms will always lag.
  • Mouse coordinates are all wrong in different ways, making it a nuisance to convert between them (which one is right anyway?)

Also, I feel old now. :older_man: :laughing: I was thinking: “go.get_parent is a revolutionary new addition! They refused that feature request multiple times before!”…it was added three years ago… :man_facepalming: :laughing: (It was originally deliberately not included or added since it could enable costly operations, and there was a “we need to protect you from yourself” mentality at the time.)

Looking over all the improvements that have been made to the camera component over the last year, things have changed a lot, and it confirms my view that Rendercam is outdated. Most of its purpose was to be a workaround to reproduce what the camera component now does.

A year ago, the built-in camera component was still almost completely pointless. You couldn’t change its properties, you had to understand the math to get its transforms, and you couldn’t use more than one at once, it really did almost nothing for you. Now that has changed.

Now, the camera component can be used and a relatively simple library module could be written to help handle the window size adaptation and the coordinate conversion stuff that Rendercam did (I’m not aware that anyone else has reproduced this since Rendercam?).

A few things that could be pretty easy to fix:

  • It seems like we are still missing a vmath function to create a matrix from position, rotation, and scale (with optional args). Of course you could just construct it yourself, but I doubt many people want to look up and decipher the math for that. And it’s quite surprising all the matrix functions that do exist (look_at, axis_angle, from_quat, rotation_x, rotation_y, rotation_z, translation), but the one function that would be more obvious is missing.

  • We need some better documentation for what “Auto Aspect Ratio” does. “Set this to let the camera automatically calculate the aspect ratio.” doesn’t explain anything.

A bit harder:

  • Not entirely camera-related (anymore), but I believe it’s still impossible or at least a nuisance to update things that are moved by the physics engine, since physics are updated after scripts. It’s been a recurring issue since the beginning. Actually, this might be even more problematic now that a separate fixed_update exists…or less?
    • Now that the “revolutionary, brand new” :laughing: go.get_parent function is here, it should be possible to recursively walk up the tree and get an up-to-date world transform for any object if you need to (yay!), though you would still need to be able to run code at the right point in the update cycle for this to be fully useful.
  • The mouse coordinates being wrong. There was some justification about gui.pick_node needing slightly offset coordinates, but if that’s the case, then they should be offset inside that function rather than messing up the low-level input coordinates.

And then there’s the big impossible (but all the more should be fixed) issue and the low-priority editor/extension UX issues:

  • Should be able to add a collection as a game object’s child. A fundamental poor choice from the original creators of Defold I think. Imagine if, with Unity, you couldn’t make a prefab the child of another prefab? Imagine if, with Godot, the root node of one scene arbitrarily couldn’t be the child of another node. That’s Defold. :expressionless: The game-object tree supports any configuration, only the editor and collection system don’t. When people say vague things like “Defold is too limiting/inflexible”, here’s a prime example. An arbitrary and wide-reaching limitation.

  • No enum script properties. :frowning: It seems like this one shouldn’t be too hard, and it would add a ton of usability and flexibility for extensions and programmings working with artists and designers.

  • Very minimal editor support for custom game.project properties. I think most libraries would have project-wide config settings (at build time) if they could. It would be great to be able to get type-appropriate widgets for these in the editor, and also default values and tooltips. Also, if libraries could have their own category and properties show up automatically somehow, that would be perfect.

12 Likes