Tech primer for real-time 3D artists?
admin
How do game artists learn the ins and outs of draw calls, texture fetches, vertex cache, and the like? Tech constraints might be boring or confusing, but they have a direct impact on the framerate of your game, the ultimate artist bottleneck in our biz. When it isn't fast, it isn't real-time, and it sucks.
I suspect like me you learn by discussing performance issues with the programmers you work with. Maybe you've coded your own rendering software at some point, but I think that's pretty rare in the world of game artists. Or maybe you read programmer-oriented books like the ShaderX series and the like. Dense reading though.
I think there's a real lack of artist-centric resources on the web for realtime artists to learn the ins and outs of our daily art decisions about performance. I have two articles on my site, but they really only scratch the surface.
http://www.ericchadwick.com/examples/provost/byf1.html
So, I'm interested in starting a Wiki about these things. The idea would be to help new artists develop their own sense for when/where/why they need to make these tradeoffs. Also, as every tutorial writer knows, there's nothing like writing it down to clarify one's own lack of knowledge on a subject. I'm not sure how much time I can devote to it, but I'm interested in the learning opportunity.
What would you like to see in such a resource?
I'm thinking of organizing it by pipeline, how artists' good or bad decisions affect each step of the rendering process. It would probably also need sections relating to specific hardware.
A wiki format might encourage some of you to do your own edits & contributions. Maybe it could be merged with Rick's excellent Game Industry job wiki, if it makes sense and he's up for it.
Sounds like this could be a massive undertaking, not sure if I'm up for it, alone. Any interest in this?
[edit.. oops on Rick's link]
I suspect like me you learn by discussing performance issues with the programmers you work with. Maybe you've coded your own rendering software at some point, but I think that's pretty rare in the world of game artists. Or maybe you read programmer-oriented books like the ShaderX series and the like. Dense reading though.
I think there's a real lack of artist-centric resources on the web for realtime artists to learn the ins and outs of our daily art decisions about performance. I have two articles on my site, but they really only scratch the surface.
http://www.ericchadwick.com/examples/provost/byf1.html
So, I'm interested in starting a Wiki about these things. The idea would be to help new artists develop their own sense for when/where/why they need to make these tradeoffs. Also, as every tutorial writer knows, there's nothing like writing it down to clarify one's own lack of knowledge on a subject. I'm not sure how much time I can devote to it, but I'm interested in the learning opportunity.
What would you like to see in such a resource?
I'm thinking of organizing it by pipeline, how artists' good or bad decisions affect each step of the rendering process. It would probably also need sections relating to specific hardware.
A wiki format might encourage some of you to do your own edits & contributions. Maybe it could be merged with Rick's excellent Game Industry job wiki, if it makes sense and he's up for it.
Sounds like this could be a massive undertaking, not sure if I'm up for it, alone. Any interest in this?
[edit.. oops on Rick's link]
Replies
I think it's a great idea - because especially with advancing technology, it's not good enough just to be a great artist, you have to understand the pipeline, restrictions and implications of any artwork you create.
http://wiki.polycount.net/UserPreferences
So, where did you learn your tech chops? I suspect through forums and talking with programmers you've worked with. Any other sources?
ben cloward's website has some good tech info too. i really liked his explanation of normal mapping.
http://www.bencloward.com/tutorials_normal_maps1.shtml
But yeah, this might be a good thing. Hopefully once it gets rolling, everybody will add their bits n bobs.
In describing the "whys" of certain techniques, I'm thinking I'll refer directly to the great art technique writeups out there, like Ben's and the other great polycounters.
Where did you guys learn what you know?
Here are two technical articles, one slightly unfinished on shaders:
http://www.twcenter.net/wiki/Shaders
and another on beveling:
http://www.twcenter.net/wiki/Beveling
I'm currently writing something up on "parallax" terminology that'll be ready in a couple weeks probably (I've counted six, how many are there: parallax, parallax with offset limiting, steep parallax, cone mapping, relief mapping, parallax occlusion... am I missing any?)
How did I learn the technical stuff? Not an easy question. I've been working closely with a programmer in one form or another (on my third now) in depth for more than a year, so I pick up some things. I was working with an engine with no tools for many months for Blood and Iron, so I basically learned the ins and outs of the entire thing, to the point where I could figure out what was wrong based on the error report (the logging was poor until the end as well). I picked up LOTS of technical knowledge. Add to this that my programmer for the bulk of the project didn't really know graphics stuff... I knew more about OGRE than he did by the end I think. Other than that hellish experience I wouldn't really wish on anybody (do you know what its like to set up a scene through a 3500 line XML file!!!), I learned HLSL from toying with ShaderFX and then doing intensive studies, reading lots of books on it and whatnot. Unfortunately I haven't had too much time to go back to it recently. Since shaders are the core of graphics technology nowadays, learning HLSL was tremendously helpful to my artistry... learning about engine architecture and whatnot I think gave me very interesting insights and experience, and taught me a helluva lot about pipeline.
In a few months I want to take up MEL scripting and maybe some C++.
I personally am looking for descriptions of different normal map types, how their information is kept and how their rendered in 3D space. There's already been a discussion about this in 2D/3D but it was all a bit tech-savy for me to completely grasp the definitions - which is why pics would help.
I look forward to the updates!
Professor420, yeah a game with no tools and no docs, that's how I got started. Great intro, when you have to figure it all out yourself!
Agreed on the pics Adam. I posted some normalmap image types on CGTalk awhile back, wonder if you saw that? There are more types, but AFAIK they're really just different ways to compress tangent-space maps (by removing the blue/Z channel). Certainly something good to add to a wiki!
I've got stuff from my semi abandoned book about cheapness, memory usage and tri-stripping
Spelunking around I saw this, verbose industry advice, from a Producer's perspective.
http://www.sloperama.com/advice/
This page looks interesting, though nothing art-specific yet.
http://www.igda.org/wiki/index.php/Game_Production_Knowledge_Base
Trouble with their wiki is you need to be an IGDA member to edit. Don't like having a $48 US barrier in the way ($30 student), discourages contributors.
I could see mirroring things on multiple wikis, but that'd get tedious fast.
Ben, I for one find the polycount Wiki unmanagable due to its software... I'm a fan of MediaWiki, I've used a couple others but reformatting all my wiki articles and learning a new markup (if it requires that) is not something I'm keen on...)
I'm interested in Wikipedia ATM. Does get a lot of traffic, has clear standards, edits get feedback, etc. Might be a lot of overhead though.
http://en.wikipedia.org/wiki/Game_development
The PC wiki is a great idea, but with the number of people expressing issues with the software it'd make sense to change it sooner rather than later.
Anyhow, here are a couple articles I found in my research. They're a bit wordy but thorough, should get you started if you're interested in this topic.
ExtremeTech: 3D Pipeline Tutorial
ExtremeTech: Game Engine Anatomy 101
I'm still looking forward to boiling it down, maybe I can invest some time on it after a month or two.