rFactor 2 Developer Q&A

Status
Not open for further replies.
Will there be 'proper' multi-monitor support. eg triple screen.
To do it properly it is not the same as just giving one camera of very wide viewing angle range. (FOV)

At the moment RF1 has a Multiview mode, which is quite FPS hungry versus a hardware triple screen system. But the multiview mode has one slight advantage, as it is now....
In Hardware manner (Eyefinity, or nVidia) the camera gives a fish-eye result, and seeing the screen is far wider than high it distorts badly the more 'outwards' the content is on the screen. eg By midway into a side monitor it is badly stretched horizontally ( a car in a side screen can be stretching dramatically out to two times it real length). You can imagine the one camera is trying to show some large viewing angle (FOV), like say a 130 degrees arc, onto a flat screen (or someones X amount angled side monitors)
Multi-view does not do that distortive manner.

I expect this is because Multiview actually uses 3 'cameras' to produce the view(s), so there are three cameras each placed to show a straight ahead view at their own angle - middle camera at 0 degrees, and then side cameras of ??? what seemed to be well out at 90 degree area in RF1. Whatever the side cameras angles of view are, that is what you need to set your two side monitors at also. But the two side camera angles are not alterable in RF1, thus you need that near 90deg monitor angle to match the cameras as they are now.

It would be good if RF2 had that Multiview, but with an angle setting option so you can put your monitors at that angle you choose and then you set the game config to match those. (eg 35deg... 45deg... whatever).
And hopefully done more efficiently so it is not a huge FPS/power hit compared to using 'single camera' Eyefinity etc.

Or an even better (??) extra option to also have would be to have the single camera mode, which is far more GFX power efficient, but give a 'Distortion correction' setting option that allows you to tune in the fisheye distortion result, to suit the angles you chose to set the side monitors. eg it would be some form of 'exponential de-stretching'. Only multi-screen users would toggle it on and set it (eg in RFconfig, or in-game). Though this extra processing would also 'cost' extra gfx power, but maybe not as much as triple cameras?

But anyway..... think MULTI SCREEN, and how to give users full use of them, with correct displayed content (no distortions), and also so they can set side monitors at angles that suit their own choices.
Thanks.
 
LesiU said:
Just define grid positions for all 103 available spots... if there are no such in AIW, rF puts cars in a straight line related to existing grid spots.
Click to expand...
That's my problem, 'straight line' usually equals backwards in to the dirt. Editing AIWs for existing tracks isn't a great idea unless you only race offline either.
 
PeterV said:
At the moment RF1 has a Multiview mode, which is quite FPS hungry versus a hardware triple screen system.
Click to expand...

How do you access this system in rF1? I am interested. I actually just posted this as a suggestion on the Outerra forums for their engine.

tjg_marantz said:
Increasing ballast limits? *whimper*
Click to expand...

Who cares marantz, The leauge should be separated based on skill if you need 2000KG of ballast. Obviously something is wrong with the people on that league.
 
ZeosPantera said:
How do you access this system in rF1? I am interested. I actually just posted this as a suggestion on the Outerra forums for their engine.



Who cares marantz, The leauge should be separated based on skill if you need 2000KG of ballast. Obviously something is wrong with the people on that league.
Click to expand...


Seriously buddy, your know it all attitude is getting annoying.
 
The Multiview option is in RFconfig - a tick box only. Only there if you have multiple screens.

For the ballast etc.... it would be good if ALL options, commands etc were available via the user interface. eg an Admin page with buttons (uibutton, gizmo etc), rollovers etc to do anything you could want to - and would of course still need some items to have text input. Just have the gizmo/command etc for every possible adjustable setting. The game doesn't have to have every one of them used in it as it comes, but have all the commands/gizmos implemented so UI modders can develop fully detailed control panels etc.
It is annoying to have to go out to edit ini files etc for so many of the 'mundane' aspects - whilst it is ok to need to do that for very low use items, but still would be good if all items had in-game gizmos available.

While at it.... there may as well be Power, Drag, and Weight (ballast) options available to Admin - even if it is not real world - for balancing Leagues out to suit their needs.

Oh, while on the UI.... make it 1024x768 (1366x1068) at least as the minimum requirement. At 800x600 it is far too clunky looking for modern day software. Probably 1280x900 (WS?) minimum really.

