Does anyone know how to increase the contrast on a viewport/camera? As you can see the modules are rendered in a very grayish fashion. I’ve tried all kinds of lighting but brightness can’t really correct contrast. I guess I could attach a filter to the viewport and correct all pixels, but that seems like an unnecessary complication. Any regular way to do it?
So I’ve also finished the module texture/model overhaul. The final one was this junkyard/scrap/pirate themed faction.
Do you mean you freeze the lighting and shadows into the images (bright and dark spots in the texture pixels mixed with the colors)? I used to do that in previous attempts to make a space opera game too. It can look okay, but never really good.
There are some things to consider:
If you have only small ships in a large space then you can write your own light manager (I’ve been writing one for my pacific islands game - it has up to 4 lights per island + the torch of the player - a perfect situation because islands are small and far away from each other). I also plan to extend that idea by creating “temporary light zones” (I’ve got many ideas how to determine the closest 4 light sources for every object and combining or splitting these zones).
If you have huge ships and space stations (you have). Then look for “deferred shading” or “light prepass shading” - some proprietary projects in this forum already showed that. I think the engine should have that too. The big engines have switched to that rendering type years ago. What it allows you to do - literally 1000 lights, even on one object like a huge ship or space station - with quite good performance.
You could use a trick (e.g. make you own voxel-based lighting - which sounds like minecraft but can look really cool if done by an awesome graphics and shader coder).
I think jME 3.1 has a light management too. I don’t know how good it is implemented though and how much you can customize it (or must customize it).
Needed to add the other side of the medal, to stay fair:
The deffered rendering - it has some disadvantages too and to overcome them can be non-trivial. Say good bye to transparency (and hello to lots of cumbersome workarounds). Good bye to simple multi sampling. And hello to high data bandwith. So it’s not only advantages.
One trick I use in my shader for lighting is passing in light sounce info at runtime. For example, if a missile is passing by your ship I pass the cords of the missile and the frag shader illuminates (makes brighter) the immediate area near the missile. Kind of like a reverse light pass I guess is the best way to describe it. So it’s like IBL but instead of the light image I pass in “light source” coordinates if that makes sense. Once the game comes out of beta in a few months I will release most of these cool effects back to the JME community.
Sounds like the same technique jme uses for singlepass lighting in 3.1+
@zissis the hud consoles bleeding trough other ships are super nice. Very very good idea that makes the displays automatically look like some piece of high tech, and brings them alive.
@Ogli: Deferred brings some other disadvantages with it. And if it is suitable for your game depends on a few factors. The only case where it really shines is having a waste amount of small lightsources. Translucency is actually already solved on higher GL versions.
Its a pain to implement, but it solves nearly all common problems. At the cost of high bandwith of course. But for a space game i probably would never opt for a deferred pipeline.