Volumetric lines

There is that great volumetric lines algorithm by Sébastien Hillaire:
http://sebastien.hillaire.free.fr/index.php?option=com_content&view=article&id=57&Itemid=74
We have ported it to Unity, and the .unitypackage is available for download there.

Included in the package are a MonoBehavior, a prefab, and four shaders:
* Additive
* Alpha blended
* Additive fast (with minimal fragment shader instructions, no _MainColor, etc.)
* Alpha blended fast (with minimal fragment shader instructions, no _MainColor, etc.)

Just drag the the prefab in the scene and set a texture like the "Default-Particle".
Enjoy.

 

Brilliant! This looks gorgeous, with the light-saber effect and all. And best of all, pure shader-based displacement to screen-space!
While testing on Android, I had some weird glitches where some vertices where transformed in the wrong direction.
To make a long story short, turns out OpenGL ES 2 will normalize the mesh's normals before they get to the vertex shader.

If you're interested, I changed the shader so that the other point used for calculating line-direction gets calculated by using normalized normal + the current end-points position instead of expecting the correct position of the other end-point through the normal input.

Code (csharp):

1.            v2f vert (a2v v)
2.             {
3.                 v2f o;
4.                 o.uv = TRANSFORM_TEX (v.texcoord, _MainTex);  
5.                 float4 vMVP = mul(UNITY_MATRIX_MVP, v.vertex);
6.                 float4 lol = float4(v.normal.x + v.vertex.x, v.normal.y + v.vertex.y, v.normal.z + v.vertex.z, 1.0);
7.                 float4 otherMVP = mul(UNITY_MATRIX_MVP, lol);
8.                 float2 lineDirProj = _LineWidth *  normalize((vMVP.xy/vMVP.w) - (otherMVP.xy/otherMVP.w));
9.                 if (sign(otherMVP.w) != sign(vMVP.w))
10.                     lineDirProj = -lineDirProj;
11.                 vMVP.x = vMVP.x + lineDirProj.x * v.texcoord1.x;
12.                 vMVP.y = vMVP.y + lineDirProj.y * v.texcoord1.x;
13.                 vMVP.x = vMVP.x + lineDirProj.y * v.texcoord1.y;
14.                 vMVP.y = vMVP.y - lineDirProj.x * v.texcoord1.y;
15.                
16.                 o.pos = vMVP;
17.                 o.color = v.color;
18.                 return o;
19.             }

I also changed the shader to allow vertex-colors so that the same material can be shared for all lines.

I made a small wrapper for handling multiple lines in my monobehaviour, and in the code that sets up my mesh you can see that the normals for the mesh are now being normalized from start.

Code (csharp):

1.     void SetupMesh(params VolLine[] lines)
2.     {      
3.         Vector3[]   vtxPos = new Vector3[lines.Length * 8];
4.         Vector3[]   vtxNorm = new Vector3[lines.Length * 8];
5.         Vector2[]   vtxUV = new Vector2[lines.Length * 8];
6.         Vector2[]   vtxUV2 = new Vector2[lines.Length * 8];
7.         Color[]     vtxCol = new Color[lines.Length * 8];
8.         int[]       vtxInd = new int[lines.Length * 18];
9.        
10.         int iCnt = 0;
11.         int kCnt = 0;
12.        
13.         for (int i = 0; i < lines.Length; i++)
14.         {
15.             for (int j = 0; j < 8; j++)
16.             {
17.                 Vector3 p1 = lines[i].p1;
18.                 Vector3 p2 = lines[i].p2;
19.                 Color   c1 = lines[i].c1;
20.                 Color   c2 = lines[i].c1;   //c2;
21.                
22.                 vtxPos[iCnt + j]    = j < 4 ? p1 : p2;
23.                 vtxNorm[iCnt + j]   = j < 4 ? (p2 - p1).normalized : (p1 - p2).normalized;  
24.                 vtxUV[iCnt + j]     = m_vline_texCoords[j];
25.                 vtxUV2[iCnt + j]    = m_vline_vertexOffsets[j];            
26.                 vtxCol[iCnt + j]    = j < 4 ? c1 : c2;
27.             }
28.             for (int k = 0; k < 18; k++)
29.             {
30.                 vtxInd[kCnt + k] = m_vline_indices[k] + iCnt;
31.             }
32.            
33.             iCnt += 8;
34.             kCnt += 18;
35.         }
36.        
37.         // Need to set vertices before assigning new Mesh to the MeshFilter's mesh property
38.         Mesh mesh = new Mesh();
39.         mesh.vertices = vtxPos;
40.         mesh.normals = vtxNorm;
41.         mesh.colors = vtxCol;
42.         mesh.uv = vtxUV;
43.         mesh.uv2 = vtxUV2;
44.         mesh.SetIndices(vtxInd, MeshTopology.Triangles, 0);
45.         GetComponent<MeshFilter>().sharedMesh = mesh;  
46.     }

