Fun with RWR exporting and a question on scaling a texture through LUA

[himilou]

So I usually set an MFD to display the RWR output because thats about the only way I can glance at it to get a quick situation assessment, being a rookie. I started playing with exporting the RWR to a viewport on my second monitor along with the 3 MFDs that you can easily export from the F18 and immediately ran into the blurry blob display.

 

I spent some time tinkering around and this is what I have discovered.

 

The RWR seems to be rendered like a regular 3D object, using simple draw commands for the circles and then treating the aircraft indicator marker fonts as a 3D object to be displayed with a solid color texture in the graphics pipeline. Thats why when you set:

shaderLineDrawAsWire = true you get an almost double vision effect, you are only seeing the outline of the front and back of the object with no fill.

 

Since the font is being rendered as a 3d object I started experimenting with several of the LUA files and these are the results I've gotten so far ( I've included MFD output for comparison next to the RWR )

First here is my monitor file settings which remains the same for all:

if  displays and #displays > 1 then 
spacingwidth = displays[2].width / 4;
primary = 
{	
	x 		= displays[1].x - screen.x,
	y 		= displays[1].y - screen.y,
	width   = displays[1].width,
	height  = displays[1].height,
	aspect  = displays[1].width/displays[1].height;
	viewDx  = 0;
       viewDy  = 0;
}
secondaryLST = 
{
	x 		= (displays[2].x - screen.x),
	y 		= displays[2].y - screen.y,
	width   = displays[2].width / 4,
	height  = displays[2].height / 2,
}

secondaryLSB = 
{
	x 		= (displays[2].x - screen.x),
	y 		= ((displays[2].y - screen.y) + (displays[2].height / 2)),
	width   = displays[2].width / 4,
	height  = displays[2].height / 2,
}


secondaryRST = 
{
	x 		= ((displays[2].x - screen.x) + (spacingwidth + 10)),
	y 		= (displays[2].y - screen.y),
	width   = displays[2].width / 4,  --384,
	height  = displays[2].height / 2, --216, 
}

 

To insert the graphic rendered distance circles which I guess have been replaced by an image overlay I uncommented these from RWR_ALR67_MAIN_page.lua ( just called main )

addStrokeCircle("TEST_CIRCLE", 1, {0, 0})
addStrokeCircle("TEST_CIRCLE_1", 0.74, {0, 0})
addStrokeCircle("TEST_CIRCLE_2", 0.56, {0, 0})
--addStrokeCircle("TEST_CIRCLE_3", 0.19, {0, 0})
addStrokeCircle("TEST_CIRCLE_0", 0.075, {0, 0})

 

for mod1

just the changes to RWR_ALR67_init.Lua that most people tinker with

 

shaderLineParamsUpdatable = true

shaderLineDefaultThickness = 0.06

shaderLineDefaultFuzziness = 0.04

shaderLineDrawAsWire = false

shaderLineUseSpecularPass = true

 

Mod2

shaderLineParamsUpdatable = true

shaderLineDefaultThickness = 0.06

shaderLineDefaultFuzziness = 0.04

shaderLineDrawAsWire = true --- the only difference

shaderLineUseSpecularPass = true

 

Mod3

changes to the RWR_ALR67_definitions.lua file, note the setting of the screensize variable and using it to easily adjust some of the other calculations

 

 

screensize = ( 0.0128 ) --0.0158

 

Radius = GetScale() -- half_width

Radius = Radius * screensize --0.0158

Diameter = 2 * Radius

SetCustomScale(Diameter)

 

stroke_font = "font_RWR"

default_material = "RWR_STROKE"

 

--stringdefs = {20 * GetScale(), 12 * GetScale(), 4 * GetScale(), 5 * GetScale()}

local fontSz = 0.000025 / screensize -- 14(0.000025) font size/screen size

 

MPDtoALR = 0.000025 / screensize * GetScale() -- 14 0.000025

 

init file

 

 

shaderLineParamsUpdatable = true

shaderLineDefaultThickness = 0.6

shaderLineDefaultFuzziness = 0.2

shaderLineDrawAsWire = false

shaderLineUseSpecularPass = true

 

Mod4

init file

 

shaderLineParamsUpdatable = true

shaderLineDefaultThickness = 0.06

shaderLineDefaultFuzziness = 0.04

shaderLineDrawAsWire = false

shaderLineUseSpecularPass = true

 

definitions file is the same as mod3

 

mod5

 

init file is the same as mod4

 

definitions file introduces another variable that is used to set fontsize and MPDtoALR

 

-- see 'use_mipfilter' in symbology_defs.lua

mip_filter_used = true

 

screensize = ( 0.0128 ) --0.0158

 

_rwrfntbase = 0.000014 -- originally 0.000025

 

Radius = GetScale() -- half_width

Radius = Radius * screensize --0.0158

Diameter = 2 * Radius

SetCustomScale(Diameter)

 

stroke_font = "font_RWR"

