This is the sweet spot for your low-poly models. Post 'em if you've got 'em!Low-poly hasn't really been a requirement in the games industry for a long while now. This thread is for low-poly art style appreciation, so please take note of these rough guidelines:
- Keep models under 1,000 triangles.
- Scenes are fine, if all models are low poly.
Some dedicated low-poly modelling tools now exist that make this art style a lot easier to produce;
Crocotile3D &
BlockbenchHere's a handy list of ways to make your art look right in mainstream 3D software:
Low-Poly Art Style Guide
Replies
TNO thanks for the tip
I solved the problem, wasn't what you told me but I got to fix it thanks to your post.
It was the texture filtering, options are hided in blender you got to make a search to find them...
Problem is not just the pixel look, it's how the textures look at the end (see the first picture).
@Spatz: thank you.
Russian solider has 1730 poly in total (with ak), uniform alone has 238 polys (the face,hair,gun and holster add to that)
47 has 670 poly in total.
It's not for a game, just for training.
Textures and wires aren't out of the ordinary, it's the same you can see in quite most of the thread.
I'm still quite new to modeling scene but here's something I pooped out
and low res for fun
512 x 512?
the ridges could be done with a normal map, probably dividing your triangle count by 5
handle / front decal could be a two triangle plane, saving you quite a few triangles.
A prop such as a chest doesn't need so much definition, the details here are worthy of a main character, especially as you are painting the lighting into the texture, the geometry could be flatter with no impact to the profile.
My first low-poly Chars.
Here's something I've made in a couple of days, inspired by a new game, still in development, Pixeljunk 1-6. I'm in no way affiliated with those cool people, it's just that the visual style seemed so very cool to me so I decided to try and make out a 3D version of one object.
I'd also have to say that this is my first attempt at a lower poly modeling and texturing so this model is still not perfect in any way, but I'm learning something new every day. The tris count is slightly above 1000 but I hope it's ok to put this here. I'll try to optimize the model even more, when I get the time.
And here's a little turntable:
All suggestions and critique are welcome. Stay cool!
Mobile spec environment and character i did for my demo app...
You can test the app / "game", as it is on the app store with a demo boARd downloadable from my site.
There is still much to do with this, fe. I have concepts for the interiors, but people out of time...
edit: oh, I thought the above crits were for AndrejGrek. I think they apply there too. texture space is at a premium on mobile
As for the style, I am glad you like it. It is supposed to be a sort of a WW2 set city with heavy espionage going on as you can obviously see, as men in suits are walking outside at night trying to look inconspicuous
@MattQ86: The character again was supposed to be prepared for further detailing, that did not happen due to time issues. But I quess that if the first screen shows the most common use case, the 850 tris is an overkill too But you can get up-close to the boARd and see the characters really detailed.
The only downside IMHO are the shadows under the guys: they are so dark that they blend with trousers.
Yes, the shadow should be lighter or more transparent. Thanks.
I could go with the VC's, i think the quality could be alright thanks to the linearity of the gradient...
But there is another problem with such texture atlases and MipMaps. There is always some unwanted mixing going on and I did not have time to fix it so I turned them off for now.
Thanks for your feedback.
512x512, 256 quake palette bmp
I was just planning to surround myself with cats, but then one of my classmates threw in that it should be my mount. So I scaled it up and gave it a saddle. It's a testament to how great this industry is that I sat back one afternoon and said to myself, "I'm painting a saddle. For a cat. A saddle for a cat"
I wish I could have gotten a bit less blurry in the face, but I wanted to match texel density and couldn't mirror across without the highlights ending up in the wrong places, giving me a bit of a derp expression.
Both of the characters are rigged (incredibly simply), and once I've finished my other class projects I'm very tempted to try and animate them.
Thanks for the response. ^^ If it wasn't meant to be me the clothing would be more colourful, but I generally wear black pants, a black t-shirt and a black jacket (and carry a black backpack). I might try a bit of a levels tweak to up the contrast between the items for a touch more clarity.
Edit: Here's a new version with a bit more contrast - it's definitely more readable at the smaller size, you can see the jacket is seperate from the pants and backpack now. Thanks again!
I have some parts set up as floating geometry, but I keep running into issues when I bake an AO map from it:
http://www.polycount.com/forum/showthread.php?t=108864
Do you mean that I should have set them up as separate parts with geometry that intersects with each other?
some of that crosstoasting up in this:
my thread: http://www.polycount.com/forum/showthread.php?t=108323
Wires please! Are those actual normals or just baked AO?
119 polys in max. Glowing plant.
blue is one half, imagine the yellow to be mirrored of the blue.
This severely reduced the amount of transparent pixels - which will save you in overdraw (when you have to draw a [semi-]transparent pixel over another pixel it costs you extra GPU-time) plus it will give you a bit closer approach to the wibbly wobbly shape of a leaf.
"This severely reduced the amount of transparent pixels - which will save you in overdraw (when you have to draw a [semi-]transparent pixel over another pixel it costs you extra GPU-time) plus it will give you a bit closer approach to the wibbly wobbly shape of a leaf."
Thanks for this info to as I wasn't aware of the increased GPU time. I thought it was a draw for the texture then a draw for the effect as a whole (Hence the larger shaped leaf plane.)
Edit: A quick question though, which would increase GPU time more, a few extra polygons or more transparent pixels?
Normally you shoot a ray out of the camera into the scene to hit the first polygon it finds. It then looks up which polygon that is, and which texel (texture pixel) on it the ray hits. Then it displays that pixel (and it does some fancy stuff with lighting).
With a (semi) transparent pixel, it does that too. BUT then it has to do it again to find out which color the pixel behind it is, so the GPU can blend the two colors. If that underlying pixel is also transparent, it has to check again, and again and again until it hits a solid colored pixel. This of course multiplies the 'render cost' of that on-screen pixel by as many layers of transparency there are.
This can be alleviated slightly by using alpha-test (making it 1-bit transparent) so it can calculate a bit faster and it also doesn't have to store the blendcolor for every layer. Or the programmer can do something like "if more than 5 layers of alpha, pretend the 6th layer is opaque black. But still, it's costly.
This highly depends on the engine and hardware you use.You could run a bunch of tests to see where the tipping point is in your case, or... you could use a thought out guess.
In the end, it doesn't have to be exact, because polygon budget estimates are not exact either, not can we accurately predict where people will be pointing their cameras. If your object is already highpoly, a 100 extra won't matter. If you're working on a topdown game with a large map area in memory but you only have one layer of foliage, maybe keeping the alpha is smarter.
In this case, I saw I could get rid of more than half the transparent pixels with only 6 extra triangles per leaf, or 18 per plant. That's about 15% more triangles, but about two-thirds less overdraw. Plus, you could now add some more shape to the leaves and perhaps upscale your UV islands a bit.
Also, keep in mind that if you have very little transparency, you might even abstain from an alpha map at all. That makes the shader simpler, reduces overdraw, and might even save you some memory.
[this last bit about filesize isn't super important, but I felt like figuring out those numbers]
If you use 1-bit alpha, a simple 64² alphamap takes up 512 bytes (half a kilobyte) which is enough for 32 vertices. But if you were to use a more reasonable 256² that gives you 8192 bytes, or a whopping 512 vertices.
eg: If you have a big box obstructing your view, and you draw the whole background, and then the big box after, you have overdraw on every pixel that is blocked by the box, and you touched all those pixels twice. Ideally you want to touch each pixel as few times as possible.
We have occlusion tests and or reverse painters algorithm to solve that. This also helps to determine if a simpler shader (drop everything but basic diffuse) should be used for objects that are obscured, or don't have a lot of visible pixels.
When an engine renders a scene, all the transparent stuff has to be pushed to the end of the frame, and then all the polygons with a transparent material have to be sorted by distance from the camera.
If you have an object with lots of polygons that uses an alpha texture just for a small part of it, then everything has to be pulled apart and sorted by distance anyways. So it works better to split off the transparent part to it's own material.
Then the engine/renderer has to expensively (small batch) render each polygon separately by distance, and possibly doing an expensive material change after each one.
So it's best to only use a transparent material on the exact polygons that need them, and to use as few polygons as possible for transparent object. Which is why you usually see flat planes to minimize things to 2 triangles.
Also, there is no such thing as Alpha Test anymore. Newer GPUs got rid of it, like they got rid of lots of outdated stuff that isn't used anymore. Alpha Test now is really an alpha blend operation that simulates the same results as an old alpha test.
i was somehow inspired enough to make a low spec version of this piece of work from Weirdboy:
100 tris
128 pixel texture
You still have to test the pixels of the polygons with the alphamap on it, right? You may not have to actually draw them on the screen, but you have to look up the texture coordinates etc which is still wasted time, if you could also make a few polygon cuts to reduce the amount of 'empty' pixels on top of eachother.
Or are you really telling me that we can make a layered mesh like
and while rendering this, the screen-pixel at the place of the pink stick does not do anything with the leaves whatsoever? No performance hit?
sure, although i do admit to not having the UVs as optimised as they should be
128 x 256 texture, like 16 tri's
thats exactly what happens with particle effects in unity on ios and that kills performance on most iphones due to the overdraw. Ive done tests and even just having one big cloud particle effect go past the camera really close is often too much for the device to handle. maybe the latest pc hardware doesnt have these same overdraw issues or they dont suffer as much?
Here's one based on an illustration by the famous Creaturebox.
990 tri's
Now, snader, I think Daaark didn't mean to say that transparency planes overlapping don't cause overdraw, but that overdraw as a whole is a much broader issue, not specifically related to transparency,but rather any case where you have two things being rendered at the same place on the screen. That's why there is occlusion culling and tools like Umbra to help hide unnecessary stuff.
Ged: No it's still an issue on PC's, although current hardware is far beefier than consoles so all of the (ported) games run pretty smooth on decent hardware. But the smoke/fog of [url="file://localhost/C:/Dropbox/Public/TeddyProtector/Webplayer_3_Fast/WebPlayer.html"]this thing[/url] are still intensive enough to give issues on older PCs.
'one big cloud particle effect' is a pretty intensive thing to run, because one particle emitter still throws out multiple stacked transparency layers so you will still get, say, about a dozen or so polygons that are half the screen area. Which means that you have to render 7 times the amount of onscreen pixels. 1 for the background , and (12x0.5) for the particle effect. So the best thing to do is to have less layers that are more opaque, or make the particles smaller and more opaque. That way you still have a 'full' look but at less cost.
kyubus: that's a peculiar way to make the eyes (the indent and the floating iris) - any reason why you did them as such?
Cactus: keep in mind in which directions and places, and for which reasons, dirt tends to 'grow'.
Laperen: those painted windows are remarkably effective, but overall I feel the texture could be a bit stronger. It's just greytones with a lot of noise right now; some color and a bit stronger painted lighting would be nice. Also, keep your texel density in mind next time, the block with the number on it has considerably larger texels.
@Nina and MrRik
I'll try your suggestions and see how they turn out.
@Vysuki
No bake. I put in the base colors and then made a black and white layer that I painted the shadows in. Then I painted the highlights in another layer and reflected colors in another. Finally I colorized the shadow layer to some bluish hue. Also, shadow layer was set to multiply and fill rate turned down a bit.
Edit: Calling him Baron Dollarsworth now, a poor guy who thinks he's rich. :icon15: