Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Simon Moos
@Shimmen
So in essence, nothing changes on the js-side of the code
Claudio Esperança
@esperanc
Of course. Thanks @Shimmen
Claudio Esperança
@esperanc

Still fiddling with the part 5 of tutorial. I was trying to see the trajectories of the particles by commenting out the framebuffer clear() call so that earlier iterations of the process would not be wiped. Thus:

       var currentDrawCall = drawCallA;
        function draw() {      
            //app.clear();
            currentDrawCall.draw();

            currentDrawCall = currentDrawCall === drawCallA ? drawCallB : drawCallA;

            requestAnimationFrame(draw);
        }
        app.clear();
        requestAnimationFrame(draw);

Unfortunately, this does not have the desired effect, but the canvas background now turns to white rather than black. Interestingly, if we limit the total number of frames to 2, we still have a black background:

        var currentDrawCall = drawCallA;
        function draw() {      
            //app.clear();
            currentDrawCall.draw();

            currentDrawCall = currentDrawCall === drawCallA ? drawCallB : drawCallA;

            currentDrawCall.draw();

            currentDrawCall = currentDrawCall === drawCallA ? drawCallB : drawCallA;

            //requestAnimationFrame(draw);
        }
        app.clear()
        requestAnimationFrame(draw);

I've tried to style the canvas background to black with css, but this has no effect. Is there something mysterious that happens between successive animation frames that could affect the compositing of the canvas?

Claudio Esperança
@esperanc
Answering my own question: One should enable the preserveDrawingBuffer flag when creating the gl context:
app = picogl.createApp(canvas, {premultipliedAlpha: false, preserveDrawingBuffer: true})
Robert Massman
@robertmassman

Reduced size texture processing while app remains at original size. My goal is to take in an image texture that has an initial size, resize the texture to a reduced size, apply a filter to the resized texture, store the results in a framebuffer, apply another filter to the framebuffer and store the output of the second filter to a second framebuffer.

Then my goal is to resize the original texture and second framebuffer to the original size and run both the texture and second framebuffer through a third filter who’s output goes to the app.

initial sizes
app size 1000 x 1000
texture size 1000 x 1000
framebuffer 1 1000 x 1000
framebuffer 2 1000 x 1000

reduced size
texture size 500 x 500
framebuffer 1 500 x 500
framebuffer 2 500 x 500

My problem seems to be trying to resize the texture and framebuffer in the middle of calling shaders. Can someone help me think about where I'm going wrong? How can I achieve working with a resized texture and framebuffer in one shader and then worked with another sized texture and framebuffer in another shader.

code
filter.drawCall = {
draw: () => {

if ( /* something is true */ ) {
  app.texture.resize( app.canvas.offsetWidth, app.canvas.offsetHeight ); // texture size 500 x 500 - app.texture
  gBuffer0.resize( app.canvas.offsetWidth, app.canvas.offsetHeight ); // framebuffer 1 500 x 500 - gBuffer0
  gBuffer1.resize( app.canvas.offsetWidth, app.canvas.offsetHeight ); // framebuffer 2 500 x 500 - gBuffer1
}else{
  app.texture.resize( app.width, app.height ); // texture size 1000 x 1000 - app.texture
  gBuffer0.resize( app.width, app.height ); // framebuffer 1 1000 x 1000 - gBuffer0
  gBuffer1.resize( app.width, app.height ); // framebuffer 2 1000 x 1000 - gBuffer1
}


// shders to be run on a reduced size texture and framebuffer

// Feed texture into first drawCall
drawCall0.texture( 'tex', app.texture );
// Write to Buffer
app.drawFramebuffer( gBuffer0 ).clear();
drawCall0.draw();

// Feed output of previous stage in next stage
drawCall1.texture( 'colorBuffer00',
gBuffer0.colorAttachments[ 0 ] );
drawCall1.texture( 'colorBuffer01',
gBuffer0.colorAttachments[ 1 ] );

// Write to Buffer
app.drawFramebuffer( gBuffer1 ).clear();
drawCall1.draw();

if ( /* something is true */ ) {
  // return texture and framebuffer's to original size
  app.texture.resize( app.width, app.height ); // texture size 1000 x 1000 - app.texture
  gBuffer1.resize( app.width, app.height ); // framebuffer 2 1000 x 1000 - gBuffer1
}

// shders to be run on a original size texture and framebuffer

// Feed output of previous stage in next stage
drawCall2.texture( 'tex', app.texture );
drawCall2.texture( 'colorBuffer10',
gBuffer1.colorAttachments[ 0 ] );
drawCall2.texture( 'colorBuffer11',
gBuffer1.colorAttachments[ 1 ] );

// Write out to screen
app.defaultDrawFramebuffer().clear();
drawCall2.draw();

},
texture: drawCall0.texture.bind( drawCall0 )
}code

