Jump to content

grovesNL

Members
  • Content Count

    8
  • Joined

  • Last visited

Everything posted by grovesNL

  1. The problem with these kinds of approaches are that the normals and extrusion direction have to be uploaded as part of the vertex data. As well it means computing the normals on the CPU if they are not known (i.e. drawing a triangle based on coordinates). It works fine for cases like this (single quad) but trying to apply it to complex data (i.e. PIXI.Graphics) could add a lot of overhead. The stencil buffer is useful for complex polygons with holes. In those cases triangulation can become expensive. The downside is that you lose the backbuffer anti-aliasing and have to apply FXAA or simi
  2. renderer.view is just a regular canvas DOM element. So you may use CSS as you would for any other DOM element: var width = 1280;var height = 720;var baseWidth = Math.floor(window.innerWidth);var baseHeight = Math.floor(window.innerHeight);var aspectRatio = baseWidth/baseHeight;var renderer = PIXI.autoDetectRenderer(width*aspectRatio, height, {backgroundColor: 0xFFFFFF});// apply CSS to the DOM elementrenderer.view.style.margin = "0 auto";renderer.view.style.display = "block";document.body.appendChild(renderer.view);var stage = new PIXI.Container();Because the margin is being used to center the
  3. I don't delete it entirely - just graphics.clear() should be ok.
  4. Typically a node graph is similar to the following structure: The nodes are the circles which would be draggable. In my case the circles are Pixi sprite and the lines are drawn in a Graphics instance.
  5. I am working on something like this currently, but it's not generic enough to be shared. I'm using a single PIXI.Graphics instance to draw lines between nodes. Each time a node is dragged, I clear the Graphics instance and redraw the updated lines. This achieves the functionality you described. I do some optimizations here such as culling nodes outside of the viewport and lines that do not pass through the viewport. I also separate inactive lines (ie. lines that do not connect to the current node) to a separate container so I can continuously update active lines only (the lines that are mo
  6. I'm trying to avoid re-implementing the entire Graphics object, because there are some features that probably necessitate the calculations to be performed outside of the GPU (such as use of earcut for polygon fills). Perhaps we could just begin with a fast Line Segment object (using WebGL shaders) as an extension. I don't use either of those services but you can email/add me on Google Chat at josh (at) joshgroves (dot) com. I'm also on GitHub at this username.
  7. I am working on an interactive data visualization in which thousands of graphic elements have to be updated continuously as the user drags an endpoint connected to each node. When render times are too slow the visualization feels sluggish and breaks interactivity. A simple (non-interactive) example can be found here, which replicates my issue with render times: http://jsfiddle.net/grovesNL/vsso0gtb/ A significant amount of time is spent in garbage collection. I've considered using object pools in the Pixi library for WebGLGraphicsData.points and WebGLGraphicsData.indices (ie. stop setting
×
×
  • Create New...