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
Project from a couple weeks ago. Normal map needs a good deal of work still. Not sure what lights/render settings people are using so as the face angles aren't apparent.
For some reason the image is shown as broken, not sure why.
So simple yet so awesome!! Inspire me to do something like that!
and of course http://wiki.polycount.com/NormalMap/ (especially this link http://www.svartberg.com/tutorials/article_normalmaps/normalmaps.html )
So here it is....
Inspiration came from this concept http://fav.me/d6b4oex
Still very much WIP, the shape of the head/face still needs some tweaks and the texture definitely needs improving
Got along way to go before I trouble any of the low poly masters on here I think
Currently sitting at 338 tris.
Next up some hair and tweaking I think.
great start.
@hardware - Yeah dude! Sometimes it's worth the extra polys to make something look a little cleaner. Plus, it can help improve expressions a lot if/when you're setting up a facial rig.
Threw together a quick hairstyle to see how it would change the look.
Did you sharpen your texture when you down ressed it? It looks like you're having the same problem that I have! Around the lips is a perfect example, it's got this bright edge around it that wasn't in the original texture.
Example :
You can kind of see it around the lips, the iris and the eye lids.
Does anyone know why it does this?
So unfortunately I don't have an answer as to why you're seeing those artefacts, although I wonder if it may have something to do with having scaled those parts of my texture.
Maybe someone else can provide us with the actual reason.
if you're worried about file size, you can just optimize the file and keep the sharpness
but i guess that explains why textures for some lower poly games look like they do
[ame="http://www.youtube.com/watch?v=iJwkFUCSBDU"]Who stole my book - healing effect - YouTube[/ame]
Game lowpoly model. 756 Tris. Let me know what you think.
Game engines, in comparison to applications like 3ds Max, Maya, and Blender, are limited in their rendering capabilities due to the fact that they have to render everything you see on the screen in real time. The standard for most games these days is 60 frames per second - in other words, the engine has to render out the entire scene on screen 60 times every second, while at the same time taking into account systems that may be acting on those assets, such as player inputs (via their gamepad), physics, etc.
Naturally, this means game engines have to cut corners and lighten the load wherever possible. Assets that go into games have to be a bit easier for the engine to handle, too. There are a number of ways corners can be cut and the load can be lightened (depending on the engine):
1) Lower polygon count
Models being rendered for film, or straight from a 3d program (ie not in real time) can be as high poly as you want. It might just mean waiting longer for a frame to render. In game, though, to get better performance artists will usually keep the polygon count a bit lower on their assets. This is becoming less of a performance hindrance for engines, though, and other issues (below) are much more costly.
2) Fewer draw calls
As I mentioned before, it is common for engines to combine all the textures of the assets for a scene into a single (or a few) larger texture sheets, usually referred to as "atlases" or "indexes".
For example...
In the above image, a bunch of textures for different assets have been put together on a larger texture sheet ("atlas"), and the game engine assigns coordinates to each one so that it knows which texture goes with which asset. The reason this is done is to cut down on the number of "draw calls" the engine needs to make whenever there is a change of state within the game.
As an analogy, imagine that you're standing outside a library. You're friend asks you to find out what year George Washington was born, so to do so you have to go inside the library, find the right book, look up the information, and bring it back out to him. Now imagine your friend has asked you to look up the birthdates of seven different people, each of which is contained in a separate book. That means you would need to go looking for seven different books to find all the info your friend wants. Imagine how much easier it would be if all those birthdates could be found in one book. The same is true with game engines. Each trip into the library is essentially a "draw call", and every time you have to do one it taxes the engine and makes it work harder. By combining the textures onto one atlas, you essentially put all the information in one place for the engine to find. This is also the reason that game engines require textures to be in powers of 2 (32x32, 64x64, 128x128, etc.), because it helps them to fit together more nicely on the atlas.
3) Minimizing the amount of transparent objects on screen at the same time
Transparency is pretty taxing on an engine, since it needs to calculate a lot of different things. It becomes even more taxing when multiple transparent objects are stacked in front or behind one another. This is one of those things level designers tend to keep an eye on, to avoid building areas in the world where you have a lot of transparent things on the screen at one time.
These are just a few factors game artists have to be aware of - there are many others, but I've gone on waaaaaay long enough already. Ultimately this is all a balancing act to avoid over-taxing the engine and to make sure the game runs at a smooth 60fps and responds well to player inputs. Games are constantly cutting corners in one area so that they can increase their budget in a different area.
Anyway, I apologize if this has all been super boring and/or you don't care. Hope someone found it interesting!
Although that might be the case in some engines, historically the opposite was true, you used a texture atlas so you could efficiently pack multiple non-power-of-2 (NPOT) textures. Is wasn't so much the software that required it, but the hardware. Division and multiplication is much (much!) simpler for powers of two, as is memory allocation and addressing. With modern programmable pipelines (packed full of floating point calculation units) it isn't that big a problem anymore, but power-of-2s might still be more efficient.
One example where POTs still have a great advantage is MIP-mapping (used for trilinear filtering). It stores sizes of the same image in one texture, each a quarter in size (half width and half height) of the previous. These smaller versions are created offline (before rendering) using quality algorithms that are too slow for constant real-time use. With POT textures, getting to a smaller size is easy, and there is guaranteed to be an integer value for both width and height until either becomes 1 texel. This is not the case for NPOTs, where you may end up on half texel widths.
Note that although modern GPUs all support NPOT textures, most common texture compression algorithms (DXTn, ETC) work based on 4x4 blocks, so having dimensions as multiples of 4 is still recommended.
A historic note from http://www.opengl.org/wiki/NPOT_Texture : So beware if you're targeting 10-year old GPUs
Thanks for taking the time to explain all that. Nice analogy. Very helpful
@third
this is all so informative. thanks!
my rig is about 7 years old so this is needed information.
Hi Parellel, I really appreciate the critique. I will work on a different material for the bag to see if I can make it more apparent as to what it is. As far as the material goes for the bin I based the bin off of a real trash can I found at a park I have included one of the reference photos.
I see, so it's a lack of cultural reference on my part. In northern Europe those type bins are usually only seen in american franchises of the plastic variety, though there are similar ones for public outdoors but they're generally more sturdy plastic with no bags.
Hey, hope you don't mind, I outlined a few things on the reference you posted that I think could help make your model look better:
1) These ridges are pretty iconic for this type of garbage can, and your model doesn't have them. I think adding them in would not only add more visual interest to the body of the can, but would also help people to realize that that top strip is a transparent plastic bag (since they would be able to see the bolder shapes of the ridges peeking through). You could either paint those ridges in, but since you're using actual lights you'd probably want the ridges to react appropriately to the light. In that case, I'd model a higher poly version of the garbage can with the ridges present, then bake the higher poly details into a normal map and apply it onto your low poly model. This way your model remains low poly but still has those ridges that will react to changes in light.
2) I think your garbage can could use a bit of grime/dirt near the bottom, like your ref shows. This, again, would add more visual interest, but it would also make the garbage can appear slightly darker near the bottom, adding to the visual weight, which helps ground it in the world.
3) These pinching points, where the material of the plastic bag is pulled together, help to differentiate it from the garbage can. Especially when those parts hit the light. Try adding more shapes in to the plastic bag like these, and also try playing with the opacity and specularity of the bag. I agree with parallel that it was hard to see the plastic bag at first - at first I thought it was just twisted UVs, and didn't realize it was a plastic bag till he pointed it out.
Hope this helps!
DemonPrincess - Yeah I understand that, sometimes it's just nicer/easier to paint at double the res and downscale it. I imagine the best way to do it is to paint at double, rescale and then continue painting / tweaking to get the result you want.
That's a valid workflow, but you have to be careful not to paint too much at the higher resolution. The downsizing process will get rid of a lot of the details and make everything look blurry overall, so you may be wasting a lot of your hard work that way.
Ofcourse, this is all assuming you know the final resolution. During actual development, it may not always be so clear, so in that case it's safer to paint the texture at a higher resolution. You can always downscale a texture and tweak from there, but you can never upscale.
This is a character I drew awhile back, I thought she'd be a good excuse to try low-poly modeling and texture work.
I gave her all 5 digits on her fingers, without those she'd be around 500 Tris.
Here are the various views and specs, I'd appreciate any critiques you guys can give me on the work I've done. Thanks!
Thanks so much! Could you explain further what you mean by making the face more planar, do you mean much more flat? I added a couple tris to give her a nose, but do you mean to remove that?
[SKETCHFAB]31a1aed4b57d472691ffdecfc6cfc25d[/SKETCHFAB]
Aside from that, I really like the style you've got going.
I'm curious about the crystals. Did you just set them with reflectivity and bake the lighting into the texture? Or some other trick?
Various sizes
Maybe in little clusters
here I made some low poly enemies recently for a personal project ^^
This is the project's wip page if you'd like to know more: http://forums.epicgames.com/threads/974180-Stranded-iOS-Twin-Stick-Shooter
cheers
full thread of this project here.