And..... the UI able to deal with multiple screens correctly - where the UI fills the centre monitor correctly for any resolution used. In multi-screen setups with bezel compensation, the middle screen that is still really, say 1920x1080, will be actually less than "one third" of the total screen width (the total width could be 6008 pixels), so the UI then need to be that same "less than one third" the screen width too.
eg Eyefinity 6008x1080, or 4940x900, means the individual screens were really 1920 wide, or 1600 wide, so the game needs to then 'know' that the real centre screen for the UI was 1920, or 1600, and to centre the UI which will them make it fill that centre monitor.
It does not do that in RF1.... it just scales the UI to "one third", which in a case of 6008 is then 2002 pixels, and thus runs off the centre monitors 1920 real size. And in eyefinity with bezel compensation this means the edges of the UI go "under the bezels" to be unseen ever.
In a "Multiview" mode this would not be an issue as the centre camera (which would be where the UI is shown when needed) is just one screen used anyway. But multiview is not as fast and efficient as hardware triple screen, so both multi-screen methods still need to be supported.
 
Oh, while on the UI.... make it 1024x768 (1366x1068) at least as the minimum requirement. At 800x600 it is far too clunky looking for modern day software. Probably 1280x900 (WS?) minimum really.
Click to expand...
I don't get it, just because you don't like how things look low-res you want the lower options removed? That seems arbitrary and will make life very hard for those with marginal systems. As for the idea it should be wide-screen, I'm one of a lot of sim racers I know who have 5:4/4:3 monitors still. The simple option is just not to use those resolutions, you don't have to impose it on others.

PC gaming is niche market enough without arbitrarily driving people away from your product.
 
Last edited by a moderator:
1) Maybe a new video (I mean WIP 4 / 2011, or finished product :D ), the next month working on rF2?

2) How many days before relase date rF2, you will say about that?
 
Last edited by a moderator:
Sorry if this subject was mentioned before, but I'd like to point an AIWCamEditor aspect which should be improved: the Camera Editor.

To create a decent offboard *.CAM file, using all 3 available Cycles for whole track is a task very exhausting. First, there's some issue with decimals of FOV and Activation Radius, sometimes they are loaded as "6.0/4.0", some time as "60/40" (which should be correct) but the radius shown on the game screen are totally crazy. Second, I don't know why but the co-ordinates of any AIW data is in a different system (XYZ for track building -> X-ZY for AIW programming)

To achieve a good camera transitioning it's necessary to play around with activation point a lot, but it's hard to manage it without see the spheres of influence theirselves and to set the right point in to AIW editor.

After all, I've figured that the easy way is to adapt the coordinates system of the track in 3dsMax and create / move imaginaries activation cameras spheres untill to cover the desired track portions, includind their height (-Z) moving. After countless adjustments and Alt+Tabs we are eventually able to extract the X-ZY coordinates of spheres and their radius.

If we be able to unify the co-ordinates system and use boxes instead of spheres of each camera as well (non-regular solids for avoid undesired interferences) the time of work would be divided by 10.

Can we get some improvements on that?

Just an opinion.
 
Last edited by a moderator:
Have you made / planning to change the way headlights are projected? Here's what I mean:

Headlights.png


Image at the top shows how it's currently done - a texture is projected top-down producing a large, orthogonal volume.

I believe it would be better to project two textures (in one pass) forward using perspective projection (bottom image).
Of course I've made headlights too narrow in bottom image, but that's not the point.

There are two benefits of projecting light forward.
First is performance - smaller frustum means less objects to process in lighting pass.
Other is that headlights now work as they should - cars will no longer lit objects above them, and when car rides on bumps - you will see it's headlights "jumping" too.
 
Headlights do indeed "suck" in rF1. The recent iRacing update has shown what it should look like. http://www.youtube.com/watch?v=Z7n1-dCaleU Trying to match it with varying intensities for offroaders etc would be all I could hope for. Also that and another video show reflectors in the road lighting up with the headlights and I never really noticed any reflective surfaces in games before. Do you plan on allowing for this? Realistic Safety reflectors on vehicles and obstacles?
untitledb2.bmp
 
The recent iRacing update has shown what it should look like.
Click to expand...
Nope :) iRacing uses texture projected from above car aswell. It's easy to recognize what technique was used if you know what you're looking for.
That's what my post was all about - the headlight projector texture.

Actually, recent iRacing build is what inspired me to write the post above.
 
Last edited by a moderator:
Well, if they simply copy how they did it in Shift 2, I think they would have the best night effects there are, imo. And since shift is based on rF1, that shouldn't be hard to do for rF2,... or is it?
 
SMS uses the rFactor/ISI physics engine, but their graphical engine is of their own design. The headlight effects have nothing to do w/ what ISI bits are in the core of the Shift franchise.

YoShImUrA said:
Well, if they simply copy how they did it in Shift 2, I think they would have the best night effects there are, imo. And since shift is based on rF1, that shouldn't be hard to do for rF2,... or is it?
Click to expand...
 
Status
Not open for further replies.
Back
Top