Thank you for the excellent code-base, this will be AWESOME to use for retro games (+special effects)!

Best regards

Anders

 

HI Guys

Thanks for sharing your great work on this.
When using this method the view of the line along its direction is distorted. Sebastien has solved this issue here.
Do you have plans to update the Unity demo using this method?

Jared

 

Hi,

first of all, big thank you @Mistale for your improvement/Android-fix.
I will do some tests by myself and then update the code based on your suggestions.
I'd like to support multiple line segments (just like LineRenderer). Have you done some research in that direction? If not, I will keep you updated with my progress on that matter.

@Lumen Digital: We're using the algorithm for mobile games. The quality-improved algorithm by Sebastien Hillaire apparently requires geometry shaders, therefore we're not planning to implement this algorithm in the near future, since we're overloaded with work right now. Might be that I happen to create a Unity port nevertheless, but I can't promise anything.

 

An alternative fix for mobile devices would be the following #pragma statement in the shader:

Code (csharp):

1. #pragma glsl_no_auto_normalization

What do you think is better?
The original code + the #pragma statement has fewer vertex shader instructions than the version proposed by Mistale, I think?!


Another thing:
I've tried to support multiple line segments, but I'm a little bit stuck right now.
My idea was to pass per vertex: the vertex position, the position of the previous point (via normals), and the position of the next point (via tangents). Here is my current (non-optimal) code:

Code (csharp):

1.  
2. v2f vert (a2v v)
3. {
4.     v2f o;
5.     o.uv = TRANSFORM_TEX (v.texcoord, _MainTex);  
6.    
7.     float4 vMVP = mul(UNITY_MATRIX_MVP, v.vertex);
8.    
9.     float4 prev = float4(v.normal.x, v.normal.y, v.normal.z, 1.0);
10.     float4 prevMVP = mul(UNITY_MATRIX_MVP, prev);
11.    
12.     float4 next = float4(v.tangent.x, v.tangent.y, v.tangent.z, 1.0);
13.     float4 nextMVP = mul(UNITY_MATRIX_MVP, next);
14.    
15.     float2 lineDirProjPrev = _LineWidth * normalize((vMVP.xy/vMVP.w) - (prevMVP.xy/prevMVP.w));
16. //                if (sign(prevMVP.w) != sign(vMVP.w))
17. //                  lineDirProjPrev = -lineDirProjPrev;
18.        
19.     float2 lineDirProjNext = _LineWidth * normalize((vMVP.xy/vMVP.w) - (nextMVP.xy/nextMVP.w));
20. //                if (sign(nextMVP.w) != sign(vMVP.w))
21. //                  lineDirProjNext = -lineDirProjNext;
22.        
23.     if (distance(prev, next) < 1.0)
24.     {
25.         vMVP.x = vMVP.x + lineDirProjPrev.x * v.texcoord1.x;
26.         vMVP.y = vMVP.y + lineDirProjPrev.y * v.texcoord1.x;
27.         vMVP.x = vMVP.x + lineDirProjPrev.y * v.texcoord1.y;
28.         vMVP.y = vMVP.y - lineDirProjPrev.x * v.texcoord1.y;
29.     }
30.     else
31.     {
32.         vMVP.x = vMVP.x + ((lineDirProjPrev.x * v.texcoord1.x - lineDirProjNext.x * v.texcoord1.x) * .5);
33.         vMVP.y = vMVP.y + ((lineDirProjPrev.y * v.texcoord1.x - lineDirProjNext.y * v.texcoord1.x) * .5);
34.         vMVP.x = vMVP.x + ((lineDirProjPrev.y * v.texcoord1.y - lineDirProjNext.y * v.texcoord1.y) * .5);
35.         vMVP.y = vMVP.y - ((lineDirProjPrev.x * v.texcoord1.y - lineDirProjNext.x * v.texcoord1.y) * .5);
36.     }
37.    
38.     o.pos = vMVP;
39.     return o;
40. }
41.  

