 It's 11.29 right now, and we are about to start the line art presentation. Well, I've got more people than I was expecting, and welcome! So, is this thing rolling? Okay, I guess so. So, line art and beyond. So, I'm Yiming, you probably know me as the line art guy for the past few years. I have been developing this non-photo realistic renderer or thing for grease pencil in render for the past few years. And on and off, of course, I'm not a full-time developer, and initially this starts as a Google Summer Code project, and I just keep optimizing the thing and make it better and better. And they gave me 50 minutes. I probably won't take as long time, so you guys will have more time to interject and maybe questions, and I could answer them as good as I can. So, there are so many of you here, and I'm not sure how many of you is more on the programming side. Could you give me a show of hands? Okay, and how many of you guys are more of the user guys and artists who use... Oh, okay, there are way more artists than programming guys. So, that's expected. I will make sure this presentation is understandable for most of you guys and make it clear and let you understand how the line art works and the ways we are planning to improve it. Let me see. Developers probably would understand it better for some concepts, but I don't know. If you have any questions, just ask, and... Sounds right? Okay, let's begin. So, some brief history of me and the project of line art. So, I am an industrial design major, so it is my job to actually produce some product renderings of gadgets and stuff, and I need to do three view or orthographic views to give them to patent registration for these kind of stuff. And I was trying to use an open source workflow for this kind of thing. And at the time, when I was in college, there wasn't any very good solutions to doing this kind of line renderings for products. There is one as freestyle, and there is another one which uses the drawing workbench or free CAD, but these two are not very much to my liking, and sometimes they have very serious problems that prevent me from using them. So, I kind of feel like, okay, I probably would write a tool my own. And as well, because I am in college at that time, so I have plenty of times on my hand. So, I think, well, it probably won't hurt, right? I just dabble around and try things. So, initially, I was doing freestyle and I found a lot of problems. I probably, you guys too, the problems with freestyle is that it might be very good for stylized renderings. It has a lot of adjustments and line styles you can use, but there are some fundamental issues with the way it generates these lines. Like this, for example, if you see these three intersecting cubes, you probably wouldn't imagine the line to be looked like that, but this is what freestyle spits out without any adjustments. I could probably make it work correctly if I subdivide the cube, but that kind of defeats the purpose, because if you cannot output a correct result on a very simple mesh, then there's probably something fundamentally wrong with how you process the geometry. And be it, it's a little bit better for organic models because you already have a lot of triangles, but it's kind of not to my liking for my purposes. So the main thing is ambiguous visibility. So you can see some of lines should be visible, but not some of the lines should not be visible, but still visible. And another problematic thing with freestyle is that the performance is dependent on feature sizes inside a camera. So you could have a very, very complex model in the camera, but it's very, very far away. And at this time freestyle would be super fast since it's a very small tiny dot on your screen. But if you zoom in, especially when you want to see a structure of a very complex mesh, once you zoom in, the thing fails up the screen, that's where the problem begins. You would see a lot of flickering lines and the performance goes right down here. And of course no intersections, that was the common problem. So the fundamental thing I have to deal with at first is the sub-edge visibility. So freestyle is not going to let you have a portion of edge that is visible and the portion is not. And when simply find the view map of freestyle, it kind of gets you through this weird result. So my program initially it had nothing to do with Blender. I probably just a user for Blender at the moment, and I know some OpenGL and I did some coding on my own and I did a line rendering program standalone which imports OBGA and spits out some renderings that I could use. And at the time it doesn't even have PNG output. Like all these images I have to use screen grab to actually produce usable results. So I was pretty dumb. I mean I have limited skills, that's understandable. And of course these are all my artworks and this was a more complex one and probably available on my art station anyway. And if I were to load this model into freestyle at this close distance, all the invisible-invisible relationship will be like unacceptable and also very slow. So next I get to know this thing called GSOC or Google Summer of Code and Blender happens to be mentoring this GSOC activity. So I was suggested I could port this tool into Blender so that more people can use it. And basically initially the first two times I did it within the mind of I just play around and explore some algorithms. And maybe it could be useful, but I wasn't really thinking about the production stage of line art. So at that time it's more like a chaos stage. But somewhat okay because in 2.7, 2.8 times the internal structure is a lot easier to handle. And so at that time it's called LANPR. I don't even know why I called it that is probably because my net handle is little a and just little a NPR. And it has three modes CPU, GPU and a image tracing mode. But well quickly we found out these other two modes are not quite useful and I focus my energy on the CPU mode is that is the traditional line art algorithm. And this is the model I got from BlendSwap. I forgot credit artist I should probably add in the description later on afterwards and it works. And at the time line art was a rendering engine. That it has some abilities to do something like renders quickly and you can adjust afterwards without like freestyle you have to render again. But it's kind of hard for us to configure and the material is not compatible with what we have in inside blender. So well it at least produce a result I don't need to use screen grab anymore. So I consider this mostly a success but it's not really useful. Okay to make it to make it as a render engine probably didn't release the full potential of this line art algorithm. So later I was suggested to put this into grease pencil. There are some good things about it because well with line art you get very accurate occlusion info and that info could be used to generate grease pencil lines. And grease pencil lines as we know are editable and the artist could use the result as intermediating and customize on the results to get whatever they need. So it was much more flexible than if I were to do a render engine. And but the adaptation is pretty limited afterwards I found out that a lot of things didn't go as what I expected. In the east things are probably better case in Japan and China we had a lot of comic industry manga industry and they like the technical pen kind of look very much. But I found out it's not the same with what we have what we have here in the west. And also there are some issues that out of my hand. First is the grease pencil aliasing that's been a huge issue and as far as I know of it's still issue in GP 3.0 and we probably gonna revamp the how we render the grease pencil thing to get it. Right and the main problem are slow and the still very intertwined logic. Okay I was I was thinking okay this logic seems to be pretty nice and flexible but in in the end it confuses a lot of artists and users you have to filter by collection by object and as you know you probably use line art and all the intersections are spit out together and you cannot do anything about it. And that is very hard to configure and another thing with the modifier setup of line art is that composition is a bit hard because modifier only gets their input geometries from this current view layer. And if you want to if you want to have another view layer just for the Christmas or it will not get the objects. So it is kind of binded you to using the current view layer and you cannot do anything about it. And finally we have a lot of crashes of course I'm not a that professional and developer so it took me a lot of wires to track down the box and stuff. So why is line art like this so in the beginning I was thinking okay this method is probably going to be better than freestyle and probably going to be faster and something didn't go as expected. I probably would share with you guys and and let you guys know what exactly is happening under the hood of line art and share with you guys about how we could improve upon this design or revamp to a new design who knows. So line art is kind of weird because it's a geometry based algorithm. I mean this title is a little bit wrong because everything is geometry based right. So what I'm trying to say is it's not based on sampling or pixels so line art doesn't rely on pixel information to calculate its result but relies on only the geometry or the vector info to like generate lines and finally they render into pixels. So that's what this title actually means. So if there is ideal like floating point there's no full floating point precision issue line art ideally could generate a precise cut of this geometry of which line is visible and which lines not. But that's not the case with modern computers. We all have precision issues with floating points. So it has pros and cons to calculate stuff in the geometry stage rather than pixel stages as you might see in the following slides. And also it's not suitable for everything. I designed line art in the mind of I want to use this for product rendering and not quite for the character rendering which a lot of you probably do. So it's not going to be as suitable for like organic models. It's purely decided by the fact that line art is designed this way. So let's take a look. So stage one line art first loads the geometry. Nice. So it detects where the contour lines going to be and all the other feature lines. They record these lines and project them into your camera like this. So now you in your camera you have like all these lines presented. And the next stage is line art would try to divide the frame into different density blocks and using these blocks to assign. Threads to work on the occlusion of these lines with all the triangles. Okay, if you have a triangle that's in front of line then the line is occluded in that segment. Easy to understand right. So like this. This is what one thread sees when it's working on the occlusion of one piece of line or an edge or whatever. So it detects where the line is and is check check out the square which contains triangles and lines where they overlap. They would check for the occlusion whether the triangles in front of the edge or is in back of the edge or it's partly and then it registers the cuts as you can see all the one segment means that these segments are occluded by one layer of face and after you paired all the lines with all the triangles they might cross you get a full occlusion and you basically register the cuts on an edge. So it's the segment of the edge that actually has the occlusion info not the whole edge. And when we done everything we got occlusion right. Sounds easy right okay. We handle the cuts much better than freestyle would because obviously we handle the occlusion info at the sub edge level it's not per edge so we can have the edge disappearing at any segment or reappearing at any point and it will not be erroneously like registered. Yeah it is simple right but of course we have a lot of caveats so consider this we have three kind of situations where the triangle could be in related to the lines. First line is in front of the triangle of course the triangle does not occlude the line it doesn't do anything. And the second one is the triangle in front of the line and it will cut the line in between the occluded places. And the third situation is a little bit more like complicated you have to decide where the line should pass through the triangle and cut them appropriately. And you think this is all nope we have a ton of other situations which it took me like maybe one or two years of unenough work to get every kind of situation exactly right. So you have maybe the lines originating from the triangle or the lines within the triangle or even the line is sharing a point with the triangle. And accounting for the direction we are cutting so the lines directional you can't cut it from left to right or the right to left you get different results and accounting for all these situations the cutting algorithm actually gets quite complex. This is one caveat and also the acceleration structure of course when you have a million of phases in your scene you won't want to compare one edge with every single triangle and see if they are occluding or not. So we have this timing structure to allow us to see which triangles might have potential to collide with the line and building this acceleration structure does cost us like time. It's just like building BVH in the traditional sense of like rendering. It's like the same thing the quadtree they call this the quadtree because it's like four directions and they call this the quadtree. The quadtree is basically a 2D BVH and it's used to determine like colliding pairs and building this structure costs time and running this structure might still requires to have logs and which degrades the performance a little bit more which we were talking afterwards. So there are a lot of caveats to this and I spend a lot of time to stabilize this algorithm and this was the actual tile visible in my standalone program which doesn't exist anymore but I have found screenshots of this program and you can faintly see the bigger tiles and smaller tiles on the more densely packed areas. So this is the acceleration structure. Let me see. Okay. Apparently, only the counter is not enough. So in the, especially in the manga industry as where I come from, I come from China, the manga industry is quite big and shadows are a highly requested feature because we want to have like trace traceable lines around all the project as charlots. And it's sometimes weird to have a character that has lines, but you don't have like shadow lines around the projected area. So shadow has been a more important part, but I'm not sure in Europe. A lot of people would use this, but this took me some time to actually develop. So let's see what line art does with the shadow. So you have a light, of course you're projecting shadow and it's either going to be a directional light or a point source. Okay, light only supports these two kinds of lines. It will treat the line, treat the light object as the camera and do the same projection and occlusion test as if it was the camera. Then we would find out that the lines visible to light will be the same as the will will become the shadow terminator. So this way we determine how the shadow would look like and we can cast this back to any receiving services like this. Like one edge of shadow can produce multiple edges of projected lines and then we run the occlusion test again. We get a perfectly rendered shadow scene in line art and this basically concludes what line art does. Of course there are chaining, there are simplification, but these are like steps ran afterwards of the main algorithm. So challenges about shadowing. So it is hard to get everything right and we need to also consider what looks good from what's right. And we cast shadow onto faces and we want to make sure that these edges on triangles doesn't interfere with each other. So you cannot have a triangle that's occluding an edge that's directly sitting on top of it. So that's going to be a problem and also with shadow in mind we can have region filtering as you can see all the lines inside the shadow area are removed. And this could give us very good flexibility for artistic expressions I believe. And also additional feature is the enclosed contour. This modifies the occlusion map and enclose all the shadow regions and remove anything that's lit in between. For you you can see that we have reduced the complexity of the scene but also preserved a very clear structural representation of the entire lighting situation. Artists probably would like this kind of thing better because it's decluttered and you can have more expressive lines this way. This was from another friend who gave me these models and let me test and guess what within closed contour feature you can have like this charcoal drawing look if you apply some effects on top of it. So this has been good. So with line art mechanism down let's talk about the technical limitations of it and how we're going to improve it. And of course later we're going to see a design of line art in geometry nodes which is probably a lot of people would like. Yeah of course I'm looking forward to it as well but I don't have consolidated design yet so let's see. On the performance side over the years I have learned that we probably don't want to like beat a dead horse. Like we already optimized line art algorithm for a long time and some things we have tested and failed to improve and we probably want to go different route than the current solution is providing us. So basically we want to tackle the locking issue and changing performance and maybe we want to switch out to an entirely different algorithm for different cases such as organic models. Let's talk about the thread clashing as you see we have the acceleration tile structure that a triangle could span across multiple of these tiles and if happens to be if multiple threads happens to be working on that same triangle. They will have to use a log and it's preventing this line art to be more performant than if it will not have logs I guess. Let's see so we could technically like copy the entire geometry for every single thread this this way we won't have any like interference between all the threads but I don't think that's going to be a viable solution. So we are going to take a look at what's coming next. I'm trying to propose a alternative algorithm for occlusion test for line art which is using limited samples along at niche and using ray tracing and to determine where the line is visible and where it is not. And as you might imagine this would lead to some uncertainty between the sample points and if a feature is smaller than a sample point it might not register. So it is faster it doesn't need to use logs so it's able to run GPU. So this is probably something like a lot more artists would desire because it's much faster to adjust and everything. It's less exact but probably not going to matter if you are doing organic models since you like drawing itself has imperfections and little imperfections like this probably won't matter in a large scale especially if you have thicker strokes and stuff. So this is one of the things I would propose to replace the current legacy line art algorithm. The next I would give a shout out to another fellow named John Wang Ziwei or I might be butchering her name but this is a newer fully GPU line art algorithm developed by him or her and it does all the tracing on the GPU it does even all the chaining on the GPU which is probably much more suited for organic models. And but it also has some problems because like line art you can filter where your line came from your line could came from collection one or two you could came from a cube or sphere but this algorithm like the image tracing algorithm will not be able to do that. But for a uniformly styled image is probably more suited so and it's faster so depending on the usage this algorithm might be preferred and you can check out his work at the following URL. And the next one we are going to tackle the object loading thing and of course shout out to Sebastian and he helped me like optimize a lot of line arts object thing. We used to take a lot of time to triangulate to find out the adjacent faces and to send these data into line art but we we realized do we need really need to have adjacency info like we probably don't want to have this kind of info for speed. And since if you probably use line art you know there's an option called allow overlapping edges which basically it does not check if an edge is from a triangle instead it would check the endpoints are the endpoints the same from the triangles and points and that turned out to be not slower than I expected. So we probably don't need to have adjacent adjacency information so we could save a lot of time by removing this step and directly feeds all the triangle piles into line art. This could be a optimization plan. On the overall design part so the modifiers are evaluated with dependency graph or by dependency graph or I would say that so it's currently a hack for line art to load the entire scene. Because line art object is also in the scene it cannot possibly depend on the scene and also write into the same thing again. So there are some hacks to allow this to work correctly but this is the root of a lot of crashes you've been having. And of course other design factors like line types and high precision cuts for like density pack models essentially like the current approach needs to be optimized for the later upcoming node based line art implementation. So we cannot directly read scene that's not conforming to the design standards of Blender. Instead we could feed geometries into line art as like in the geometry node basically and we can get rid of all the attributes that we are previously recording in this edge. Because once we geometry node the line art we're going to use the generic attributes instead of this hacky approach of like intersection ID, object ID, material silhouette, recordings, whatever. So per segment attribute it's going to be like this so when you are trying to filter a result from line art you will probably going to need to assign attributes to input in geometries as filter groups and afterwards when you are done calculating line art we can connect the output and separate the geometries to shape differently with the same filter group you assigned previously and this would also tackle the intersection filtering. So as you may know line art doesn't really filter the intersection correctly but if with attribute based filtering you can assign different attributes to different input geometries then filter the intersection of these attributes like the red lines are going to have both attributes from one and three and the yellow ones are going to have two and three and by identifying these attributes you are able to separate these lines and shape them differently. So a generic line visibility node is probably going to be the next line art geometry nodes design and it will extract the core visibility feature and allow you to input a geometry and camera of course to an output the result edge segment as curves so basically look like this. The cube and okay two cubes and we can assign different groups like a group one and two we join them together send into the line art node and we separate these geometries with group number one. And if the group is one it goes to style group one and if the group is not one it goes to two and this way we have a more generic way of doing line art in geometry nodes. Let me see and for feature line detection we can also expose that to geometry nodes instead of doing it all inside line art. And this is how we could detect the crease lines like if you have a cube and you have an edge angle and you find edge angle is less than a certain threshold we can determine that this is a crease line. And then we record this crease line as attribute and store it in it and connect the geometry into line art then line art would know that we need to calculate this line and so we don't need to have line art to do this hacky feature line detection. Filtering by group like this so you could have a visible group and a attribute group like group one you form an ad logic so this this way you could filter out what's inside group one and it is also visible. And this could be the simplest visible line filtering schema of the new line art design and also it's much easier to do intersection filtering as well. So you have you want to show like the intersection lines between group one and two basically you just put an end in between and the lines who have both group one attribute and group two attribute can be filtered as the intersection line. So it's much easier to understand and much less confusion to the users. So the most frequently asked question for me is that can we even make this more generic like line visibility ability is good but we kind of want to expose a more generic version of line art into geometry nodes like this. So you have some geometry you first detect feature lines as one node do visibility as another node the chain lines as an even third node and you got profit right. The problem with this is that line art is dependent on its internal data structures and exposing these data structure could pose a design problem for the geometry nodes. Because as we know as we all know that geometry nodes does doesn't have customer structures for you to pass around so we can only pass the geometries and in that case is going to be very efficient in efficient to like expose line art internal data and you probably would have a lot more repeated calculations this way. So it is possible but we could trade off performances and since there are no custom data sockets and we will do a lot of more calculations so it's possible but I would propose to not do this in the near future. And this was the proposed data structure change just like the Christmas tree change like we want to have attributes as a more generic way of storing properties instead of any other hacky approach I had previously and we'll see how this goes. How about baking? So baking is another topic people would want to ask once we have geometry nodes as the line art approach because geometry nodes will calculate one frame and one frame only and you move to the next friend it up again. Now we have simulation nodes things might be a little more easier but baking is kind of problem because we probably want to apply a modifier and then we get one frame and not not anymore. So now we have geometry nodes tool we probably want to invoke these tools at every frame of the range you want and possibly you can have a baking down this way and also it simplifies the caching of line art data. So if you have line art modifier there is a lot of caching going on if you like want to reuse the previously calculated view map but this time with geometry nodes you just calculate once and filtering all the things and combine them together so no need to cache so there's a little bit good thing over there. Another good thing is that we can additionally store vertex attributes for line art to pass to the output so we can have, for example, normals and apply lighting effects on the thickness of the grid pencil line and this could be a little bit slower as you get more attributes into the vertex and lines and of course a little bit more memory cost. You could probably use attribute transfer for this but it's not as important. The probably the last thing last thing for optimization is the chaining. We want to trade off quality and speed so a lot of times the chain is not perfect. The design of grid pencil stroke means that we cannot have a stroke terminate and not smoothly interpolate between visible and invisible so that we have to break all those visible and invisible strokes into different strokes. And also a shout out to Sebastian and he implemented this smooth counter modifier from this address which allows us to flip those jagged triangles to form a continuous contour line and this way we can have a fully enclosed contour on subdivided models like this. And this is also beneficial for us because we want to do grid pencil feeling and once the country is guaranteed to be closed we can have a guaranteed perfect feeling of grid pencil. It is a little bit slow but on the plus side this algorithm doesn't need to run fully because line art can handle partly visible edges. So the algorithm could be run in like half of the stage then pass it to line art you can get very perfect result. It can be made into a form of a modifier or a node these are both acceptable and we can see what we can implement in the future. And also another additional algorithm is the temporal coherency thing and the problem with temporal coherency in grid pencil is that it depends on previous frames so when you want to modify one frame every frame down the line needs to change to match the requirements of the temporal coherency. So that's not probably gonna be inside render anytime soon but we could do some researches on how we could let grid pencil handle this. The flat attribute thing is another thing I could propose for simplifying the stroke drawing as you can see if you have four segments of the grid pencil now we have to do actual fourth strokes because grid pencil attributes are smoothly interpolated and if we have the flat output in the shader we could use flat interpolation or if any open geo developers would call the geo provoking vertex method and using the flat attributes we can have one stroke with four different terminating attributes. So it's gonna save a lot of data in the terms of line art and also it would be like much much faster to render as well. Okay this is this originally line art design like this because grid pencil doesn't allow me to do this continuous line drawing so I have to break it up on visibility but if we can implement this flat attribute thing the breaking up might not be necessary so we can have continuous contour drawing even if it's jagged it's probably not gonna be as visible as we have it now. And also we have intersection problems but this is something I'm gonna solve down the line so I'm not gonna bother anybody with this. Finally the z-order and transparency thing in grid pencil is probably gonna need a revamp because now we have the strokes overlapping each other to produce this kind of diamond shape like overfill but with with layer folders you probably can combine the strokes into one layer and one layer folder and adjust the transparency on its own for composition and you get semi visible but it's solidly filled strokes as an entirety not having these diamond shapes. And also a shout out to Shen Chao's algorithm called cello this is a dynamically filled grid pencil algorithm so when you can you can actually adjust the filling of this of the areas by adjust the blue curve underneath this to animate stuff. I thought that would be pretty cool and it might be implemented into grid pencil as well. So my plans actually I have no idea because I'm probably gonna start investigating all the algorithm and these caveats very soon because now I have more time after I'm finished schools. Yeah if there should be a time frame I mean first of all I probably gonna help Falk on the grid pencil 3.0 thing because obviously it's very new and a lot of tools are unfinished like you have basic drawing tools like a lot of editing is still undone and probably gonna help them there first and support nodes and modifier migrations that's for the grid that's for the geometry nodes. And the line art node is probably gonna be developing parallel to grids pencil 3.0 and when the geometry node for grids pencil is ready line art node will probably be ready as well. The GPU algorithm needs some more explorations. I'll see what I can do but it's probably gonna be done since it's much more performant and the artist would desire it more. So sometime in the 4.0 we probably will have line art node probably 4.3 I guess and for GPU lines is probably gonna be down the line 5.0 but it might not be 5.0 might also be 4.0 something depends on if I have time or not. And wait hold on even more distant plans. Well these are more fuzzier like anti aliasing. I'm not a proficient geodeveloper but I know some stuff I probably would help. I wish we have turned Clement to write graphics code this way and we could have flawless rendering setup but for grids pencil it's kind of there there we have some problems I probably would help them solve them. And flat attribute support for better chaining result and down the line other camera distortions for perspective and fisheye. So that's about some plans I could think of. If my change I will see what I can do. Okay some extra advices for like in general not limited to line art is that mostly for artists it's like shapes need to be combined first of all as you can see this is a shadow of a bunch of planes you may want to call it leaves. Okay like shapes like this if you combine them you can read them as a unity but if you do not combine them you will read as a bunch of random lines and you do not know what's going on. And the same is true for any line based algorithm and you want the shape to be simplified and readable. A lot of cases when I see people doing models is that they have like an architecture models they detailed down to all the handrails on the outside of the architecture but the architecture is like 100 meters away so everything there is going to be a black splotch. You probably don't want that so shapes need to be combined you probably want a silhouette of the handrail but you don't want a whole bunch of lines there and it's also related to proper level of detail and just like this monkey here if you zoom out too much you probably want to only have a silhouette instead of a bunch of lines and prevent you from reading the shape. So a lot of people come to me and say well this line art thing is still very slow and I check the file they have a bunch of extra details in there and it's not even going to be visible in the final output. So sometimes when modeling for rendering lines you probably want to take care of the level of details in mind that's for the art side. I think mostly it's just it and I'm done and I'm here for questions on the implementation of Lyon. I know I ramble a lot for the technical part I hope it doesn't bore like a lot of you but anything you have in mind for line art and these planes you can ask me right now. Okay so the question is should we have a separate type of graph than geometry nodes for specifically line art. The current plan is we do not want to have that because line art is going to spit out generic geometry at the moment and the point for this is that you can reuse all the other geometry nodes for line art for its output. So it is better we keep everything line art related in the geometry nodes and this way you get a lot more flexibility you don't need to implement any extra nodes for the separate node graph. Okay any more questions? Okay oh I see so the question is when we parallelize the algorithm why should we copy the triangles. That's because like you a triangle could span across multiple tiles and it could be worked on at the same time by a lot of threads and a thread could also work on multiple tiles then to have the same triangle so the triangle does not want to be worked again. So inside every triangle there is a registration for every thread it's like for example you have eight threads then every single triangle would have eight bits for the thread to register that this triangle I have already worked on and some triangles have not. So in order to make this workable you have to kind of copy the triangle case you actually need to change what's inside the triangle. The same happens with lines of course you are cut the line but the line also have this bit where it stores oh this line have already been worked or this line have happened not. So that's why we need to copy the triangles when we do parallelization but this is pretty memory hungry so we probably won't go that direction any further so we want to use GPU for the sampling based approach. Okay thanks. Hi. Yes in technically yes because when for example you feel doing a traditional 2D art like if you're drawing like manga stuff you probably won't have to draw like every single window on a building when you the building is very far away. So that's kind of a generic advice for how do you handle like a fairly detailed thing because you want don't want anything extra to like grab the attention of what's what's needed to. So ideally you should have modeled the places differently when you are far away and when you are close close and nearby and I think it's probably going to cause a little bit problem in production because you probably want more efficiency and you don't want to have a lot of models scattering around and configure the level of detail. But in the general sense you probably wanted to because it's going to be a problem for every single algorithm. Well I mean the the line art does have silhouette feature so maybe you can have the same geometry in the background but you use the silhouette feature and it will automatically just outline everything but nothing in between. This is going to be like easier for you to track all the shapes and for you to be readable and more questions. I guess that's about it and thanks for coming and enjoy the rest of the show.