default_material = "RWR_STROKE"

 

--stringdefs = {20 * GetScale(), 12 * GetScale(), 4 * GetScale(), 5 * GetScale()}

local fontSz = _rwrfntbase / screensize -- 14(0.000025) font size/screen size

 

MPDtoALR = _rwrfntbase / screensize * GetScale() -- 14 0.000025

 

fontScaleY_dflt = fontSz * GetScale() -- 59/0.112

fontScaleY_small = 0.5 * fontSz * GetScale()

 

fontScaleX_dflt = fontSz * GetScale() -- 59/0.112

fontScaleX_small = 0.5 * fontSz * GetScale()

 

So you can see that we can get pretty decent scaling control over the font rendering but none of these settings seems to effect the friend or foe indicators around the lettering ( the ^ for enemy and the half circle for friendly. )

 

So I dug a little further and discovered that adjusting values in this statement will control the spacing between letters etc, but still no symbology

stringdefs[sTROKE_FNT_DFLT]		= {fontScaleY_dflt, fontScaleX_dflt, 74 * fontSz * GetScale(), 74 * fontSz * GetScale()}

 

Digging deeper I found this in the f18\scripts\materials.lua file

The font file is also specified here but I left that out of this post for clarity.

 

 

[i]the solid texture color for the symbols[/i]
materials["RWR_STROKE"]					= {0, 255, 0, 230}

-- HMD
materials["HMD_SYMBOLOGY_MATERIAL"]		= {2, 255, 20, 255}
textures = {}

local ResourcesPath = LockOn_Options.script_path.."../IndicationResources/"

textures["ARCADE"]							= {"arcade.tga",	materials["INDICATION_COMMON_RED"]}		-- Control Indicator
textures["ARCADE_WHITE"]					= {"arcade.tga",	materials["SIMPLE_WHITE"]}				-- Control Indicator
textures["IFEI_INDICATIONS"]				= {ResourcesPath.."IFEI/IFEI_Fixed_Symbology.dds", materials["IFEI_FONT"]}				-- Control Indicator
-- DBG
--textures["INDICATION_MPD_ADI_DBG"]		 	= {ResourcesPath.."MDG/DBG_ADI_background.jpg", materials["DBG_RED"]}

[i]The tga shape file which contains the circle and the ^ and other symbols[/i]
textures["INDICATION_RWR"]					= {ResourcesPath.."RWR/indication_RWR.tga", materials["INDICATION_COMMON_GREEN"]}
textures["INDICATION_RWR_LINE"]				= {"arcade.tga",							materials["INDICATION_COMMON_GREEN"]}
textures["INDICATION_TGP"]					= {ResourcesPath.."MDG/tgp_texture.tga",	materials["INDICATION_COMMON_WHITE"]}

 

Now I think the last issue to this display is that the scaling of the symbols is set for the little RWR in the panel and is too small to be rendered correctly when the RWR is exported. I think the rendering is done with this function from the RWR_ALR67_Common_definitions.lua file

function AddSpecialSymbols(name, file, number, stt_y, aaa_y, sam_y, ewarn_x)

 

So does anyone know if scaling values are set in this function and if so how they work?

 

Im going to cross post this in another thread on this but wanted to place it up front for attention as a new thread.

 

Thanks!!

[derammo]

Hey, nice work!

 

I'm a Helios developer, and our users pretty much always have to export the RWR (so it will match up with the extra cockpit panels views.) It is a known problem that the rendering math is somehow different for some exported views, resulting in the extremely fuzzy blobs on the exported RWR. It's like someone forgot to push some multiplier in that path or something :)

 

People usually just dial down the stroke width and fuzziness parameters for the RWR, which then in turn destroys the RWR shown in the game itself. It seems there are some overall multipliers that are applied to these values in one path but not the other. So if you make them work well in the export, the in-game goes to hell.

 

Since you have gone deeper than I have on the RWR, I wonder if you have found any way to use different rendering parameters for in-cockpit and exported views. If we could decouple these, we could do a lot better job exporting views and also having decent in-game views at the same time.

 

I enjoyed reading your mods and learned some stuff I might be able to use in the future.

 

Cheers!

[himilou]

Thanks. Good to meet you!

First off let me say that Helios looks pretty great! I have not yet played with it but I have spent some time looking at the captzeen website and the work that has been done on that looks pretty cool. Im headed in a similar but simpler direction, just looking at instrument functionality vs the high quality visual effect that you get with Helios.

 

This is really my first time down the rabbit hole with LUA so Im pretty unclear on variables are available, and the scope in which they exist.

 

That being said I think the answer would depend on exactly how helios is working. Is the monitor that Helios being displayed on under the control of DCS or is it a full helios implimentation?

If its under the control of DCS AND Helios basically sets the script changes then you could experiment down the line of what try_find_assigned_viewport does in ViewportHandling.lua

 

