Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MVJB]

I don't have the SDK yet (I should get into it and play around with it a bit) but do the meshes allow for UV texture coordinate settings? If so, you could put all your textures on a single texture/material and have your mesh sprites change the UV coordinates depending on what you want to display. I use this method in my DX11 gauge tech in FSX. Also, when I don't need to render text but rather some other simple primitive shape, I use actual meshes pre-programmed into my shaders which is a little lighter on the GPU in that they aren't as pixel shader bound.

Eg for rendering a unfilled circle, the only pixels calculated would be the ones covered by the triangles, rather than in a sprite case, a whole square section of pixels of the dimensions of the circle.

Ultimately, being able to render 2D meshes and sprites to texture with predefined scripts by the Outerra team would be what I would like to see.

[Uriah]

Hi MVJB,

I am really not sure either way if that is possible. I can look into it.

My next version of the HUD will use one texture, with all the characters for a font set on on map, and each mesh will have a different UV position on that map, but it still uses multiple meshes. It would be optimal if you could have a script which can change the UVs, this way you just have one mesh, and one map. I will definetly be looking for a better solution to this problem.

From what I understand there is a long-term permanent OT solution under development, that is all I know. I think there is a thread discussing it somewhere.

Regards,
Uriah

[Levi]

Here's my version of your script Uriah.
As you can see, the overall length have been considerably reduced.
This is the script used on the F-117 to display the heading digits on the left screen, but now you don't need to call the meshes within the initialize function anymore, making the script even shorter.

Code: [Select]

var geom, jsb;
function rad2deg(angle_rad){return angle_rad*180/PI;}

function digits(input, lenght_string, lenght){
var string = (Math.round(input*1)/1).toString();
this.str_length = string.length;
this.value = (lenght_string + string).slice(lenght);
}
function update_frame(dt){
//Digits Heading
var digits_hdg = new digits(rad2deg(jsb['attitude/heading-true-rad']), "000", -3);

geom.set_mesh_visible('MFD9_hdg_A_00', digits_hdg.value.charAt(0) == 0);
geom.set_mesh_visible('MFD9_hdg_A_01', digits_hdg.value.charAt(0) == 1);
geom.set_mesh_visible('MFD9_hdg_A_02', digits_hdg.value.charAt(0) == 2);
geom.set_mesh_visible('MFD9_hdg_A_03', digits_hdg.value.charAt(0) == 3);
geom.set_mesh_visible('MFD9_hdg_A_04', digits_hdg.value.charAt(0) == 4);
geom.set_mesh_visible('MFD9_hdg_A_05', digits_hdg.value.charAt(0) == 5);
geom.set_mesh_visible('MFD9_hdg_A_06', digits_hdg.value.charAt(0) == 6);
geom.set_mesh_visible('MFD9_hdg_A_07', digits_hdg.value.charAt(0) == 7);
geom.set_mesh_visible('MFD9_hdg_A_08', digits_hdg.value.charAt(0) == 8);
geom.set_mesh_visible('MFD9_hdg_A_09', digits_hdg.value.charAt(0) == 9);

geom.set_mesh_visible('MFD9_hdg_B_00', digits_hdg.value.charAt(1) == 0);
geom.set_mesh_visible('MFD9_hdg_B_01', digits_hdg.value.charAt(1) == 1);
geom.set_mesh_visible('MFD9_hdg_B_02', digits_hdg.value.charAt(1) == 2);
geom.set_mesh_visible('MFD9_hdg_B_03', digits_hdg.value.charAt(1) == 3);
geom.set_mesh_visible('MFD9_hdg_B_04', digits_hdg.value.charAt(1) == 4);
geom.set_mesh_visible('MFD9_hdg_B_05', digits_hdg.value.charAt(1) == 5);
geom.set_mesh_visible('MFD9_hdg_B_06', digits_hdg.value.charAt(1) == 6);
geom.set_mesh_visible('MFD9_hdg_B_07', digits_hdg.value.charAt(1) == 7);
geom.set_mesh_visible('MFD9_hdg_B_08', digits_hdg.value.charAt(1) == 8);
geom.set_mesh_visible('MFD9_hdg_B_09', digits_hdg.value.charAt(1) == 9);

geom.set_mesh_visible('MFD9_hdg_C_00', digits_hdg.value.charAt(2) == 0);
geom.set_mesh_visible('MFD9_hdg_C_01', digits_hdg.value.charAt(2) == 1);
geom.set_mesh_visible('MFD9_hdg_C_02', digits_hdg.value.charAt(2) == 2);
geom.set_mesh_visible('MFD9_hdg_C_03', digits_hdg.value.charAt(2) == 3);
geom.set_mesh_visible('MFD9_hdg_C_04', digits_hdg.value.charAt(2) == 4);
geom.set_mesh_visible('MFD9_hdg_C_05', digits_hdg.value.charAt(2) == 5);
geom.set_mesh_visible('MFD9_hdg_C_06', digits_hdg.value.charAt(2) == 6);
geom.set_mesh_visible('MFD9_hdg_C_07', digits_hdg.value.charAt(2) == 7);
geom.set_mesh_visible('MFD9_hdg_C_08', digits_hdg.value.charAt(2) == 8);
geom.set_mesh_visible('MFD9_hdg_C_09', digits_hdg.value.charAt(2) == 9);

if (digits_hdg.str_length <= 2)geom.set_mesh_visible('MFD9_hdg_A_00', false);
if (digits_hdg.str_length <= 1)geom.set_mesh_visible('MFD9_hdg_B_00', false);
}


