what a fucking answer ;D Thanks for explaining it to the 3D illiterate layman. godspeed! :y:
I want to know anything that stands out as needing improvement. Anything that looks off.Baring some minor adjustment, I think you got it pretty much as good as it can get -- which is good enough for your purpose. It looks pretty cool.
I think you need to create some scenes where pixel art is combined with this. I don't see a huge value in making an entire 3D game like this, the value is in making a pixel art game, and having certain parts be 3D I think. Then the question is if you can make your shader fit that particular game, to a point that it doesn't break the immersion.
If I think more idealistically I would say that there are some things that you just don't want to be AAed at all. If you look at Metal Slug, for example, their strategic use of hard edges contributes a lot to the readability of the art, which IMO should be a primary concern of any game developer.If we keep looking at it as a realtime application, that's another conundrum we have: pixel art can afford to be very sharp, because it doesn't have to hide mistakes. And thus sharpness is a common trait of pixel art. The more we try to just sweepingly blur the errors out here, it will tend to look less convincing as pixel art and more like just another form of cellshading, as well as make a carefully managed colour palette less and less meaningful in the end. A very narrow line to walk in optimizing it. So that's something to keep in mind.
Thanks! On the "too realistic" front, I'm curious precisely what you mean. Texture? Details? Clean lines?I think most of all it means the calculated correctness of whatever it applies universally. Be it perspectives, shadows, shading, whatever not done manually. it is all physically correct or solves numeric otherwise, even when it is "toonish". Since this kind of correctness in everything across all frames this smooth is not tradition to pixel art, it can look uncanny.
: I don't think you can judge these by themselves, as pixel art.
1) They are not and not meant to be pixel art
2) You'd probably use this shader in a scenario where it makes sense, like combining it with pixel art for certain characters that would otherwise prove impossible to animate
That's an issue with the model, not the shader. Any attempt to fit more shape information into a subpixel area would end up messy, no matter the medium. Here's a cleaned up version:It is an issue with computed rendering at large. And that's what I'm pointing to: it isn't an issue in pixel art, because the pixel artist knows and controls exactly the conditions of display that don't change, and tailors the art perfectly to fit that, understanding what detail fits what degree, distance and sub-pixeling, for example.
What I point out also are aesthetic problems regardless of what art it is. Yet the topic is "3d meshes as pixel art", and Howard stated specifically it is his interest to find out how close he can get to look like it, and asked for what problems are in his way. Actually, trying to integrate it with other real pixel art makes judging and discussing the problems as pixel art even more important, since you would want to avoid glaring aesthetic breaks between the assets sitting next to each other. Maybe I come across too critical though. And after all, you are an actual pixel artist on professional level, so I'd say Howard should rather listen to your opinion on what you like about it.Oh, I would hardly value my opinion above anyone else on this forum. I do get your point. I think the point is this: I think he can still get a fair bit closer to pixel art, but he'll never get close enough to be able to call it pixel art. The simplest definition of pixel art is art where you have control over individual pixels. I don't feel like any of the renders have enough control to call it pixel-level control. I do think you can get away with combining stuff like this with pixel art though, and that would be my aim if I were to make something like this. Also, the fact that you can make procedural animations is HUGE. The only way to have procedural pixel animation is by using a combination of lots of keyframes and paper-dolling, which doesn't provide you with even a sliver of what's possible with 3D models.
The more flexible you make the conditions of display, the more the problems in the rendering as pixel art. There are little to no margins for mistakes in real pixel art. The adaptions you made to the model are mostly good for the conditions you adapted them for. Change distance, and they come back the same, among the issues it still has either way compared next to manually polished pieces. Curiously though, micro-managing models like that to fixed angles and distances, starts to eat up some of the advantages of going 3d.
Conceit: Jesus, sorry. I try and answer with all the information! :P
Quote from: Howard DayThanks! On the "too realistic" front, I'm curious precisely what you mean. Texture? Details? Clean lines?I think most of all it means the calculated correctness of whatever it applies universally. Be it perspectives, shadows, shading, whatever not done manually. it is all physically correct or solves numeric otherwise, even when it is "toonish". Since this kind of correctness in everything across all frames this smooth is not tradition to pixel art, it can look uncanny.
That reminds me of that article explaining GGXrd's art style, Conceit posted it awhile back in the OT thread IIRC.yup. (btw Ai nice link Imma watch it)
the bone themselves have a higher degree of freedom than usual, so the characters can fake 2D flaws. For example facial features can move around the face to better match drawings (Bedman in his instant kill cinematic as he'd appear withoutI know this kind of stuff is like the opposite of a cheat, tweaking everything to fit one speficic occasion and never use it again, it's almost anti productivity anti fast workflow =/ but some other techniques do allow for artistic direction without constant tweaking.
deformation
(https://i.imgur.com/0Le6f8z.jpg),
the suggested 2D corrections
(https://i.imgur.com/3AlH2Ox.jpg)
and the final result
(https://i.imgur.com/5t0ujza.jpg)
SNIP!
Characters also needed to fake or exaggerate perspective in ways changing the camera's field of view couldn't achieve so this was done through allowing bone scaling on all three axes. UE3's animation system can't do that out of the box, they had to code it themselves and cite it as a great advantage to having access to the source code. And once they had that in, that meant they'd also opened the door to all kinds of muscle motions, cartoony squash'n'stretch animations and deformations. A big punch will get a big fist and so on. Bone scaling is now a feature in UE4 and they like to think it's because of Xrd.
May's victory pose
(https://i.imgur.com/syQBkeG.jpg)
the actual deformation
(https://i.imgur.com/4aemscg.jpg)
SNIP
Sol in Softimage with his bone scale settings
(https://i.imgur.com/nhjo2Ev.jpg)
R channel of the vertex color is a shadow bias, ie it's like ambient occlusion except artist-directed. Pixels that have a lower value will be more easily in shadowThey do something crazy with each one of those channels which I dont really know what they're for. There was a whole topic talking about this stuff where people broke it down for me but I cant seem to find it anymore ( if any mod reads this, did it get wiped off automatically or something?)
((https://i.imgur.com/1PPKLRx.jpg)
occlusion term,
(https://i.imgur.com/tVgRjXC.jpg)
model without it,
(https://i.imgur.com/V80qxnA.jpg)
model with it).
Specular highlights are controlled by the R and B channels of the ILM texture. R is specular intensity, B is specular size.
(https://i.imgur.com/ibZ397m.jpg)
See this close-up of I-no where the left side and right side of her top have different specular size
In technical terms? No, I don't have enough relevant experience to say.
Ai: Ahh, yes. I'm very familiar with the GGXrd's art style and methodology. I'm actually directly using their Vertex AO > driving lighting ramps. Its a great idea, and I'm a huge fan of everything they did. I'm glad you like the improvements - I'm still pushing it more!
Anything you'd like to see?
Conceit: I'm being incredibly sarcastic. :P I knew what you meant, and I was just trying to be humorous. I'm already doing a ton of the stuff they're talking about in the GGXrd technical papers - but I'm doing them with mobile devices and sheer speed in mind. Things like the specular levels and material presets - all of that's done with the ramps. Need a large specular hit? Push the lightest bar in on the side. It really is quite versatile. :DOhh, dynamic gradient mapping. Now this is more familiar territory. I guess that means that multiple lightsources are a pain to do. I worked out an option for that previously which basically adds a blending factor between two or more ramps (with the caveat that the ramps are ordered and you can only blend between ramps with adjacent indices). Perhaps that's an idea that might be usable here.
"There are little to no margins for mistakes in real pixel art." That is...not actually a viewpoint I hold with. At all. In fact, I have no idea how you'd ever quantify that! What's a "mistake", and what's a thinking artistic choice? Dithering is a choice - how much it's dithered is a choice - color ramp hue shifting is a choice...in fact, I'd be shocked if there's pixel art anywhere that would completely fall under the "no mistakes" label. Everything someone does as an artistic choice may be a different choice than another artist would make.I don't like arguing it too much, but having a better understanding of the problems you're dealing with is important for any success in finding further improvements to the shader. So this is not to stop you, but you need to be aware of these things for your work. That's how Pixelation serves you best in your quest.
Heh, you might be surprised. I'm actually exerting a lot of control on everything visible.The measure by which to judge your control on the pixels is not the code, but the image we're looking at. It is obvious, not surprising. The shader controls the pixels, not you. And the shader's use of techniques in this control is very simplistic and often less than ideal to a given need compared to how pixel artists use the same techniques. A pixel artist knows how to get the best out of a technique on a given piece. The most important limitation you should consider to work on as was pointed out, is giving the artist more selectivity options with which a certain technique is applied. That is give back at least some control over the pixels to the artist by having some more control options on the shader, in the ability for more selectivity in application of a technique on the model. An on/off toggle for a technique is far away from pixel art control. Finding out which control sub-options on each pixel technique make sense and are useful could be your next best goal in searching improvements from here on out. The level of control you allow the artist to still maintain over the image manually, despite the dynamics, is in the end most what decides how close you can make it useful as pixel art, less how smart you would try to make the shader by itself. It's important to remember that.
Seiseki: Thanks! On the "too realistic" front, I'm curious precisely what you mean. Texture? Details? Clean lines? All of this can be... tweaked. For instance, here's a shot with some noise introduced and no shadows.
Ai: Okay, like this? MADE A DRONE.Yeah, that's pretty good. The only issue I can spot seems to be at the ends, where variation in line width due to varying pixel alignment becomes a bit apparent.
(http://www.hedfiles.net/PixelShader/pixart_33.gif)
Thems some thin lines, son! the object line width is totally controlable - you use the vertex alpha value to multiply the width.
...and as for "AutoHinting"... yes, that's completely possible. Even easy! You run into the problem we did last time, though - your assets need to then be built on a grid...and that will only really work at a single zoom level. Zoom in and out, and your exact pixel positioning goes away. :(That just sounds like.. manual snapping. Autohinting is more like dynamic snapping, so that whatever scale you're rendering at, it's snapped to those pixels, not whatever pixel scale you started out with.
And multiple lights with lighting gradient maps... totally possible as well! I know because I've done it. Here's a test I did for a tribute to the Star Trek 25th Anniversary art style. As you can see, the lighting is ramped, there's multiple colors, and they all play nice together.Can't see shit, cap'n. Blank white rectangle on top of a blank white page.
http://www.hedfiles.net/STMobile/STMobile.html
Seiseki: Oh, gotcha. Here's the scene with Dawnbringer's 16 color palette with no dithering. :DLooks pretty clean.
(http://www.hedfiles.net/PixelShader/pixart_34.png)
Okay! So, I re-wrote the dithering to work on the material, not as an overlay. It works a TON better.Yay! I was helpful :D
TBH I prefer anything that doesn't produce those weirdly-clustering isolated 'bits of checkerboard' we were getting before. Increasing dither levels to 4 (2x2 bayer matrix) or more would do that IME. No dither at all would also do that.But I specifically enjoyed those bits of checkerboard :(
Howard is doing some really impressive and new stuff here, yet I feel like the replies are starting to turn into discouragement.Oh, I think I plainly stated before in the thread that this whole thing is HUGELY exciting to me :). I love what he's doing and I can't wait to see more.
TBH I prefer anything that doesn't produce those weirdly-clustering isolated 'bits of checkerboard' we were getting before. Increasing dither levels to 4 (2x2 bayer matrix) or more would do that IME. No dither at all would also do that.But I specifically enjoyed those bits of checkerboard :(
Ai: Getting exact Bayer dithering patterns is more complex than you'd think. You have to put all the info into a single texture.I don't understand what the difficulty is. Bayer matrices are exactly small 2d textures that you threshold; which as I understood is exactly what you are already doing.
Gil: ..Uh, wow - so, I'm a little surprised you're taking this to the "this can't possibly ever work" level... To be honest, I thought we'd been working pretty well together, and I thought I'd been making great progress. Honestly, I and you both know this will never replace pixel art - that's not the point - the point is to get as close as we can, and I don't think we're there yet.The reason I took that route is because I went in with graphicsgale, ready to provide to edits that could help you out and found there's very few pixels there that felt placed. I do a lot of cleanups of processed stuff and that's what it felt like, like I'd had to clean the whole image.
Ambivorous: Yo. :)Yeah, that seems to fix the issue with clusters of checkerboard without looking overly un-pixely. Looks nice, especially the napalm on the woman is closely approaching my idea of how it should ideally look.
Ai: Oh, well the issue is that I'm not smart. I didn't understand what you were saying, and was going about it a totally wrong way. Sorry. I've put your dithering matrix, as is, into the build - and it looks pretty cool!
Gil: Hmm. pixel clustering is likely something I could write a shader for, but only on DXT11 platforms... I'm looking at ideas on how to push it more - like the 2-pixel minimum clustering thread - but forcing the shader to do things the way I want is turning a bit awkward.2pix minimum would be nice as an option in a similar vein to the option I suggest above (that is, as a way of emphasizing the different roles of visual elements by differentiating them stylistically). It is surprisingly hard to solve well, though, IME -- a fair bit of planning goes into getting a final result that is both reasonably clean and attractive.
A pixel artist always would draw very clean outlines and AA them with not more than 4 colorsThat seems slightly problematic:
In your model there are some planes (especially round ones) which have 5 colors plus dither, which is an effect no pixel artist would ever go for. It takes to long and works against having clear and strong clusters.
That seems slightly problematic:
(http://i.imgur.com/nzW9KNK.png)
(http://i.imgur.com/PycipNe.png)
(remade gfx for Bub-n-Bros. Lots of colors (24 - 266 per icon), no dirty tools used (not even lowered opacity), coherent on a pixel level)
ptoing: Hmm - but one that only affects the shadowed areas? Yeah, I can do that. :D
the more time you spend with the 1x1 pencil tool the better this project will becomeI do notice, that as I get better as a pixel artist, I'm starting to use less and less of the 1x1 brush. It used to be that pushing individual pixels around was 90% of my time, nowadays I just seem to work in broad strokes, apply automated effects, use the selection tool a lot and then in the end slap around a few pixels (but exactly the right pixels) to tidy up the image to pixel standards.
the more time you spend with the 1x1 pencil tool the better this project will becomeI do notice, that as I get better as a pixel artist, I'm starting to use less and less of the 1x1 brush. It used to be that pushing individual pixels around was 90% of my time, nowadays I just seem to work in broad strokes, apply automated effects, use the selection tool a lot and then in the end slap around a few pixels (but exactly the right pixels) to tidy up the image to pixel standards.
How all that relates to what Howard is doing, I don't know, but he'll figure it out :)
Really? Do you have any examples of this kind of workflow? Sounds like a really odd way to make pixel-oriented artwork (I don't mean to be disrespectful; I'm genuinely curious to see what you mean).I don't tend to keep progress around (bad habbit, I should, if only for backup reasons), but I think you can see that kind of progress in this folder:
The art looks good, man. I wouldn't get too concerned over whether not it can be called pixel art, because the bottom line is that it looks good regardless of what it is.It's more a question of whether it will *fit in* with actual pixel art, which Howard has set as a goal. That's the context of all this discussion about making it more pixel-arty.
from my friend on skype:
"If you combine this with a vertex shader that quantizes bone position to limit the framerate of character animation, you could do some pretty sick things with IK"
I don't know jack all about this "Third Dimension" stuff but here you go
from my friend on skype:
"If you combine this with a vertex shader that quantizes bone position to limit the framerate of character animation, you could do some pretty sick things with IK"
I don't know jack all about this "Third Dimension" stuff but here you go
Yes, to achieve a better effect, "limited animation" should be used, with a small sumber of animation frames. This could also just be done directly in the 2d modelling application with keyframes spaced accordingly, and then with Unity slowing the animation down suficiently.
from my friend on skype:
"If you combine this with a vertex shader that quantizes bone position to limit the framerate of character animation, you could do some pretty sick things with IK"
I don't know jack all about this "Third Dimension" stuff but here you go
Yes, to achieve a better effect, "limited animation" should be used, with a small sumber of animation frames. This could also just be done directly in the 2d modelling application with keyframes spaced accordingly, and then with Unity slowing the animation down suficiently.
I'm pretty sure that Guilty Gear does this to bring the 2D sprite "feel" to 3D models in XRD.
There is next to no smooth movement, the model kind of snap into the next pose.
Conceit: Thanks! So, I am controlling the ramps directly. Here's the texture.
(http://www.hedfiles.net/PixelShader/MultiRamp_Test.png)
The way the shader works is that it only lets you set the vertical (v) position of the UV map - the horizontal position is skewed side to side based on the angle of the surface to the scene light, the in/out shadow value, and vertex ambient occlusion.
You can see in that map that there's some hueshifting going on - not a huge amount, but some.
If you're looking at the build (or those images I posted) the palette being used isn't exactly accurate. I've added options to palettize to classic videogames. The examples I posted are being indexed to Rise of The Triad, Arne's 64 color palette, and Duke Nukem 3d. The only one using the actual palette I made for this project is the image on the light background with no AA.
http://www.hedfiles.net/PixelShader/pixart_01.png
The difference from the IRKALLA mechs is that those were pre-rendered in Max, using a procedural max material. This is 100% realtime, designed for use in games.
lachrymose: Thanks! This actually works on everything, including phones and tablets.