All of these parts exist (there are even several 3D Defold projects using PBR setups out there, the parts of it will be public eventually) but they really need to be one whole system that’s thought out and works well together. 3D camera, post processing, materials. Would want one big complete version that has many more of the features 3D game devs would want, and a more lean version for more basic games.
[+] It’s easier to click once or twice than it is to type something.
[+] You can’t make typos or any other mistakes.
[-] It takes up much more space in the properties panel.
[-] It makes it harder to set a custom mode.
The last point is what I’m considering right now. It’s very cool that Orthographic lets you set custom projection modes, I’m thinking of adding something similar to Rendercam. Using a text-input box would make it easier to use custom modes—you could use them exactly like the built-in ones.
I prefer checkboxes. If there are too many modes, it’s easier to have them listed out instead of having to remember or research what each of them are called. Either way it’s not a big deal, though.
I’m using Lumiere and creating a program in the runtime and switching to it hangs the game for a moment every time (to create a shockwave effect in the specific position on the screen when player hits something). Do you see any way of improving Lumiere or do you have some better ideas, @jhonny.goransson?
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.
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.
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.
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?
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.
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.
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.
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.
I might keep the checkboxes and add another text field for custom modes/override.
