Aah, sorry, I thought it was your opinion about Lumiere, but now I see you were actually quoting @britzl 
1 Like
Cool, thanks for the input, guys! Now I am still 90% undecided! 
I might keep the checkboxes and add another text field for custom modes/override.
Yeah, that would be really nice! I briefly searched around in the source regarding that. It looks like there’s code for script properties scattered all over the place though, so it might be a pain. It would be an awesome feature though.
1 Like
I notice that the render colours are not kept with Rendercam, or maybe I’m doing something wrong?
These settings flash the screen white for one frame (presumably when Rendercam is not active), then the screen turns black:
1 Like
I think you need to check the render script for RenderCam and figure out what colour it uses when calling render.clear().
The game project settings are used immediately on application startup.
2 Likes
Yeap, thanks. aglitchman actually fixed this a while ago but I never updated the release.
This should do it:
6 Likes
New users need to know about Rendercam. If you’re new to Defold try downloading the example project of Rendercam to see how it works and why it is useful.
https://github.com/rgrams/rendercam/archive/master.zip
Download the zip, extract it, open the game.project in the folder with Defold.
This year will probably be the year of many new big 3D projects happening with Defold so projects like Rendercam are more important than ever!
With a boom for webgames on the horizon, 3D webgames in particular will be a very big opportunity for developers. Defold’s HTML5 target is excellent, it is very close to being the very best 3D tool for high performance 3D webgames, and there is a very good chance the missing gaps toward becoming the very best tool for 3D webgames will be filled in this year. 
10 Likes
Thanks @Pkeod, you’ve always been the most enthusiastic supporter!
I’ve been thinking, off and on for a long time, about what I should do with Rendercam. Possibly I should release some sort of disclaimer. Yes, it works. But I’m not actively improving it. I’ve been very occasionally updating it so it remains usable and merging some PRs, but that’s about it. At this point it’s very old and somewhat amateurish code. It’s a bit bloated and doesn’t lend itself well to customization. There are some new engine features that could be incorporated to fix some of the weird workarounds. Some of the unreleased branches have more up-to-date features.
I did spend a lot of time last year working on a rewrite, but engine limitations kept preventing me from making Rendercam what I want it to be. I’m no longer using Defold for my own projects, so working on Rendercam is not an active, personal concern.
Anyway, I’m still undecided. I don’t have a ton of time for it, and I’m only motivated to work on things that I believe will meet my own, personal ideas of “quality”.
- Officially retire Rendercam?
- Continue letting it get older and older but still usable?
- Pass it on to someone else?
- Get over myself and improve it as best I can within the engine limits? (unlikely)
I think most people use Orthographic or their own code for 2D projects, so I could retire Rendercam but write a minimal 3D-only camera helper to fill the gap?
7 Likes
I’d of course say don’t give up! Yet you have to do what’s in your own personal interest and interests. If you don’t have the desire or heart to continue the project officially declaring there will be no more updates / officially passing it on to the community would be for the best. There are some features in Rendercam in particular related to interaction which are crucial for several kinds of games. Your contributions will always be acknowledged.
Could you list the main current ones that concern and limited your work?
What I see necessary is an evolution of Rendercam that grows further in scope with more features and more consideration for all of the kinds of modern rendering situations, since the camera code and rendering code is so closely related. A radical evolution needs to be all in one and opinionated. Much of this will require more progress with Defold itself too.
Many things in one
- camera types for rendering
- camera types for movement (for example, once we have mesh collision add helpers related to world mesh camera interaction - it needs to be part of a big package and be accessible)
- rendering situations (ex support splitscreen ez, picture in picture multi cameras, support render to texture ez (we need a way to render 3d characters models that can be used in UI like Dota2/any 3D RTS portraits))
- post processing situations, a more simplified render target pipeline
- common and necessary stock materials well made and optimized by people who know what they are doing, not by people who are not experts just trying to get shaders to work
- beyond the basics of stock materials a simplified way of using PBR materials and rendering PBR
Lots of work requiring skilled people willing to help. I’m optimistic! We are at a turning point and even without any changes toward what is necessary games will still continue to be made which use what already exists and they will draw many more people toward Defold in a compounding effect.
Something engines like Unreal or Unity have is a way of efficiently building materials / fp/vp programs stripping them down to what’s actually used, maybe some kind of similar tool could be made to make it easier for people to build their own shaders for common situations, can be an external tool or editor extension + config file. That is sort of what’s needed to make a graph based shader editor. It’s all a lot of work and complicated but it is still the sort of direction forward necessary. Of course it goes beyond the camera, but it is part of the render.
2 Likes
Looking back through my post history, I think I summed it up here: Any plans for improve the camera?
#1 - Primarily:
So it is possible with the built-in camera component, but that conflicts with your point #3: Multiple Cameras. As you say, rendering with multiple cameras at once has lots of uses.
I really think there should be a separate step in the update loop specifically for updating cameras. After scripts, after messages, after animations, after physics…before rendering. Otherwise there’s always going to be some weird caveat where everything breaks.
“Enum” script properties with drop-downs seems like a trivial thing, but I think it would give all assets a big usability boost, and it’s those kinds of cool little features that motivate people like me to make assets in the first place. Generate custom game.project settings also falls in that category.
I think camera movement controllers—1st person, 3rd person, spring-arm collision, etc.—could be in separate assets. I don’t think it needs to be bound to the view/rendering stuff, it should just be moving a game object around. Plus it’s hard to do a one-size-fits-all script for those. You don’t want to lock people into too much at once. But those things should be pretty easy and fun to do.
The render script pipeline stuff is a bit more complicated, but I agree it would be great to have a nice system for that.
Is PBR and general 3D shader stuff still waiting on engine limitations? It’s been a while since I messed with that stuff.
Anyway. I just wanted to let you guys know the status. I don’t want anyone to get their hopes up too high. 
6 Likes
What do you think @jhonny.goransson ?
I know that PBR has been mostly possible for several years now but there were a few missing features like tangent (normal/bump map requires pre-calculation of tangent vector of mesh) sRGB/dFdx that made it harder to get working perfectly. An issue with PBR is it needs to be easy for designers to work with. It should be as easy as turning on the rendering for it, connecting the textures and materials, and you get PBR.
I believe recent changes with OpenGLES 3/WebGL 2 should make the above mentioned no longer limitations any more. Mesh with custom vertex formats also helps. But I’m still not the one to know for sure.
Maybe the camera component could be changed so that it is like GUI components in that it has its own .camera_script able to be associated with it. Then a builtin .camera_script (with all current camera behavior) goes in the builtin folder that is automatically associated, and it can be copied / modified to produce more unique behavior / have its updates ran like you say.
6 Likes
Using rendercam as lua module make it easy to work with multiple cameras. Old module fork https://github.com/d954mas/2.5d-shooter/blob/master/rendercam/rendercam_camera.lua I have better module in my current private project, with all other rendercam functions. I will try move it to github some time later.
You can use go functions in renderscript. You need to save script instance in go. Then change that script instance in renderscript.
4 Likes
Cool, I’ll have to check out how you’re using that.
Yeah, I’m aware of the script-instance thing. I should have said, “use multiple cameras without a Native Extension”. I didn’t really want to require everyone to use a Native Extension to use Rendercam, but maybe that’s stupid.
In my own ‘dev’ branch I am using the hacky lua technique of modifying the globals table to change the script instance.
3 Likes
I am using the hacky lua technique
It is fine to use temporary solutions in order to move things forward while advocating for real solutions.
I haven’t seen anyone post a snippet for this, so here is mine if anyone needs it
local rendercam = require “rendercam.rendercam”
function init(self)
self.url = msg.url()
rendercam.add_window_listener(self.url)
self.ratio = rendercam.window.x / rendercam.window.y
end
function on_message(self, message_id, message, sender)
if (message_id == hash("window_update")) then
if (message.aspect > self.ratio) then
rendercam.activate_camera(hash("/camera2"))
else
rendercam.activate_camera(hash("/camera1"))
end
end
end
1 Like
@Pkeod PBR is definately possible, but not easy. I made some examples with normal mapping for tangent stuff, but it’s using mesh buffers for that so it’s not a drag n drop solution. It would be nice to have that as part of the import process however, but I don’t know if @JCash has any input on it?
3 Likes
Our mesh component is currently purposefully manual, in order to give most control to our users.
However for the model component, I see us supporting a custom vertex declaration later on, and as such import any tangent space data (or other custom data) from the models.
2 Likes
A bit late to the party. I’m quietly alarmed at the words “retire rendercam” as I’m actively using it, and loving it, in my projects!
I use Rendercam for 3D projects and Orthographic for 2D projects. A minimal 3D only camera sounds like a great idea to me.
To me, a well maintained camera extension is important in any engine. It’s one of those make or break things that newcomers are likely to immediately start using, and see as a core part of the engine. Having two options, Orthographic, which is superb, and its 3D counterpart would be ace.
7 Likes
+1 
4 Likes
I agree. RenderCam is great. But it is also quite stable and would work in its current state for a long time. We do not plan to introduce any breaking changes the APIs used by render cam.
3 Likes