which produces something like this:


Anyone any ideas?

I'm wondering if a trivial solution is even possible, because Unity's LineRenderer produces similar glitches (The smaller green line at the right in the screen shot is a Unity LineRenderer)

 

@j00hi: I'm using the shader as-is for both single-segment and multi-segment lines. Treat every pair of points in the line as a separate line when building the procedural mesh, so that point 1 has a direction-vector to point 2, point 2 has a direction-vector to point 1, point 3 has a direction-vector to point 4 and so on...

I'm not sure that I understood your questions completely. If not, please let me know.

Btw, I've refined the shader a bit since my last post, so that it now displays lines correctly in the scene-view without the need for being in perspective mode.

Code (csharp):

1. Shader "FrontLine/FrontLineShaderConstWidth" {
2.     Properties {
3.         _MainTex ("Base (RGB)", 2D) = "white" {}
4.         _LineWidth ("Line Width", Range(0.01, 100)) = 1.0
5.         _LightSaberFactor ("LightSaberFactor", Range(0.0, 1.0)) = 0.9
6.     }
7.     SubShader {
8.         Tags { "RenderType"="Geometry" "Queue" = "Transparent" }
9.         LOD 200
10.  
11.         Pass {
12.  
13.             Cull Off
14.             ZWrite Off
15.             //ZTest LEqual
16.             Blend One One
17.             Lighting Off            
18.  
19.             CGPROGRAM
20.             #pragma exclude_renderers d3d11
21.             #pragma exclude_renderers d3d11_9x
22.             #pragma vertex vert
23.             #pragma fragment frag
24.             #pragma debug
25.             #pragma glsl_no_auto_normalization
26.  
27.             #include "UnityCG.cginc"
28.  
29.             sampler2D _MainTex;
30.             float _LineWidth;
31.             float _LightSaberFactor;
32.  
33.             struct a2v
34.             {
35.                 float4 vertex : POSITION;
36.                 float3 normal : NORMAL;
37.                 float4 texcoord : TEXCOORD0;
38.                 float4 texcoord1 : TEXCOORD1;
39.                 float4 color : COLOR;
40.             };
41.  
42.             struct v2f
43.             {
44.                 float4 pos : POSITION;
45.                 float2 uv : TEXCOORD0;
46.                 float4 color : COLOR;
47.             };
48.  
49.             v2f vert (a2v v)
50.             {
51.                 v2f o;
52.                 o.uv = v.texcoord.xy;
53.                 float4 vMVP = mul(UNITY_MATRIX_MVP, v.vertex);          
54.                 float4 otherMVP = mul(UNITY_MATRIX_MVP, float4(v.vertex + v.normal,1.0));  
55.                 float2 lineDirProj = _LineWidth *  normalize((vMVP.xy/vMVP.w) - (otherMVP.xy/otherMVP.w));
56.                 float4 vMV = mul(UNITY_MATRIX_MV, v.vertex);
57.  
58.                 vMV.x = vMV.x + lineDirProj.x * v.texcoord1.x + lineDirProj.y * v.texcoord1.y;
59.                 vMV.y = vMV.y + lineDirProj.y * v.texcoord1.x - lineDirProj.x * v.texcoord1.y;
60.  
61.                 o.pos = mul(UNITY_MATRIX_P, vMV);
62.                 o.color = v.color;
63.                 return o;
64.             }
65.  
66.             float4 frag(v2f i) : COLOR
67.             {
68.                 float4 tx = tex2D (_MainTex, i.uv);
69.                                
70.                 if (tx.a > _LightSaberFactor)
71.                 {
72.                     return float4(1.0, 1.0, 1.0, tx.a);
73.                 }
74.                 else
75.                 {
76.                     return tx * i.color; //_Color;
77.                 }
78.             }
79.  
80.             ENDCG
81.         }
82.     }
83.     FallBack "Diffuse"
84. }

 

