Fedor

Members
  • Content count

    44
  • Joined

  • Last visited

  1. That helps... for the PG example... http://www.babylonjs-playground.com/index2_5.html#460BZJ#17
  2. @sable, Fastcheck does not help me here. I need accuracy when picking UV coordinates. Fastcheck does picking using only the bounding box. And what do you mean with the double render - I have one scene.render() in the code...
  3. Ok, but in fact I am doing the same: the texture.update is my example is also in it's own loop... And you leave out Picking here, which seems to be the biggest problem...
  4. Do you base that conclusion, that Picking can be called every frame, on this example? There is a difference: this scene has a lot of objects with each just a few faces. My scene only has one object with a lot of faces. That may be significant. I tested it and put the picking function in the draw function so it is now executed every frame. Frame rate when doing nothing drops from 60FPS to around 40FPS. http://www.babylonjs-playground.com/#460BZJ#13 But in a sence you are right, it is not the only problem... I tried switching of the texture.update() (which fired every 10th second) and the FPS went back to 60: http://www.babylonjs-playground.com/#460BZJ#14
  5. Got it: http://www.babylonjs-playground.com/#460BZJ#12 On my machine the frame rate of this example is around 8FPS.
  6. @jerome and @NasimiAsl my application does not clean the canvas or redraws a lot - it just ad the last brush strokes on the canvas. This involves drawing the brush image 30 times on average per frame. This is nothing to the canvas element performance wise. The size of the canvas does not really affect performance while drawing. I did test 'stop drawing each frame', now using update() at certain intervals. Here are some benchmarks: Action: continuous drawing by holding down the mouse button and moving it over the mesh, measured on Firefox Drawing on 1024 texture, update every frame (provided something has been drawn): around 20FPS, allmost smooth Drawing on 4096 texture, update every frame (provided something has been drawn): around 5FPS, drawing stutters Drawing on 4096 texture, update only every 100ms: 3FPS (15FPS on Chrome), drawing stutters heavily Drawing on 4096 texture, update only every 200ms: 5FPS, drawing stutters heavily Drawing on 4096 texture, update only every 500ms: 8FPS, drawing stutters heavily Drawing on 4096 texture, not updating at all: 20FPS, but we don't see any results Drawing on 4096 texture, not updating and drawing commented out in the onMouseMove: ALSO 20FPS (same on Chrome), but we don't see any results I took the frame rate from the debuging layer. It looks like texture update is not the only problem. Holding the mouse button down somehow also eats a lot of time. But it could also be the scene.pick(scene.pointerX, scene.pointerY)-function which I had not commented out. Tested that: 8. Drawing on 4096 texture, not updating and drawing commented AND picking out in the onMouseMove: 45FPS (55FPS on Chrome) --- WOW!!!! Tested it a second and third time. Looks like Picking is even more time consuming! I'm now trying to mock up a demo in Playground to proof it and allow further investigation.
  7. Still working on my sculpting tool, I am now testing basic texture paint functions. I am using a single dynamictexture that is only updated just before rendering IF anything has been painted. When I keep the texture small - say 1024^2 -, the speed is reasonable, when increasing it - to 4096^2 - performance drops dramatically. I am pretty sure it is not the drawing functions or the canvas, I have created applications in the past that draw much more in a single frame then I do now. (see http://www.traxeditor.com if you like) It looks like it is the Dynamictexture update() method. Does anyone have any ideas how to speed it up or work around it? Is there an other way to paint the texture?
  8. I think that is what Babylon does. But that seems to be slower then this routine. It involves copying buffers and it does all normals on my 50K model...
  9. Using facet data would not help here because I need updated normals for just a few facets. I have coded a function that recalculates the vertice normals. It depends on an extra buffer for the vertice to triangle relation. I also stored indices, normals and points in my own object to have quicker access. calcNormals: function(list) { var tri_normals = {}; var newData3 = new Float32Array(3); var idx = 0; var _p2t = base_model.p2t; var points = base_model.points; var poly = base_model.poly; var normals = base_model.normals; var geometry = base_model.mesh.geometry; var tlist = []; for (var i in list) { // Recalculate for every vertice in the list var currPoint=list[i]; tlist = _p2t[currPoint]; var normal = new BABYLON.Vector3(0, 0, 0); var tl = tlist.length; for (var t = 0; t < tl; t++) { // Calc all triangles connected to the vertice var currTri=tlist[t]; if (tri_normals[tlist[t]]) { // If we already got this one, use that var tnormal = tri_normals[currTri]; } else { // If not, calculate it. faceId = currTri*3; var vertex1 = BABYLON.Vector3.FromArray(points, poly[faceId] * 3); var vertex2 = BABYLON.Vector3.FromArray(points, poly[faceId + 1] * 3); var vertex3 = BABYLON.Vector3.FromArray(points, poly[faceId + 2] * 3); var p1p2 = vertex1.subtract(vertex2); var p3p2 = vertex3.subtract(vertex2); var tnormal = BABYLON.Vector3.Normalize(BABYLON.Vector3.Cross(p1p2, p3p2)); // Keep it for later use tri_normals[currTri] = tnormal; } normal.x += tnormal.x; normal.y += tnormal.y; normal.z += tnormal.z; } // Divide to get the average (no need to normalize it!) normal.x/=tl; normal.y/=tl; normal.z/=tl; // Store it in my normals array and feed it to the mesh idx=currPoint*3; newData3[0]=normals[idx]=normal.x; newData3[1]=normals[idx+1]=normal.y; newData3[2]=normals[idx+2]=normal.z; geometry.updateVerticesDataDirectly(BABYLON.VertexBuffer.NormalKind, newData3, idx * 4) } }, Works fine, hope it will be of use for others. If anyone has an idea how to increase the speed, let me know.
  10. Well, I am building a sculpting application in which I will change a small number of vertices per frame on a now 50K vertices model. The updateVerticesDataDirectly-method helps me to change just them and not have to swap the entire vertices buffers all the time. But to recalculate the normals every frame I now use computeNormals and then use updateVerticesData to swap the entire normals-table.
  11. That sounds like a plausible explaination... @Deltakosh can I ask for an extra feature? It would be great if there would be a function that would (re)calculate a single normal...
  12. if you comment out the test++ line (#124) you will notice that it will only cover the top of the sphere AND that test #2 uses different colors while it should only paint vertices red: http://www.babylonjs-playground.com/#DMYNYQ#13 Now multiply it again and it does what I've asked it to do, color vertices red all over the sphere: http://www.babylonjs-playground.com/#DMYNYQ#14 (tested on Chrome and Firefox on Ubuntu 17.04 machine)
  13. Model poor quality in babylon

    Indeed, that is also my conclussion @inteja. Good explanation @Wingnut, thnx
  14. Okay, here it is: http://www.babylonjs-playground.com/#DMYNYQ#10 It shows that setVerticesData and updateVerticesData do not differ in speed all too much. updateVerticesDataDirectly indeed is a lot faster. I am updating about 100 vertices per frame in this benchmark. You may want to try this in all major browsers, there is a huge speed difference between Firefox and Chrome. The latter one being much slower for the first two cases and twice as fast for 'Directly' One more question for @Deltakosh: as you can see in case '2' I pick a number between 0 and the number of vertices and multiply that by 4 (four numbers in a colour). Strange enough I only got this case to work when I multiplied the idx variable by 4 a second time...