Captain Harlock

  • Content Count

  • Joined

  • Last visited

About Captain Harlock

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yup, that was it. Too many pixels. Thanks Fatalist.
  2. I'll give the idea of one unique buffer for vertices and colors a try. But I want to come back to your idea of using multiple batches of "reasonable" sizes. Suppose I choose k batches, each containing N/k triangles. I''ll end up calling drawArrays k times, each with 1/k the amount of data. Could you explain why this would help? What's the fundamental reason? Isn't the GPU doing the same amount of work? Is parallelization helping? Why does it matter if I make k calls vs 1? It is certainly counterintuitive to me, as I would expect that the overhead of k calls from javascript would make it worse. Please help me understand.
  3. Hi, Thanks for your response. I have a few follow up questions: - I will end up modifying the buffer, but for the sake of the experiment I tried with STATIC_DRAW. I couldn't notice any difference in performance, at least on this example. - The vertex attribute data is already in one buffer. - I don't use an index buffer and drawElements. Why would that be better than drawArrays? In my case I never reuse vertices, so the amount of data to transfer with drawElements should be strictly superior to that for drawArrays. - What do you mean by "memory overhead"?
  4. I'm using WebGL to render N triangles in 2D. The triangles' geometry and colors are random, computed once and placed in buffers at start up. My shaders are super simple. Then I render them by one call to drawArrays, and animate via requestAnimationFrame. The FPS drops rapidly as N grows (both on my PC and my MacPro). When N = 10k, it's painfully slow. All over the web I see smooth demos with very large numbers of triangles. What I'm doing is very simple: You can vary the number of triangles and see performance go down. I don't get it. Isn't WebGL expected to excel at this type of things? What am I doing wrong?
  5. I'm not sure I understand your solution. Could you give me more details? Whether it's using TRIANGLE_STRIP or LINES or LINES_STRIP, the buildLine function is still attempting to create a mesh of triangles around a line. That function is invoked if the Polygon has a non-zero lineWidth, so It seems to me that it's the one that needs to change. Am I mistaken?
  6. Gotcha. Yeah I looked at the code, and it seems to be triangulating around lines using normals to give them thickness, by an amount of linewidth / 2: What I'm looking to do is fairly simple, so I'll probably end up writing it in webgl, rather than using Pixi. Thanks for your response Ivan!
  7. Well, I'd like polygons with borders. But I don't want the border to scale. If I have to redraw each time, that's going to have a performance hit (as opposed to just rescaling, which would is "just" modifying a matrix), right?
  8. Is there a way to scale a Graphics without getting the linewidth scaled as well? For instance: var stage = new PIXI.Container(); var graphics = new PIXI.Graphics(); // Set a fill and line style. var linewidth = 10; graphics.beginFill(0xFF3300); graphics.lineStyle(linewidth, 0xffd900, 1); // Draw a shape. graphics.moveTo(50, 50); graphics.lineTo(250, 50); graphics.lineTo(100, 100); graphics.endFill(); // Now, scale this Graphics. var scale = 5; graphics.scale.set(scale, scale); // all lines now have width linewidth * scale In the example above, the vector "shape" gets properly scaled by a factor of 5. Unfortunately, so does the linewidth. I am trying to render Graphics vector data on top of Google Maps (typically polygons over countries), and when the map gets zoomed in, I want to rescale the data without getting enormous boundaries.