Firstly, thank you both for providing these useful stuff! In case you are still able to monitor this thread, I was wondering about the following case. I have used the shader above to create a curved line, but I get the effect of the picture below, which makes the curve to look more like a spine, instead of a continuous line. Could you suggest of a workaround to reduce this effect. I have tried various methods, from different textures to changing the mesh's vertices position, as well as different shaders(like this with tangents above) to no avail.

 

That's because at the beginning and at the end of each line segment, basically 2 textures are drawn above each other. Additive blending or alpha blending results in such an effect. I suspect, you are just stitching together multiple line segments using the original technique, i.e. your arc consists of multiple volumetric lines. With the original technique, this is the effect you get.

I tried to overcome this limitation by the approach described in post #5. You can try that, but I cannot guarantee that it will work in all cases because I haven't continued to work on that. However, maybe I will somewhen in the near future.

 

Hey Mistale, do you remember the reason for including those two pragma statements in the shader?

#pragma exclude_renderers d3d11
#pragma exclude_renderers d3d11_9x

Was there any problem with the d3d renderers?

 

Hey J00hi, I honestly don't remember why I excluded those renderers... If the shader works without those lines, go for it! I have a vague memory of trying something that only worked with OpenGL, but I don't see anything of that nature present in the current shader.

 

Ok, thanks - then I'll just leave those #pragma statements out.

It's been a while but I finally found some spare time to continue work on the volumetric lines. I've created an asset which will be available in the Asset Store for free. As an additional feature, I've added support for nicer looking line strips (without those "hinge joint"-like looking things between the line segments)

@.entity , that should be especially good news for you if you are still looking for a solution to your problem from post #7.

I hope, the asset will be available until the end of this week, it is currently in review. I'll keep you updated.

 

@Mistale regarding the asset: I've incorporated some of the code changes which you have proposed into the shader code - most importantly, that mul(UNITY_MATRIX_P, vMV) calculation so that it works for both, orthographic and perspective viewports. I gave you credit for your support in the source code by referring to your Unty forum username "Mistale". I hope you are fine with that?! If you want me to change something, include your mail addres, or something like that, please let me know. I won't make any money with the asset, it will be free.

 

@j00hi : That's perfectly fine by me

 

Hi j00hi! I am terribly sorry for being absent, but it turns out that I forgot to activate the ”watch thread" option and after posting I started working on other things and I just missed to check back. To this day though, my concern about these volumetric lines is yet to be fulfilled and your new information comes as a valuable present!

When all started, I just wanted to be able to “draw” lines in Unity (efficiently) and I was not expecting it would turn to be the trickiest task I met so far. I started my attempts by using this solution I found of drawing meshes with Graphics class, in order to save the overhead of creating gameobjects. It worked, but the lines were oriented to the direction they were created only. I learnt that a more efficient way than reconfiguring the mesh in every frame the camera moves (for a billboarding effect), would be to let a shader do it. I then found your post, but I had this little issue with the joints. You’re absolutely correct that the method I used when I posted, was to create multiple prefabs. Of course, this is something I want to avoid and, probably, I was not certain of what I was doing at this time. I am still at the process of learning the basics, I would say, and although I enjoy digging into all the different challenges, I am nevertheless far from efficient with all these game developing requirements.

Due to my mentioned insufficiency, it took my some time to refresh my memory regarding my previous tries with VolumetricLines. I finally remembered that the result in the picture of my previous post would be achieved with the shader Mistale provided. When I tried to paste the code of your #5 post into the Additive shader, there was the compiling complaint of not having tangent struct. I then somehow managed to combine the code in #5 with Mistale’s shader without errors, but then the material would ask for mesh tangents. I finally added a class that calculates the tangents, there where no errors, but despite that the mesh was there (I could see the wireframe), there were no drawn pixels. I thereafter quitted.

Since my long research with the shader method had not yielded very good results, my latest attempt was to create tube-like meshes, with the help of MegaShapes since I had the plug-in already, and just ignore the billboarding attempt. Now, however, I am looking forward for your updated package, in order to test it. I would value your advice here of what would be the most efficient, performance-wise, way to go, in order to create a lot of lines. Tube objects (I am also currently looking of how to combine several independent meshes in one game object with megashapes) or one (maybe a few chunks of a) big mesh that contains the volumetric line components that create the lines and billboard them with your shader? Or would your shader work with the Graphics method as well (I don’t see why not)?

