I would store lighting parameters in my materials and that info is passed every time an object is to be rendered pass by pass. That's it, right?
I had a look at the Project Offset videos to see some realtime action in a wysiwyg shader editor. In order to have total control over the rendering pipeline (this includes custom shadowing techniques, fully configurable rendering solutions such as doing a pre-Z pass, deferred shading etc), DLLed shaders will work beautifully and very little code will have to be generated. IIRC, Yann mentioned something about generating binary shader code and that approach would be ideal. Something that I'll definitely look further into, when I've finished some of the more important stuff...
shader system implementation
Quote:Original post by coelurus
I would store lighting parameters in my materials and that info is passed every time an object is to be rendered pass by pass. That's it, right?
I had a look at the Project Offset videos to see some realtime action in a wysiwyg shader editor. In order to have total control over the rendering pipeline (this includes custom shadowing techniques, fully configurable rendering solutions such as doing a pre-Z pass, deferred shading etc), DLLed shaders will work beautifully and very little code will have to be generated. IIRC, Yann mentioned something about generating binary shader code and that approach would be ideal. Something that I'll definitely look further into, when I've finished some of the more important stuff...
That wasn't a very good example, I admit. You know, I was about to bring up another example, but I just realized a (rather simple) solution to having it fit well with a plugin system. To be honest, I'm kind of embarrassed.
Author
@Zemedelec:
1. please stop generalizing this the way one processes grass inside his engine is personal preference
i could create a density map for the whole scene or i could do this on a terrain batch base or inside a shader definition this doesn t matter at all
2. i don t need to create and destroy nodes the grass is represented as a vbo full of quads and you just apply a different texture to it so all you need to do is store a node for your grass batch that tells the engine that it exists and can be rendered if visible
3. i don t aim for consoles and there is no huge amount of preprocessing to do when creating a grass batch
- create a global VBO if it doesn t already exist
- add a grass batch node to the scenegraph
- start rendering done *this is simplified but shows how it works*
4. implementing such a api for content creation isn t much of a problem and it s certainly not very complexe
its probably as complex as the intermediate mode of modern graphic apis as OGL or D3D
5. it allows you to add detail on the fly without the need to develop tools inside a scene development environment that are hardly used so spares time
1. please stop generalizing this the way one processes grass inside his engine is personal preference
i could create a density map for the whole scene or i could do this on a terrain batch base or inside a shader definition this doesn t matter at all
2. i don t need to create and destroy nodes the grass is represented as a vbo full of quads and you just apply a different texture to it so all you need to do is store a node for your grass batch that tells the engine that it exists and can be rendered if visible
3. i don t aim for consoles and there is no huge amount of preprocessing to do when creating a grass batch
- create a global VBO if it doesn t already exist
- add a grass batch node to the scenegraph
- start rendering done *this is simplified but shows how it works*
4. implementing such a api for content creation isn t much of a problem and it s certainly not very complexe
its probably as complex as the intermediate mode of modern graphic apis as OGL or D3D
5. it allows you to add detail on the fly without the need to develop tools inside a scene development environment that are hardly used so spares time
Quote:Original post by coelurus
I would store lighting parameters in my materials and that info is passed every time an object is to be rendered pass by pass. That's it, right?
But lighting is dynamic, and depends on the position in scene graph.
And material is something like property of a surface... how do you connect both?
Quote:Original post by coelurus
I had a look at the Project Offset videos to see some realtime action in a wysiwyg shader editor.
Yes, I mentioned something like that in the beginning of the thread.
But this system is suited for text-generated shaders indeed, not DLL-based, if of course you don't implement shader nodes in these DLL-s, not complete shaders, so you can link nodes in a way you want.
And such a system is very interesting and I'd like to build one for our pipeline, in the simpliest way possible - text replacer, with light as multipass (eventually, if don't fit into current profile).
I can explain the first draft, if somebody is interested.
As for the text-based approach, here is one more point of view, very interesting, because it is decoupled from actual lighting:
http://www.talula.demon.co.uk/hlsl_fragments/hlsl_fragments.html
Quote:Original post by ZemedelecQuote:Original post by coelurus
I would store lighting parameters in my materials and that info is passed every time an object is to be rendered pass by pass. That's it, right?
But lighting is dynamic, and depends on the position in scene graph.
And material is something like property of a surface... how do you connect both?
I just ask the light manager which lights influence a particular object in space the most. Works pretty well.
I would like to eventually write a graphical tool for shaders and I realize that a script-based renderer would be very easy to use for that. Still, only binary code can change a rendering pipeline totally if, say, we would like to implement tech that was not available at the time the renderer was written.
That's the fundamental difference; DLLs supply new code, scripts only control existing code in the renderer. Period. Note that there are no indications in any way of a definition of how the DLL:ed shaders work; I will most probably investigate methods for shaders to automatically compile at engine startup to fit the current host which means they will slide over to some sort of scripts. There still is an advantage using DLL:ed shaders, as mentioned in the previous paragraph.
Another site to bookmark, thanks [smile]
Quote:Care to expand on what you do?
im a great beliver in keeping it as simple as possible
everything is specified as text files materials/shader/shader info.
materials specify how an object looks like under various conditions
Quote:http://www.talula.demon.co.uk/hlsl_fragments/hlsl_fragments.html
yeah this is similar to what i have to generate standard shaders (though some shaders are to specific to be handled easily by a generic ubershader)
Quote:I just ask the light manager which lights influence a particular object in space the mostu cant do this ie ignore lights without it impacting visually on the scene
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
