Illumination — Ready-to-use forward shading lighting for 3D games

[Pawel]

Hi!

Anyone experimented already with adding shadows to Illumination? It would be so better!
I am trying to investigate @jhonny.goransson Shadow Mapping example, but can’t figure out yet how to merge it into Illumination example, so any advises would be gold!

Shadow mapping example has one light source, while in illumination there could be many, so those are probably not compatible out of the box

[astrochili]

Anyone experimented already with adding shadows to Illumination?

@Pawel I’m very surprised and glad at the same time, but @d954mas makes something like that: https://twitter.com/d954mas/status/1654841624063619074

Mine Universe Week 5

[Pawel]

Aaa, so probably it is adapted from @Dragosha’s lights and shadows

[d954mas]

Yes it is @Dragosha shadows.
Idea is simple. You have point light from illumination(no shadows).
And you have sun light with shadows from dragosha.

Then you try to mix two shaders in one shader)

[astrochili]

Huh, after a good look it turned out that the normal maps in the example are not created correctly and do not correspond to DirectX or OpenGL

Accordingly, the algorithm in the shader was also wrong.

Fixed the algorithm and added the ability to specify in the shader parameters which normal maps are provided - in OpenGL (default) or DirectX format .

Also fixed the sun blinking on surfaces when the sun rotates.

[Yannic]

Hello!

I just tried the example project in Defold 1.6.4 and none of the lighting appears to be working?

I simply downloaded git repo, opened it in Defold 1.6.4, and made a build.

Any ideas what could be wrong?

[astrochili]

Oh, really. It works fine on 1.6.1, but not on 1.6.4.

I’m not sure exactly why, there are no errors in the log, so it’s taking me a while to figure it out.

[astrochili]

Okay, figured out with it!
Starting from Defold 1.6.3 mesh component respects sampler names.

Their order in the editor is now sorted by alphabet instead of the sequential order from the source file as it was before. But it also affects calls like go.get('textureN'), where N now depends on the alphabet.

So I changed texture1 to texture0 to fix the bug (DATA_TEXTURE was 2th before 1.6.3), but the dependence of the N on the alphabet looks a little flimsy…

Is it okay? Or may be there is a new way to get texture path by sampler name? My use case:

local TEXTURE_DATA = hash 'texture0'
local data_url = msg.url('#data') -- #data is mesh component
...
data_texture_path = go.get(data_url, TEXTURE_DATA)
resource.set_texture(data_texture_path, data_texture_header, data_buffer)

[jhonny.goransson]

I think that for meshes you should be able to get a texture by the sampler name if that’s how we save the texture mappings these days… we really don’t want resources to depend on indexing like this

[astrochili]

Only go.get(data_url, hash 'textureN') works at the moment . Or should I try something else?

go.get(data_url, hash 'DATA_TEXTURE')
>>>
ERROR:SCRIPT: illumination/illumination.lua:309: '/illumination#data' does not have any property called 'DATA_TEXTURE'

[jhonny.goransson]

No it’s the only one that works, I’m just saying as a note for myself that we should probably allow setting textures by sample name at some point but for now that’s the only way to do it

[electroskeptic]

A question: is there a possibility to DETECT light? Like, a sensor of sorts, that triggers once light hits it?

[Mathias_Westerdahl]

No. Perhaps you can use collision objects to detect them.

(Also, please don’t ask the same thing in different threads)