darkblu said:
* consider what you want to do for the edges - your options are post-processing (edge-detection filters) or hull extrusion. the former is the overal-better approach (more flexible, etc) but it requires rendering to texture. the latter is relatively cheap - comes at the cost of some more vertex work and an extra drawcall per object.
Yep. I'm going to have to see if/how feasible using edge detection will be. Right now I'm betting on worst case scenario for proof of concept stuff, so that would be hull extrusion. It's likely I'll have a tiered outline approach anyway; in an MMO you cannot control how much is on screen at a same time and events can bring normally stable clients to their knees (if the servers don't buckle first). So it's possible, depending on outline quality, that the client will automatically shift to less complex methods.
I believe there is a way to do single pass outlines too by checking if the normal of a fragment is sufficiently pointing away from the camera and then adding a black pixel there. I suppose that could be the final tier, but I don't have high hopes for quality, particularly as I'd have to hull extrude the base model in the vertex shader to make up for losing inside pixel space.
darkblu said:
* don't be afraid of normal mapping - the fragment shader takes just an extra texture lookup (i.e. the normal map lookup). the vertex shader does not need to be much more complex either, given you'd normally use your light sources in object space - it's one more transform from there to tangent space. skinning can tax your vertex shader a bit there, as you apparently should skin at least one more vector to form the tanget basis (and that's num_bones X transformations per vector), but with good vertex counts you'd be skinning w/ normal mapping at no time.
Before I respond to this, first... more shiny graphics!
3D rendered on the left, hand drawn sprites on the right for comparison. This is using a very simple shader and I quite like the results. The outline was created through hull extrusion, which doubles the tris from ~1k to ~2k. The result is definitely passable though.
The shader used here uses some very basic per pixel lighting (dot product of the light and the normal) and then tiers the intensity, and I think the results are pretty nice for such a low poly model. So I don't expect to be using normal mapping on the Pandora, as at this resolution it's really not necessary. Normal maps might be relatively inexpensive but they still require texture state changes (very expensive) and extra memory. It may be added as an option (turned off by default) if I decide to add it for desktops anyway, though.
The nice part is that so far I'll only need textures for small details. The whole body can be done with simple vertex colours. I might be able to stuff a lot of the details that
do need textures (like the character's eyes, decals on clothing, things like that) into a texture atlas that combines a lot of very tiny textures, and require extremely few texture state changes while rendering mobiles.
So I'm feeling pretty good about getting all of this running at a stable speed on the Pandora so far.
Bonus: I created a rotating animated gif of the character base.
In the stills it's easy to pick out distracting flaws in some of the pixels, but in the wild the model would probably never be completely still. The gif is to see if - when animated - the flaws become less apparent, which they do to me. I hope shimmer won't be too much of an issue though. A lot of that comes from the outlines, I think, and if I'm not married to using hull extrusion the actual results will be much better.
But even with this level of quality, I'm quite confident I can make this game look kickass.
And as a last bit of news, it's likely that someone I know and trust will be helping out with the 3D modelling when I figure out what the actual specs and budget are, freeing me up to do more environmental texturing work and coding.
