Leavu+ERI 2.1 release

[questerymj]

Thanks for reply so quick Yoda. /bow

 

These monitor use only 1 USB cable to powered and connect with PCs. Not DVI or VGA.

 

They use displaylink chip as adapters, display 2d only and cannot display any 3D acceleration generated output. Thet are functional limited but easy to setup because you only need 1 USB cable.

 

I can use them for Open Falcon MFD exporter (2D cockpit capture and 3D pit output worked) and display shakvl/Abris for Blackshark. I just think if you can add a process to make them into 2D graphic every frame like the 2nd monitor outut in BS, they can be display in these monitor.

[Moa]

Awesome. It is excellent to see that LEAVU has been put to use on a Linux server as well as the usual Windows clients. Thanks for posting here alpha_VTFS161.

 

It is a bit of a relief knowing that the extra effort of going OpenGL was worth it. I'd feel pretty bad having suggested this and then no-one used it. I always reckon portability gives uses more options, but there can be downsides (beautiful looking but crappy speed of text rendering in Java 2D is one).

 

One more feather in LEAVU2's cap and another well done to Yoda.

Edited November 18, 2010 by Moa

[Haggart]

While in training this evening, I'd trouble with Leavu (clicking the "Add instrument" button crashed Leavu). After an hour, I traced back the error now to WindowBlinds - deactivating it solves the case. Perhaps we could add to the doku that Leavu is incompatible to Wb...?

[questerymj]

I'd self-resloved my problem with usb-powered monitors.

 

Looks like I need to run LEAVU and FC2 under windows7. Even I installed the newest driver from displaylink LEAVU still doesn't rendering graphics under XP 32bit, but it works under W7 64bit like magic! Thanks for great work Yoda!

[RvEYoda]

While in training this evening, I'd trouble with Leavu (clicking the "Add instrument" button crashed Leavu). After an hour, I traced back the error now to WindowBlinds - deactivating it solves the case. Perhaps we could add to the doku that Leavu is incompatible to Wb...?

 

I think we really need to replace the graphical engine of leavu2...it is getting too messy :). Users shouldnt have to mess around with dlls...

Especially since the system it was developed for (JOGL 1) is no longer maintained by its developers

 

If anybody has any suggestions for a fast 2d or 3d system which can be placed in an AWT window then that would be where we could start.

Basically what i need to be able to do is :

 

- For 2d instruments: 2D rendering with the ability to draw primitives

- For 3d instruments: 3D rendering similar to OpenGL or Direct3D, ability to draw primitives, basic shadows and lighting

- Being able to run very high fps (60+) with low cpu hit (<1% cpu for 50-100 objects on screen)

- Not having to load any dlls explicitly (tiring for the installation and annoying with 64bit JVMs!)

- 2d and 3d renderers can be entirely different, we can replace the 2d one to begin with.

- Must run on linux and windows.

Edited January 19, 2011 by =RvE=Yoda

[Moa]

Hi Yoda, good to see you're around again.

 

Users don't have to mess around with DLLs if you bundle a 'fatjar'. The DLLs are still there, but bundled inside the single executable program.

 

While I didn't need DLLs, I did use a fatjar for lottu (http://stallturn.com/wiki/en/lottu).

 

