LOW-POLY ART
polycounter lvl 19
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:
Here's a handy list of ways to make your art look right in mainstream 3D software: Low-Poly Art Style Guide
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.
Here's a handy list of ways to make your art look right in mainstream 3D software: Low-Poly Art Style Guide
Replies
I just feel he needs a bit work on the speed of his punch. Some adjustment on the curve. Maybe some highlights on the chain.
But those details is just to be annoying...he looks very good.
I can´t realy see, but have you used some bones to act as muscles?
Can ya show your UV layout? I get the feeling UVs aren't properly aligned and it's making your texture blurry.
Also, ManxViking, that's so awesome, I agree the animation could be improved by being a bit faster but it's already awesome as it is.
Oleg: try to keep as many straight horizontal and vertical lines you can to make the pixels align better. you have alot of curved unwraped areas which could have been straightened out, bare this in mind next time you do an unwrap
felipefrango , here is the UV and the texture does look blury on some parts , I think I just didn't Uv mapped it right ? maybe I placed large details on small UV and it didn't come up right.
The bottom of that piece could have been uv'ed straight and let the glass have some distortion instead. Would keep the metal bits crisp and the glass being a bit fuzzy probably wouldn't be too noticable as there aren't really any details on it.
The spring wastes a ton of space, especially since it is just a flat color. You could squish it into a thin little strip and hide it anywhere.
The bottom uv's under the 3 circles could have been straight.
And the long body strip up top should have been straight and taken more space as it's a large piece and focal point.
I'd say if you tightened it up you have about 25% wasted space.
Indeed!
Great model, I like it so much. Love the idea of dynamic vertex painted blood!
How many bones did you use for the animation?
And Drayton, are you using Unity's physics etc for your iPhone game, or your own?
I realise this would be upper end budget for handheld consoles, although somewhat justifiable for the main character with significant upper body motion. That said, I've no idea what bone and animation limitations there are for mobile development, any info would be enlightening.
Same here. :thumbup:
The general rule always applies: the less, the better. Skinned meshes are always quite expensive to render, so limiting the use of bones to the essential, and also using a maximum of 2 weights per vertex, could be a good choice (and still make the deformation look good).
I don't think there's a precise limit on iPhone about the max number of useable bones, but I remember that NDS can "only" handle a maximum of 31 bones per model.
The choise of bone number also depends on how many animated characters are going to be on the screen togheter, obviously. A fighting game with just two skinned characters can flawlessy use a bunch of bones on the character's face, on hair and clothes, etc. Instead, this will be a really bad idea in an RPG with many and many characters being rendered togheter.
I remember some NDS games that, in the worst case scenario, used a single bone for thights and feet, and same for forearm and hand. It looked a bit strange, but at least it was a good way to reduce calculations.
This trick won't be needed on iPhone3GS/Android though, they're drastically more powerful than a DS.
I rigged a few characters with a basic low poly set and had no issues for the web player. (2-3 spines, no finger, toes, etc...)
I can't see anyone getting to carried away with rigs on mobile dev though, it's all pretty low res and everything anyway. Do you need more than 4 bones per vert? Or 20 bones for facial anims, etc...
What framerate are you getting with that many cars?
Either way it's impressive, in fact I think that PhysX engine is the best thing about Unity by far, it seems fast and solid.
Testarossa and Lan Evo. There are more cars, but these are the only 2 that are completed.
Various gameplay screenshots. The first track weighs in at around 30,000 polys, but no more than around 2000 are rendered per frame. Most tiled textures are 128 by 128.
I noticed on the demo on your site that your materials aren't two sided, on tight corners you can see through the back of the wheels and through the car. If it's not too expensive you should cap the back of the wheels and some fill in geometry on the inside of the wheel arches. Texture wise they can be thrown onto some dead texture space filled black. Maybe 60 extra triangles, but possibly worth it.
Framerate varies a lot depending on how many cars are on the screen, but mostly depending on the device, so it's very hard to tell... Here is a brief summary (count that, like in Burnout, you must first drive shortly, then you start the crash mode):
iPodTouch4
Has a good, tight average of 45 when driving and to 30 when crashing continuously, but can drop to 20 for some moments in the worst cases, where lots of cars crash and are rendered togheter. But it never falls under 15.
iPhone3GS
It's better due to the smaller resolution: almost stuck to 60 when driving and to 30 when crashing, but this too can drop to 15 for some seconds. Also the deformation script takes a bit more to process here, but the game is still very well playable.
iPodTouch2
The worst one, obviously. Despite running well at 40 when driving, it's costantly around 20 or lower when crashing with more than 10 cars...
In order to achieve the maximum framerate possible, I put up a simple way to split calculations (like following waypoints) in many sequential cycles. When traffic cars are spawned, they are gradually assigned into one of the defined group of calculations (they are 4 now). The game then processes only one group per update, reducing CPU calculations many times as the number of groups.
This causes traffic cars to be not very smooth when turning, but it's slightly noticeable only on really thight corners.
I also used LODs, dynamic rendering distances, different shaders for every device and other tricks, in order to achieve the highest framerate possible. Unfortunately it's a really heavy game, and I can't really get it to over 30 FPS on every situation and device...
What about iPodTouch2? Performances are everything but smooth now. Actually I'm not using latest Apple Devkits because there are some errors with Unity, but when I'll switch to latest ones (and Apple forces us to do it, at submission time), they will only support devices from third generation and on. So, actually I'm not very worried about poor performances on iPodTouch2, because it simply won't be compatible, later.
You know what? I really loved it. It resembles me a lot of OutRun, and the style is so retr
From a personal perspective, I would work on getting it as close to 60 as possible, one of the reasons Burnout 3 is such a joy to play is the generally rock solid 60fps. Only when there is a MASSIVE pileup does it drop to more like 30. But then again I'm a real framerate whore, and would always choose 60fps over dynamic lighting, or more polys etc
I wonder if there is any compromise you could make to ensure it always hits at least 30.
Oh also, have you determined how much of the framerate drop is down to physics and how much is simply due to the extra polys being rendered?
Viking, yep, fair point. Basically I set a car polygon budget of 300, so that's why I've skimped as much as possible on the bottom of the car, sides of the wheels etc.
Because we're in the 3D industry, we're going to notice everything, but do you think most players would also notice the backs of the wheels being absent etc? They would definitely notice the bottom of the car, but most of the time the car is not upside down, so that's less of an issue.
Giles - thanks, I've worked very hard on the car handling/physics, to strike a balance between accessibility/fun/challenge. Hopefully I've accomplished at least some of them
Also, it's been my MO from day 1 to create something closer to a handheld game than a standard Flash game, that's why I've created a pretty big, console style track.
For rendering, I'm using LODs for traffic cars in order to reduce the polygon count to the minimum, and will use LODs also on scenery objects. I only suppose I'm using a wrong (and FPS-killing) sistem of handling them, I really need to improve this aspect. Oh, I also need to try different solutions for colliders. I have yet to determine if two or three rectangular colliders per car are really less expensive than a single ultra-mega-lowpoly mesh collider, as the Unity documentation states.
Other than that, some of the most expensive calculations are due to these scripts:
- Shadow positioning through raycasting - Well, without basic planar shadows it just looks wrong to me...
- Changing car color (lighter or darker) based on being inside a shadow or not (this one through raycasting too... argh) - This one is really nice to see, but I'm considering removing it, even if it's ultra optimized. Not sure...
- Waypoint following - It just has to be there, no matter what, but needs some trimming even if it's already optimized a lot.
- Realtime chassis deformation - It calculates only on impact, so it's only matter of few frames. This one to MUST be there.
I would love to stick it to at least 30 if possible, while mantaining an appetible graphic work (some iPhone players are really graphics whore, hehe). I guess 60 FPS is actually a dream, it would require insanely low graphics and less cars, but... I just love to do things this way. :P
This game must be special for the insane number of cars and other vehicles colliding all togheter.
One note though: 60 or 70 vehicles togheter (if possible) is actually the top number I plan to reach in the final levels of the game. Other levels will have less of them, but starting from 30-35. There will be breakable objects though, like fences, small poles, etc, so the number of things around grows even more. Luckily these one will be nothing more than a bunch of triangles with a single rectangular collider attached to it.
Please let me know if I'm just talking too much to be considered off-topic, I'm sorry for it. ^_^'
Oh, that's right, now I recgonize Ridge Racer in it! I wonder why I really didn't thought about it. :O
You are right, from the moment I seen a Ferrari and a sunny beach, I thought: "Omg, that's OutRun!
Really a good job on the engine. It just looks very funny to play. A multiplayer mode would be sort of a killer-feature for it. *_*
@Norest: really nice Skyline! Very PixelArt inspired!
now its time to make some monsters
Technically speaking, do they all share the same basemesh/UVs and did you put the props like the hats/ponytails in seperate meshes/UVs?
e-freak, they have no any rigs. Unfortunately animation will be very simple. I really want to see how you bring them to live, but i'm afraid mesh is to simple. I'm not even sure that they can raise the hands up. You can check the mesh here http://www.polycount.com/forum/showpost.php?p=1330464&postcount=6157
Still want to try?
Hatsya, no. I really want to do them but there still a lot of work undone - like monsters. But beside this dwarves i`m planning to make few hero characters. Player will choose one of them at the start of the game. One or two of them should be female i think
In what way did you trim the physics down? Is Physx fairly configurable, ie number of iterations, penetration etc?
Although I haven't actually tested collision mesh vs collision mesh etc, I'm working on my own solid body dynamics engine, so I know how it works.
I can more or less guarantee you that 2 or 3 rectangular colliders are faster than a low poly collision mesh.
How it works is edge and face detection. 3D box physics etc generally use the seperating plane test, so basically the fewer edges and faces you have, the faster your checks are going to be. So the only way a custom collision mesh is going to be faster is if it's comprised of less edges and faces than 2 boxes.
Incidentally, what's the basic logic involved for the raycasting of being inside a shadow or not? Real time lighting is the main area of 3D I don't have much experience in.
Regarding waypoint following, this should be trivial. It shouldn't put much of a dent in performance at all.
By the way yeah, I'm going to implement multiplayer as soon as the game has made some capital
^ My character bases made from Blender 2.49. Supposed to be low-poly, to be laptop-friendly.
Most recently creature for the web game im working on 1000 triangles on the dot, click for unity preview with some cheap flames :P
http://dl.dropbox.com/u/14324914/WebPlayer/WebPlayer/WebPlayer.html
Can't decide on colours though, the original concept was purple, but we later decided it looked out of place... Heres the three types ive narrowed it down to. Which do you guys prefere?
Regarding collision meshes, today I tried to change my usual 22-triangles Mesh collider with a single Box collider per car. Honestly, everything looked like to be the same. There wasn't any noticeable performance gain... That was quite strange, so I also tried to remove plane shadows and that script wich dynamically changes the illumination of the car (through raycast). This time performance was a little better, but I really wonder why just "a little". Everything had to run much smoother, but it didn't. I'm not sure, but I can only suppose rendering is taking the most out of the framerate. You liar profiler...
Since the game looked quite ugly without shadows and dynamic lighting, and since Box colliders were not improving performance at all (and they also had unrealistic behaviour), I reverted everything as it was.
Instead, I optimized a lot of things inside the GUI script, through doing a lot of caching, and it really made me gain some FPS even on iPodTouch2. ¬_¬
Next, I do raycasting to detect if the car is inside a shadow, because I'm not using realtime shadows at all. These shadows on the ground and walls are generated by Unity's integrated Beast lightmapper. To be honest, Unity doesn't support realtime shadows when developing to iOS (well, that's lame, bacause iOS can handle them!). It's still possible to do them through some additional render to texture shaders and scripts, but unfortunately they are calculated on a per-object basis, and since I have dozens of cars, I really prefer the raycast way.
Briefly, I shot a raycast from each car towards the opposite direction of the main light source. If a ray collides with something solid, this means the car is under a shadow, so I change its color to be darker, and vice versa. This script works with that calculation groups trick, so it's fair cheap to run.
Finally, talking about waypoint following, you are right, I supposed it to be almost insignificant too. Instead, despite being a really simple piece of code, I sadly discovered that simple commands such as rotating a car in order to steer, and pushing it forward to make it move, are the most expensive things in all the script, more than converting the world position of waypoints into local relative position. And since there are a lot of cars running, it's not really cheap at all. The first time I tested it on iPodTouch2 some weeks ago, with 40 cars, the highest FPS count was... 4.
Then I optimized it with that trick of calculation groups, and was able to bring it back to something playable.
Sorry for the long reply, but I really enjoy speaking about this tecnhical stuff.
So are you going to sell it? Because I'm going to buy it.
Hard to pick a favourite from that bunch but definitely great variety there. Let's see some monsters
O I didnt see that thanx dude that took it down to like 200
I tried my hand at some lowpoly stuff today. 30 poly each, 1 64x64 diffuse and alpha.