|
|
@@ -1,4 +1,12 @@
|
|
|
= Physically Based Rendering – Part one
|
|
|
+:author:
|
|
|
+:revnumber:
|
|
|
+:revdate:
|
|
|
+:relfileprefix: ../../
|
|
|
+:imagesdir: ../..
|
|
|
+:experimental:
|
|
|
+ifdef::env-github,env-browser[:outfilesuffix: .adoc]
|
|
|
+
|
|
|
|
|
|
I’ve been looking at Physically Based Rendering (PBR from now on) since a few weeks, because that’s what all the cool kids are talking about these days. I read almost all the interweb about it and finally somehow wrapped my head around the mechanics behind the concept.
|
|
|
|
|
|
@@ -125,4 +133,9 @@ Now there are pro and cons on using one or the other. Here are the main points :
|
|
|
|
|
|
IMO, the metalness workflow is more suited to real time 3D engine. And as an artist I find it more intuitive.
|
|
|
|
|
|
-That said, as a developer making his PBR pipeline; especially for an engine mainly used by Indie devs; whatever pipeline you choose, you can’t ignore the other. Free or charged PBR ready model you can find are done with whatever workflow suited the artist. some conversion are possible, but that’s easier for user to be able to use the model as is. That’s why I decided to support both in my implementation.
|
|
|
+That said, as a developer making his PBR pipeline; especially for an engine mainly used by Indie devs; whatever pipeline you choose, you can’t ignore the other. Free or charged PBR ready model you can find are done with whatever workflow suited the artist. Some conversion are possible, but that’s easier for user to be able to use the model as is. That’s why I decided to support both in my implementation.
|
|
|
+
|
|
|
+'''
|
|
|
+
|
|
|
+* <<jme3/advanced/pbr_part2#,Physically Based Rendering – Part Two>>
|
|
|
+* <<jme3/advanced/pbr_part3#image-based-lighting-in-pbr#,Physically Based Rendering – Part Three>>
|
mitm