I then used JSmooth (http://jsmooth.sourceforge.net/) to create a single exe for Windows users (Linux/Mac users [eg. me] that alter the tracks [even if they can't play them] can cope with a jar). I also used JSmooth to create the 'dynamicscore2' collector program that can be installed on LockOn game servers (used on stallturn for VNAO stats and the 104th Phoenix server stats, http://stallturn.com/104th/) as the single file is easy to install (known as 'xcopy installation' in the Windows world as you can simply do a file copy to install it).

 

For an example of a JAR that bundles DLLs for different operating systems within it see the JNA (Java Native Access) library.

 

ps. If it was me I'd be using Swing and doing optimizations (eg. caching rendered text that changes far more slowly than 60 fps, and then using the dozens of hardware accelerated texture compositing units built into modern GPUs) rather than using awful AWT (although good for brute-force rendering at 60 fps) that has a lot of cross-platform issues.

 

pps. I have some altered LEAVU2 LUA export scripts and modded LEAVU code that allows access to flaps, hook, gear, canopy and speedbrake status. I used this to make a little Angle-of-Attack control and mechanical status panel for when I do US-style carrier landings with VNAO. The controls are ugly as I never got around to skinning it, but I should commit the code as it might be handy for pit-builder.

 

Finally, Integrity Checking has pretty much been standardized on most of the more popular LockOn servers. Due to a potential exploit in LockOn exports and fact that new users could not connect using a default installation of LockOn if they have the LEAVU export scripts you'll find that most servers effectively prohibit the use of LEAVU (naturally, for my purposes my stallturn server does allow its use, but instead requires the VNAO mod).

Edited January 19, 2011 by Moa

[RvEYoda]

I'm also hoping to get away from old JOGL1 unsupported(by original devs) dlls, who knows what will happen in the future.

Whether it's swing or awt i dont really care much about tbh :).

 

Also the JOGL1 stuff doesnt run well with either AWT or swing once you reach a lot of open windows (starts being a problem at 20-100 depending on what kind of system you are running, even with the simplest helloWorld JOGL+swing/awt windows)

[Moa]

http://jogamp.org/ is where the action has migrated to.

 

You could also try JMonkey Engine ot LWJGL (or one of the other number of libraries for Java over OpenGL), although they're more scenegraph oriented. One benefit of JoGL is that it is close to the C API, which means there is a large number of © tutorials, samples and documentation and are straightforward to get working.

[SilentEagle]

I have some altered LEAVU2 LUA export scripts and modded LEAVU code that allows access to flaps, hook, gear, canopy and speedbrake status. I used this to make a little Angle-of-Attack control and mechanical status panel for when I do US-style carrier landings with VNAO.

 

Funny, I'm doing something similar with a few more outputs for my own personal program. Thanks to Yoda, it should actually become reality.

[RvEYoda]

http://jogamp.org/ is where the action has migrated to.

 

You could also try JMonkey Engine ot LWJGL (or one of the other number of libraries for Java over OpenGL), although they're more scenegraph oriented. One benefit of JoGL is that it is close to the C API, which means there is a large number of © tutorials, samples and documentation and are straightforward to get working.

 

Yeah but the new JOGL 2-api is completely different......from what I understand remade from scratch :P......

Maybe better to leave leavu as it is, due to the low demand.

[Moa]

Well, OpenGL 3 and later have changed (more shaders and less fixed-function pipeline stuff, finally eliminated in OpenGL 4) so it follows that JoGL also had to change.

 

I don't think LEAVU needs customized shaders for its 3D stuff so OpenGL 2 or lower should be perfectly fine.

[vippen]

hi,

i try to install leavu on two pc but it's very hard

could you help me to install it?

[RvEYoda]

Been thinking a bit about making a new (far more capable mostly for coop) leavu and migrating to JOGL 2, however JOGL 2 seems to have the same multi-window issues as JOGL 1 (but even worse!)

 

http://forum.jogamp.org/Crash-when-creating-more-than-15-jogl-awt-windows-td3054540.html

 

An option tbh would be to use a pure-java rendering canvas for all 2d instrument and only use jogl for 3d. Another option would be to use C++/d3d like I did a long time ago, but that would be a pain for data serialization, compatibility, byte orders, threading, yada yada..

[Moa]

By 'pure-java' rendering do you mean Java2D? This is fully hardware accelerated (DirectX or OpenGL depending on the platform) and does not require JoGL (although can mix rendering with JoGL).

 

One thing Leavu2 could do is remember the aircraft state and only render when the state changes rather than every frame. The aircraft mechanical state changes relatively slowly so this is a good optimization. This would help with the load.

[RvEYoda]

By 'pure-java' rendering do you mean Java2D? This is fully hardware accelerated (DirectX or OpenGL depending on the platform) and does not require JoGL (although can mix rendering with JoGL).

 

One thing Leavu2 could do is remember the aircraft state and only render when the state changes rather than every frame. The aircraft mechanical state changes relatively slowly so this is a good optimization. This would help with the load.

 

By pure java I mean not having to include any other jar/dlls than what comes with the standard oracle jres.

 

It's not a load issue moa, Just creating blank AWT+JOGL2 windows will cause JOGL to crash above 15-20 or so windows on a high end machine. I just used the most basic example, see the post I linked to above. (just copy paste the code and try it :))

 

I am thinking java2d can be a decent choice and then limit 3d windows to let's say 5 or 10 for JOGL stuff.

[RvEYoda]

Moa try this below:

(change number of windows if you like, 25 should be enough for a crash in JOGL 2).

In JOGL 1 I can do about 50 windows. Memory is not the issue, you can give the vm

as much as u want and it wont change a thing.

In C++/D3D I could do well above 100 and it still wasn't anywhere near crashing.

 

/************ HELLOJOGL.java *********/

package hellojogl;

import javax.media.opengl.GLCapabilities;
import javax.media.opengl.GLProfile;

public class HelloJogl {

   public static void main(String[] args) throws InterruptedException {

       GLProfile.initSingleton(false);
       final GLCapabilities glcapabilities = new GLCapabilities(GLProfile.getDefault());
       for (int i = 0; i < 25; i++) {
           new OneTriangleAWT(glcapabilities);
       }

   }
}



/******** OneTriangleAWT.java*******/


package hellojogl;

import javax.media.opengl.GLAutoDrawable;
import javax.media.opengl.GLEventListener;
import javax.media.opengl.GLCapabilities;
import javax.media.opengl.awt.GLCanvas;

import java.awt.Frame;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;

import javax.media.opengl.GL;
import javax.media.opengl.GL2;
import javax.media.opengl.glu.GLU;

public class OneTriangleAWT {

   final GLCanvas glcanvas;

   public OneTriangleAWT(final GLCapabilities glcapabilities) {

       glcanvas = new GLCanvas(glcapabilities);
       glcanvas.addGLEventListener(new GLEventListener() {

           @Override
           public void reshape(GLAutoDrawable glautodrawable, int x, int y, int width, int height) {
               OneTriangle.setup(glautodrawable.getGL().getGL2(), width, height);
           }

           @Override
           public void init(GLAutoDrawable glautodrawable) {
           }

           @Override
           public void dispose(GLAutoDrawable glautodrawable) {
           }

           @Override
           public void display(GLAutoDrawable glautodrawable) {
               OneTriangle.render(glautodrawable.getGL().getGL2(), glautodrawable.getWidth(), glautodrawable.getHeight());
           }
       });

       final Frame frame = new Frame("One Triangle AWT");
       frame.add(glcanvas);
       frame.addWindowListener(new WindowAdapter() {

           public void windowClosing(WindowEvent windowevent) {
               frame.remove(glcanvas);
               frame.dispose();
               System.exit(0);
           }
       });

       frame.setSize(640, 480);
       frame.setVisible(true);

   }

   public static class OneTriangle {

       protected static void setup(GL2 gl2, int width, int height) {
           gl2.glMatrixMode(GL2.GL_PROJECTION);
           gl2.glLoadIdentity();
           GLU glu = new GLU();
           glu.gluOrtho2D(0.0f, width, 0.0f, height);
           gl2.glMatrixMode(GL2.GL_MODELVIEW);
           gl2.glLoadIdentity();
           gl2.glViewport(0, 0, width, height);
       }

       protected static void render(GL2 gl2, int width, int height) {
           gl2.glClear(GL.GL_COLOR_BUFFER_BIT);
           gl2.glLoadIdentity();
           gl2.glBegin(GL.GL_TRIANGLES);
           gl2.glColor3f(1, 0, 0);
           gl2.glVertex2f(0, 0);
           gl2.glColor3f(0, 1, 0);
           gl2.glVertex2f(width, 0);
           gl2.glColor3f(0, 0, 1);
           gl2.glVertex2f(width / 2, height);
           gl2.glEnd();
       }
   }
}

[RvEYoda]

Problem solved. Now got 150 or so opengl windows through jogl2 from 1 single application.

There might yet be hope for some new development...

[Moa]

Almost missed this! I'm curious what the issue was Yoda, I'd like to avoid the issue, whatever it was.

[Cali]

That would be nice to see this allowed in multiplayer. Maybe the 104th will add it since the Su-27 have R-77 and the Migs can fire AIM-120's :lookaround:. As long as the online security thing is good.

[RvEYoda]

Well if I develop a new version it will be a highly experimental one with VERY overpowered features (take it as far as possible with the data given), so mostly for special coop and pre-decided events/special servers. I doubt normal servers would allow it :)

 

