[Feature Request] Glow bars...

[make-42]

Basically like the shadow effect but with colors and gradients...

[nikp123]

you can change the shadow color, which should achieve the same effect, though gradients are yet to be implemented

[make-42]

It sort of achieves it but I think a different spreading curve and having it be on both sides of the bars would make the glow more convincing

[make-42]

I made a demo with GLSL of what a glow effect could look like.

#ifdef GL_ES
precision mediump float;
#endif

#extension GL_OES_standard_derivatives : enable

uniform vec2 resolution;
uniform float time;

float rand(float n){return fract(sin(n) * 43758.5453123);}

float noise(float p){
	float fl = floor(p);
  float fc = fract(p);
	return mix(rand(fl), rand(fl + 1.0), fc);
}


void main( void ) {

	vec2 position = ( gl_FragCoord.xy / resolution.xy );
	float brightness=1.;
	float color = 0.0;
	float r = (position.y*0.843)+((1.-position.y)*0.243);
	float g = (position.y*0.)+((1.-position.y)*0.286);
	float b = (position.y*0.564)+((1.-position.y)*1.);
	float barheight = (noise(position.x+time))*(1.-position.y);
	color += ceil(sin(position.x*50.));
	color += exp(sin(position.x*50.)/brightness);
	color *= barheight;
	gl_FragColor = vec4( vec3( color*r, color*g,color*b),1);

}

http://glslsandbox.com/e#65127.5

[nikp123]

True, it's as convincing as I thought it would be.
Since shaders achieve a lot of functionality that pure code doesn't, I though of migrating the entire OGL renderer to be VBO based instead of 90s OGL, which would allow me to just cram in shaders. But I have no idea how to organize them, so that would be a major pain to do. Also this would resolve many workarounds that I've implemented simply due to default shaders being different on different drivers and OS-es. I think I have a demo working in VBO, so that would be a good starting point.

[nikp123]

The tree is 70 commits old, so it shouldn't be that hard to work with. Just updates are going to be slow since I'm busy atm.

https://github.com/nikp123/xava/tree/opengl-vbo

[nikp123]

Also since I'm kinda bad with OGL, can you link me to a resource where I could share local variables (in C code) with shader code.

[make-42]

Will do!

[make-42]

OpenGL Shading Language 4.5 Documentation: https://www.khronos.org/registry/OpenGL-Refpages/gl4/
IO GLSL code: https://gamedev.stackexchange.com/questions/29672/in-out-keywords-in-glsl

[make-42]

Improved the demo and edited my comment...

[make-42]

Hell yeah! Nice work!

[make-42]

Made it generate a curve http://glslsandbox.com/e#65127.6

[make-42]

For integrating it inside the program I just need to replace float barheight = (noise(position.x+time))*(1.-position.y); with float barheight = data(position.y);

[make-42]

ehehehehe http://glslsandbox.com/e#65239.0

[make-42]

A short video shot at 800x450,60fps showing my shader in action...
XAVAShaderDemo.zip

[make-42]

Ported my shader to GLava in about 10 min...

reencodeportedtoglava.zip

[nikp123]

Guess I closed this issue by accident, sorry.

[nikp123]

I'm adding the "help wanted", since the current shader is quite unoptimized (a whole third of an Intel HD5500 used when being run). If anyone could come up with a:

• Customizable (being able to change not just the looks, but also the shape of the visualizer) - like being able to go from bars (the default) to a circle (potentially)
• Lightweight (I mean this speaks for itself really)
• Simple to implement (Like not adding an additional 10k SLOC and/or chaning the entire codebase to accomidate the change)

solution, I would gladly accept it.

[nikp123]

dynamically loading code sounds fun

Obviously need to clean this up and make the functionality flawless before even thinking about merging it to master.

[nikp123]

by the way, I think leaving XAVA logic purely to the cpu is the best option, while I could for example make an output mode which processes shaders on top of what the dynamic function did

If this turns out to be the best solution, redoing this as a lib would be the solution, since it doesnt interfere with what I've already done, increasing stability.

[nikp123]

I guess implementing geometry shaders would be better, as doing this logic in fragments is just silly.

Anyway future me, start off here: https://www.youtube.com/watch?v=r2hue52wLF4

[nikp123]

oops

[make-42]

fixed the issue

[make-42]

kinetic still doesn't work

[nikp123]

the issue was simple... only files labeled with "default" were treated as XAVA configs. The others were custom and therefore featured a different error message. Instead of checking which default files were installed, I just made it so that it treats custom shaderpacks as default ones.

[nikp123]

Anyway on your side, you'll just have to clear the shaders folder and run XAVA again.

[make-42]

It works, kinetic darkens the viewport when there is a high velocity of bars right?

[nikp123]

yes

[make-42]

Nice

[nikp123]

Actually I like the opposite effect more. Sending in a new version

[nikp123]

as you see it's a totally original idea without any stealing going around

[nikp123]

geometry shaders BOII

ps: gpu requirements up in OGL 4.2. Sorry not sorry that your Librebooted T60 ain't gonna run this.

[nikp123]

also PS: OpenGL ES is dead also

[nikp123]

dd3a6c4

i should've just used modern ogl from the beginning, it's so MUCH better and I wouldn't be rewriting this once again

[make-42]

ouch

[nikp123]

yet i wrote it once again

turns out cutting out a single stage made things significantly worse to work with

[bypepe]

is it possible to see the highest level peaks??
regards

[nikp123]

is it possible to see the highest level peaks?? regards

Not ATM. I was thinking about adding lua support since geometry shaders are not flexible enough.

Currently debating whether I should do lua or add C "modules".

Lua is easy, compatible, less prone to errors

C is native, faster and fundamentally more flexible

Performance is no biggie since it's basically doing basic math each frame...
Compatibility is big because with Lua I'd most likely have to generate huge header files.
Also I'd like for the shaders to be simple enough that anyone with basic programming knoweledege could do them

That's where I'm at ATM. The current shader system sucks even if it has all this effort put into it.

[nikp123]

Also with Lua scripts or "C modules" I could lower the OGL requirements once again.

[make-42]

Personally, C modules sound better to me, but since this is your project, you can do as you wish!

[nikp123]

i think they're good enough now...

[nikp123]

Update, gl modules exist and are cairo-like. Now to just implement them ;)