Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 Aug 2010
Offline Last Active Today, 10:16 AM

Posts I've Made

In Topic: Questions about Physical based shading(PBS)?

22 October 2016 - 12:38 PM

Rendering is to make something visible. Usually with geometry, material and light. Shading is how light reacts with a material so it is almost the same but a subset excluding geometry.

In Topic: Questions about Physical based shading(PBS)?

20 October 2016 - 09:55 AM


I would not call the first method physically based since it does not even trace the path of photons.

Physically based rendering in my definition is forward ray-tracing so that a water surface can focus light to create bright spots of light.

Backward ray-tracing is a cheap trick to save performance but will not look realistic.


Not many games use forward ray-tracing because it is very slow from missing a lot of light that is never comming to the camera.


The scientifically correct way to use both reflection map and light sources is to add them together but since reflection maps are often reused approximations, you can multiply them instead so that a shiny object in a dark place will not glow from having a static reflection map.

Thank you for your reply.


What you say is ray-tracing, as i know, it is not real-time, so i can not use it in game engine.


What i really want to know here is physical based shading, just like lighting calculation in Unreal and Unity.


http://blog.selfshadow.com/publications/s2014-shading-course/ This link is what i talk about.


I am sorry if i misunderstand Physical based shading and Physical based Rendering, but as i know PBS is the approximate way to PBR, am i right?



Nvidia made a realtime raytracing demo a few years ago that runs on regular graphics cards.

Lots of hobby programmers show their realtime raytracers on YouTube in 20 to 30 FPS.

There is custom hardware for realtime raytracing called "ray tracing board" if GPU performance is not enough.


If a simple refection map is physically based then I don't know what is not physically based. The term is commonly used in game engines that have grainy graphics, focal blur that cannot be removed and low framerates.


An example of physically based shading is the Arauna game engine.


In Topic: What programming language should someone pair with LUA?

19 October 2016 - 01:22 PM

The common arguments for C++ is "because it is faster".

  But for whom is it faster?


The common arguments for scripts is "because C++ is a pain to use".

  So why do you use C++ in the first place?


The common arguments for OOP in C++ is "because it is higher".

  So why do you use a low level language just to fragment the heap with allocations that Java could move to the stack automatically?


If you use a safe compiled language as a middle layer then you can get both safety and performance at the same time which I consider to be a good tradeoff for most of the code.


Scripts are supposed to allow hard coded events for dynamically loaded things so that the core of the game does not have to change for each user made level.

A compiled language (C / C++) will catch a lot of run-time bugs as compile-time errors so use it instead of scripts whenever it makes sense.

A safe compiled language (Basic / Java) can prevent access violation and memory leaks leading to robust execution for the level designer and other tools.


Whenever you use scripts, consider if function pointers, class inheritance, data flow graphs, state machines or tables can be used instead.

The simpler it is, the easier it is to maintain when the interface has to change and graphical representations are nice to have in level editors when you just want a door to open when a button is pressed.


Use scripts when:

* You have dynamically loaded content and want players to be able to make their own things

* You want to do something that cannot be done easily with a compiled language because it is not expressive enough


When it comes to performance, higher languages give faster code given that the programmer is a beginner by applying high level optimizations more freely.

A low level language cannot do high optimizations because it is too explicit and assumes a certain level of hand optimization.

When writing code in C, you can be amazed by how poor the optimization is when looking at the assembly code. (around 5% of obvious optimizations applied)

Writing the same code in a higher language can then apply most of the obvious optimizations and some that you did not even think about.


Use C/C++ when:
* You are optimizing some things on a level where a higher language has awkward workarounds

* You want to use SSE/NEON SIMD intrinsics with multi-threading

* There is a certain library that has no wrapper yet

* You want to make code that can be called from another language without heavy dependencies

* You need the generic pointers for data management

* ...

In Topic: CPU + GPU rendering with OpenGL

17 October 2016 - 11:37 AM

The implementation is done with gl_FragDepth now and the performance is great! :) Thanks for the help everyone.

In Topic: CPU + GPU rendering with OpenGL

16 October 2016 - 08:05 AM

Writing depth in the fragment shader is discouraged since it disables early-z, ie, your fragment shader has to be run anyway to determine if the fragment is occluded or not. You dont want that.


There are other ways to force the Z value (from the vertex shader or using glDepthRange).


Per vertex would give flat sprites instead of nice intersections.