The previous versions of leavu were very toned down compared to what u could make of pure own-sensor data, in the attempt to make some online servers accept it, but since that didn't cut it anyway for public servers..... Maybe it's time to make something with a bit of power!

 

I would probably also screw around with weapon ranges/radar numbers if I can find any files that allow me to do such. (Such modifications however would not work on any online servers even if u tried to, so theyre only for private/coops/events)

 

Almost missed this! I'm curious what the issue was Yoda, I'd like to avoid the issue, whatever it was.

 

http://forum.jogamp.org/Crash-when-creating-more-than-15-jogl-awt-windows-td3054540.html

 

bottom 5 posts

Edited June 23, 2011 by =RvE=Yoda

[alpha_VTFS-161]

=RvE=Yoda, if you reconstruct LEAVU,

 

could you integrate an air-to-air TACAN?

All position datas should be there in the data excange between the a/c.

There must be only an panel for control the TACAN transmitter and the TACAN receiver and a field for display the distance in the MFD.

I thing this feature will help all pilots to fly a better formation like in the real live.

 

Regards, Alpha

Edited July 1, 2011 by alpha_VTFS-161
forgot something

[RvEYoda]

=RvE=Yoda, if you reconstruct LEAVU,

 

could you integrate an air-to-air TACAN?

All position datas should be there in the data excange between the a/c.

