 All right, then. I think we're just about ready to start as I see most of people who are interested have already filed in So thanks everyone for coming. It's nice to see so many people here It that's interested in this particular topic and yes to make sure everyone Wants to be are actually here since there's actually a minor misprint in the pamphlet if you're interested in Grease pencil in VR. This is actually the wrong session if you want to learn more about that I would suggest that you head down to the theater instead And without further ado Let's start get started. I Should warn you though this talk actually it seems like some people actually misread So let's wait a few minutes to let them file out and there. That's it going again I like would like to warn all of you though This talk is going to be a little bit of a technical or rather a Talk about free technical topics as such the supply of need to renders is actually going to be running as little bit sparse But I hope to keep you all entertained and Hope all of you learn at least something from this. Oh, right But first some kind of introductions is probably in order My name is Gustav Valde-Marsson a software engineer at arm where I typically help out with various bits and bobs in the Mali graphics driver stack and especially the parts that are related to hardware accelerated ray tracing and To top it all off. I'm a so-called industrial PhD student at Lund University in Sweden Where I also work with various ray tracing related topics some of which will actually make a small appearance later on in this talk All that said I am obliged to say that I do not represent arm during this event Nor is any of the content here sponsored by them as such any views that I express here in the presentation are strictly my own So let's get into the meat of things then shall we as I hope you can imagine The topic I will discuss is about managing custom data inside of GLTF files and using blender as our interface for doing this As such I can imagine that the audience is split something like this on one side we have people who know and work with GLTF in one way or another and on the other we probably have blender developers or plug-in writers and Lastly we have some Group of people that probably have some kind of data that isn't natively inside of blender or in GLTF But somehow want to make them work together And this could be really any kind of data. It could be some tree data Some funky textures or data used to a completely elsewhere in some kind of database And my goal here today is of course not to make any of you an expert on any of these topics But what I want to do is slowly pull all of these groups together just a little bit So there's a bit of overlap such that anyone who wants to do something similar to what I have done just a little bit easier and Of course, I hope to do that with a few compelling examples With that we have a few different areas to cover as such I will naturally start by talking a little bit about GLTF itself What it is what kind of data it actually stores and so forth Second, I'll briefly go over how blender works with GLTF files and talk a little bit about the add-on that drives that process As well as a discussing at least one of a tool that you may come across when working with these kind of files Such as when you're trying to pull GLTF data into your own rendering frameworks After that we get into the custom things themselves Here, I will present the extension mechanism in GLTF that makes all of this possible And after that I will go into detail how you would construct a simple plug-in That simply performs a bit of watermarking on each image that we are exporting After that, I'll also show some of the other functions or hooks as they are called that we can modify inside of this export process I'll then move on to my primary use of these facilities Namely generating a thing that is known as a micro map during the GLTF export process And finally, I'll be wrapping things up by saying a few words about the importer side of GLTF as well So where should we start? Well for completeness sake, we obviously should start with GLTF itself In short, it is a royalty-free format for transmitting and Loading 3d scenes and models while keeping the data itself about these models as small as possible Both while it is in memory and while it is stored on disk Additionally and most interesting to us. It is very extensible Which is what makes everything else I will be talking about here possible That said GLTF is not a universal 3d modeling format The base primitives it supports are distinctly geared towards real-time rendering use cases In fact, many of the constants and enumerations in the format map directly to equivalent API values in OpenGL All to make it as seamless as possible to load all the data in a file and send it directly to the GPU for rendering But of course the format is not limited to that as an example the material model it uses is pretty general and With the aforementioned extension system. It is well extendable I should mention though that I will not really go into the detail of how to offer GLTF scenes But I will instead focus on some of the more technical aspects that we need to know about to write plugins like this That said, Cheuviens du Roor, and I hope I'm not butchering your name too much Is what one of the primary offer of the GLTF importer Exporter add-on that I've literally built everything on top of will actually have a session right after this in the classroom venue That will deal with this particular Aspect in much greater detail so starting with the GLTF files themselves essentially The there are essentially three versions of GLTF which in blender are exposed as GLTF embedded separable or binary and the first two of these are essentially two versions of a JSON file and Only really differs in how some of the data are packed inside of that file For the embedded format all data even images are packed inside the same file and Binary data is just encoded using base 64 for all strings and then it's just as JSON string inside the file and this is all to make it easy to transport and share the file while also being able to change it slightly afterwards Change some of the other aspects is more easily But of course if you want to actually change the binary data You basically need a separate tool to pull it back out again to re-offer it For the other one all the data or the binary data is instead packed into separate files That are stored next to the primary GLTF file And this is mostly to make sure that it's easier to re-offer Some of these files basically the textures if you want to change them after the fact and The last format is an entirely binary format and thus is also the most compact version of this and That is a format that I like to think of as a binary equivalent of JSON But of course there are more new and nuances to it than that, but it's nothing that I have time to get into in this talk So let us take a look inside of the GLTF file then shall we? In brief the entire file structure is actually really well encapsulated inside this single Relationship diagram which lists essentially all types of objects that you can find in the so-called GLTF world And while it looks a little bit complicated We can actually start to pull this apart to identify some key components that we may care about in some contexts For instance this top part of the file basically define the scene graphs inside file and that is plural Basically, we have a single file that can contain or a single thing that can contain multiple scene graphs and On top of that it also actually contains the whole bone hierarchy for skinned animations but that is another side note that we won't be getting into and Just to show you roughly how this is structured This is a scene that just contains a single scene graph and you can see in the topmost Node basically you have a list of indices which represent the scene and in this trivial example The scene that it represents is just a graph with a single root node with two child nodes with separate transforms associated to them one with a rotation and one with a translation and Then of course It wouldn't be a proper scene graph if we didn't have measures associated with them and those can then be stored inside of each node separately and This use of indices that you can see here is a reoccurring theme in GLTF To keep everything as compact as possible Objects are practically always stored in a linear array Which are then crossed reference with indices when we need one of the other objects and Moving on this next part defines the shape the base shading model that is used by objects in the scene by default a Physically based rendering model that is called the metallic roughness model is used which essentially defines up to free Textures that we may care about a color a metallicness factor and a roughness factor Again, these are more details that I won't really be going into And lastly we have the so-called data storage model or data acquisition model And as you can imagine from this talk, this is something that we will actually have to care about a little bit Since it's quite important for us when we want to store custom data inside of these files so most of one Most of the work we want to do in this talk really just boils down to this We want to take some kind of data from some other source that we already have somewhere and pack this into something that GLTF understands and Since it is a JSON file, we could really pack anything into it But beyond the JSON primitives themselves there are these are their basic building blocks to packing other kinds of data inside this files and We can basically break down into a few different levels at the lowest level We find the buffer which is really just an unstructured source of bytes with a length associated to it and Just above that we have the buffer view which is really just a bit of metadata on how to index into a buffer using a offset an optional stride and length and Above that we find the accessors textures and images which describes Exactly what kind of data we want to access and how it should be accessed through for instance a buffer view So what becomes of all of this when it actually reaches blender them? well this is where the GLTF importer exporter add-on comes in and The way that it struck is structured is really straightforward Each object that exists in GLTF has an exact corresponding class as so to say that with it and That and any entity that was previously cross-referenced with indices that I mentioned before gets resolved through a proper object references object reference and all that to make it easier to handle this kind of data So thanks to she again and the other contributors of the GLTF add-on we can actually ignore many of these low-level details as That is automatically handled for us Even the low-level buffer handling and image objects gets automatically converted to classes that are called binary data and image data That automatically handles the conversion of well a byte array in Python to Well classes that we can read later on But I would be getting into that in much more detail a little bit later So Why if you are actually working with the format though keeping the GLTF specification and the object reference sheet That I have actually linked down here is actually really helpful because there's a lot of objects And you might care about some sub parts of them. So using them is an absolute must So in summary these classes will act as data containers if you need the data or a Rapper for reading and writing the various GLTF files However, if you are on the receiving end of a GLTF file, you may actually have to care about these details If you are exporting files from blender using GLTF and then using for instance the tiny GLTF C++ library to load the file in that case all you get are direct struct based a direct struct based representation of the GLTF file and It is entirely up to you to actually read back the data that you actually want Including handling this index resolution that I mentioned earlier Which as in in this truncated snippet that I wanted to show requires quite a bit of code in my case This takes roughly another hundred lines to correctly read back a single array of values which could be anything from float values to vectors and While it is bare bones tiny GLTF is the best tool that I've found for this application all you want to do is really read back GLTF files and If we obviously compare this to the facility lease we have Available in blender through the GLTF add-on everything is just much nicer in comparison To write a buffer and at the same time create a buffer view we simply construct a binary data class and If we want to read data back, that is just stored as a unstructured Byteray or as a binary data actually then we simply call the decode accessor function But the pet so depending on our context life may or may not be so easy for us and The final thing that I want to mention about GLTF is of course the extension mechanism As I mentioned earlier the GLTF file is essentially just a JSON file as such We technically can add whatever data we want to it Obviously the specification requires some stuff But it also gives us an official way for adding new attributes to it in a structured fashion This is done by adding new key object pairs under the special extension object in the file The key here in this case is the vendor prefix Basically the letters key khr for Kronos in this case followed by some kind of descriptive title Which in this case is light punctual which refers to allowing storage of various point-like sources inside of the file For this talk though Everything that everything that we will be working with is obviously going to be custom in some sense as such Wherever this prefix come into play, we will just be using the prefix none So it's up to you to choose whatever prefix is applicable for you and These extensions then essentially comes in two different flavors and they are appropriately named required and optional and as the name suggests a Compliant GLTF parser slash renderer should abort the process if an extension isn't supported For instance, if measures are compressed with an unsupported compression algorithm, they naturally cannot be handled in a Satisfiable way Optional ones though could be things like meta data containers or optional rendering features For instance, if the client does not support it, it should still be able to use the rest of the data Although renderings may be slightly different different from what the author intended and Then these extensions that are listed at the top of the JSON file like can see in this example here Then depending on the actual extension itself More extension keys like these can be found inside of the file attached to the other kinds of objects for instance seen For instance point lights are typically attached to a scene graph in some way as such It makes sense to actually attach these extension objects to the node objects in the file So that we can actually manipulate point lights as if they were actually nodes in the scene And of course some of these extensions are useful to are sorry useful to many people out there So okay, they are occasionally standardized as in the case of this punctual light extension And a collection of these can be found this link that I've included in the bottom However creating official standardized extension in this way is well beyond the scope of this talk But for anyone interested This link provides any details that you want in this case And finally we get to the plugins themselves and a quick disclaimer before we go on I would not like to claim that I'm a very good Plug-in. I would claim that I'm not a very good blender plug-in writer In fact, I'm pretty sure that there are much better ones in this very room But with that I would like to present a first example of some of these gltf tools that we can use a Simple plug-in that basically watermarks all textures while we're exporting them from blender And this is of course Admittedly a bit of a facetious use case, but it is a good example to see all of these things in action So with all that let us go over how to create one of these exporters exporter plugins in detail So let us start with having a clear goal in mind we want to know We are we already know what we want the water market to do. We have a nice little visual cue up here in the corner And we want this to happen to all images as we are exporting them But obviously we want to be able to control this plug-in and process in some kind of fashion To that end. We obviously want some kind of panel Add some kind of panel to gltf exporter that looks something like this Basically, we want the ability to enable or disable this plug-in so we can stop watermarking and Want the ability to select what image we should use as a watermark But let us start from the top first We need a special variable called BL info that blender uses to pick up various meta data about the plug-in such as the name Description current version of it as well as which Verse which blender versions it supports and so on and this is of course not unique to our type of plug-in But probably applies to all blender plugins and after a bit of digging I even found a specification for this So you can see what options are available for this Dictionary and what things you shouldn't be adding to it And next we get into the so-called property class that actually contain these control options In short, we want some kind of Boolean option to properly enable disable the option the plug-in itself and a string to use as an identifier for the work watermarking image and This property class is then used to help us create the actual buttons that change these options Which what is what we'll look into next and to do that? We actually need another class for the so-called look and feel of these buttons or controls This one uses a slew of variables and methods to define how to create the buttons how to set the properties and Even how they should be created and look And of particular interest to us here is the so-called BL parent ID variable Here this is set to a special key which basically signals that we are a child of the main gltf exporter panel Obviously, we could set these buttons to be anywhere in the blender UI by controlling that But this is a kind of logical place for it since we probably want to control our gltf options along with well the other options for it Then to actually create the buttons itself. There's a few things that we need to do and I only want to highlight a few things Basically, we get these draw methods that basically draw our panel itself and for that We get a layout where we actually add the various things that we want to create and to do that We have to call this prop method and give it the property class that we had Created previously and then select which key or option. We actually want to change and here is one caveat I really want to highlight It is strongly recommended to actually make sure that these two classes are uniquely named as such you can otherwise you can get enough Well Otherwise you can get into a weird situation where only the last plug-in that you loaded is actually going to show up in your export panel and Then finally to actually get them into blender in some reasonable fashion We basically need to register them and these are done with using these collection of methods and Of course if we'll register the classes We probably also want to unregister them if we should disable the add-on itself And that is done with the corresponding unregister methods One for the panel and one for the properties and then we finally get into the class that finds the gltf plug-in itself In your script you should define a class with the exact name gltf to Export user extension and then add methods to these that corresponds to the Methods that we want to customize or the data that we want to customize So in our case we want to customize all images that we export Something that is done using the appropriately named gather image hook Where we simply receive the gltf image and all other Blender data that's equivalent to this exported image and For completeness the actual function that does the watermarking process looks something like this Basically, we first convert the encoded image because that is just unstructured binary blob at this moment and in this case I do that using Well a minor utility function just to get back a NumPy array Representation of the image and then I basically applied the watermarking by just slapping it on top of that array and Finally to convert all the images back to binary. We use these special classes that I mentioned before Although we have to be a little bit careful depending on what the user wants we can actually get Different things inside of the image class Basically, if we decide to have an embedded gltf file the so-called URI Attribute in the gltf image will not be populated as such we should probably replace the what they call the buffer view of the image rather than the uri and that is simply done by testing that particular attribute and Setting the appropriate class in this case and the main reason we want to do this is that It's basically that We want to respect the user's choice if they have selected an embedded format We probably should respect that and make sure that everything still is that after we have run our plug-in We could override it, but of course a good plug-in should respect the user's choice And lastly, I want to mention a few words about the special Extension class that I didn't actually get to use in this watermarking example This is a special class that is used to signal that we are adding extension data to a file in some way Such as the exporter can pick this up and add it to the list of extensions in the file and As I showed before we can place this extension class pretty much anywhere such as in the node hierarchy for this very small example And it can essentially contain anything that can become valid JSON data And this includes any of the other GLTF classes such as the binary data class that I mentioned before and Now is probably a good time to add a little reminder for completeness sake I typically install add-ons by dropping the file that is represented by it into the add-on directory of Blender But then I completely forget to actually enable it and sit around scratching my head wondering where all my stuff has gone So this is easily fixed by opening the edit menu going to the preference dialogue and Opening the add-on section then I recommend enabling all sections and searching for GLTF And then simply click enable to make the add-on usable And I'm sure there are ways of doing this automatically From the command line, which I typically prefer to work on but this is a good way and a good reminder of how to do these Kind of things and if you have done all of this correctly You should have populated this extra section inside a GLTF export panel with all of your options Moving on to the actual hook functions then As you probably know Blender has loads of primitives and GLTF supports many of these and these are exposed in a long List of methods that you can see here All of which you can actually override but in short each of these map to one of the objects that you can find in the GLTF world So beyond the image hook that we looked at for the watermarking plugin We will only really talk about a few more methods or out of all of these Namely the mesh and the primitive hook and while this is pretty Restrictive I think that just the mesh hook alone is a good example Such as it's pretty easy to infer what else could be done in any of the other hooks In general, I try to think of each of these methods something like this It is a method that receives both the blender version of the object and the GLTF version And then it's up to us to actually customize and look at these things in order to decide what we want to do with them So in the case of a mesh we get the blender and the GLTF version of the same mesh But we also get objects that might be related to it in some way for instance We get for meshes. We also get the blender vertex groups the modifiers and active materials And finally all methods also gets this last object you can see here, which are export Export settings, which is controlled by the GLTF add-on itself, which are things like the Export directory where we are exporting things and other things like that And this then finally moves us on to my actual use case for GLTF As I mentioned, I use GLTF as my primary 3d modeling format for my research renderer As such, I often investigate various new techniques or types of data However, creating new formats for loading and manipulating this data is really annoying As such, I eventually realize that the GLTF extension mechanism could actually be used to simplify this matter quite significantly As such, allow me to present one of the things that I've been working on during the last year A relatively new type of rendering primitive that exists in Vulkan and DirectX That is known as a Micromap And basically this is the kind of thing that we can visualize something like here to the right And in this case, this is a texture file that is taken from our classical sponsor scene And what we want to do is be able to generate whatever this thing is here on the right And if you were to actually apply these to our traditional sponsor scene We can get an effect that looks something like this inside our ray tracing pipeline And this is entirely without using any kind of alpha mapping The Micromaps are effectively something that makes our geometry much more granular And it does that almost for free So without digging into too many of the details, and I mean this is a Vulkan extension after all There are loads of details to go around But we can still pretty easily describe it as follows Take any triangle in your scene Split this triangle along the midpoint edge of each Split each edge of the triangle along their midpoint Thus forming four new virtual sub triangles And then repeat this process up to n times Which becomes our so-called subdivision level Next, we can associate a value with each of these sub triangles And then we can use a special space filling curve to actually linearize each of these values Giving us a single array of values Which is our Micromap In short, you can then view this Micromap as a very specialized per triangle texture And what I want to do then is generate some kind of realistic data for each of these triangles Now in Vulkan currently, there are currently only one official type of Micromap available Namely the so-called opacity Micromap That is a map that stores opacity values for each of the sub triangles And only very specialized ones at that Basically, we have zero for a fully transparent triangle One for a fully opaque triangle And two different values of unknown We don't know the opacity values And want to have an escape hatch for faster processing in corner cases Naturally, this is a very specialized type of opacity And in fact, it is targeted at improving the performance of hardware-accelerated ray tracing applications By reducing the number of times you actually have to call the any-hit shader But that is a discussion for a completely different time And I want to stress this here While it looks like we are storing an array of values The kicker here really is that we only need to store two bits for each value In fact, there is another mode to these Micromaps Where we only need to store a single bit per value Hence, these Micromaps can be really compact Especially when you compare these to typical alpha maps And for completeness' sake, at rendering time We then have a very efficient algorithm for actually going from a triangle's barycentric coordinates To a Micromap index And consequently, the Micromap value that we stored in that specific virtual sub triangle So, to get back to my case then What I want to do is create a simple plugin That can generate these kind of Micromaps And embed them as part of the GLTF file Such that I can manipulate this data in some fashion And test out this new extension in various ways But, of course, I also want these to be realistic in some sense That is, we want our exporter to find any existing alpha texture Associated with the triangle And then generate a representative opacity Micromap for it So, in short, you can summarize this with this pseudocode For each triangle, add Micromaps to it If it has an alpha texture associated with it And yes, so we're clear exactly what we will get out in the end We want to be able to generate GLTF files That contains extension objects that looks something like this That is, the primitive, that is the list of triangles in the scene Now have a list of Micromaps also associated with it With any other meta data that might be interesting in this case Such as the subdivision level that I mentioned earlier So, on the face of it, it looks like we should be able to just add customization methods For primitives, and we should really just be off the races Unfortunately for us, or me at least in this case GLTF structures primitive something like this Basically, the meshes themselves contains the actual material And the primitive doesn't really have access to it So we actually need to move ourselves up a little bit in the hierarchy And customize the mesh exporter method instead And another good reason for moving up to the mesh level Is that we can much more easily attach custom primitive Custom control attributes to each mesh inside of Blender That actually allows us to control this Micromap generation process On a per mesh basis And this is something I do by just adding custom attributes Inside a mesh object down here And in this case I just name them according to what the attributes are Such as the subdivision level that you can see here Thus, to adapt our little loop to the GLTF world We want to do something roughly as follows Each time we export a mesh We want to check if the triangle contains alpha textures And if so, extract the GLTF triangles Basically the indices, the UVs, materials and textures And then use these to map the triangles to the alpha textures And generate Micromaps for that mapping And then finally store these as extensions inside the GLTF file And this is pretty easy on the face of it And all we really need to do is actually replace this loop With the gaver mesh hook, essentially And then we're really off to the races There are a couple of caveats here That makes this a little bit more challenging in practice For instance, each time we actually subdivide these triangles We basically quadruple the number of sub-triangles That is, it scales by a power of four And that can easily be very computationally dependent However, each of these sub-triangles are actually computationally independent So we can actually use any kind of multiprocessing In order to accelerate this process to generate them And of course, in Python, we can use the multiprocessing module In order to handle this for us And of course, if it's computationally heavy We probably also want to use profiling To help us find some problematic snippets And of course, in the essence of time Multiprocessing itself is a very complicated topic With numerous corner cases that I don't have time to go into But just for completeness' sake I want to include some general advice If you end up in a similar situation like this Remember that local variables and functions Are typically not available to you Avoid nested parallelism Try to flatten any nested structure that you have And provide those as arguments instead to your What do you call them? Parallelization functions For instance, for my micro-maps I typically want to parallelize over all primitives And all sub-triangles Which are basically give these methods as indices And remember that all data that are sent to these functions Are essentially copied As such, this could actually be really expensive Who are sending away large textures to each of these functions And finally, set appropriate chunk sizes The Python default of 1 is often inadequate So try to divide your tasks equally Between all of your cores And profile your applications I cannot stress this enough Python has loads of tools to make this easier So try to use them when possible And, including And to further help things The GLTF add-on actually has two more special methods That can help us with this in some regard These are simply called, as their names suggest Before and after the export process themselves As such, there are excellent places to start Or stop the profiling Or to actually print out the profiling results But moving back to the micro-maps themselves Obviously, I didn't learn everything about GLTF And micro-maps at once So I actually ended up with more than one format To store each of them in But as different extension objects So I basically ended up with two different use cases For really small micro-maps that I used for testing purposes It was much more easily mapped By using just a string It was much more easy to just store them as a string And then you could just change some of the few bits inside of it In order to change the objects that were testing However, larger micro-maps That actually represent some kind of texture Are probably not going to be modified in that kind of way So for them, we might actually use The existing GLTF buffer system instead To keep it much more neatly contained So in the previous example that I had up there We basically stored all of our micro-maps As strings inside a JSON object Which, of course, is terribly inefficient Effectively, we're using eight times as much storage As is necessary Instead, it's much better to use The existing GLTF buffer system for this use case Which we can very simply do By just converting the micro-maps to a byte array And then adding them to a binary class Like I do in this case And obviously, this talk only really concerns Opacity micro-maps However, NVIDIA have defined At least one other type of micro-map That is known as a displacement micro-map Which is already available in DirectX and Vulkan As a provisional extension On top of that, it also seems that they're looking They're working with more types of micro-maps As they have defined GLTF extensions For micro-maps with much more general attributes For each of these sub-triables This, though, is something that I have Not really explored in detail just yet But, of course, it would make sense To modify my plugin in some way Such that we can actually generate something Of the same format Additionally, displacement micro-maps themselves Might be something to keep an eye on in the future As this thing could be something That might fit neatly into the sculpting baking process But this is really just me speculating I don't really know enough about Either the extension or the baking process itself To have a valid opinion about this And, lastly, I want to talk briefly about importers Most of this talk has obviously focused on exporters Which makes sense, as that is what I've primarily been working with But it is also the most common use of GLTF Typically, we have a detailed model With loads of data In Blender or some other framework That we are effectively filtering as we are exporting it There are, of course, exceptions And the most compelling of these use cases Are probably compression Say you have developed a new compression algorithm That you might want to use the importer As an effective way of testing The decoding process of this mesh And, really, the structure of these add-ons Are very similar to the exporter With many of the same hooks Available for it Before many of the same hooks Available for it And the main thing that can differ Is that we now sometimes have Both a before and after hook Since we can't really get The Blender representation of a GLTF mesh Before we have decoded it And, obviously, I'm not skilled enough Really to develop something like this For a talk like this So we'll settle with showing a much simpler importer And this simple importer Basically looks at a GLTF file And looks if we have used any of these Micromap features that I showed you before And if they are present Then we basically add those custom attributes That I showed you before Basically these ones And setting these are really easy We basically just look inside our We basically look inside of a GLTF mesh For the presence of the extension key That I mentioned And if it's there We just set these on the Blender mesh attributes And they will be populated As I showed you here And just to quickly summarize everything then In this talk I've talked about GLTF What it is How it's structured And what kind of data it can store The GLTF add-on That Blender uses to import And export GLTF files And plugins to this add-on That allows us to customize This import and export process Along with at least two examples Such as a water marker And a Micromap importer and exporter plugin And finally I provided a small Collection of tips and tricks For how we would handle Things like multi-processing Or profiling inside of Blender And with that I think it's time to open up for questions I guess you could use it for rasterizing There's not really anything that stops that As it's effectively a texture of some kind But currently It's really only used for the Vulcan ray tracing hardware Accelerated ray tracing pipeline As far as I know It's not added to the rasterization pipeline I don't think there's As strictly any benefits to it But there could be I haven't really investigated this In detail It could be For instance in my case This GLTF extension Are optional So if you try to actually load This in a different Basically if you try to load this In my framework You get the Micromaps themselves Because obviously I support the framework But they are optional So if you load it somewhere else You basically get the base Thing without Micromaps That's a very good question Essentially On GitHub There is a Similar to many other Cronus things I should probably mention I'm not actually affiliated With Cronus in any way So this is just me Looking at what is accessible On GitHub Basically the GitHub repository Contains a list of all Currently official extensions But of course you can also check All forked repositories On GitHub And many forked ones Are the ones that contains these Extensions that are currently in works Such as the NVIDIA ones That I showed here I haven't encountered any limitations Yet But I haven't really worked with All that many just yet One thing that I did encounter Is that the hooks Can actually change definition Depending on which version of blender You are actually using Hopefully that is something that Would be rectified If the GLTF add-on Is more tightly integrated into blender But it might be a good thing To actually have a layer between Your GLTF GLTF extension plugin The last thing that I showed on the example And have that one basically Check which blender version you are using And changing which method that you actually Apply for that attribute I don't actually One more question down there It's absolutely fine Do you have your answer And be sure to check out Julian's talk Just after this Any other questions? If not Then call the session