![]() ![]() ![]() My consideration over my own shading language changed across the months I've used it and let me tell you my workflow was slightly more flexible. The amount of efforts saved could be debated. So we don't save much and yet we get the problem of a custom language. Note your language - just like mine - isn't providing any meaningful level of abstraction. I would use a standard language because of the tools. Would you rather write your shaders in a language my language or still rather write your shaders in a plain shader language, and why? Having developed a scripting language which I also use for shading purposes, I take the liberty to rephrase your question to: Thanks for reading, and up until next time, I've attached a somewhat complete shader example of the tessellation terrain shader I'm currently working on, based on the Terrain Tessellation example from NVIDIAS DX11 SDK.įor those of you that reguarely work with plain HLSL/GLSL-shaders, I want to ask a question: Given what you have read so far, would you rather write your shaders in a language like mine (given that there is full documentation, etc.) or still rather write your shaders in a plain shader language, and why? Would be very interested to hear some different opinions. Next time, I'll probably talk about some more specific block-types that are needed for developing shaders, like "constans", "extentions", and probably also more complicated stuff like templating shaders (which I partially still have to implement). ![]() You also always have to figure out the correct combination of Inside/Edge-Tessellation-Factors yourself, as well as what UV you want as input in the domain-shader. while "outputcontrolpoints" exists in DX11 also, you still have to manually write it as the array-size in the hull/domain-shader input signature. From what I've seen during building the parser for those, you normally have to specifiy lots of duplicated data, e.g. So for those of you familiar with the Domain/Hull-Shader, I think it should be clear that my shading language is taking quite a bit of work. here, since the domain-shader also has access to a "textures"-block, and so on. In the "functions"-block, I've specified a Bilerp-function, which could probably be somewhat pulled in the standard-repertoir of the shading-language, as it is probably needed extremely often.Īnd thats it! You can do all your displacement-mapping etc. "UV" is defined for you, depending on what you have got - for a quad its float2, for a triangle it would be float3. You have an "in" block with as many controlpoints as you specified in "outputcontrolpoints", using the hull-shaders "output" for the vertex elements. So there is really little special about that here. So lets have a look at how a geometry-shader looks like, shall we? geometryShader So in my own implementation, I tried to keep the requirements for coding any of those shaders as simple as possible.įor the following shaders, I assume you already have at least a basic understanding of the concepts. IDK, its straightforward and not that overly complicated to understand, but there is quite a lot to remember about the exact syntactical structure of those things. One thing I noticed when learning geomentry, domain and hull shaders in DX11 was that those had quite some bulky syntax. After a long time of not being productive again, I've finally come around to fully implement the current-gen API features to my engines shading language, now called "ASL" (acclimate shading language).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |