I suggest downloading Build 49, some content from the time we've since updated, and actually taking a look.dont remember... too much and things aint change much...
That is a ludicrous statement, in my opinion.i think that the gap in performance between rf1 and rf2 its not acceptable.
I suggest downloading Build 49, some content from the time we've since updated, and actually taking a look.


The cars look horribly disconnected to the track at the moment, particularly in replay mode. Really need to nail that dark shadow look underneath and around the car much farther out and not just when the car is close to the camera.
RBR is simply the only actual rally sim ever released, but I don't find it has any good ffb compared to rf2 or rf1 with realfeel.
totally agree!!!The cars look horribly disconnected to the track at the moment, particularly in replay mode. Really need to nail that dark shadow look underneath and around the car much farther out and not just when the car is close to the camera.
I forgot the last one but it was something with digital ... anythingall my rF2 stuff looks much much better.
I suggest downloading Build 49, some content from the time we've since updated, and actually taking a look.
The sense isn't present in the gmotor2.5 updating - return on gmotor2.0. Gmotor2.5 at all doesn't justify the potential but only loads system requirements more.
Does gmotor will be able to improve on the aspect of optimizing the frame rate?.Or do we have to wait a few years until we have more powerful computers that improve the performance of gmotor?.This last option would not be good.
The way content is designed is a huge performance factor and unfortunately ISI is using pretty low-level tools for content creation. I think many small companies cannot afford to put time ( and money ) into creating advanced tools. That's why usually you only see big players do it.
No, I'm talking about companies like Id Software, Crytek or Epic Games, who provide their engines with a set of custom tools.
A lot of performance optimizations can be offered by such tools - things you cannot do on the fly while rendering or loading a level.
A good example is qvis tool from Quake. It ran for hours processing single map, but when it finished, game engine could use that calculated information to render level with maximum efficiency. Qvis was even capable of removing polygons that would never be seen from where player could go.
It's a bit different nowadays and more so with outdoor sceneries, but for each situation you can always find the most efficient way to organize your geometry and materials.
An artist usually wants to keep his geometry and materials organized in a way that is easy for editing. engine needs content organized in a way that's efficient for rendering. So straight 1:1 export from 3D Studio is not always a good idea.
But like I said - creating tools is a lot of extra work. I'm working on a terrain editor recently and the amount of work is just huge. You could compare it to creating entire rendering engine of a game. I'm not giving up, because in the end I know it will be worth it.