Material problems, lighting problems, editor problems. Want to contribute

I’ve been working with the editor (scene composer) lately. It looks great btw, and the functionality is very good. The blender key shortcuts makes it very easy to use.



I am going to start merging Forester with the editor soon, during this fall. There are some differences between the systems but it’ll be smoothed out gradually. Most of the placement stuff is already availble in the editor so it’s far less work then I anticipated.



There are issues with materials tho and I want to fix it. Forester use single pass lighting (mostly because the shaders contains a bunch of non lighting related stuff, and there’s more to come). I am currently using survivors lib, or at least basing the lighting stuff on his code and use his MaterialSP.java file (which extends Material.java).



The only real difference between MaterialSP and Material is the single pass routine. MaterialSP.java passes a “number of lights” uniform to the shaders. This of course is not compatible with the normal materials, but the default single pass lighting doesn’t work anyways. Ambient lights makes it into the light list and messes it up, and the list is hard coded to 4 lights (unless it’s been changed without me knowing it).



This single pass stuff has been mentioned before a couple of times. The survivor code works well. Single pass works well. I don’t think there’s a big performance difference tbh (haven’t really measured), but it’s good for shaders that has lots of non lighting stuff that should not be repeated, and it produce no bugs that I’m aware of (after about 6 months of regular use).



This is one of the main obstacles to editor integration, since you clone models and add them, but cloning a model using MaterialSP instead of Material causes a null pointer exception. I guess a check can be made to see what material class is used in the editor, but again - single pass in Material.java doesn’t work anyways so patching does not really create any bugs, it just moves the old obsolete system towards a good working alternative.



I just wonder if it’s possible to merge MaterialSP with Material.

@Momoko_Fan’s brain is working overtime solving the general injection/pass/lighting issues of the shader system atm.

Please note the recent changes in RealSlimShader.

@normen

Ok nice. I know there are lots of shader stuff going on, just wanted to bring it up again.



I’m guessing that lighting will be neither the current multi or single pass stuff in the future, but more like a 2.0 version. That is exciting. Gonna put shader rehaul on hold for some time then, see what happens.



Is there any way I can help with the shader stuff please let me know. I can write shaders and do tests etc. I’ve done some pretty advanced water and sky shaders, among other things (texture advection, reflection/refraction, HDRR, numerical integration, volumetric textures etc.), I can do OpenGL/CL stuff directly (to some degree), and have worked with the jME material/shader/renderer code.



@survivor

Yeah I noticed all of that in the new build. The comments and tech info you write in the thread is almost as useful as the actual code btw.



I wouldn’t care too much about “cleanliness” since it’s mostly shaders and a few classes (just my opinion). Those that use it know how to read code and pick what they want out of it.

@androlo said:
Is there any way I can help with the shader stuff please let me know. I can write shaders and do tests etc. I've done some pretty advanced water and sky shaders, among other things (texture advection, reflection/refraction, HDRR, numerical integration, volumetric textures etc.), I can do OpenGL/CL stuff directly (to some degree), and have worked with the jME material/shader/renderer code.

You have access to the core chat. These topics are too vague/fragile to be discussed in a forum really and any direct ideas for implementations are best discussed in realtime if they don't exist in code.

See this post (at the very least, we should have this): http://hub.jmonkeyengine.org/groups/graphics/forum/topic/lighting-performance/?topic_page=3&num=15#post-179330



Also, see issue 510 comment 1 regarding the agenda for lighting. This is mostly for Android and multipass, but it would include fixes for the singlepass lighting if implemented.



And don’t listen to Normen, shader injection is due for 3.1 release. It was never planned for 3.0. These lighting issues are unrelated to it.

@Momoko_Fan said:
And don't listen to Normen, shader injection is due for 3.1 release. It was never planned for 3.0. These lighting issues are unrelated to it.

:? I didn't say anything about releases?

Read those notes etc. I get it, thanks.