Open edljk opened 6 years ago
Sorry for the multiplication of the updates. I hope, it should be stabilized now. Do not hesitate to modify. Any comments are welcome.
Sorry, I will need to take a close look at this... I'd really just hope to address this with some nice looking julia code + transpiler at some point :P
No problem at all: this is not an emergency and the proposed approach is for sure not completely satisfactory..
Anything new regarding lighting? I noticed frag files changed in GLMakie since this tentative :-). Is it now possible to have a more uniform lighting in 3D? Add several lights? etc.
Sorry, no ;) Would still be nice to have of course
What do you think about extending your light_calc function to define other lighting styles?
Actually, this simple hack makes it possible for me to obtain a uniform lighting just by extending light_calc
.
One issue (??) that I have is that the parameter shading
does not seem to be taken into account for meshscatter!
. Is it on purpose?
No, that's likely a bug ;)
I tried to fix it without success, sorry! Here is the code I used to have "uniform" lighting
mutable struct Lights
description::String
intensity::Array{Float64, 1}
end
function GLMakie.GLVisualize.light_calc(x::Lights)
if x.description == "uniform"
ST = [ 0.0 0.0 1.73205; 1.63299 0.0 -0.57735;
-0.816497 1.41421 -0.57735; -0.816497 -1.41421 -0.57735]
lights = [Vec3f0(ST[k, :]...) for k = 1:size(ST, 1)]
strl = """
vec3 L = normalize(o_lightdir);
vec3 N = normalize(o_normal);\n"""
for k = 1:size(lights, 1)
strl = strl * "vec3 light" * string(k) * " = blinnphong(N, o_vertex," *
"vec3(" * string(lights[k][1]) * "," *
string(lights[k][2]) * "," *
string(lights[k][3]) * ")" *
", color.rgb); \n"
end
strl = strl * "color = vec4(light1 * " * string(x.intensity[1]) * " + " *
"light2 * " * string(x.intensity[2]) * " + " *
"light3 * " * string(x.intensity[3]) * " + " *
"light4 * " * string(x.intensity[4]) * ", color.a);"
#println(strl)
strl
else
""
end
end
..with the option shading = Lights("uniform", [0.7, 0.3, 0.3, 0.7])
Actually, the sprites
function in particles.jl gets a data
field without the key shading
after a call
meshscatter!(..., shading = false)
but I am not able to identify the path from meshscatter
to the sprites
function..
Finally, I managed to fix this (shading not taken into account in meshscatter) by some modification in
GLMakie
by adding the shading
field in the right places in the files particles.jl and drawing_primitves.jl and adding
"light_calc" => light_calc(shading)
in particles.jl in the meshscatter
function and
AbstractPlotting
adding the shading
fields in the right places in the file interfaces.jlAre you interested in a PR for this small extension?
That'd be awesome :) Thanks for your work on this, and sorry that I have this on low priority and therefore am not very responsive :D
No problem at all: you are right, this is definitely low priority!
light
field (with backlighting)assemble_shader
inutils.jl
is the right place to add lighting optionsvalue
calls to transform signals. I guess there is still some work to be done to preserve interactivity.. At least it should not affectMakie
calls.