- This topic has 14 replies, 6 voices, and was last updated 15 years, 6 months ago by
.
-
Posts
-
-
Sorry i am just wondering what the gamedevelopers.ie community have to say about the actual use of value of creating shaders.
I personally started using fxcomposer and created three original shaders in 45 mins but i discovered that most of the time it is heavily dependent on textures.
I dont know maybe i am missing something can someone clarify the actual fantastic thing about shader creation programs considering everything that is needed for games is already created anyway.
Tanks
-
Hi Sean,
From my point of view they have their place in the pipeline.
The problem they answer in my opinion is this.
Programmer’s are sitting down, setting the device state (lights, materials, textures, alpha blending, etc) all in code.
Artists come along and complain about the lighting, or hues, or whatever.
Programmers have to turn on some renderstates, and disable others on the device. Clean build (go for lunch…), come back run the game, and the artists now think it needs another change.
This process can be minimised by a certain amount of data-driven design, (INI/Lua), but not all of it.
Solution, is to outsource how the scene looks, and the corresponding device state for each object to a "shader creation tool" like FX composer or render monkey. Now, all the programmer has to do is get the game up and running, and the whole thing might as well be black and white as far as (s)he is concerned.
The artists can knock themselves out until they are blue in the face (pun definitely intended), and there is no re-compiling, required. Well almost none.
You could still achieve this process, without FX Composer. But I’ve yet to meet an artist who would be willing to work in notepad alone. No, I’m pretty sure they’d rather surrender a lung than their mental mill…
Anyway, that’s pretty much my 2 cents.
-Brendan.
-
thanks jediboy, that post has made things alot clearer to me. It is very much appreciated. :D
-
We use a graphical shader editor for Prototype. It’s one that was developed in-house, which means we have a lot of control over how it exports its shaders, and we can attach game-specific metadata to the exported files which is a big bonus. We can also specify game-specific shader constants in the shader editor, which is then automatically filled in by the engine at runtime, all without the artist having to touch any code. They certainly like using it, love the instant feedback they get from the 3d preview, and of course prefer it to working with shader code which just scares them. It also enables many more people on the team to work on shaders than just the graphics coders, which is great for me because I have enough on my plate as it is!
There are definitely downsides though. Give a graphical shader editor with real-time feedback to an artist, and they’ll certainly be able to produce a nice looking shader. However it will also probably be a very expensive one, depending on how technically aware the artist is about the cost of various shader operations – they’ll access vertex textures all over the place, or put things in the pixel shader that should really be in the vertex shader, or even engine code. Like any other node-based editor, the more complex shaders will invariably end up looking like spaghetti, with node connections criss-crossed all over the place and making it much harder to decipher than just straight code. Also the downside of an in-house solution is that the tool itself also takes coder time to maintain and fix, which can be a real time-sink compared to just using an off-the-shelf editor. For this and other reasons, we’re going to switch to a mainly text-based shader pipeline for the next project. However I’m sure we’ll still be using shader GUIs for some things, as the instant feedback just can’t be beat.
I think a graphical shader editor definitely has its place and can aid productivity no end, but the really important stuff (the base lighting code etc) must still be tightly controlled by a coder armed with a text editor.
-
thank you satchmo, this has cleared things up for me relating to shader creation tools.
:D
-
we’re going to switch to a mainly text-based shader pipeline for the next project. [/quote:ba0fe799d4]
Yuck!
-
I think this fire needs more oil. Here’s the opinion of Christer Ericson:
http://realtimecollisiondetection.net/blog/?p=73
I’ve mulled over this some more since my comments on the thread. Basically if you are a tight team who knows what they are doing, and can actually communicate graphical systems are fine. I think everyone is better off when extra users, particularly the artists, can make changes without needing to directly program. The problem arises in believing that every solution you can create is a valid one… and idiot/enthusiastic programmers initially selling the idea as such. Performance is the main reason why a nice looking shader may be invalid. A good artist will eventually learn how to maximise both performance and visuals, trust them.
Recommendations imo: Write a text based system. Layer with a one-2-one graphical system, all options exposed. Write performance feedback tools that an artist can use to gauge shader issues, instruction count, memory accesses and texture usage. Put your best technical artists on the job of making these shaders.. people like Pete there.
Later, mid-project, when the look of the game is decided, write a final layer that is a very constrained subset of shaders just for this game (i.e. a dialog box per overall shader, some check buttons, edit boxes etc – also worth supporting command line for this too). You do this so that changing the options is easier and faster for artists. You don’t do this because you don’t trust the artists to keep performance high (it’s up to the lead and technical artists to instruct correct usage), you do it so that everyone can work faster and avoid bugs in their shader code.
Key difference between this approach and typical approaches is that no-one is trying to write constraints and dependencies into the shader system. Sure it’s breakable but it’s open for experimentation too for the artists. Trust the experienced ones!
Course, this is just what I’d do. I’d be interested in different approaches.
-
Yuck![/quote:c6533db1d4]
Haha yeah it sounds like a step backwards alright, but actually our 3 best shader artists already prefer writing straight Cg to messing around with nodes and connections – given half a chance, they’ll just write one big node with loads of inputs and outputs, effectively bypassing the node-based GUI part. Given that, and the fact that it allows us much tighter control over shader performance and what code gets used where, I’m definitely looking forward to working with the new system.Node-based shader editors are all well and good for demonstrations, but when you’re dealing with real 200-instruction shaders made up of about 30 different nodes all connected to each other, it just becomes a nightmare to grep. Straight code is so much easier to deal with, comment, organize and reuse. We’ll still use graphical editors for previewing and iteration of course, but development is going to be largely code-oriented.
Granted, regular world/prop/character artists will no longer be able to edit shaders themselves, but in reality they never do anyway even for the simplest shaders – they come to me or one of the shader artists. And honestly I don’t really want them editing shaders in the first place, they do more bad than good in the long run.
-
Thank you too all for posts :)
-
Used a few node systems and always thought it would be good to program one using my half artist, half programmer, half arsed brain. Some day.
-
try fx composer it is a piece of cake. I created three custom shaders during the half an hour right after doing the tutorials that are with it and on net. It’s a piece of cake.
-
No I’ve written shaders before and have used fx composer, I meant I’d like to code an fx composer app that works within budgets.
-
Thats quite ambitious, good luck with it. :)
-
Hi all,
I just picked up Gems 7, and paper 7.4 discusses integrating shaders (and associative managers, etc.) into a game engine, with a sleek data-driven design.
"Support You Local Artist: Adding Shaders to Your Engine," Curtiss Murphy, Game Programming Gems 7, CRM, 2008.
Good read.
B.
-
cheers for info :D
-
- The forum ‘Creative Content’ is closed to new topics and replies.