Mike Reinstein
@mreinstein
@tsherif I'm wondering how one goes about efficiently modifying rendering data at run time
let's say I have a vertex buffer with 10,000 floats in it (5,000 vec2s basically)
and I want to change those 5,000 points at run time
(I might want to remove some, or update some)
I see that there is a data(...) function that allows me to overwrite parts of the buffer, but I don't see any way to say "there are now only 4000 floats in the vertex buffer"
my plan was to pre-allocate a vertex buffer that has the maximum number of entries I'd need, and then specify how many items are actually in it at run time, but there doesn't seem to be an API for this. What would you recommend?
Tarek Sherif
@tsherif
@mreinstein Would the DrawCall.drawRanges method help? It let's you manually set how many vertices/instances to draw.
Mike Reinstein
@mreinstein
oh, I don't see that in the docs, maybe I missed it
ah, I see it now
Mike Reinstein
@mreinstein
so in my case, if I have 2 triangles (12 floats) in my vertex array, and I only want to draw the second triangle, I would do something like this? :
drawCall.drawRanges([ 3, 3 ])
drawCall.draw()
Tarek Sherif
@tsherif
I believe so. It's not a usage I've tested, so let me know how it goes.
Mike Reinstein
@mreinstein
I'll let you know what I find either way, thanks for the info!
@tsherif another question: is it ok to share uniform buffers among multiple draw calls?
I want to do something like this:
const uniformBuffer = app.createUniformBuffer([ PicoGL.FLOAT_MAT3 ])
.set(0, world.modelView)
.update()
const drawCall = app.createDrawCall(program, triangleArray)
.texture('tex', texture)
.uniformBlock('SceneUniforms', uniformBuffer)
const drawCall2 = app.createDrawCall(program, triangleArray2)
.texture('tex', texture)
.uniformBlock('SceneUniforms', uniformBuffer)
I'm assuming when I make changes to uniformBuffer, they will be reflected in both draw calls
and I guess the same question applies to Texture objects, I'm assuming it's ok/good to re-use them across different draw calls
Mike Reinstein
@mreinstein
answering my own question, yes it seems to be fine to share textures and uniform buffers across draw calls
@tsherif I'm wondering if you've ever considered some kind of shader graph support for picogl
Mike Reinstein
@mreinstein
in looking at examples of both picogl and webgl, I've found it's kind of hard to understand the relationship between all the shader programs and draw calls, and how data flows around.
something kinda like this: https://nme.babylonjs.com/
Bach Le
@bullno1

@tsherif I'm wondering if you've ever considered some kind of shader graph support for picogl

that sounds too high level but I guess you can build one on top of it, I'm doing SDF font rendering on picogl now

Bach Le
@bullno1

@tsherif on VertexBuffer.data(data, offset) use glBufferSubData to replace it so it can't "grow".

What do you think about tracking the buffer size in VertexBuffer and automatically grow it by calling glBufferData instead?
This makes the VertexBuffer a bit more "high level" since it can magically grow but right now, there is no easy way to change the size of the buffer. It is possible to call webgl directly but it relies on tracking the inner working of picogl which tbf, is pretty thin.

Of course doing VertexBuffer.data(data, offset)with offset > 0 to grow it is problematic since we would have to do some glCopyBufferSubData to some temp buffer before calling glBufferData.

Alternatively, a bind() method could be added to all "resources" so that they can be bound directly to the context for manual tweaking but that could easily break picogl's internal state caching.

unrelated, what's the point of rebinding the target to null here: https://github.com/tsherif/picogl.js/blob/master/src/vertex-buffer.js#L168

AFAIK, the next user of this target would just rebind it.
Moreover, the whole library relies on VAO anw so the non-VAO target wouldn't have much effect.

That said, performance-wise I don't think it would make much difference since the browser would probably have some internal state tracking and it won't even make a syscall there.

Mike Reinstein
@mreinstein
too high level for what?
Bach Le
@bullno1
for picogl
rjbudzynski
@rjbudzynski
Hello! In PicoGL, how do I read the data in a VertexBuffer in order to operate on it with the CPU?
rjbudzynski
@rjbudzynski
Seems that WebGL2 has a ctx.getBufferSubData() for this purpose - but PicoGL does not expose it, or did I miss it somehow?
rjbudzynski
@rjbudzynski
Also, I'm having problems setting up a transform feedback DrawCall with no vertex array bound.
When it was using a vertex array all was fine, but now: GL_INVALID_OPERATION: Active draw buffers with missing fragment shader outputs.
Actually what might be more relevant is that in the working version, I was both rendering to screen and saving data in a transform feedback buffer - here I don't want to render anything. AFAIR I should be calling gl.enable(gl.RASTERIZER_DISCARD) or the like at some point, but PicoGL doesn't seem to expose that, either?
rjbudzynski
@rjbudzynski
hmm looks like nobody comes here anymore.
FraserLee
@FraserLee
This looks pretty dead, but it's worth a shot
Does anyone have a clue how you'd get a floating point texture (RGBA32F) in PicoGL.js ?
Tarek Sherif
@tsherif
@FraserLee several of the examples use float textures, e.g.: https://github.com/tsherif/picogl.js/blob/master/examples/deferred.html#L161-L163
@rjbudzynski You can enable/disable GL state (including RASTERIZER_DISCARD) using App.enable() and App.disable, e.g. https://github.com/tsherif/picogl.js/blob/master/examples/wandering-triangles.html#L275
getBufferSubData isn't currently exposed through the API.
rjbudzynski
@rjbudzynski
okay, thanks. I somehow did find that, and invoking getBufferSubData bypassing the PicoGL API works fine.
Also, creating a draw call with an empty vertex array does the trick for my first question.
Here's the result of my wrestling with PicoGL: https://rjb-vicsek.surge.sh/
FraserLee
@FraserLee
@tsherif thanks so much!
I think I was accidentally looking at an old version of source, I didn't think it was directly supported