local heliosviewport = find_viewport(A_Helios_Defined_RWR_viewport) 
if heliosviewport then

   if heliosviewport.x == ( A_SCREENWIDTH_THAT_IS_DIFFERENT)
       LUAglobalvalueHelios = true

 

and then wrap the rendering code of RWR inside an if then statement. This approach does not fix the actual cockpit RWR though, just gives you more control on the rendering on a different monitor.

 

Now for a completely off base question that you might know the answer to.

 

Does DCS recognize additional monitors \ displayports that windows would consider to be in the detached state? You probably would have run into this in the form of a bug where you thought that helios was on screen n but that output display did not function but setting the output for helios to n+1 or n-1 fixed the issue.

 

Cheers,

[derammo]

Helios actually doesn't do anything magical with the viewports. We render the controls ourselves separately (all the switches and gauges, etc.) and then we overlay that separate application over the exported viewports (MFDs, RWR, etc.) that are just like the ones you use. So we are really just using the external viewports in a very vanilla way. So that's why I was asking if, in your normal use of external viewports, you have ever been able to set different rendering options (stroke widths, fuzziness, etc) for external viewports while simultaneously rendering the in-game ones unmodified.

 

About your off base :) question:

 

DCS just opens a window and draws it with DirectX. It positions this window a little bit cleverly, but basically it is just a super simple application in terms of how it uses the desktop. All the coordinates in the monitor setup are relative to this window.

 

I have never seen it do anything weird regarding disconnected displays. I have multiple graphics cards and many monitors, and a virtual monitor dongle (an HDMI dongle that pretends to be a display) and I have used any combination of them for various tests. During those tests, I frequently have connected, disconnected, and connected but disabled displays. I have never seen anything weird.

 

Helios is just a Windows application drawing some frameless windows. It doesn't do anything weird with displays either.

[himilou]

Hey,

 

Well I've only been flying DCS for about a month now, I've owned it for about 3 but spent 2 of those messing around with building my own headtracker before I threw in the towel and bought TrackIr ( glad I did or I would probably not be here now, lol )

So what I have posted is really the very start of me playing with rendering external viewports.

 

I flew tonight with the RWR modded as I outlined above and I immediately noticed that on my exported RWR screen the boat indicator symbol does get rendered correctly. If you look at RWR_ALR_67_Common_definitions.lua you will see

function AddBoatHarmSymbols()

That pretty much confirms that the rendering of the RWR symbols is done througn the functions in this file, and

the function AddThreatSymbol is most likely the one with the bad scaling.

These are what would have to be duplicated with different values if what you are pursuing is possible.

 

The reason Im asking about the monitor situation.

 

I've been playing with some code that allows capturing of screen buffer output. Its pretty efficent, I think I experienced only about a 4 frame per second loss capturing the entire DCS main window and rendering its output into a scaled window, without me having to do any fancy DX coding.

 

I then started thinking that if you had a (ghost ) display \ monitor that windows thought was VGA \ SVGA you could tell DCS to render the viewports to that display using the same display[n] code that I posted above for my monitor config.

Example:

I have two real monitors hooked up. From above

primary = 
{	
	x 		= displays[1].x - screen.x,
	y 		= displays[1].y - screen.y,

If a ghost monitor could be presented by windows to DCS ( displays[3] ) Then the exported MFD info could be sent to that display and I could capture only that monitors frame buffer info. Since VGA has far fewer pixels and the MFDs dont require any fancy depth \ overlay \ other rendering pipeline computing the export should result in almost no perf loss.

 

In Windows 7 you could add a non existent VGA monitor and because VGA is not really plug and play windows would give you an unknown display in display manager. This however is good enough for a frame buffer to get created and rendered too. There are youtube videos of people extending their desktop onto android \ apple ipads through this trick and some capture software.

Anyhow Windows 10 does not let you fool the system like this without a VGA dongle, though I'm still researching into this. Thats why I asked about the monitor stuff.

 

Maybe you could do an experiment. Attach your dongle to your system and see if windows recognizes it. If it does try using the displays[n] config as outlined above and try exporting a view to the non existent monitor. If a frame buffer gets created then while you wont see the exported info the rest of your display should render as configured. If DCS does not see a frame buffer then it will default to rendering the entire main window across all your recognized display outputs. ( You will also see a LUA config error in your DCS log file )

 

Cheers!

[himilou]

Hey Derammo,

 

I just had a light bulb click on concerning what you are trying to do. Could you send me copies of the default F18 RWR script files?

Yes I have my own but im pretty lazy about backing up the originals, so I would like to test my idea with an unadulterated set....

[derammo]

we don’t have to do this experiment. Rendering viewports into a dongle and then screen grabbing / desktop duplicating that output to another display or even another computer over LAN is standard procedure that people use all the time.

 

The dongle just looks like a display to Windows so you can position it as part of your Windows desktop and span the DCS window across it. Then you can place viewports on it.

[derammo]

thanks for the PM. I will reach out there so we can compare code