I tried using scene3d camera but im so used to rendercam as of now that using anything but it is sorta awkward. Thing is, a fellow defolder told me not long ago that rendercam is not supported (confirmed to be true) AND is already outdated due to frustum culling. But isnt frustum culling a thing apart from the camera? In the sense that a camera library doesnt have to deal with it since you specify the bouding box of a mesh separetaly. IMHO rendercam is nowhere outdated or deprecated, but i have yet to make a full on project with it.
It just needs to be patched to work with frustum culling. Should be a small change!
rendercam is good as is mostly and very useful. But it’s not going to get official updates most likely. Someone else needs to fork it and update it.
Defold itself needs something like rendercam and orthographic all in one in the builtins folder! Good camera features are so crucial it’s maddening this still isn’t part of core Defold!
3 Likes
I’m totally up for the job to maintain it somehow! Problem is it probably will take some knowledge I don’t have like working with the frustum culling. Tho I’m totally up for the challenge, rendercam do be truly a great extension.
2 Likes
Depending on your definition, yes it is. However, I believe it still works just fine, I’m just not updating it. I pretty much kept up regular support for it from 2017 until the end of 2022, but I’m done with that now. I’m not using Defold for personal projects anymore, so I wouldn’t be testing and using it myself. The code is very old now and should be rewritten from scratch in my opinion (which I started multiple times). Much of the core of it is obsolete at this point.
The purpose of frustum culling is to only draw objects that are visible (to the camera), so yes, it is closely tied to the camera. It would only take a line or two in the render script to hook it up. You can look at Defold’s built-in render script for reference.
There are various limitations with Defold that made me not want to rewrite Rendercam. Mostly focused around object transforms and the core update loop, plus some editor stuff that limits how user-friendly one can make an extension. One or two possible new things have been opened up by new Defold features, like the new go.get_parent() and Jhonny adding multiple camera support a few weeks ago (woo, thanks! 
), but the other issues are either fundamental or low-priority (or both), so I don’t see them changing anytime soon.
10 Likes
Just out of curiosity, what issues are you thinking of specifically? The cameras not being updated in the stack was a bit shocking to find, none of us in the team knew the code worked that way previously so maybe some of your pet peeves can be addressed 
especially if it would help improve the camera system
6 Likes
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?) 
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? 
)
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. 
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… 
(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” 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.
- Now that the “revolutionary, brand new”
- 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.
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.
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
maybe the task to rewrite a new simpler module as you said be better than actually trying to rework things with rendercam. Be honest, a lot of things you talked in your post i couldnt fully understand, specifically the post update and physics engine stuff, but i agree that the camera component now is much more robust than it used to and that a simpler wrapper module over some specific quirks (like math and transformations) might be a good way to have it. I said i would go on the task to make a new camera module or rework/update rendercam to fit newer features (even forked it on my github), but ive been stuck in my personal projects. This weekend i will take a closer look at the camera component and tinker something out, but a new module that better fits what defold is nowadays is a good one i trully think…
1 Like
also the thing with the editor, i totally agree with that. I made 2 lighting libraries so far (none was good enough tho 
) and it always upsetted me that i couldnt see it working in the editor. Although the enum part isnt to mad to me, lua’s manual always encourage the programmer to use strings as “enums”, many other libraries do so like solar2d and love2d. Even lua itself when it comes to io and others uses plain strings. Tho i totally understand why that is not ideal.
1 Like
@jhonny.goransson Hmm, I just thought of another thing that may actually be the most pressing. The View and Projection matrix properties on the camera are currently read-only. Either there needs to be a function to update these (recursively updating the world transform of the object to get the View), or the user needs to be able to do that themselves, otherwise we’re back to the situation where these properties can’t be used and need to be completely duplicated by the user in a script (which brings up the need for a post-update callback all over again).
Somehow, you need to be able to move the camera or change its properties, and then immediately use it to do screen-to-world/world-to-screen transforms, within the same frame.
Yes, I believe so.
Well, the only way to get better is to dig in and try things out yourself, and keep trying to improve them (and reading the documentation in detail of course). 
4 Likes