userland icon indicating copy to clipboard operation
userland copied to clipboard

Published 20 hours ago • verified publisher icon raspberrypi

Osc shader

Open avilleret opened this issue 10 years ago • 17 comments

this patch add a new OpenGL scene to Raspistill application. It's called shader and let the user load vertex and fragment shader via command line. Also, if compiled with liblo, it automatically exposed each uniform via OSC. Thus any shader parameter can be controlled by another OSC capable application locally on the Pi or remotely.

avilleret avatar Feb 23 '15 18:02 avilleret

@6by9 does this PR have any chance to be merged (look aside from the conflicts)? If not, it should be closed

Ruffio avatar Nov 18 '16 12:11 Ruffio

I know next to nothing about OpenGL so can't comment on that side. I don't know if @timgover has a few minutes and would be prepared to review the GL side of this.

There are several other bits mixed in to the PR as well (eg liblo, and extra exposure mode) - if this is for a new OpenGL scene then it should ideally be just that bit. Raise separate PRs for the other things. There's also no need for the development history that lead to the PR - changes should really be squashed into one commit.

I will find 10 mins to go through and review this, but comments like "don't fully understand all the consequences of this.." instill a deep sense of foreboding.

6by9 avatar Nov 18 '16 13:11 6by9

Hi,

I just merge master into osc-shader branch to fix merging conflict. Merging should be safe now. Liblo is optionnal, if you don't have it, it will not be enabled and build fine. You will still be able to load vertex and fragment shader, but you can't control it with OSC.

Fell free to ask me some modification before merging.

avilleret avatar Nov 18 '16 20:11 avilleret

Do I need to make more changes to see this PR merged ?

avilleret avatar Jan 13 '17 13:01 avilleret

@avilleret @6by9 Another one that has slipped through the cracks - what should we do here?

JamesH65 avatar Jan 18 '18 11:01 JamesH65

@avilleret Sorry about the delay, would it be possible to rebase against the latest tree then we can try and get this merged.

JamesH65 avatar Jul 02 '18 15:07 JamesH65

@avilleret ping

JamesH65 avatar Dec 13 '18 10:12 JamesH65

I'll try to rebase this against master in the next few weeks and let you know

avilleret avatar Dec 13 '18 10:12 avilleret

Thanks. Quite a few changes in the camera code, so good luck!

JamesH65 avatar Dec 13 '18 13:12 JamesH65

@JamesH65 could you give it a try ? I don't have a camera to check until January 6th

avilleret avatar Dec 25 '18 19:12 avilleret

@avilleret what do you say?

Ruffio avatar May 03 '20 13:05 Ruffio

@Ruffio, sorry, what is the question ?

avilleret avatar May 03 '20 14:05 avilleret

@avilleret did you check with camera? @JamesH65 could you give it a try ?

Ruffio avatar May 04 '20 07:05 Ruffio

Sorry, this has just completely slipped past. I have no idea whether this would work on a Pi4, I suspect not. @timg236

Unfortunately needs to be rebased again.

JamesH65 avatar May 04 '20 08:05 JamesH65

Sorry, this has just completely slipped past. I have no idea whether this would work on a Pi4, I suspect not. @timg236

Unfortunately needs to be rebased again.

The Broadcom specific extensions are never going to work on Pi4, although if someone was sufficiently enthusiastic they could implement equivalent functionality using GLES 3.0 / MESA on Pi4.

timg236 avatar May 04 '20 08:05 timg236

If this specific PR is never going to work, and therefor never goint to be accepted, then it should be rejected IMHO.

Ruffio avatar May 12 '20 12:05 Ruffio

It will work on Pi3 or older so long as the legacy GL driver is selected which I believe is the default

timg236 avatar May 12 '20 13:05 timg236