polycount on a portfolio piece
polycounter lvl 6
hello guys
first of all . i wish you all a successful new year
to the topic .
im seeing a lot of artists going crazy with polycount on portfolio pieces just because the new gen is giving them more freedom in that regard .
and i personally feel like falling to the temptation .
so my question is .. what are your thoughts on polygoncount for portfolio pieces
a very simple example ..
lets say you have a character holding some coins in his hands
while 1 is the cheapest ( as i know ) . it doesnt work from all angles
and 2 has the obvious polygons showing up
so would you value quality over optimisation in your portfolio ?
even if the object is not really that important
first of all . i wish you all a successful new year
to the topic .
im seeing a lot of artists going crazy with polycount on portfolio pieces just because the new gen is giving them more freedom in that regard .
and i personally feel like falling to the temptation .
so my question is .. what are your thoughts on polygoncount for portfolio pieces
a very simple example ..
lets say you have a character holding some coins in his hands
while 1 is the cheapest ( as i know ) . it doesnt work from all angles
and 2 has the obvious polygons showing up
so would you value quality over optimisation in your portfolio ?
even if the object is not really that important
Replies
If the character is 1000 vertices, and holding 5 coins, then #2 is better.
But your topology on #3 is not great. When you have long thin triangles, that's bad for real-time 3d rendering.
We talked about this recently, I'll see if I can dig it up. In the meantime,
Too much optimization (do polygon counts really matter?)
http://www.polycount.com/forum/showthread.php?p=2213096#post2213096
If there's a few of them and they're being held out to camera, probably 3.
If there's a good few of them or there not a focal point, probably 2.
Not sure how much I'd go for 1 in a folio piece. Unless there were tons of coins... but then I probably wouldn't have them all individual coins anyway.
Polygons are much cheaper than the memory and overdraw issues caused by use of alpha transparency.
; )
I think optimization is very important for you to know, but in your portfolio nobody cares or gives you any kudos for that. Just make it look amazing and be always smart with your tris, thats what counts, the impression you make, not a number of some stacked up triangles that you probably dont even show
its kinda obsolete in such a case, as you dont see the optimization in the best case, and you would start with the LOD0 (highest) mesh anyways, and go down from there on, so you could always go lower with any piece you show, by making an LOD and turning texture res down. The viewer could always assume an LOD exists but dosnt see it. Showing various LOD stages seperately is always a cool thing tho, but more of a bonus-y thing that is not expected
Farfarer : thank you . i do understand that it always depend on the situation . but the thing is with portfolio pieces is that i can do whatever i want with it . as i make the rules myself .so its kind of an inner struggle . as i prefer to add more polys . but then that might show the viewer that i do not do a good job in terms of optimization
Dylan Brady : i see . thank you very much for correcting me .. i assumed that it is the cheapest because i see a lot of old games prefer to use alpha over polycount
Shrike : thank you for the input . i personally also prefer to go higher with polycount to avoid the ugly polygons and give myself more freedom in making the model look better . was interested on what do you guys think on the subject
It might be worth having things in your folio with different target polycounts, if that's a worry for you.
Dylan: I'd probably use alpha test for that. It's a little more expensive, but still better than alpha blend (unless you're on mobile).
Hey Eric!
I'm curious, how you would go about re-topologising #3?
To prevent thin tris on cyl caps, the only thing that springs to mind would be the basketball method (from a quick google search:
I read Kryzon's post you linked and he mentions there not being much data gathered about how the two techniques cost when compared.
Is your reason for saying it's not great because in this circumstance the object is inherently small and is likely to be rendered as a few pixels? In that situation I can imagine the thin triangles causing issues.
However, does this also mean that for larger, closer objects or LODs meant to be displaying on a larger portion of the screen, it's okay for OP's topology or would you still try replace them?
I knew that thin tris were bad before but I had no idea of the scale until your post, cheers.
image from
Best low poly circle topology
The coins up top just look sloppy to me. They say "I don't give a fuck about topology". But topo does matter, in my book.
I updated my post in that thread with some other references and clearer text:
http://www.polycount.com/forum/showthread.php?p=2213096#post2213096
I remember a thread on General Discussion on the game "Ori and the Blind Forest," and one of the artists posted an explanation image showing how they created their sprite meshes.
What they were doing was, instead of using a quad that bounded the sprite texture, which has a lot of empty space in the form of transparent pixels, they added cuts to form a simple "hull" around the sprite as seen in these two images, courtesy of user Neox: Na
in the case of the image you posted .. how would you rank it in terms of which is more cheaper ?
is it cheaper than #2 in my image ?
is it? let me check
nope should be there
http://www.polycount.com/forum/showpost.php?p=2119996&postcount=122
i had all of the data on the server removed a few weeks back, but all small files (images) should be back up and i can see them
EDIT: I think I have misunderstood your question. I think it's likely to be cheaper than coin #2 because there is less geometry and pixels to be rendered, but to be sure you have to ask your programmer to profile the rendering of each coin to see which is faster.
You can do this yourself in an engine, by rendering ten thousand of each coin and measuring how much time it takes (in milliseconds). The coin that takes less time is the fastest.
How kind, thank you.
2-3) Really depend on a lot of factors. What kind of game, what kind of hardware, how many objects will be rendered, how important are they, how close does the camera get ect...
In general each transparent pixel is a lag bomb waiting to go off and the less transparent pixels you have floating around the screen the better off you are. This also helps with shadowing. Shadows based on geometry are easier to render than shadows that have to be filtered through opacity maps. So if you trim your planes as tightly as possible you can have fairly accurate shadows without having to go through the opacity map.
Also, polygon counts aren't what kill performance any more. A lot of hardware is getting to the point that it is better at pushing points of data (verts) better than dealing with complex shaders. So using a few more polys and a simple material to describe an object, is often better than using a more complex material. But all of that is determined by the scope of the game and the hardware it's running on.
Here are some other threads that discuss similar things:
http://www.polycount.com/forum/showthread.php?p=1520610
http://www.polycount.com/forum/showthread.php?p=1470080
http://www.polycount.com/forum/showthread.php?t=112248