Question: Can this extension be used directly from the Babylon master release? Otherwise, it’s a lot of work, and the fly-by-wire here is not as good as three.js
https://demos.babylonjs.xyz/greased-line/github-globe/
1 Like
As @sebavan said, doing a plugin in the same way than the decal map plugin would be great! We would have to decide if the code should be added to the core library or if it should stay outside: what do you think @sebavan? I think having it inside Babylon.js is ok if @roland can implement it as an optional plugin like for the decal map?
Also, why having a specific case for PBR? You should normally be able to implement the feature for both the standard and PBR materials with the same plugin material.
Hey!
I’m peeking at your code just right now.
This something I was not thinking about and sounds like a great idea. it will just require to rewrite the whole thing for the standard material (maybe I’ll be a lucky bastard and the plugin will work out of the box for the standard material as well - just to handle some discrepancies in variable naming in the shaders for std and pbr) 
However not all of the custom material properties are supported on both materials so setting some of them will have no effect on PBR (you have to use PBR material specific properties) but I think this could be handled. Is it a good idea to just console.warn that the custom property used has no effect on the mesh and one should use the PBR material’s property (for example let’s talk about the map custom property which is de facto albedoTexture in PBR) or is it a better approach to simply set the albedoTexture with the map texture provided in custom properties?
Many thanks!
r. 
The vertex shader works out of the box 
The fragment shader is not the same for the two materials so it produces black lines for now - but this can be easily fixed - I think having one plugin is a way to go!
The question which remains open is how to handle the custom properties properly.
Thanks again!
I am all for it to be part of core and following the decal map approach should solve it all ???
@wudao it would be great to add something actionable to your comments. saying it is not as good is one thing but at least explaining which area and why you think it is not as good would be great so that we can improve it ? It will be usable from master once the PR will be merged and lets thank @roland for the amazing work he is doing here instead. Babylon is open source, so please bear with people contributing on their own time.
3 Likes
I think it’s better to avoid console.warn for this and rather have docs that explains it.
Why not just directly using albedoTexture instead of creating a property in the material plugin? Again, the docs can explain which of the existing properties of the material are used by the GreasedLine plugin.
Tha’ts what I am doing for the PBR material, but differently for Standard material. This is why I was worried it could be confusing but yeah you’re right the docs will explain the differences and that’s it.
Thank you!
Not yet.
It was done in 30 minutes as a raw example just to show one of the ways how it can be done and not to compete with any other similar solution in BabylonJS or THREE or whatever.
2 Likes
Dude, the BabylonJS port is far more advanced than the original THREE.JS version with more custom properties and with PBR material support…
EDIT: The latest version is here:
1 Like
@Evgeni_Popov it was a very wise suggestion to use the same plugin for both materials! 
It works like charm!
@sebavan summoning you as well for the question
I’d like to support lines without any lighting just with a plain color (so it can be superfast) which will be a custom material property called color (maybe lineColor). I could set gl_FragColor at the end of the fragment shader to color but it will be a vaste of GPU cycles to do all the color calculations included in std/pbr shaders.
Is there a simple way to disable/skip certain parts of the shader, using a #define maybe or my second thought is is it possible to replace the whole shader block with getCustomCode in the plugin with an empty string? The third option is to comment out the code using getCustomCode and add an /* and a closing *\ somewhere at the end of the fragment code I am not interested to run.
Or GPUs are fast enough - don’t give it a sh*t and let the user use emmissiveColor?
Thanks!
you can use the pbr material in unlit mode to disable all computation of colors ???
Also, just to be sure, are you reusing enough code from the standard / pbr material to justify making a plugin for them instead of doing a custom shader? Because by disabling lighting, a big chunk of what those materials are doing is removed…
As @sebavan said, material.unlit = true for PBR and material.disableLighting = true should be what you need to disable lighting.
2 Likes
http://www.bootstrapmb.com/item/8634/preview
I think you can refer to this
Yes, that’s exactly what I want when the whole line (or line segment) must be the same color and not be affected by any lights.
Like this one for example:
Cool, this is exactly what I need. I was also planning to do a transplant similar to THREE.MeshLine to meet my needs, but I found that you have already done it so well. Thank you so much.
1 Like
Hey guys!
The good news is that I need to draw lines in our work project so I can officialy continue to work on GreasedLine and get paid for it but more importantly I will have time to do it 
I already created one PluginMaterial for Standard and PBR materials as suggested by @Evgeni_Popov so I am getting closer and closer to finish it, but it have some issues:
One of those issues is:
When I set the emissiveTexture on the StandardMaterial I can see some artifacts. It’s really strange because those pixels are gl_FragColor.a = 0.
This is the where I do dashing. When I uncomment the line with the if condition those artifacts gets discarded so clearly they have alpha set to 0.
if (useDash == 1.) {
gl_FragColor.a *= ceil(mod(vCounters + dashOffset, dashArray) - (dashArray * dashRatio));
// if (gl_FragColor.a == 0.) discard;
}
But now if I set material.alpha = 0.99999 (any value lower than 1) the artifacts are gone.
Can someone explain me what’s happening here please?
What about the if statements in shaders? I read a lot about them, how evil they are, but some articles says that modern GPU drivers are able to compile the code to overcome performance issues with ifs. Should I avoid them? I could use the useDash variable in the computation itself and do the right math to get the same result without the if statement, I could test both scenario’s performance on my GPU but it will be not an objective result so what are your recommendations guys? To IF or not to IF
Thanks!
alpha=0.9999 will cause the system to consider your meshes as transparent and not opaque, which means that alpha blending will be enabled for them. This may be your problem when you leave alpha=1: are you enabling alpha blending for your material?
As far as if instructions are concerned, if the condition only involves uniform variables, then performance is considered good, because all threads on the GPU will run the same code. If it doesn’t, then I think it depends, but in general I would say not to worry too much, unless you can show that it severely affects performance in some cases.
2 Likes
I get this, but why are the artifacted pixels visible only on the edges of the mesh and not inside the mesh? I set the alpha of ALL the ‘invisible’ pixels to 0 and the inside of the mesh is hidden correctly but the edges are still rendered even if the alpha of those pixels is set to 0, the same value as the inside pixels.
Yes, this makes sens Thank you!
EDIT:
Blending mode change doesn’t change anything, the artifacts are still visible.
No idea I just tried an educated guess based on the differences between alpha=1 and alpha < 1.
I think it would be easier to see what’s going on if you could provide a repro that works / that fails.