Mmmmmmm You guys smell that? Just baking some normal maps

congrats on discovering the first 3D related meme in the history of the universe.

File: dtmyfc.jpg (5KB, 216x149px) Image search: [Google]

5KB, 216x149px

>>500890

Your new is showing.

>https://en.wikipedia.org/wiki/Utah_teapot

>>500889
clearly fake

>>500896
this isn't a meme you bitchbubble

File: 18s04fkzrmdrpjpg.jpg (37KB, 240x360px) Image search: [Google]

37KB, 240x360px

>>500889

applying normal maps is orgasmic

AHHHHHHHH

IM CUMMIN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! IM CUMMING!!!!!!!!!!!!!
AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH


AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

>>500898
Ah that'd be cool. Use one of those frosting air brushes to color a cake so that it actually looks like tangent space normals.

>>500951
hmm thats actually a cool idea

>Using normal maps
>Not displacing everything

Everything. From bricks down to the cracks in leather. Optimal for the ultimate photorealistic results.

>>500968

And suboptimal for performance in realtime media.

Every tool has a purpose.

>>500906
>I don't know what meme means, and think it has to be some bastard child of the demotivational because that's what /b/ calls them, and /b/ originates all internet culture!

Damn kid. Just damn.

>>500968
ive never seen anybody so wrong
>optimal
>displacement
KEK

>>500969
>>500980
You guys obviously don't know how to 3D.

>>500984
you have to be stupid to use displacement maps on everything. it's a waste of memory. just use parallax or bump for stuff that isn't a point of focus, like brick on that section in a castle that's only seen once.

>>500984
please tell me more about how displacement needs to be used for everything.

if it dosnt break silhouette, it dosnt need to be displaced. and if its a huge displacement, you model it in.
these fucking shitters trying to act like they know more than everybody
https://www.artstation.com/artwork/hdfgfg

>>500889
>>500898
clearly cake

>>500999
>>500985
>>500969
>>500968
you kids.
displace.
then bake normals.
then low poly.

File: .jpg (14KB, 220x200px) Image search: [Google]

14KB, 220x200px

>>500889

Shit, i wasnt ready

File: 1375603892801.jpg (21KB, 500x490px) Image search: [Google]

21KB, 500x490px

>nignogs that don't use tessellation when available

File: hra72.jpg (189KB, 1028x1513px) Image search: [Google]

189KB, 1028x1513px

>>500999
>>500985
>>500980
You guys are stupider than he is.

>>501097
>actually believing tessellation is worth while in it's current state

>>501104
Not sure what your point is, both offline renderers (e.g. renderman) and real-time renders use tesselation.

For a recent real-time example, "shadow of mordor" uses tesselation.

The most unique feature of pixars renderman is probably its micropolygon rendering strategy, which is based around a smart way to tesselate surfaces in a way that is highly screen-space optimal.

>>501124
(also, I'm not that >>501097 guy)

>>501124
in games its great for ground surfaces like gravel, snow, dirt etc. but not for much else. the problem is that it pushes the geometry beyond its original boundary which causes clipping problems and shadowing errors. it's even worse when you have baked lighting (which many games still use) because the original mesh might be hidden under another model (and thus that part is baked as having a shadow). this shadow is then pushed through the model ontop of it which makes it look like the ground has black spots all over the place. dynamic lights would solve it but then you'd be dealing with a lot more performance costs etc.

i only use tesselation in my environments for ground surfaces. even walls tend to look like shit, again mostly a problem with shadowing errors. its a shame because tesselation is a great way to create depth in scenes largely lit by indirect lighting (where normal maps from rough surfaces like concrete have very little highlights)

>>501124
The performance hit for tesselation doesn't justify any use un realtime scenarios. Just use things like parallax occlusion mapping and you'll be fine.

>>501127

there are many more uses for tess in RT rendering than just displacement mapping, btw.

shadows are usually not very precise anyway, so semi-microscopic details like those that would be introduced by things like displacement mapping are not generally expected to be accurately reflected by SM. Heck, in most engines you can't even expect it to accurately reflect all objects in the scene at all.

I'm not sure I follow your baked lighting example. Tesselation is generally well-behaved with baked lighting. If tesselation causes clipping in your objects or other topological changes, you messed up anyway. But that said, there is nothing that really prevents you from baking at a high tess level, if you insist on having bogus geom/tesselation. Bottom line, if getting shadowing errors from tesselation is a common occurrence for you, either you or your engine must be doing something wrong.

Either way, there are many ways real-time rendering can go wrong (it's all just a big hack, after all), not having tesselation/displacement mapping that is so crazy that it creates artefacts is just another one of the many things that you have to look out for.

There are other ways to use tesselation than displacement mapping, though. It can be used for all kinds of things -- smoothing out objects, UI elements, reducing GPU transfer buffer sizes, [procedural] water (that's a popular one), cloth, ... etc.

As example for cloth, your physics engine might compute a lattice of 100 x 100 nodes, that change every frame (since, well, physics.) 100 x 100 looks too crude to present to the user, but the physics engine can't deal with more. So now you could either

- on the CPU, tesselate the mesh of 100x100 quads into, say, 500x500 quads, triangulate them, then push the whole buffer (which is now 25x bigger, but #YOLO) through the PCIe bus to the GPU where the GPU can render it
- just push the 100x100 buffer to the GPU where it gets tesselated and triangulated by the hardware in no time

>>501151
(and ye, baking at high tesselation levels will have no serious impact on performance since that uses an offline rendering mechanism that uses BVH et al anyway, so increasing the amount of geometry by a few times doesn't have that much of an impact on the baker.)

oh, ye, another example of where tesselation comes in for realtime renderers is ptex, if you want your renderer to support ptex, it basically needs to tesselate everything.

https://developer.nvidia.com/sites/default/files/akamai/gamedev/docs/Borderless%20Ptex.pdf <--clickeroo

File: tears-of-joy.jpg (42KB, 625x415px) Image search: [Google]

42KB, 625x415px

>>501154

>>501154
Conceptual gem, visual shit.

File: del.jpg.png (127KB, 432x292px) Image search: [Google]

127KB, 432x292px

>>500889
Looks delicious, OP. I'll pour some tea.

>>501237
this makes me uncomfortable

>>501240
looks good to me

File: cumin.gif (3MB, 512x512px) Image search: [Google]

3MB, 512x512px

>>500909

Yeah, cumin's pretty good stuff.

>>501154

I dont get it

File: lole.jpg (56KB, 393x391px) Image search: [Google]

56KB, 393x391px

>>500889
Fuck