Does the lineSystem not work with the defaultPipeline DoF?
I am currently working on this: https://playground.babylonjs.com/#Y7CS4N#240
But I somehow cant get the Tilt Shift effect I was going for.
So I made a small scale test, to see if it even works, but could not get the focus set up…
https://playground.babylonjs.com/#Y7CS4N#241
Am I missing something or is it a technical limitiation?
Hi and a warm welcome to the BJS community,
I am not sure to understand your question in full. From your PG, it’s clear that DoF works with the line system (in fact, with all GUI elements).
So it must be a matter that you cannot find the correct setting to blur either the forefront or back of your lines, yes? I am not sure what you want to achieve (should it blur in the front or in the back?). Anyways, you have a number of parameters for your camera in there but depending on what you want to achieve, it looks like you did not account ‘lensSize’. As for the arcRotateCamera you would need to adjust this also depending on your radius from target (again depending on the effect you want, no faen clue what it is). May be you could post a draft pict or mock-up for our understanding? Thx and have a great day 
Dear mawa, thank you very much for the warm welcome and taking your time to respond.
I am sorry for not having been more precise.
Technically, you are right, the dof works. But its an all or nothing option.
Maybe you are correct and I am just to dumb to find the right settings, but thats why I implemented the gui elements. Even after fiddling around with the sliders for quite a while, I could not find the right combination to achieve the desired result.
I expect to get both blurry, the foreground and the background, only leaving a shallow area of sharpness at the core of the particle system. Basically a tilt shift.
But until now either everything is blurry or nothing at all…
(It almost feels as if the origin of the line system is used to determine the blurriness of all lines at once.)
I did not test the lensSize yet, but that one does not affect the position or length of the focal area. It rather amplifies the effect, no? I will add it to my test and try it out, though.
P.S.: I plan on disabling the zoom, so setting the focal point dynamically is not needed.
I can assure you that you are not dumb. Depending on size, the difference can be really tiny (smaller than the values you can get from the slider (like 2 decimals more)
A picture/draft would really help if it’s not too much of a worry for you to create one? Even very drafty.
No, but the target of the camera is, since you are using the arcRotateCamera. The fov is calculated from the camera distance to the target. When you zoom-in (actually reposition your arcRotateCamera on the radius to target, fov comes along and if your scaling is really small… again, the difference can be so minimal that you can’t even see it. To make sure fov follows when you ‘zoom’ (or better said, approach your target) with the arcRotateCamera, you need to adjust at least fov with a multiplier of the camera radius to target. It’s actually a lot more complicated to explain (especially for me since english is not my language 
than to do. Reason why I small mock-up, schema or picture would help setting up the base of a PG for you…
Edit: Actually let me check on that
I just noticed you are using the FS advancedTexture, so forgive me for the above, but you may be right in this case. You might have to use another method for the advancedDynamicTexture…
Edit2: Actually (my apologies) you were right and in a way it’s logic. Since the advancedTexture is 2D depth is not accounted from the camera view on the 2D advancedDynamicTexture.layer. In fine, it’s me beeing dumb So even if I createForMesh I will still remain in the 2D environment with the advanced texture. So, there must be (and I somehow know there is) another way to draw lines in the 3D environment. I just don’t recall how. Give me a minute for a search and I can callin some people on your case who will likely be able to help. Again, my apologies for the confusion.
@PolygonalSun @Evgeni_Popov Sry, I am unable to find the right answer for this. May be yours can kindly help @morph3us find best solution to draw lines in the 3D environment (that would work with fov). I figured that the line system with advancedDynamicTexture and the 2D lines would both likely not work (since they are 2D). I’m quite sure there’s another way but I don’t recall it.
Edit: Stupid me, just realized and I even used it before, isn’t it simply with createLines?
var lines = BABYLON.MeshBuilder.CreateLines(“lines”, {points: myPoints, updatable: true}, scene);
Hey mava, there is absolutely no need to apologize. Neither for sharing your thought progress, nor for your “poor english”. (It’s not my mother tongue either and you are very well articulated!) I am very grateful that you are invested in my problem, thank you so much!
When I started out making the scene, I actually started with “createLines”, but there are a few caveats:
1.) It makes one continous line. Because of this I can not alpha blend the lines depending on their length correctly, because alpha values are stored as a per point basis, not line segment. This means that each point would dictate the alpha values of two “independent” lines.
2.) I circumvented this by creating a seperate line for every connection, but that lags. Maybe I did something wrong with the implementation, but it immediately dropped to 30fps and got worse the longer I let it run in the background. Thats when I started using the lineSystem.
I tweaked one of the “createLines” examples and still can not get the DoF to work.
Are you sure this should work?
The CircleOfConfusion post process used by the DoF effect needs that the objects write to the depth buffer, but the LinesMesh don’t update this buffer because alpha blending is enabled by default. You can try to set needAlphaBlending to false like this:
Another way to make it work would be to use something other than a line (like a thin tube for eg).
Interesting reading, as always 
. Seems to be more tricky than I would have thought.
Hello evgeni, thank you for your input!
The problem is, that in my initial main scene, I want to fade the lines in and out, based on how far apart the start and end point of each line segment is. (see first link in first post)
Disabling the alpha blending alltogether brakes this effect, as I can not (rightly so) set the materials alpha values anymore.
Also it seems that this only works with single lines, not a whole lineSystem, as I didnt get it to work in my test scene. (But maybe I jsut did something wrong.)
So yeah, looks like I want to do something impossible… too bad…
I fear for bad fps, if I use something else than a lineSystem, so I am not really thrilled about switching.
Should I take Evgeni`s post as answer or does anyone have more ideas?
I think you should test with tubes and thin instances (Thin Instances | Babylon.js Documentation), the perf should be good as you will get a single draw call in that case.
From my experience, it will be very hard to get a more reliable and accurate input on this particular subject. I think you can rely on this answer. Doesn’t mean you cannot twist it or combine it to ‘do your own thing’. Something I often do. But as for the base, you can be pretty sure that it’s just like this. I understand you can be a bit disappointed that the ‘easier method’ does not work (and so am I) but the sooner you get over it, the sooner you’ll have the new method up and running, right? In the end, I believe the effect you want is totally achievable, it’s just that it is going to require some additional effort. Again, sry for this outcome.
I believe SPS will have the same issue, correct? I quickly made a test but it seems to do the same, can you confirm?
@Evgeni_Popov The wiki says thinInstances are only for static meshes and I cant find an “updatable” like in the lineSystem. Is this really the way to go?
@mawa
It looks like the particle system suffers the same problem, yes.
It behaves the exact same way as the lineSystem does.
I really didnt want to sound miffed overall, sorry if I did.
In the long run, yes, I have to think of another solution, but I am tired…
Had almost finished this thing in Three.js before and it didnt work out either, so I am a bit worked out on this…
Regardless, thank you very much, both of you, for your input!
Not at all. I know how it is and I’m with you. May be take a rest from it for today and return here tomorrow. You might have a fresh mind and so would we Sometimes the solution comes when you don’t look for it all too hard. I’m still sure we can find a way…
You can update the mesh(es) matrix(ces) directly in the matrix buffer to make the mesh move. They don’t have to be static. Now, if all meshes are moving in a frame, maybe it’s not the right solution… But the only way to know is to test it, if you don’t have hundreds of thousands of meshes it could still be ok.
Just a little update, I will put this project on ice afterwards…
I was able to create a static replica of the system using normal geometry:
Thin Instances obviously dont work, because the cylinders have to have different length.
Although I tried pretty hard, I didnt get the DoF working in the DefaultPipeline, so I resorted to the LensRenderingPipeline. But the effect I achieved is, as you can see, very blobby. So yeah, I dont have no patience for this no more. Too bad, really, but thanks for your input again!!
Howe
I agree it’s kind of sad. I also wanted to have this thing working. I’d say we would really need to find a way to have DoF working with the line system (if by any means possible). It kind of feels odd that it works with all advancedDynamicTexture components except this one. On the other hand, it’s understandable that it doesn’t do it but yeah…kind of sad. That’s all I can say. Thanks for sharing your efforts and results. May be one day we’ll figure this out better.
Thank you for being here and making this place worth posting!
@Evgeni_Popov can you think of any tricks we could put in place to make them compatible ?
