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.
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.
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