Finally, I thank you so much for your first reply and I am grateful for the upcoming package. Please excuse my lengthy post, but I considered it as a way to balance my former absence. Somehow…

 

In terms of performance, I am pretty sure that VolumetricLines rendering is quite the same as using a LineRenderer. It has a little computational overhead to create those volumetric look, of course, but that shouldn't be really noticeable since it features a very fast shader-based implementation.

What VolumetricLines can achieve, what none of the other techniques can, is to let the lines appear volumetric. See the following screenshot. Depending on which texture you give the material, you can achieve the look of a volumetric laser shot or a solid tube.



On the screenshot, you can also see the new feature in action: the volumetric line-strip. It has some limitations, but for some cases (when the line strip behaves nicely and doesn't bend too much between the segments) it works quite well.

The other options from the website you refered to are also great, use one of them if you have to draw a huge amount of lines which don't have to appear volumetric.

 

Hi j00hi! I was coming back to the forum to make some more clear inquiries than those with the previous post and it seems you were patient enough to read the whole thing, so thanks a lot. It's the volumetric effect that I desire the most (actually this arc you have in the screenshot, is exactly the geometry I want to use and in the image it looks perfect), so I'll mind performance later. I have a question about this line strips of yours however (both in this screenshot and that on post #5). Have you edited the VolumetricLineBehavior to create one mesh that has multiple of these 3ple-quad components? By just adding the volumetric line shader on a unity quad (for example), would not give the billboarding effect. Are these vertexOffset uvs that make the difference? Maybe I should simply wait for the new package.

 

The arc looks quite good from this perspective but there are some little glitches when viewed from steeper angles... you'll see. So, it's not perfect but I believe, it's the best which can be achieved with the volumetric line rendering algorithm 1 by Sebastien Hillaire. He has proposed another volumetric line rendering algorithm which is computationally more expensive but also looks better:

• Volumetric lines 1: http://sebastien.hillaire.free.fr/index.php?option=com_content&view=article&id=57&Itemid=74
• Volumetric lines 2: http://sebastien.hillaire.free.fr/index.php?option=com_content&view=article&id=54&Itemid=56

But I haven't implemented the second one and I can't tell if I ever will.

The line strip uses the shader from post #5 without major modifications, actually. What's new is that I am creating a tailored mesh geometry for the line strip. One line strip has one underlying mesh which has all the data needed for the shader (stored in vertices, normals, tangents, uv, uv2). The source code is included in the package, so you can explore it in detail.

I don't know when the Unity guys will review the asset. It's in pending review state since almost one week. If you are in urgent need of the asset, i can send you a .unitypackage beforehand.

 

Thanks j00hi! You've been absolutely helpful and encouraging, while I think the tube-mesh objects method would not work very well and, concerning performance, I would have -sooner or later- to review the shaders method. Thank you for the links, I had visited these places before, I downloaded the assets, but due to my knowledge level, I didn't know what to do with them and I decided to discreetly look away . As for the glitches, I think I can imagine what are you talking about and I am sure they won't bother at all. While I was trying to deal with this overlapping additive effect before, I converted the volLineBehaviour script to generate single quads and despite the effect on the image below, which I found from that time, I was even thinking to use it as the final solution. It was far from ideal though and it was then that I posted here. Anyway, enough with this "nostalgic flashback", I'm now looking forward to the new package, i could wait for the official release and I could easily work with other things in the meanwhile. On the other hand though, I'm excited to test and experiment with the new goodies, so only in the case it is not a big trouble...ok I'll pm you my email! Thanks! ε(

 

Well, I don't seem to find the way to send you a private message. But it's ok, I can wait for the public release.

 

Thanks to j00hi's good work and generosity to offer me the new package earlier than its public release, I had the chance to try it and to find out how cool it is, with its new features and all! And, of course -as also j00hi reminded me-, deep respect goes to Sébastien Hillaire, the inventor of the algorithm.

It took me first some time to realize that the volumetricLine classes were nicely organized in a namespace and after I figured this out, it took me some more to introduce it in my things (I am using a method of creating arcs and I messed up local and world spaces, however, j00hi's one, that is to draw a part of sinus function, is remarkably smart). Finally, I wanted to have vertex colors, so I added some more lines of code (both in the behavior and shader scripts) and I was ready to go. Well, the mentioned glitches are there, but they are hardly noticeable. What will might concern me are the instances of the material used that have to be created for the lines not to interfere (thus, one draw call per line object). Is it the case, due to the properties of the shader? However, I have tested it with decades of lines and the performance is significantly good. So thanks again to everyone who contributed!!

(that is 3 lines)​

 

Hi, sorry for reviving an old thread, but I can't make this work.

I drag the prefab to scene and nothing happens, what am I supposed to do to the prefab, default particle already set.

 

Hi! I am not using the older package anymore, but I happened to still have the old one, so I tried with that also. However, it doesn't make any difference between the two, in this case. After you have placed the prefab in the scene, you won't see anything in editing mode. You need to run the game in Play mode. Also make sure that you have defined two different vectors for Start Pos and End Pos, although already by default they are set to (0,0,0) and (0,0,100). And of course focus the camera, either in the Scene window or the Game window to see the line object from a close enough distance.

By the way, I wanted to mention that before. The Volumetric Lines shader (together with the mesh behavior) for strip-kind meshes, is in my knowledge after a long research, the only method I found ( specifically for Unity), which is able to provide this billboarding effect for this kind of meshes. And by that I further mean a shader, which doesn't rotate the whole mesh around a pivot point, but its fragments separately. Awesome!

 

Hi .entity, when I set a value for end vector, all what I get is a full white screen:

http://i.imgur.com/SXpsYg8.png

 

Unless you are too close to the line object and then the white screen is the result of the so called "Lightsaber" effect, it might be relevant of how your graphics card handles the shader. In the first case try to move the camera backwards or better yet choose a different than the white color as Main Color and maximize the LightSaberFactor slider (which in return would eliminate the LightSaber effect) so that you will be able to see the line's main color. If modifying the light factor will result to change from the white screen to the color you have chosen for Main, then you have created the line object, you can see it and probably you are too close. If it's not the case, then something else might happens and if it has to do with my second assumption, then I have no idea about these stuff and it's only a rough speculation of mine.

 

Here's how it should look like with the settings you see in the inspector:

 

I'm using something similar as in this picture as a laser "projectile" (space combat) and cannot get a standard collider to work with it. How would I go about detecting it colliding with a box collider of another space craft?

Oh, to explain what's exactly happening: I'm shooting it in a direction but as soon as I add any kind of collider (without isTrigger being on), than the projectile sometimes randomly disappears and shifts position. Not sure what that's about.

Edit: Never mind, my projectile were hitting the bounding box around my own ship (it was extending beyond my ship cannons ), also I can use triggers instead of the colliders so it's less expensive. Hope I can still play particles at the entry point.

 

Hey Guys!

Since this asset is free anyway, could you add it to the GitHub? So I'd commit a few optimizations.

I've just downloaded it and there are a lot of room to improve the shaders code. I did it for myself but I don't mind to share these edits... if there would be an easy way to do so (like GitHub project).

 

That's a great idea. I will set up a GitHub project.
Thanks in advance for your contribution!

 

Here's the repository on GitHub: https://github.com/johannesugb/VolumetricLinesUnity
Please send me your GitHub username or email-address then I'll add you as a contributor.

 

Cool @Lex-DRL what optimisations were you thinking?

 

@Lex-DRL I would love to check those optimisations as well! Extra excited if they manage to reduce the number of draw calls when rendering multiple lines of the same material.

 

@.entity
I actually already managed to do this. But it forced me to rewrite the mesh generation scripts completely... And right now I'm literally use nothing from this asset: not scripts, nor shaders.
I can't share these scripts (that's why I suggested to share shader code only). But the basic idea is following.
Right now this asset stores positions of the next and previous points in the line as NORMAL and TANGENT semantics respectively. This doesn't let us use it with batching. Because when batching is on, Unity combines meshes to a single batch, transforming tangent and normal as vectors, not as points.
Instead, you need to provide normalized direction vectors to the next and previous points and then recreate the actual points positions in the shader itself.

 

@Lex-DRL
Thanks a lot for letting us know and I appreciate your sharing of the conceptual groundwork. I also apologise for missing the particular point, where you refer to the shaders only. Cheers!

 

@.entity
No need to apologise, man. You made me embarrassed.
I haven't even share any code here yet. So far I'm waiting for the access to GitHub project.

 

@Lex-DRL: Is this different than the code I used in one of my replies (referring to normalized direction instead of absolute positions)? See #2 and #6. Just curious if there are more performant ways.I essentially gave up on using this technique a couple of years ago because of (lack of) performance on android with many lines.

 

@Mistale
Sorry for reeeeeeeally late response.
Yep, seems like you used the same approach. As for performance... it's still faster then doing it on the CPU, isn't it?

 

Really sorry to necro this thread. Just wanted to check if anyone knew if the Volumetric Lines version 2 method was ever implemented to account for artifacts with intersection and some Camera Points of View?

 

No, I haven't implemented version 2. This year was kind of horrible for me in terms of finding time to further develop and improve the asset. However, things are calming down, the chaos is decreasing and next year there should be plenty updates and improvements. I'll add Volumetric Lines version 2 to the whislist.

 

Of-course. You're work is most appreciated. No stress. I would love to contribute I have a good amount of programming experience but I am quite new to unity and graphics and shader code. I was wondering if you could give me your personal opinion on how difficult a project like this is? What kind of learning I would need to go though to get something like this ported over to a unity asset?

 

If you would like to contribute, the project is on GitHub: https://github.com/johannesugb/VolumetricLinesUnity
I'm not sure yet whether it would be better to integrate Volumetric Lines version 2 algorighm into that one or create a separate project.

It's rather difficult to tell my opinion about the difficulty in your case... I've first implemented the algorithm in OpenGL some years ago and since I had little graphics programming experience back then, it took me a while. Porting it to Unity was rather fast - took me about half a week. A basic understanding of the graphics programming pipeline is a must. For the Unity-specific shader programming stuff, Unity's own documentation is good.

 

Understood. Thanks again for version 1 and I hope things calm down for you soon!

 

Finally, version 1.3.0 coming in the next days to the asset store.
Thank you so much, Lex-DRL, for your contributions!

 

I have observed a problem with the volumetric lines implementation in my asset and I just wanted to ask you if any thoughts come to your mind what could be the problem here.

Vertices flipping
At steep angles when close to a line, the vertices of the quad at the end of the line are flipping. I'm not quite sure why this is happening. I think it never happens when both line endpoints are in front of the near plane or (maybe more accurately: ) both are inside the viewing frustum, but it occurs if one endpoint is behind the near plane. See the following video:

Any thoughts on this issue is highly appreciated!

 

How can you make it look like a solid tube?

 

This is like, the best thing in all of Unity.

The. Best. Asset.

Totally fantastic. A lifesaver.

THANK YOU, Johannes Unterguggenberger!!!!

https://assetstore.unity.com/publishers/11022

 

Hi, I know this is a basic question, but I'm having trouble getting the volumetric lines to be visible to the camera. I keep looking back to the example scenes, but I can't quite pin down what needs to change.

 

I am very glad to hear that! If you want to share your work, I would be very interested in which games/applications it has been used for.

Comments like this one motivate me and encourage me to push on the development of the asset, or maybe of an advanced version of it or even the advanced volumetric lines algorithm, which is based on geometry shaders.

 

Please provide more information on what kind of problems you are experiencing exactly! Sharing screenshots of the editor window and the game view might help.

 

I just found the solution, as it turns out I overlooked the clear flag in the camera. Thanks anyway! This asset is exactly what I'm looking for. Thank you for making it, and thank you for replying so soon.

 

Hi j00hi,

First of all, great asset, I used it for laser guns in a VR glove demo, if you want to check it out. But now my problem: I've switched to the Lightweight Rendering Pipeline (lwrp) in Unity 2019.2.6f1, and sadly the shader doesn't work there. Is there a way to make it work in the lwrp? There is already a similar question in the asset store by someone else btw, but I figured I'd try here as well.

Thanks,
Hagen