There must be only an panel for control the TACAN transmitter and the TACAN receiver and a field for display the distance in the MFD.

I thing this feature will help all pilots to fly a better formation like in the real live.

 

Regards, Alpha

 

I'm curious, what sorts of instrument would you use to display the data?

The current datalink in leavu, any specific reason you would like a tacan-ish implementation instead? (the datalink is much more powerful :)

[alpha_VTFS-161]

Hi,

as far as I know all modern generation fighter are equipped with an air-to-air TACAN transmitter. And as well they use the "normal" TACAN receiver for air-to-air ranging.

Display should not the problem. In the upper part of the MFD in RADAR mode is enough space to place two fields, one for direction and one for range to the transmitter.

As an further step you could integrate an ground-to-air TACAN to get direction/range from an airbase. So its easier to get that information than clicking trough the in build solution.

And I would like to have an in cockpit editable bullseye to avoid the use of only a way-point as bullseye.

By the way, I am unable to get an accurate idea how far my wingman is away from me (normally you should get it +- 0.1 NM), if I'm in a 80 NM RADAR scope and use only the link feature.

I know there are a lot of wishes at once but these are some steps to approach the simulation of the real F-15C.

 

Regards Alpha

Edited July 3, 2011 by alpha_VTFS-161
fix orthography

[RvEYoda]

Hi,

as far as I know all modern generation fighter are equipped with an air-to-air TACAN transmitter. And as well they use the "normal" TACAN receiver for air-to-air ranging.

Display should not the problem. In the upper part of the MFD in RADAR mode is enough space to place two fields, one for direction and one for range to the transmitter.

As an further step you could integrate an ground-to-air TACAN to get direction/range from an airbase. So its easier to get that information than clicking trough the in build solution.

And I would like to have an in cockpit editable bullseye to avoid the use of only a way-point as bullseye.

By the way, I am unable to get an accurate idea how far my wingman is away from me (normally you should get it +- 0.1 NM), if I'm in a 80 NM RADAR scope and use only the link feature.

I know there are a lot of wishes at once but these are some steps to approach the simulation of the real F-15C.

 

Regards Alpha

 

I'm not sure I'm following you alpha or if you have seen what leavu is. Maybe you have. Leavu is just a software for external instruments. I can't change anything about how the game works.

 

I export own instrument (only) data from the game and then display on external monitors. I can't actually edit something that is in the ingame cockpit. Now maybe you already realized that, please send me a PM or contact me on msn if you think we could still work something out from that. (Forums = too slow and too much confusion)

[RvEYoda]

Hi,

as far as I know all modern generation fighter are equipped with an air-to-air TACAN transmitter. And as well they use the "normal" TACAN receiver for air-to-air ranging.

Display should not the problem. In the upper part of the MFD in RADAR mode is enough space to place two fields, one for direction and one for range to the transmitter.

As an further step you could integrate an ground-to-air TACAN to get direction/range from an airbase. So its easier to get that information than clicking trough the in build solution.

And I would like to have an in cockpit editable bullseye to avoid the use of only a way-point as bullseye.

By the way, I am unable to get an accurate idea how far my wingman is away from me (normally you should get it +- 0.1 NM), if I'm in a 80 NM RADAR scope and use only the link feature.

I know there are a lot of wishes at once but these are some steps to approach the simulation of the real F-15C.

 

Regards Alpha

 

I'm not sure I'm following you alpha or if you have seen what leavu is. Maybe you have. Leavu is just a software for external instruments. I can't change anything about how the game works.

 

The game exports instrument/sensor data and then I display this on external monitors. I can't actually edit something that is in the ingame cockpit. Initially i did include a bit more capability than leavu currently has but a lot of people got frustrated since they felt it made the f-15 overpowered in the game. In order to emulate the behaviour of a datalink, I wrote a server software which my external instrument software could connect to, thus different leavu users could share their own instrument and sensor data. This can be made precise enough to 1 m (or better ;)) , but for the similar reasons as previously (people complained) I chose to have it update only 1/second. It should however be good enough for precision better than 0.5 nm. Possibly 0.1.

Edited July 3, 2011 by =RvE=Yoda