[Uriah]

Nice, condensed all that into the function and called the geoms from update. Very nice.

Hopefully it won't be much longer we'll have to use such a hack. With render to texture API and the 3d cockpit manipulators, extended controls, lights and emissive textures, MFDs, HUDs, will be functionally complete. Then we just have to figure out how to slip the .js scipt into multiple files, so we can have MFD_display.js and include that in aircraft.js so the MFD script can be plugged into any mod easily.

Does anyone know how to include a second javascript, called from the first? I know it should be possible, no different than web pages including multiple javascript files to control the css style sheet containing the html content. When the computer executes the script, the include should just extend the original script, like it is inserted at the include line. It might be an OT side limitation. We can include many .xml files in the FDM as Systems. I need to be able to do that with the script.

Thanks for posting that Levi!

Best regards,
Uriah

[Levi]

Yes, hopefully render to texture API will be ready sooner than later, so that this kind of hacks are no longer needed.
I like the idea of modularity. And reusing pieces of code is always a good thing.

I think it's not possible to include a second javascript at this moment without official implementation, but I hope I'm wrong.
For very long scripts, splitting them into several parts would be very useful, so all can be more clean and organized. Just as you already can do with the FDM.

[SteelRat]

Yes, hopefully render to texture API will be ready sooner than later, so that this kind of hacks are no longer needed.
I like the idea of modularity. And reusing pieces of code is always a good thing.

I think it's not possible to include a second javascript at this moment without official implementation, but I hope I'm wrong.
For very long scripts, splitting them into several parts would be very useful, so all can be more clean and organized. Just as you already can do with the FDM.

Code: [Select]

$include("path/script.js");
The only problem for the folder "Outerra/TerrainData" you must specify a full path "E:/Outerra/TerrainData".
I want to hear from the developers about the magical way) to get the path to the custom folder.

[cameni]

We actually want to avoid dependency and version hell that would be introduced by allowing includes outside of the package file. I'll rather optimize loading of scripts (if they have the same content), but you should not expect the $include to work with stuff outside the package.

Does anyone know how to include a second javascript, called from the first? I know it should be possible, no different than web pages including multiple javascript files to control the css style sheet containing the html content. When the computer executes the script, the include should just extend the original script, like it is inserted at the include line. It might be an OT side limitation. We can include many .xml files in the FDM as Systems. I need to be able to do that with the script.

I haven't tested it, I assumed that $include would work from nested includes as well. Beware it's not exactly the same thing as a C-style include - Javascript must parse the file first, and only when it then executes the $include statement, it will add the content of the included file, parse and execute it. I'm now not entirely sure what's the actual order of all parse-execute operations during a nested include.

[SteelRat]

We actually want to avoid dependency and version hell that would be introduced by allowing includes outside of the package file. I'll rather optimize loading of scripts (if they have the same content), but you should not expect the $include to work with stuff outside the package.

Does anyone know how to include a second javascript, called from the first? I know it should be possible, no different than web pages including multiple javascript files to control the css style sheet containing the html content. When the computer executes the script, the include should just extend the original script, like it is inserted at the include line. It might be an OT side limitation. We can include many .xml files in the FDM as Systems. I need to be able to do that with the script.

I haven't tested it, I assumed that $include would work from nested includes as well. Beware it's not exactly the same thing as a C-style include - Javascript must parse the file first, and only when it then executes the $include statement, it will add the content of the included file, parse and execute it. I'm now not entirely sure what's the actual order of all parse-execute operations during a nested include.

I have a big request, not remove it. I plan to actively use it. I'll let you know about the problems, if they will.

[cameni]

Problems will follow soon on their own

Any dependency on other packages or modules is asking for trouble in the future. Packages should contain everything they need, and not be dependent on other data that may be updated or removed independently. Includes are for better structuring of the code within the package.

[SteelRat]

Problems will follow soon on their own

Any dependency on other packages or modules is asking for trouble in the future. Packages should contain everything they need, and not be dependent on other data that may be updated or removed independently. Includes are for better structuring of the code within the package.

OK, you here the God creator!)

[Uriah]

Works for me! Thanks for the info Cameni.

Regards,
Uriah