@phr00t said: Where are @nehon's awesome shadow renderers? :)What did I do to deserve that kind of taunt? I wonder...
@nehon said: What did I do to deserve that kind of taunt? I wonder...
You did some great work, thats why 
@phr00t said: I believe I used your SSAO filter for 3089. I made some modifications to it to improve performance that I wanted to share. I commented out a ton of stuff that I wasn't using to save "if" branches. I believe you had an "if" branch inside a loop, which killed performance. Make sure you are using #ifdef instead of "if" branches. Here is how my SSAO filter looked:
Thanks for this!
I’m so bad at getting around to performance tuning. I’m literally just starting on it with the GUI library. How sad is that? At least I can pretend that it is still in alpha, though, I really should have pushed this forward.
@zzuegg said: I would actually be really curious about the progress on your project Empire..Sorry for OT chris
Np! I’m looking forward to hearing about it as well.
Also keep in mind that this is just a starting block to a final effort that I’m sure @nehon will be heading up.
I hear rumor that lighting is about to change for JME to increase performance for multipass lighting anyways.
The lights used in this effort are not JME lights, but are created/managed the same way and still use JME shadow queues…
I believe you attach them to nodes to limit there influence… if not, then that was were I was going next and you likely want to add this first.
It would work like this… When building the Geometry list for rendering shadows, you would:
- Start with the list from the node the light is attached to and all of it’s children.
- alter the list based on ShadowMode
- Render the depth map.
The trickier part would be limiting the receivers list, but, honestly, I don’t believe this is necessary, as you still have Render Buckets and shadows wouldn’t be rendered over transparent/translucent objects anyways… they would, however, still be rendered under them.
@t0neg0d said: Np! I'm looking forward to hearing about it as well.
Don’t worry, currently I’m switching to jfx based gui, so there is not much to see for the moment (Well except guis obviously).
But I will post updates from time to time when I have a few parts done.
(Also I kinda try to get at least 1 screenshot per month into the screenshot wip thread, so it kinda shows what the current progress is)
1 Like
@Empire Phoenix said: Don't worry, currently I'm switching to jfx based gui, so there is not much to see for the moment (Well except guis obviously). But I will post updates from time to time when I have a few parts done. (Also I kinda try to get at least 1 screenshot per month into the screenshot wip thread, so it kinda shows what the current progress is)
I keep a solid eye on the progress of that effort. It looks really neat.
Any progress on defered rendering yet? The light in shadow problem is something I’d so much like to see resolved! 
… and put hundreds of lights on a scene too of course
@.Ben. said: Any progress on defered rendering yet? The light in shadow problem is something I'd so much like to see resolved! :D ... and put hundreds of lights on a scene too of course :D
Personally, I’ve done nothing with this project in quite a while. As for JME’s effort… I have no idea =(
OK thx for the headsup.
1 Like
@.Ben. said: OK thx for the headsup.
Actually, thanks for the reminder! I’ve been working on 2D games as of late and almost forgot about this.
I’ve been using a custom-made single pass lighting system for my games with decent success… you can look for more information here:
http://hub.jmonkeyengine.org/forum/topic/heres-code-for-a-single-pass-lighting-system/
Basically, I have sections of my game world that take a fixed number of lights (like 6), and in my Java code, I determine which brightest lights are in those sections, then just set those lights to the shader for that section.
EDIT: However, I’d love to see progress here… lighting could use a big boost in jMonkeyEngine!
But… I’m reading also that almost 2 years ago, @kwando started an implementation of Deffered Shading. Are you guys working in parrallel or is it the same project/vision to integrate it to 3.1 or whatever next release?
This: http://hub.jmonkeyengine.org/forum/topic/wip-deferred-shading/
@.Ben. said: But... I'm reading also that almost 2 years ago, @kwando started an implementation of Deffered Shading. Are you guys working in parrallel or is it the same project/vision to integrate it to 3.1 or whatever next release?This: http://hub.jmonkeyengine.org/forum/topic/wip-deferred-shading/
My effort was nothing more than a personal project that I wanted to share the results of if it was successful. I took a slightly different approach to lighting/shadows than what had been tried/discussed here and wanted to prove out the concept before mentioning it.
I haven’t heard any noise about furthering a deferred rendering system in JME, so this project went to the back burner until that becomes a priority for the engine. At that point, I was planning on donating my effort to fuel ideas. I still plan on doing this… just waiting for this to become a priority so the effort isn’t lost.
EDIT: And just so I feel like I’m not coming across someone tapping there foot waiting for others to stop dragging ass. I still don’t think this should become a priority until the core devs feel that the current feature set is complete, stable and bug free (or as bug free as humanly possible). In the end, the deferred rendering system (if the shadow rendering ideas I have here were to be used) would rely on a few parts of JME that are still in flux (lighting, shadows, etc… I hear lighting is going to get an overhaul and the shadow renderers were recently changed and are still getting put through their paces)
kwando got 30 likes on his first post, also you got 16 on first post. I mean, this talks. Deferred Lighting should be taken as a high priority, especially now that iOS support is out (which was IMHO very high on the list). I encourage you and others to get Deferred Lighting into core. This really looks like it’s a wanted feature for the community.